Why websites are slow

Most slow Australian small-business websites are slow for the same five reasons, and none of the five are mysterious. The reason speed problems persist is not that they are hard to diagnose. It is that the causes are decided at build time by people who are not measured on them, and discovered later by an owner who has no way to attribute the problem.

What follows is ordered by how often each turns out to be the cause. That ordering is a judgement formed from doing this work, not a survey, and it should be read as a place to start looking rather than as a statistic.

1. Images that are far larger than they are displayed

This is the most common cause, and on many sites it is the only one that matters.

The mechanism is simple. A photograph is uploaded at the resolution it came off a camera, a phone or a stock library. It is displayed in a space a fraction of that size, particularly on a phone. The browser downloads the entire file, decodes it, and then throws most of the pixels away. On a good connection the waste is invisible. On mobile data outside a metro area, that one file can dominate the entire experience of the page.

Two secondary versions of the same problem: images saved in formats chosen a decade ago, when better ones now exist; and a single image served to every screen, so a phone downloads the file that was sized for a desktop monitor. Both are covered in images and formats.

It is the top of this list because it is simultaneously the most common and the cheapest to fix. It requires no redesign, no platform change and no argument about architecture.

2. Third-party scripts

Every chat widget, tag manager, heat-map recorder, review carousel, consent tool, remarketing pixel, A/B testing tool and duplicate analytics package is code from someone else’s server, fetched over someone else’s connection, executing on your visitor’s device.

Each one costs three separate things: a network request that your page may wait on, download and parse time, and main-thread execution time that blocks the page from responding to taps. That last cost is why script bloat shows up in Interaction to Next Paint as well as in load time, explained in interaction to next paint.

They accumulate invisibly. A tag manager looks like one script in the page source and is a container for however many tags have been added over three years by three different marketing people, most of whom no longer work there. Nobody removes them because nobody is certain what would break.

The test is not technical. Every third-party tool on the site should have a named person who can say what it is for and what decision it informs. The ones that fail that test are the cheapest performance improvement available anywhere, because deleting code is free and always works.

3. Page builders that ship bulk

Visual page builders trade build speed for delivered weight. That trade is often the right one commercially, and it is a real trade rather than a defect.

The mechanism is that a general-purpose builder must be able to render anything the user might construct, so it ships the code for everything on every page. A page with a two-column layout and a heading may load the stylesheet and script for sliders, tabs, counters, popups and animations that are not on it. It also tends to produce deeply nested markup, which costs the browser layout work.

The result is that two sites which look identical in a screenshot can behave completely differently, because what a visitor receives is not what the page looks like. The relevant question when buying is not whether a builder was used, but whether the build removes what is not needed before publishing. Some setups do this well. Many do not do it at all.

4. Render-blocking CSS and JavaScript requests

Before a browser is permitted to draw anything, it must fetch and process the stylesheets and scripts declared in the head of the document. Until that finishes, the visitor sees nothing — not a partial page, nothing.

The usual pattern is a large stylesheet containing rules for the whole site, several font files, and a script or two placed at the top for convenience. Each is a separate round trip, and they are often sequential rather than parallel because one resource is only discovered after another has been read.

The fixes are well understood: inline the small amount of CSS needed for what appears first, load the rest without blocking, defer scripts that are not required for the initial render, and preload the fonts actually used above the fold. It is engineering, not content, which is why it is invisible in a design review and absent from most quotes.

5. Cheap, oversubscribed hosting

Last on the list, and first in most conversations, which is the point of ranking it here.

Hosting sets how long the server takes to produce the first byte of the response. On oversubscribed shared hosting, your site is one of many on the same physical machine, competing for the same processor and memory. When a neighbour has a busy hour, you slow down, and nothing about your site has changed.

Server response time sits underneath every other metric — it delays the start of everything — so genuinely bad hosting cannot be optimised around. But it is fifth on this list because a fast server delivering a heavy page is still a heavy page. Upgrading hosting is the most commonly sold fix and frequently the least effective one, because the money is spent where the problem is not. How to tell the two apart is set out in hosting and speed.

Why caching and a CDN mitigate these causes rather than fix them

Caching and a content delivery network (CDN) come up in almost every conversation about a slow website, and they genuinely help — but they are mitigations against the five causes above, not a sixth cause in their own right. Server-side caching stores a pre-built copy of a page so it does not have to be regenerated on every visit, which shortens the delay covered under cheap, oversubscribed hosting. A CDN serves static files — images, CSS, JavaScript — from a server physically closer to the visitor, which reduces the round-trip time for the http requests covered under render-blocking resources and, to a lesser extent, third-party scripts. Browser caching means a repeat visitor’s device does not re-download files it already has, which helps every return visit to a heavy page regardless of which of the five causes made it heavy in the first place. None of the three makes an oversized image smaller, removes an unused third-party script, or lightens a page builder’s markup — they make the same amount of code and the same files arrive faster, which is real, measurable help that still leaves the underlying cause exactly as heavy as it was.

What this means when you are buying

Four of these five are decided during the build, by choices that never appear in a proposal and cannot be seen in a mockup. That is the argument for treating performance as an engineering specification with acceptance criteria attached, rather than as something to look at later — and it is the same reason two quotes for the same-looking site can differ so widely, which is dealt with in how a website quote is built up.

The build decisions themselves — platform, pipeline, hosting architecture, which scripts are allowed on the page — are covered on development work in Brisbane.