Fix Slow Sites: Speed Wins You More Leads.

If your website feels slow on your phone while you are standing in town, it is slow. That is the test that matters for Bay of Plenty businesses. People are usually on mobile data, half-distracted, and ready to leave if the page hesitates. Speed is not a technical vanity metric - it directly affects enquiries, bookings, and trust.

This is a practical guide to how to improve website loading speed without turning your business into a software project. Work top-down: measure, remove obvious weight, tighten delivery, then keep it fast with monitoring.

Start with proof, not opinions

Before you change anything, capture a baseline. You want repeatable numbers so you can tell which change helped and which one did nothing.

Use a speed test that reports Core Web Vitals and a waterfall view of requests. Test your homepage and at least one high-intent page (service page or booking/contact page). Run each test on mobile settings and do it a few times.

Pay attention to three signals, because they translate well to real user experience: LCP (how quickly the main content shows), INP (how responsive the page feels when tapped), and CLS (whether the layout jumps around). If you can improve LCP without damaging INP, you usually win.

The trade-off: chasing a perfect score can waste time. You are aiming for consistent fast loads on typical NZ connections, not a trophy.

Fix the biggest weight first: images

Most slow small-business sites are image-heavy. That includes hero banners, sliders, background images, and “just in case” gallery photos.

Start by checking your largest images. If you see 2-6 MB uploads, that is the first fix. Resize images to the maximum size they are displayed at (plus a bit for high-density screens), then compress properly. Use modern formats where possible. WebP is usually the sweet spot for browsers, and AVIF can be even smaller but is not always worth the extra complexity.

If your site is WordPress, image optimisation can be handled through a plugin, but do not assume the defaults are correct. Check what it is producing and confirm it is serving the optimised file, not the original.

Lazy loading should be on for below-the-fold images. Do not lazy load the main hero image if it is the LCP element - that often makes things worse.

The trade-off: aggressive compression can make logos and text inside images look fuzzy. If your logo is an image, make sure it stays crisp. Better yet, use SVG for simple logos and icons.

Cut page bloat: fewer sections, fewer widgets

Speed work is often content work. If your homepage has a slider, three different carousels, animated counters, video backgrounds, and eight different fonts, it will load like a brochure, not a tool.

Ask one question per page: what action do you want the visitor to take? Then remove anything that does not support it.

Carousels are a common culprit. They add scripts, extra images, and layout work. Most visitors do not wait for slide two anyway.

Embed videos carefully. A full video embed can pull in heavyweight scripts. If the video is useful, consider a click-to-play thumbnail approach so the scripts load only when needed.

The trade-off: stripping features can feel like you are “removing value”. In practice, a faster page with a clearer call-to-action converts better.

Hosting and server response: you cannot cache your way out of a weak foundation

If Time To First Byte is consistently high, you are waiting on the server. This is common on crowded shared hosting or with misconfigured stacks.

For WordPress and OctoberCMS, you want a stable server configuration, up-to-date PHP, and sensible resource allocation. If your site is on cheap hosting and you are running multiple plugins, page builders, and heavy database queries, you will feel it.

Check for:

• Old PHP versions
• Slow database response
• Too many server-side redirects
• No full-page caching

If you are using DigitalOcean with proper server management, you can generally get fast, predictable performance, but configuration still matters. A clean stack with caching and correct headers will beat a bigger server that is poorly tuned.

The trade-off: moving hosts is disruptive. Do it when you have a clear reason, not as a first guess.

Caching: do it in layers

Caching works best when it is layered. Each layer reduces work somewhere in the chain.

Browser caching is the simplest win. Set long cache lifetimes for assets that do not change often (images, fonts, CSS, JS). If you version your assets (for example, style.css?v=123), you can safely cache for longer because updates will change the version.

Full-page caching is next. For many small-business sites, most pages do not change per visitor. Serving pre-built HTML is much faster than generating it on every request.

Then add edge caching via a proxy CDN. If you are using Cloudflare, configure caching rules sensibly. Cache static assets aggressively and consider caching HTML for pages that are safe to cache. Make sure admin areas and personalised content are excluded.

