Page Speed Optimisation
Last updated
Page speed matters for two reasons: it affects Core Web Vitals scores that Google uses as a ranking signal, and it affects conversion rates directly: slow pages produce higher bounce rates regardless of their ranking position. The fixes are the same either way.
Core Web Vitals defines the three metrics (LCP, INP, CLS) and their pass/fail thresholds. This article covers the specific optimisations that improve those scores.
What causes slow pages?
Most page speed problems come from a small set of causes:
Unoptimised images. Large, high-resolution images in JPEG or PNG format that are not compressed or converted to modern formats. Images are typically the largest assets on a page and the most common LCP bottleneck.
Render-blocking resources. JavaScript and CSS files that must load before the browser can paint anything. Scripts in the <head> that do not use async or defer block rendering until they have fully downloaded and parsed.
No caching. Each page visit reloads static assets (fonts, scripts, images) from the origin server rather than serving them from cache. Browser caching and CDN caching both address this.
High TTFB (Time to First Byte). The server takes too long to respond to the initial request, adding latency before anything else can happen. Often the result of slow server-side processing, shared hosting limitations, or absence of a CDN.
Third-party scripts. Analytics tags, chat widgets, ad scripts, and social embeds that load synchronously delay rendering for content the user is trying to read.
How do you optimise images for page speed?
Images account for the largest proportion of page weight on most sites. Three changes produce the most impact.
Convert to modern formats. WebP reduces file size by roughly 25–34% relative to JPEG at equivalent visual quality. AVIF compresses further still and is now supported by all major browsers. Convert images to WebP as a minimum; AVIF produces further gains where build pipeline tooling supports it.
Compress without visible quality loss. Tools such as Squoosh, ImageOptim, or a build pipeline step reduce file size without perceptible quality degradation. A 2MB hero image typically compresses to 200–400KB with no visible difference at screen resolution.
Set correct dimensions and apply lazy loading selectively. Images should be served at the size they display, not at double or triple the pixel count. The HTML width and height attributes prevent layout shift. The loading="lazy" attribute defers loading of below-the-fold images until the user scrolls near them, reducing initial page weight.
Do not lazy-load the LCP image. The largest visible element on initial load should start loading immediately. If your LCP image uses loading="lazy", remove it. Add fetchpriority="high" to signal that it should be prioritised above other resources in the load queue.
How do you eliminate render-blocking resources?
The browser cannot paint content until it has processed all render-blocking resources in the <head>. The goal is to reduce what must load before first paint.
Defer non-critical JavaScript. Add defer to script tags for code that is not needed for initial render. defer downloads the script in parallel with HTML parsing and executes after parsing completes. Use async for independent scripts that do not depend on DOM ready. Scripts that require no interaction to trigger can often be loaded after a user interaction event fires.
Inline critical CSS. The CSS required to render above-the-fold content should be inlined in <head> rather than loaded from an external stylesheet. This eliminates the render-blocking external request for the CSS that matters most to first paint. Non-critical CSS can be loaded asynchronously using a <link rel="preload"> pattern.
Minimise CSS and JavaScript. Remove whitespace, comments, and unused code from delivered files. Build tools including Vite, esbuild, and Webpack handle this automatically. For WordPress sites, plugins manage minification.
Audit third-party scripts. Use the Coverage panel in Chrome DevTools to measure each third-party script’s contribution to load time. Scripts not justified by their performance cost should be removed. Those that are justified can often use defer or fire after first interaction.
How do caching and CDNs improve page speed?
Browser caching. Cache-Control HTTP headers instruct browsers to store static assets locally and not re-request them on subsequent page loads. Set long max-age values (one year is standard for versioned assets) for files that do not change between deployments. Use content hashing in filenames so updated files bypass the cache automatically.
CDN caching. A content delivery network serves cached copies of static assets from edge nodes geographically close to the user, reducing both TTFB for static assets and load on the origin server. For sites hosted on Cloudflare Pages or Workers, static assets are automatically served from Cloudflare’s edge without separate CDN configuration.
Cache what changes rarely. Images, fonts, CSS, and JavaScript rarely change after deployment and are good CDN and browser cache candidates. HTML pages for content sites should have shorter cache lifetimes or be cache-invalidated on deploy. Avoid caching personalised or session-dependent content at the CDN level.
How do you reduce TTFB?
TTFB is the time between the browser sending an HTTP request and receiving the first byte of the response. It reflects server processing time plus network latency. If TTFB exceeds around 800ms in field data, it is worth addressing before other optimisations.
Upgrade hosting. Shared hosting with resource contention is often the bottleneck. A VPS, managed hosting, or a platform with appropriate infrastructure for the traffic level reduces TTFB at the server level.
Enable server-side caching. For dynamically rendered sites, caching rendered HTML responses prevents the server from rebuilding the page on every request. Platform-level caching (WordPress page caches, Varnish, Redis) handles this.
Use a CDN for HTML. Full-page edge caching serves cached HTML responses from the CDN for pages that do not vary per user. Effective for high-traffic editorial content where the page is the same for all visitors.
Reduce server-side processing. Database queries, external API calls, and complex business logic running on every request slow TTFB. Profiling server-side processing identifies where time is spent.
What tools measure page speed?
Google PageSpeed Insights. Reports lab data (simulated test) and field data (from the Chrome User Experience Report, CrUX) for LCP, INP, and CLS. Field data reflects real user experience across the last 28 days and is what Google’s ranking signal uses. Lab data identifies specific bottlenecks.
Chrome DevTools (Lighthouse). Runs locally in the browser with a detailed breakdown of load time, render-blocking resources, image opportunities, and specific bottlenecks with estimated savings. The Network panel’s Waterfall view shows what loaded when and what blocked rendering.
Search Console Core Web Vitals report. Aggregates CrUX field data across all pages on your domain. Identifies pages failing Core Web Vitals thresholds at scale, grouped by issue type, sorted by traffic.
WebPageTest. More granular than PageSpeed Insights, with control over connection speed, device, location, and run count. Useful for testing under controlled, repeatable conditions.
What is the right order of fixes?
Not all fixes have equal impact. A practical prioritisation sequence for most sites:
- Images. Convert to WebP, compress, set correct dimensions, and fix LCP image loading: remove
loading="lazy"from the LCP element, addfetchpriority="high". - Render-blocking resources. Defer non-critical JavaScript, inline critical CSS, audit third-party scripts.
- TTFB. If field data shows TTFB above 800ms, address hosting or enable server-side HTML caching.
- Caching. Set
Cache-Controlheaders for static assets; verify CDN caching is active. - Third-party scripts. Remove or defer anything not justified by measurable benefit.
Running PageSpeed Insights on your highest-traffic pages before and after each change confirms the measurable improvement from each fix.