Web DesignPerformance

Why Your Website Is Slow, and What Fixes It

Kage Works12 August 20268 min read

Your host has a plan two tiers up that promises faster pages. It buys processor time and memory, and your site is unlikely to be short of either.

Two things slow down a small business website in New Zealand. The first is distance: your customer in Hamilton waits while bytes travel to wherever the site lives. The second is work: the browser has to download and run everything you put on the page before it can show anything useful. A larger plan on the same server in the same city pays neither bill.

Name the symptom before you spend

"Slow" describes two different faults with different fixes.

One is a page that sits blank or half-drawn while the main image or headline arrives. Google measures that as largest contentful paint, and treats 2.5 seconds or less as good at the 75th percentile of real page views (web.dev).

The other is a page that has drawn itself and then ignores you. Tap the menu, wait, tap again. That one is interaction to next paint, good at 200 milliseconds or less. Content that jumps under your thumb is a separate measurement, cumulative layout shift, which irritates your customers without slowing anything down.

Both show up in PageSpeed Insights, in the field data section rather than the large lab score at the top. Our article on what to ask a web design agency covers why that section beats the lab score for deciding anything.

The seconds go to waiting, not downloading

Largest contentful paint breaks into four phases: time to first byte, the delay before the browser starts fetching the main element, the time spent fetching it, and the delay before it paints.

Chrome's own analysis of field data found that on pages with poor LCP, the browser waits 1,290 milliseconds at the 75th percentile before it starts loading the LCP image, close to four times what the download itself takes (web.dev). Compressing that image attacks the smaller number.

Around three quarters of mobile pages have an image as the largest element, and preload, the markup that tells the browser about a file early, appears on about 2% of pages (HTTP Archive Web Almanac 2025). Four things create that wait on a typical NZ business site:

A plugin applying loading="lazy" to every image, including the hero. Lazy loading hides the image from the browser's preload scanner, so discovery waits for layout.
A hero inside a slider or carousel. The image URL lives in JavaScript, so the browser learns about it after downloading and running the script that builds the slider.
A hero set as a CSS background. The browser finds it after parsing the stylesheet rather than while reading the HTML.
Render-blocking fonts and stylesheets queued ahead of the image.

The fix costs a few lines. Put the hero in the HTML as a real <img> with width and height set, take the lazy attribute off it, and add fetchpriority="high". Adoption of that attribute reached 17.3% of mobile pages in 2025, most of it arriving when WordPress added it to core (Web Almanac), so a WordPress site on a current version may have this handled already.

Distance costs more from New Zealand

Southern Cross, which operates the cables carrying most of our traffic to the Americas, publishes one-way latency for its network at around 63 milliseconds between New Zealand and the United States (Southern Cross). Call it 130 milliseconds for a round trip.

You pay that round trip more than once. Before your server sees the request, the browser resolves DNS, completes a TCP handshake, then completes a TLS handshake. Each leg crosses the Pacific. A site sitting on a US server therefore starts several hundred milliseconds behind one in Auckland, and a redirect from the www version to the bare domain buys another full round trip.

Two things changed the options here. Cloudflare runs a point of presence in Auckland, peering with local providers from inside the facility most of them use (Cloudflare). AWS opened its Asia Pacific (New Zealand) Region in Auckland in August 2025 with three availability zones, after first announcing it in 2021 (Amazon). Local origins and local edges are both ordinary purchases now.

Distance is worth fixing, with one limit worth knowing before you pay to move a server. Distance shows up in time to first byte, which web.dev suggests keeping to 800 milliseconds or less (web.dev) and budgets at roughly 40% of a good LCP (web.dev). Cutting TTFB from 900 to 200 milliseconds takes a real 700 milliseconds off every page. It does nothing about the other three phases.

A CDN buys the same proximity for a fraction of a migration, and most sites skip it: about a third of HTML documents came from a CDN in the 2025 crawl, the lowest share of any content type (Web Almanac). Read the fine print on the free tiers, because a CDN caches your images, CSS and JavaScript at the edge by default while still fetching the HTML from your origin. A slow CMS stays slow until you cache the pages too.

The case where your host is right

Sometimes the server is the problem, and it has a signature. Load your site on a quiet Tuesday morning with no traffic on it and check TTFB. Above 1.8 seconds counts as poor by web.dev's threshold, and on an idle site that points at a content management system running database queries for every visitor rather than a shortage of CPU.

Page caching fixes that, and every major CMS has it. A bigger plan does earn its money in one situation: your site is fine at 10am and slow during a sale, which means you are running out of capacity at peak. Measure at the hour it hurts, not the hour that suits you.

Everything marketing added last year

92% of pages load at least one third-party resource, and 67.7% of the 15.78 million sites in the December 2025 HTTP Archive crawl request at least one third party that blocks rendering (Web Almanac). The median mobile page in that crawl spends 1,916 milliseconds with its main thread blocked, against the 200 millisecond guideline (Web Almanac).

On a plumber's or a restaurant's site, those third parties have names: a booking widget, live chat, a Meta pixel, a reviews carousel, a tag manager container, a cookie banner, a font provider. Each one runs JavaScript on the same main thread that has to answer the customer tapping your menu button, which is where the second symptom comes from.

Open the network panel and list every domain your page contacts. For each one, write down the person who asked for it and what it returns. Delete the ones missing either answer. Load live chat when someone clicks the bubble rather than on page load, and self-host your fonts so a second connection to another provider never blocks your text.

Spend in this order

Delete the third-party scripts nobody owns, and defer the rest. An hour of work, no ongoing cost, and the tapping symptom improves the same day.
Fix the largest element: a real <img> in the HTML, no lazy attribute, high fetch priority, dimensions set, served as WebP or AVIF. Usually half a day.
Put a CDN in front of the site and enable page caching in your CMS. Free to about $30 a month.
Cache at the origin if your CMS builds pages per request.
Move or upgrade the server last, once you have measured TTFB and know what you are buying.

Steps one and two cost the least and move the most on a typical small business site. Hosts pitch step five first, because it carries a monthly invoice.

A twenty minute check

Take your highest-traffic page and run it through PageSpeed Insights on mobile. Read the field data at the top, then find the LCP element audit and look at which of the four phases holds the seconds. Load delay points at your image markup. Time to first byte points at hosting or caching.

Then open the page in Chrome with DevTools on the network tab, tick "disable cache", reload, and sort by domain. The count of domains that are not yours is the number you can cut without a developer.

Re-run the same page a week after each change. The Chrome UX Report behind that field data covers a rolling 28-day window, so the numbers from real visitors lag your fix by weeks even when the lab score jumps the same day.

If the audit turns up a site that needs rebuilding rather than tuning, our comparison of Squarespace, Webflow and custom builds covers where each platform's performance ceiling sits.