The trade-off: caching can cause “why is my change not showing?” issues. The fix is process: purge caches when deploying changes, and keep a clear rule set so you do not accidentally cache forms or checkout states.

Reduce scripts and stop loading everything on every page

Most sites load too much JavaScript. Each extra script adds download time, parsing time, and potential delays to interactivity.

Audit what is loading. If you have five marketing tags, three chat widgets, a map embed, and multiple analytics tools, your visitors are paying for them with time.

Remove tools that are not being used. Then make sure the remaining scripts load efficiently. Deferring non-critical scripts so the browser can render content first. Avoid blocking scripts in the head unless they are genuinely required to display the page correctly.

Be especially careful with:

• Page builder addons
• Slider libraries
• Heavy form plugins with extra tracking
• Old theme bundles that include everything

The trade-off: some third-party scripts are business-critical (call tracking, booking tools). Keep them, but load them only on the pages that need them.

Fonts: fewer files, fewer weights

Web fonts can quietly slow a site. Multiple font families and weights mean multiple downloads, and fonts can delay text rendering.

Use one or two font families. Limit weights (for example, regular and bold). Host fonts locally where appropriate so you are not waiting on an external provider. Set font-display to swap so text appears quickly, even if the font loads slightly later.

The trade-off: swapping can cause a momentary style change. For most users, readable text now beats perfect typography later.

CSS: ship less, and only what you use

Large CSS bundles are common with themes and page builders. The browser has to download and process all of it, even if your page uses a small portion.

If you can, reduce template complexity and standardise components so you are not generating unique CSS per page. Remove unused CSS where practical, and avoid stacking multiple design systems (theme CSS plus builder CSS plus custom CSS plus plugin CSS).

The trade-off: CSS cleanup is fiddly. If you are not careful, you can break layouts. Make changes in a staging environment and test on mobile, tablet, and desktop.

Database and CMS housekeeping

For WordPress, the database can accumulate clutter: post revisions, transients, old plugin tables, and spam. A slow database means slower page generation.

Keep plugins lean. Every plugin is code you now have to maintain and test. If a plugin duplicates a feature already provided by your theme or platform, remove it.

For OctoberCMS, keep the core and plugins updated and watch for slow components, unoptimised queries, and oversized media libraries.

The trade-off: updates can introduce conflicts. That is why scheduled updates and rollback plans matter more than “update whenever you remember”.

Measure again, then lock it in

After each meaningful change, re-test the same pages. If LCP improved but INP got worse, you probably reduced image weight but added script work elsewhere. If CLS got worse, you might have introduced lazy-loaded elements without reserving space.

Once you have a clear improvement, keep it that way with a basic maintenance loop: uptime monitoring, performance checks, and regular updates. This is where most sites backslide - a new plugin gets added, a new tracking tag appears, images get uploaded straight from a phone, and six months later the site is sluggish again.

If you want this managed as an ongoing process rather than a one-off clean-up, Responsive builds and maintains WordPress and OctoberCMS sites with Cloudflare in front, DigitalOcean infrastructure, and scheduled update workflows designed to keep performance stable.

Common “it depends” scenarios

Some speed fixes are not universal.

If you run a booking system or eCommerce, caching rules need to be tighter. You can still cache most content, but cart and account flows must stay dynamic.

If your customers are mostly rural or travelling, mobile performance matters more than desktop scores. Test on mobile first.

If you rely on Google Maps embeds, chat widgets, or social feeds, accept that these tools have a cost. Your job is to control where they load and whether they block the main content.

If your site is already fast but conversions are weak, speed is not the bottleneck. Do not keep shaving milliseconds if the page structure, offer, or call-to-action is unclear.

How to improve website loading speed without breaking your site

The safest approach is simple: change one variable at a time, test, then keep going. Start with images and obvious bloat, then address caching and scripts, then move deeper into CSS and server tuning.

If you do nothing else, do this: compress and correctly size images, remove unnecessary plugins/widgets, enable sensible caching, and stop loading third-party scripts site-wide by default. That combination is usually enough to turn a slow site into one that feels quick on a phone.

Your closing test is practical: open the site on mobile, tap a service page, scroll, and hit the contact button. If it reacts immediately and nothing jumps around, you have removed friction where it counts - right before the enquiry.