Page speed

Page speed is one of those topics where the popular advice — “make it faster” — is technically correct and operationally useless. What matters is knowing where the speed losses actually come from, what each gate of the load pipeline costs, and which fixes carry leverage versus which are theatre.

This article covers the broader page speed picture — what TTFB, FCP, LCP, INP, and CLS each measure, where they typically fail, and the fix sequence that consistently moves both rankings and conversion. The previous article (Core Web Vitals) covers the three Google ranking metrics in depth; this one zooms out to the full pipeline.

“The fix that delivers ROI is rarely the fix that’s easiest to talk about. Most page-speed wins come from removing things — third-party scripts, oversized images, blocking JavaScript — not from adding clever optimisation tricks.”

The five gates of page speed

Every page load passes through five performance gates. A fast page is fast at all five; a slow page typically fails badly at one and the rest mask the problem.

Gate 1 — Server response (TTFB)

Time to First Byte is everything that happens before the browser has the first byte of HTML to render. It’s the foundation: a slow TTFB caps every downstream metric because the LCP clock can’t start until paint can begin.

What typically slows TTFB

• Slow origin server. Cheap shared hosting, under-provisioned VPS, single-region origin serving global users.
• No CDN. Every request crosses the planet to your origin instead of hitting an edge node.
• Server-side rendering with cold caches. Each request rebuilds the page from scratch.
• Heavy database queries on every page load — uncached product lookups, unindexed searches, N+1 ORM patterns.
• Slow third-party APIs in the render path — calling a remote service synchronously before responding to the user.

What fixes TTFB fastest

• Put the site behind a global CDN with edge caching (Cloudflare, Fastly, Vercel, Netlify).
• Cache aggressively at the CDN — long TTL on static, stale-while-revalidate on dynamic.
• Move expensive computations off the critical render path; precompute or background them.
• Add database query caching and indexes for the queries that fire on every page load.
• Use HTTP/2 or HTTP/3, enable compression (Brotli or gzip).

Gate 2 — First paint (FCP)

FCP is when the browser paints anything visible — text, image, SVG, even a background colour. It’s the first signal to the user that the page is alive.

What typically slows FCP

• Render-blocking CSS. The browser parses HTML, hits a stylesheet link, and stops painting until the CSS is downloaded and parsed.
• Render-blocking JavaScript in the head without async or defer.
• Synchronous third-party scripts (the most common offender — analytics, A/B testing, consent management).
• Heavy CSS frameworks shipping unused styles to every page.
• Critical fonts loaded with font-display: block — text is invisible until the font arrives.

What fixes FCP fastest

• Inline critical CSS for above-the-fold content; load the rest async.
• async or defer every script in the head.
• Audit third-party tags ruthlessly — most sites can remove half without anyone noticing.
• Use font-display: swap with a system fallback so text paints immediately.
• Preconnect to required external origins so DNS + TLS doesn’t block.

Gate 3 — Main content (LCP)

LCP is the moment the largest above-the-fold element finishes rendering. On most pages that’s the hero image; on text-heavy pages it can be the H1 or a large paragraph block. See the Core Web Vitals article for the full LCP fix list — the short version is: optimise the hero image (right format, right size, preloaded, not lazy-loaded) and unblock the render path.

Gate 4 — Interactivity (INP)

INP measures the worst-case latency between any user input and the next visible paint, across the entire session. A page can have a great LCP and still feel broken if every click takes 600 ms to respond. Replaces the older FID metric, which only measured the first interaction.

What typically slows INP

• Long tasks blocking the main thread — the JavaScript handler can’t run until the current task finishes.
• Large client-side framework hydration — React/Vue/Angular still hydrating when the user clicks.
• Synchronous network calls on click — the click handler awaits a fetch before painting feedback.
• Animation jank on layout-triggering properties.
• Third-party scripts that run on every interaction (analytics on click, chat widget, replay tools).

What fixes INP fastest

• Audit long tasks in DevTools Performance tab; break up anything over 50 ms.
• Code-split routes; lazy-load components that aren’t needed on first paint.
• Show optimistic UI on click (skeleton, button-pressed state) so feedback paints before any network call.
• Use requestIdleCallback or React’s startTransition to defer non-urgent work.
• Cut third-party scripts on interaction surfaces — analytics that fires on every scroll is INP poison.

Gate 5 — Visual stability (CLS)

CLS measures how much the layout jumps as the page loads or as the user interacts. Detailed fix list lives in the Core Web Vitals article. The 90% rule: set width and height on every image and iframe, reserve fixed-size containers for dynamically-loaded ads/embeds, inject banners below existing content not above.

The page speed fix sequence (priority order)

When you inherit a slow site, work in this order — each step compounds with the previous one:

• 1. Hero image and LCP element. Right format (WebP/AVIF), explicit dimensions, preloaded, not lazy-loaded. Single highest-leverage fix on most sites.
• 2. Third-party script audit. List every script tag, get the business case for each, kill the ones with no clear owner. Marketing tags accumulate over years; deleting half typically improves both LCP and INP.
• 3. CDN + edge caching. If the site isn’t on a global CDN, that’s the easiest TTFB win available. Free or low-cost on Cloudflare for most sites.
• 4. Image optimisation site-wide. Move all images to WebP/AVIF, serve responsive sizes via srcset, lazy-load below-the-fold.
• 5. CSS and font optimisation. Critical CSS inlined, non-critical async; font-display: swap; subset fonts to required glyphs.
• 6. Bundle size and code splitting. The INP fix — usually a 2–4 week engineering project, not a content fix.
• 7. Set up Real User Monitoring via the web-vitals npm package so regressions are caught before they hit Search Console’s 28-day delay.

Common page speed mistakes

• Optimising for Lighthouse instead of real users. Lighthouse runs in a controlled environment; it’s not how your users experience the page. Trust Search Console’s real-user data over Lighthouse scores.
• Lazy-loading the hero image. Lazy-loading is great for below-the-fold content; on the LCP element it actively prevents a good score.
• Treating third-party scripts as untouchable. Every script on the site has an owner who can defend its existence — but most can’t.
• Skipping the CDN because “the site is fast on local”. Local is irrelevant. Real users are on flaky networks across multiple continents.
• Front-loading optimisation tricks (preload, prefetch, prerender) without fixing the actual bottleneck. Preloading a script that should be deleted is theatre.
• Shipping the fix and never measuring the regression. Without RUM, the next deploy might silently re-break what you fixed.

The bottom line

Page speed in 2026 is five gates: server response, first paint, main content, interactivity, visual stability. A fast page is fast at all five. The fix sequence — hero image → third-party scripts → CDN → site-wide images → CSS/fonts → bundles → RUM — moves both Core Web Vitals and conversion. Speed is a small direct ranking factor; it’s a much larger conversion factor; and the conversion math usually justifies the engineering investment before the ranking math does.