Speed Kills (Bounce Rates)

Speed is not a technical vanity metric — it is the first thing every visitor experiences, before your copy, your design or your offer gets a chance to work. Google's own guidance treats page experience as a ranking input, and its Core Web Vitals thresholds are the closest thing to a published target: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1.

Those thresholds exist because slow pages get abandoned. The effect compounds on mobile, where connections are worse and patience is shorter, and it compounds again on paid traffic, where every abandoned session was money spent to acquire a visitor who never saw the page.

The practical framing we use with clients: your load time sets a ceiling on every other optimisation you make. There is no headline good enough to rescue a page nobody waits for.

The critical rendering path is everything the browser must download, parse and execute before it can paint the first meaningful pixel. Optimising it means minimising both the number of round trips and the bytes in each one.

In practice, three things dominate. Render-blocking CSS and JavaScript in the document head stop the browser dead until they resolve. Web fonts loaded synchronously hold text hostage until the font file arrives. And uncompressed, unsized images push the largest element on the page far later than it needs to be.

Each has a well-understood fix: inline or defer non-critical CSS, load fonts asynchronously with a sensible fallback so text paints immediately, and serve images in modern formats at the size they will actually be displayed.

Serve images as WebP or AVIF, with explicit width and height attributes. Modern formats routinely cut image weight by half or more against JPEG at equivalent quality, and declaring dimensions prevents the layout shift that happens when an image arrives and shoves the content below it down the page.

Lazy-load anything below the fold, and only anything below the fold. Lazy-loading your hero image is a common own goal — it delays the very element Largest Contentful Paint is measuring.

Defer non-essential JavaScript. Analytics, chat widgets, cookie banners and tag managers are rarely needed in the first second, and they are frequently the largest scripts on a marketing site. Third-party embeds deserve particular scrutiny: you inherit their performance, and you usually cannot fix it.

Preconnect to the origins you know you will need — font hosts, image CDNs — so DNS and TLS negotiation happens in parallel rather than serially at the moment of first use.

A large share of the slow sites we are asked to rescue are slow for the same structural reason: they were assembled from a theme plus a page builder plus a dozen plugins, each of which loads its own CSS and JavaScript on every page whether that page uses it or not.

You can optimise around that up to a point — caching, minification, a CDN — but you are compensating for weight that never needed to exist. Hand-written markup ships only what the page actually uses, which is why a custom build tends to start where a heavily optimised builder site finishes.

That is a real trade-off, not an absolute rule. A small brochure site on a well-chosen theme can be perfectly fast. But if speed is a commercial priority rather than a nice-to-have, the architecture decision matters more than any individual optimisation.