How to Reduce Page Load Time: The Complete Page Speed Optimisation Guide

If you want to speed up your website and hold on to every visitor who lands on it, page load time is one of the highest-leverage variables you can control. A slow site loses visitors, loses rankings, and loses revenue — often before a single word of your content is read. This guide covers everything you need to know about page speed optimisation, from the five-minute quick wins to advanced server-level techniques, with practical steps you can act on today.

Whether you run a WordPress blog, a Shopify store, or a custom-built application, the principles are the same. Every millisecond you save is a marginal improvement in user experience, in Core Web Vitals scores, and ultimately in the number of people who convert. Let's work through it systematically.

Why Page Speed Matters: Rankings, Experience, and Revenue

Page Speed as a Google Ranking Factor

Google confirmed page speed as a desktop ranking factor in 2010 and extended it to mobile results in 2018 with the Speed Update. Since then, the introduction of Core Web Vitals as page experience signals in 2021 has made the relationship between load time and rankings even more direct. Core Web Vitals are now part of Google's ranking algorithm, and three of the four signals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — are directly influenced by how quickly and stably a page loads.

Slow pages are less likely to rank well in competitive niches, not only because of the direct speed signal but because high bounce rates and short dwell times send negative engagement signals back to Google. A page that loads in 1 second and is read for four minutes looks far healthier in Search Console than a page that takes six seconds to load and sees 70% of users bounce immediately.

How Load Time Affects User Experience

Human perception of speed is surprisingly precise. Research by Google found that 53% of mobile users abandon a site if it takes longer than 3 seconds to load. Akamai's research found that a 100-millisecond delay in load time can reduce conversions by 7%. These figures are not theoretical — they represent real visitors choosing not to engage with your content.

Users form opinions about page quality within the first few hundred milliseconds. A page that renders quickly feels trustworthy and professionally built. A page that stalls, shifts layout, or shows a blank white screen for two seconds feels broken, regardless of how good the content is. Speed is part of the first impression.

The Business Case: Conversions and Revenue

The connection between page speed optimisation and revenue is well documented across industries. Walmart found that every 1-second improvement in load time increased conversions by 2%. Mobify found that a 100ms improvement to their mobile homepage increased session-based revenue by 1.11%. Pinterest reduced wait time by 40% and saw a 15% increase in SEO traffic alongside a 15% increase in sign-up conversions.

For e-commerce, the arithmetic is straightforward: faster product pages mean more people reach checkout, and more checkouts mean more revenue. For content sites, faster pages mean lower bounce rates, longer sessions, and more ad impressions. Whatever your business model, reducing page load time almost always has a measurable positive effect on the metrics that matter.

Measuring Page Speed: Tools and Metrics

Before optimising, you need a baseline. There are two types of performance data to understand: lab data (synthetic tests run in controlled conditions) and field data (real user measurements collected from actual visitors). Both matter.

The Key Metrics to Track

Tools for Measuring Page Speed

• Google PageSpeed Insights — Free tool combining Lighthouse lab data with Chrome User Experience Report (CrUX) field data. The most important tool for understanding how Google sees your page performance.
• Google Search Console (Core Web Vitals report) — Shows field data aggregated from real users in your audience. Identifies pages that need improvement based on actual visit data.
• WebPageTest.org — Highly configurable synthetic testing tool. Allows testing from different geographic locations, connection speeds, and devices. Shows waterfall charts that make it easy to identify bottlenecks.
• GTmetrix — Popular tool combining Lighthouse with WebPageTest data. Provides a waterfall view, filmstrip, and actionable recommendations.
• Chrome DevTools (Lighthouse tab) — Run audits directly in your browser for any page, including those behind logins or staging environments.
• RankNibbler Site Audit — Checks your page for script loading patterns, image issues, and other performance-related SEO factors across 30+ checks.

Understanding Your Waterfall

A resource waterfall is a visual breakdown of every file your page loads, when it starts loading, and how long it takes. Reading a waterfall chart is one of the most effective ways to diagnose exactly what is slowing your page down. Look for long chains of sequential requests (where one resource cannot load until another finishes), large files with long download times, and render-blocking resources that delay the first paint. WebPageTest and Chrome DevTools both produce excellent waterfall views.

Quick Wins: High-Impact, Low-Effort Optimisations

Not all optimisations require technical depth. The following changes can often be made in under an hour and deliver significant improvements to page load time.

Image Optimisation: The Biggest Single Win

Images are consistently the largest contributors to page weight. On an average web page, images account for over 50% of total page size. Optimising images correctly is usually the single highest-return action you can take to reduce page load time. There are several distinct aspects to get right.

Compress Images Before Uploading

Most images uploaded to websites are far larger than they need to be. A photograph taken on a smartphone might be 5–10MB in its original form. Even after scaling it to web dimensions, it might still be 1–2MB unless compression is applied. For most web images, a target of under 150–200KB per image is a reasonable goal without visible quality loss.

Use tools like Squoosh (free, browser-based), ImageOptim (Mac), ShortPixel, or Imagify to compress images before or after upload. Most image editing tools (Photoshop, Affinity Photo, GIMP) also allow you to export with quality settings — exporting a JPEG at 75–80% quality typically reduces file size by 60–70% with no perceptible quality difference at screen resolution.

Switch to WebP (and Consider AVIF)

WebP is a modern image format developed by Google that delivers 25–35% smaller file sizes than JPEG at equivalent quality, and 25–50% smaller than PNG for images with transparency. All major modern browsers support WebP, making it a straightforward replacement for most JPEG and PNG images on the web.

AVIF is a newer format that achieves even better compression than WebP — typically 30–50% smaller than JPEG — but has slightly less universal browser support. It is worth using where supported, with a fallback to WebP or JPEG. The HTML <picture> element makes this straightforward:

<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description">
</picture>

Use Responsive Images with srcset

A common mistake is serving the same large image to every device. A desktop hero image at 1400px wide is completely unnecessary on a 375px mobile screen, yet many sites serve the same file regardless. The srcset attribute on <img> elements allows you to declare multiple image sizes and let the browser choose the most appropriate one:

<img src="hero-800.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
alt="Hero image">

This can reduce image transfer size on mobile by 60–80% compared to always serving the full-size version.

Add Width and Height Attributes to Prevent CLS

When a browser loads a page, it needs to know the dimensions of images before they download so it can reserve the correct space in the layout. Without explicit width and height attributes, the browser cannot do this, and other page elements will shift when the image loads — contributing to a poor Cumulative Layout Shift score.

Always add width and height attributes matching the intrinsic dimensions of the image. Modern CSS (height: auto) ensures the image still scales responsively even when dimensions are specified in HTML. Use the image dimensions checker to audit your pages for missing dimension attributes.

Implement Lazy Loading

Lazy loading defers the loading of images (and iframes) that are not visible in the initial viewport. The browser only fetches them as the user scrolls toward them. This dramatically reduces the amount of data loaded on initial page view, improving both LCP and overall load time.

The native HTML attribute makes this trivially easy: loading="lazy". Add it to any image or iframe that appears below the fold. Do not apply it to the hero image or any above-fold images — those need to load as quickly as possible. Use the lazy loading checker to see which images on your page are missing this attribute.

For the LCP image specifically, consider adding fetchpriority="high" to signal to the browser that this image should be prioritised above others.

Serve Images from a CDN with On-the-Fly Optimisation

Image CDN services like Cloudinary, Imgix, or Bunny.net can serve optimised images automatically — choosing the right format, compression level, and dimensions based on the requesting device. This removes the manual compression and conversion step and ensures every user gets the most efficient version of each image. Many modern hosting platforms (Vercel, Netlify, Cloudflare) include basic image optimisation as part of their CDN offering.

JavaScript Optimisation

JavaScript is the second largest contributor to slow pages after images, and in many ways it is harder to deal with. Unlike images, which simply take time to download, JavaScript must be downloaded, parsed, compiled, and executed — all of which blocks the main thread and delays interactivity. Heavy JavaScript is the primary cause of poor Total Blocking Time (TBT) and Interaction to Next Paint (INP) scores.

Use async and defer on Script Tags

By default, a <script> tag in the <head> of a page blocks HTML parsing while the script is downloaded and executed. This can add seconds to your FCP and LCP. The solution is the async and defer attributes.

• async — the script downloads in parallel with HTML parsing and executes as soon as it is downloaded, potentially interrupting parsing. Best for completely independent scripts like analytics or ad tags.
• defer — the script downloads in parallel with HTML parsing but only executes after the HTML is fully parsed. Best for scripts that depend on the DOM but do not need to run immediately.

Neither async nor defer is appropriate for scripts that must run before the page renders (for example, A/B testing scripts that manipulate the DOM). But for the majority of scripts on most pages, defer is the correct choice. Use the script loading checker to audit your page for scripts that are missing these attributes.

Code Splitting

Modern JavaScript bundlers (Webpack, Rollup, Vite, esbuild) support code splitting — breaking a large JavaScript bundle into smaller chunks that are only loaded when needed. Instead of loading 500KB of JavaScript for every page, you load a small core bundle and then dynamically import additional modules as the user interacts with the page. This is especially important for single-page applications (SPAs) where the full application JavaScript might be enormous.

Route-based code splitting is the most common pattern: each page or route only loads the JavaScript it actually needs. Component-level lazy loading via React.lazy(), Vue's async components, or similar framework patterns takes this further by deferring non-critical UI components until they are needed.

Tree Shaking

Tree shaking is the process of removing dead code — JavaScript that is imported but never actually used — from the final bundle. Modern bundlers perform this automatically when using ES module syntax (import / export). The most common culprit is importing an entire library when only one or two functions are needed. For example, importing the full Lodash library (import _ from 'lodash') adds around 70KB to your bundle; importing only the function you need (import debounce from 'lodash/debounce') adds only a few KB.

Minification

Minification removes whitespace, comments, and shortens variable names in JavaScript and CSS files, typically reducing their size by 20–40%. All major build tools minify automatically in production mode. If you are serving unminified code in production, this is a high-priority fix. Check the CSS and JS checker to see whether your page's scripts and stylesheets are being served in minified form.

Audit and Remove Unused JavaScript

The Chrome DevTools Coverage tab (accessed via the command palette or More Tools menu) shows exactly what percentage of each JavaScript file is executed during page load. It is common to find that 60–80% of a large third-party library is never used. Common offenders include jQuery (still loaded on millions of sites despite being largely unnecessary with modern browser APIs), large UI component libraries where only one or two components are actually used, and old A/B testing or personalisation scripts that are no longer active.

CSS Optimisation

Inline Critical CSS

Critical CSS is the minimum set of CSS rules required to render the above-the-fold content of a page. When CSS is loaded via an external stylesheet in the <head>, the browser must download the entire file before it can render anything — this is called render-blocking CSS. Inlining critical CSS directly in a <style> tag in the <head> eliminates this blocking behaviour for above-fold content, often improving FCP by 0.5–1.5 seconds.

Tools like Critical, Penthouse, or the Critical CSS generator in web.dev can automatically extract the critical CSS for any page. The remaining non-critical CSS is then loaded asynchronously using a pattern like:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

Purge Unused CSS

CSS frameworks like Bootstrap, Tailwind CSS, and Foundation ship with hundreds of kilobytes of CSS rules. On a typical page, the vast majority of these rules are never applied. PurgeCSS, UnCSS, or Tailwind's built-in JIT mode can automatically remove unused CSS, reducing stylesheet size by 90%+ in many cases. A 300KB Bootstrap stylesheet might be reduced to 15–20KB after purging unused rules.

Reduce CSS Specificity and Complexity

Complex CSS selectors and deeply nested rules slow down browser rendering. While the impact is usually smaller than that of large file sizes, reducing selector complexity and avoiding expensive properties like box-shadow, filter, and border-radius on elements that animate can improve rendering performance, particularly on lower-powered mobile devices.

Combine and Minify Stylesheets

Each separate CSS file requires its own HTTP request and parsing step. While HTTP/2 reduces the overhead of multiple requests compared to HTTP/1.1, combining stylesheets still reduces round trips and simplifies caching. Minify all production CSS to remove whitespace and comments. Use the CSS and JS checker to count how many separate CSS files your page is loading.

Server-Side and Hosting Optimisation

No amount of front-end optimisation can fully compensate for a slow server. Time to First Byte (TTFB) — the time from a browser making a request to receiving the first byte of the response — is determined entirely by server-side factors. A TTFB over 800ms is a strong indicator of a server-side problem.

Use a Content Delivery Network (CDN)

A CDN distributes your static assets (images, CSS, JavaScript, fonts) across a global network of edge servers. When a user in Tokyo requests a file, it is served from a nearby data centre rather than a server in Frankfurt or New York. This reduces the physical distance data has to travel, cutting latency by 50–200ms for users far from your origin server.

Popular CDNs include Cloudflare (free tier available), Fastly, Amazon CloudFront, and BunnyCDN. Many hosting providers include CDN functionality. For most sites, simply proxying through Cloudflare's free plan delivers meaningful TTFB improvements with minimal configuration.

Enable Browser Caching

Browser caching instructs visitors' browsers to store static resources locally so they do not need to be re-downloaded on subsequent visits. Set Cache-Control headers with long max-age values for assets that rarely change (images, fonts, JavaScript bundles with hashed filenames) and shorter or no-cache values for HTML and frequently updated resources.

A typical caching policy: Cache-Control: public, max-age=31536000, immutable for versioned static assets (JS/CSS bundles with hash in filename), and Cache-Control: no-cache for HTML pages. This means repeat visitors will load your page almost instantly while still getting updated content when you deploy changes.

Enable GZIP or Brotli Compression

Text-based resources (HTML, CSS, JavaScript, SVG, JSON) compress extremely well because text has a high degree of repetition. GZIP compression typically reduces text file sizes by 60–80%. Brotli, a newer compression algorithm developed by Google, achieves 15–20% better compression than GZIP for most web content and is supported by all modern browsers.

Compression is configured at the server level. For Nginx: gzip on; gzip_types text/html text/css application/javascript;. For Apache, mod_deflate or mod_brotli. Most CDNs handle compression automatically. Verify compression is active using the Network tab in Chrome DevTools — look for content-encoding: br (Brotli) or content-encoding: gzip in the response headers of text resources.

Enable HTTP/2 (and HTTP/3)

HTTP/2 allows multiple requests to be multiplexed over a single connection, eliminating the head-of-line blocking that made HTTP/1.1 slow for pages with many resources. HTTP/2 also supports server push (proactively sending resources the browser will need) and header compression. Most modern hosting providers and CDNs support HTTP/2 by default. HTTP/3, based on the QUIC protocol, offers further improvements for users on high-latency or lossy connections (particularly mobile networks) and is increasingly available.

Improve Server Response Time

A slow TTFB points to server-side issues: an underpowered server, unoptimised database queries, a PHP or CMS application without caching, or network congestion. Solutions include:

• Upgrading from shared hosting to a VPS or managed cloud hosting
• Implementing server-side page caching (WP Super Cache, W3 Total Cache for WordPress; full-page caching in other platforms)
• Optimising database queries and adding appropriate indexes
• Using a PHP opcode cache (OPcache) to avoid recompiling PHP files on every request
• Choosing a hosting provider with servers geographically close to your primary audience

Preconnect to Critical Third-Party Origins

If your page loads resources from third-party domains (Google Fonts, CDN hosts, analytics services), the browser must perform a DNS lookup, TCP connection, and TLS handshake for each new origin before it can start downloading the resource. The rel="preconnect" hint tells the browser to establish these connections early:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Use rel="dns-prefetch" as a lower-priority fallback for browsers that do not support preconnect.

Font Optimisation

Web fonts are a common but frequently overlooked source of page speed problems. Loading a custom font requires a network request to an external host (or your own server), and if the font is not available when the browser renders the page, text will be invisible or replaced by a fallback — a phenomenon that contributes to poor Cumulative Layout Shift scores and poor user experience.

Use font-display: swap

The font-display: swap CSS property instructs the browser to render text immediately using a fallback font and then swap in the custom font once it has loaded. This prevents invisible text during font loading (FOIT — Flash of Invisible Text) and ensures content is readable as quickly as possible:

@font-face {
  font-family: 'MyFont';
  src: url('font.woff2') format('woff2');
  font-display: swap;
}

Serve Fonts in WOFF2 Format

WOFF2 is the most compressed web font format with universal modern browser support. It is typically 30% smaller than WOFF and far smaller than TTF or OTF. Always serve fonts in WOFF2 format, with WOFF as a fallback for older browsers.

Self-Host Fonts Instead of Using Google Fonts

Loading fonts from Google Fonts adds a cross-origin request and an additional round trip. Self-hosting the same fonts (which is permitted for Google Fonts) eliminates this overhead, allows you to set aggressive cache headers, and reduces the number of external origins the browser must connect to. The google-webfonts-helper tool makes downloading Google Fonts for self-hosting straightforward.

Subset Fonts to Required Characters

If your page only uses Latin characters, there is no reason to load a font file containing Cyrillic, Greek, Chinese, and emoji glyphs. Font subsetting reduces file size by stripping out character ranges you do not need. Tools like Glyphhanger or fonttools can create subsetted font files. Google Fonts does this automatically via the &subset=latin parameter.

Limit the Number of Font Variants

Each font weight and style (regular, bold, italic, light) is a separate file download. Loading six variants of a font family adds six network requests. Audit your font usage and load only the weights and styles you actually use.

Third-Party Script Management

Third-party scripts — analytics, chat widgets, advertising tags, social share buttons, heatmap tools, A/B testing platforms — are one of the most common causes of slow page load times. They are loaded from external servers you do not control, block the main thread, and often load additional scripts themselves. A page with 10–15 third-party scripts may be adding 2–5 seconds to load time even if every first-party resource is optimised.

Audit Your Third-Party Scripts

Start with an inventory. Use the Network tab in Chrome DevTools or a WebPageTest waterfall to identify every external domain your page makes requests to. For each script, ask: Is it still active? Is it actually being used? What would happen if it were removed?

Common candidates for removal: old A/B testing scripts from campaigns that ended months ago, duplicate analytics tags (many sites run Google Analytics, Hotjar, Mixpanel, and a tag manager all at once), social share buttons that generate almost no clicks, and chat widgets that are rarely used by visitors.

Load Non-Critical Scripts After the Page Loads

For scripts that do not need to run immediately (chat widgets, survey tools, secondary analytics, retargeting pixels), delay loading until after the page has become interactive. The simplest method is to initialise them inside a window.addEventListener('load', function() {...}) callback or, better, after a short timeout following the load event. This keeps critical rendering unimpeded and moves third-party script overhead outside the initial load window.

Use a Tag Manager Responsibly

Google Tag Manager and similar tools make it easy to add scripts without developer involvement — which is why sites using them often end up with dozens of tags firing on every page. Configure tags to fire only on the pages where they are needed, remove inactive tags, and audit the tag manager container regularly. Tag Manager itself has a performance cost, but it is much smaller than the cost of loading 20 unmanaged individual scripts.

Facade Patterns for Heavy Embeds

Embeds like YouTube videos, Intercom chat, and Google Maps are extremely heavy — a single YouTube embed can add 400–600KB and multiple render-blocking scripts to your page load. The facade pattern replaces these with a lightweight placeholder (a static image or simple UI) that only loads the full embed when the user clicks on it. Paul Irish's Lite YouTube Embed is a popular open-source example for YouTube.

Core Web Vitals Improvements

Since Core Web Vitals became ranking signals, optimising for these specific metrics is an integral part of page speed work. Each metric has specific technical levers. For a deep dive, see the Core Web Vitals guide.

Improving Largest Contentful Paint (LCP)

LCP measures the time until the largest visible content element (usually a hero image or large heading) is rendered. The most impactful improvements are:

• Optimise and preload the LCP image: <link rel="preload" href="hero.webp" as="image">
• Add fetchpriority="high" to the LCP image element
• Reduce server response time (TTFB) — LCP cannot begin until the HTML arrives
• Remove render-blocking resources that delay LCP element discovery
• Ensure the LCP resource is discoverable in the initial HTML (not inserted by JavaScript)

The target for LCP is under 2.5 seconds. See the full LCP guide for a detailed breakdown.

Improving Cumulative Layout Shift (CLS)

CLS measures visual instability — how much page elements move around after the initial render. The most common causes are:

• Images without explicit width and height attributes (use the image dimensions checker)
• Ads, embeds, or iframes without reserved space (use CSS aspect-ratio or fixed container dimensions)
• Dynamically injected content (banners, cookie consent bars) that pushes other content down
• Web fonts causing text reflow when they load
• Animations that affect layout properties instead of transforms

The target for CLS is under 0.1. See the CLS guide for specific fixes.

Improving Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as the Core Web Vitals interactivity metric in March 2024. It measures the latency of all interactions during a page visit, not just the first. Poor INP is almost always caused by long tasks on the JavaScript main thread blocking interaction handling. Fixes include:

• Break up long JavaScript tasks into smaller chunks using setTimeout or the Scheduler API
• Avoid synchronous layout operations (forced reflows) in event handlers
• Defer non-critical JavaScript to after the page is interactive
• Use web workers for heavy computations that do not require DOM access

Page Speed Optimisation by CMS

WordPress Speed Optimisation

WordPress powers over 40% of the web, and its performance characteristics are well understood. Out-of-the-box WordPress is not particularly fast, but it is highly optimisable with the right configuration.

Caching plugins: WP Rocket, W3 Total Cache, and LiteSpeed Cache are the most capable options. They provide page caching (serving static HTML instead of re-running PHP on every request), object caching, database query caching, and browser caching configuration. WP Rocket is the most beginner-friendly paid option; W3 Total Cache and LiteSpeed Cache are free.

Image optimisation plugins: ShortPixel, Imagify, and Smush automatically compress uploaded images and can convert them to WebP. ShortPixel and Imagify also offer bulk processing of existing image libraries.

Asset optimisation: WP Rocket, Autoptimize, and Asset CleanUp can minify and combine CSS and JavaScript, inline critical CSS, remove render-blocking resources, and defer non-critical scripts.

Hosting matters enormously for WordPress: Shared hosting with an overloaded server produces TTFBs of 2–5 seconds regardless of how much you optimise the front end. Managed WordPress hosts like Kinsta, WP Engine, or Cloudways are optimised specifically for WordPress and typically deliver TTFBs under 200ms.

Reduce plugin bloat: Each active WordPress plugin may add CSS, JavaScript, and database queries to every page load. Audit your plugins, deactivate unused ones, and use Asset CleanUp or WP Rocket's per-page exclusions to prevent plugins from loading their assets on pages where they are not needed.

Shopify Speed Optimisation

Shopify handles server-side infrastructure for you, so TTFB and server configuration are generally not issues. The main performance levers are theme choice and third-party apps.

Choose a fast theme: Dawn (Shopify's free official theme) is the fastest widely available option and scores well on Core Web Vitals. Many premium themes load large JavaScript frameworks and multiple external resources that add seconds to load time. Check theme performance using PageSpeed Insights before purchasing.

Audit installed apps: Every Shopify app you install can inject JavaScript, CSS, and tracking pixels into your storefront. Apps that add even 200–300ms each stack up quickly. Remove apps you no longer actively use. Shopify's theme editor shows a performance impact indicator for installed apps.

Optimise theme images: Shopify CDN delivers images efficiently, but you still need to upload appropriately sized and compressed images. Use Shopify's built-in | image_url liquid filter with size parameters to generate correctly sized variants rather than serving the original upload.

Defer third-party scripts: Use a custom script loader or a Shopify app like Littledata or Analyzify to defer analytics and tracking scripts until after the page is interactive.

Other Platforms

For sites built on Wix, Squarespace, or Webflow, front-end optimisation options are more limited since you do not have access to server configuration or full code control. Focus on what you can control: image optimisation (size, format, lazy loading), minimising the number of installed integrations and third-party embeds, and choosing themes or templates that are already optimised for speed. On these platforms, upgrading to a higher plan sometimes means faster servers and better CDN coverage.

For Next.js, Nuxt, or other modern framework sites, take advantage of built-in optimisations: Next.js's Image component handles WebP conversion, sizing, and lazy loading automatically; Nuxt Image does the same. Use static generation (SSG) or incremental static regeneration (ISR) where possible to eliminate server processing time and achieve near-instant TTFB.

Advanced Techniques

Resource Hints: Preload, Prefetch, Preconnect

Resource hints give the browser advance notice about resources it will need, allowing it to start fetching them earlier.

• rel="preload" — fetch this resource immediately, it is needed for the current page (use for LCP images, critical fonts, key CSS)
• rel="prefetch" — fetch this resource with low priority, it may be needed on the next page (use for resources needed on the next likely navigation)
• rel="preconnect" — establish a connection to this origin early (use for third-party origins that are critical to page rendering)
• rel="dns-prefetch" — resolve DNS for this origin early (lower-priority alternative to preconnect)

Serve Static HTML with Edge Rendering

For the absolute best TTFB, serve pre-rendered HTML directly from the CDN edge — as close to the user as possible with no server-side processing. This is the principle behind Jamstack architecture. Platforms like Cloudflare Pages, Vercel, and Netlify serve static assets from their edge networks, achieving TTFBs of 20–50ms globally. Even for dynamic sites, generating static HTML for high-traffic pages and serving it from the edge can deliver dramatic TTFB improvements.

Service Workers and Offline Caching

Service workers are JavaScript scripts that run in the background and can intercept network requests. A well-configured service worker can serve cached assets instantly on repeat visits, bypassing the network entirely for static resources. Progressive Web Apps (PWAs) use service workers extensively to achieve near-native performance on mobile devices. For content-heavy sites, a stale-while-revalidate caching strategy delivers cached content immediately while fetching an updated version in the background.

Reduce DOM Size

A large DOM (more than 1,500 nodes is the PageSpeed Insights warning threshold) slows down style calculations, layout, reflow, and paint operations. Every time JavaScript modifies the DOM, the browser may need to recalculate layouts and repaint the screen. If your page has a very large DOM, consider virtualisation for long lists (only rendering visible items), removing hidden elements that are never shown, and simplifying overly nested HTML structures.

Optimise Web Animations

CSS animations and transitions that affect layout properties (width, height, top, left, margin, padding) trigger expensive layout recalculations. Animations using transform and opacity instead are GPU-accelerated and do not trigger layout, making them dramatically cheaper to run. Adding will-change: transform to elements that will animate hints to the browser to promote them to their own compositor layer.

Prerender Next Pages

For sites where the next likely user navigation is predictable (a blog home page where most users will click the first article, a product listing where most users will click the first result), the Speculation Rules API allows you to prerender the next page before the user clicks. When they do click, the page appears to load instantly. This is supported in Chromium browsers and can dramatically improve perceived navigation speed.

Checking and Monitoring Your Progress

Speed optimisation is not a one-time task. New features, third-party scripts, image uploads, and plugin updates continuously affect page performance. Set up monitoring to catch regressions before they hurt rankings or conversions.

• Check Google Search Console Core Web Vitals report monthly to see how real users are experiencing your pages
• Set up PageSpeed Insights API monitoring or use tools like SpeedCurve, Calibre, or Sentry Performance for continuous synthetic monitoring
• Add performance budgets to your build process — fail the build if JavaScript bundle size or Lighthouse score drops below a threshold
• Run a full site audit after significant changes to catch new issues before they accumulate

Frequently Asked Questions

What is a good page load time?

For Core Web Vitals, Google's threshold for "good" LCP is under 2.5 seconds. For overall page load, a fully interactive time under 3 seconds on a mid-range mobile device on a 4G connection is a reasonable target. Aim for under 2 seconds for competitive niches where page experience is a meaningful ranking differentiator. The page speed guide covers these benchmarks in detail.

Does page speed directly affect Google rankings?

Yes, but it is one of many signals. Page speed (measured through Core Web Vitals) is a confirmed Google ranking factor, but Google has stated it is a tiebreaker between pages of otherwise similar relevance and quality. You are unlikely to outrank a significantly more authoritative page purely on page speed, but in competitive SERPs where multiple strong pages are competing, page experience can be the deciding factor.

What is the difference between page speed and page size?

Page size is the total weight of all resources on the page (HTML, CSS, JavaScript, images, fonts). Page speed is how quickly those resources load and the page becomes usable. A small page on a slow server can be slower than a larger page on a fast CDN. Both matter, but speed is what Google and users actually experience. Reduce page size to improve speed, but do not treat size reduction as the goal in itself.

How do I reduce TTFB?

Time to First Byte is determined entirely by server-side factors: server processing time, database query speed, geographic distance to the server, and network routing. Fixes include upgrading hosting, implementing server-side caching (so PHP/database processing only runs once), using a CDN to serve cached responses from the edge, and ensuring your application code is optimised without unnecessary database queries or heavy computations on each request.

Does lazy loading affect SEO?

No. Google's crawler supports native lazy loading (loading="lazy") and will render and index lazily loaded content. However, do not lazy load above-the-fold images — the browser needs to load these immediately for a good LCP score, and Google needs to see them early for indexing. Only apply lazy loading to images that appear below the fold. Use the lazy loading checker to audit your page.

What causes Cumulative Layout Shift?

CLS is caused by content moving around after it initially renders. The most common causes are images without explicit dimensions, ads or embeds loading into the page after initial render without reserved space, dynamically injected banners or notifications, and web fonts causing text to reflow when they swap in. See the CLS guide and use the image dimensions checker to find missing width and height attributes.

Is WebP better than JPEG for all images?

For photographic content, WebP is typically 25–35% smaller than JPEG at equivalent quality, making it the better choice in almost all cases. For images with transparency, WebP replaces PNG with significantly better compression. The only significant limitation of WebP is that it is not universally supported in older browsers (particularly Internet Explorer), but if your site analytics show minimal IE usage, WebP is a straightforward win. Use the <picture> element with a JPEG fallback if you need to support older browsers.

Should I use a CDN even if most of my visitors are in one country?

Yes, even for geographically concentrated audiences. CDNs improve performance not just through geographic proximity but also through optimised routing, DDoS protection, edge caching that reduces origin server load, and automatic optimisations like Brotli compression and HTTP/2. Cloudflare's free plan delivers these benefits at no cost and is worthwhile for almost any site regardless of audience geography.

How does JavaScript affect page speed?

JavaScript affects page speed in two main ways. First, large JavaScript files take time to download and parse, delaying when the page becomes interactive. Second, JavaScript execution on the main thread blocks user interaction — every millisecond the browser spends running JavaScript is a millisecond it cannot respond to clicks, scrolls, or keyboard input. Heavy JavaScript is the primary cause of poor INP scores. Use the script loading checker to audit how your scripts are loaded.

How often should I check my page speed?

Check after any significant change: deploying new features, installing plugins, updating themes, adding third-party integrations, or publishing content-heavy pages. For actively maintained sites, a monthly audit is a reasonable baseline. Set up automated monitoring so you are alerted to regressions rather than discovering them during a manual check weeks after they happen. Use the RankNibbler site audit for a quick health check any time.

What is the impact of fonts on page speed?

Web fonts can add 200–500ms to page load depending on the number of variants and the font host. The impact is larger on first visits (before fonts are cached) and for users on slower connections. Add font-display: swap to prevent invisible text during loading, preconnect to the font host, and consider self-hosting fonts for maximum control over caching. Limit font variants to only those you actually use.

Can I speed up a Shopify or Wix site if I cannot edit the server?

Yes. Even on hosted platforms where you cannot configure the server, you can still optimise images (format, compression, sizing, lazy loading), minimise the number of third-party apps and scripts, choose performance-optimised themes, and reduce the number of custom fonts and variants. These changes alone can often halve load times on slow Shopify or Wix stores. The server-side constraints are real, but front-end optimisation remains highly impactful.

Summary: Page Speed Optimisation Priority Order

With so many techniques available, it helps to have a prioritised sequence. Start with the highest-impact, lowest-effort changes and work toward the more complex optimisations.

1. Audit your current performance baseline (PageSpeed Insights, RankNibbler site audit)
2. Compress and convert images to WebP; add lazy loading to below-fold images
3. Add explicit width and height to all images
4. Add async or defer to non-critical scripts
5. Enable GZIP or Brotli compression on the server
6. Set browser caching headers for static assets
7. Purge unused CSS; minify CSS and JavaScript
8. Inline critical CSS for above-fold content
9. Add a CDN if not already in use
10. Preload the LCP image
11. Audit and remove unnecessary third-party scripts
12. Add font-display: swap; self-host fonts if possible
13. Upgrade hosting if TTFB is consistently over 800ms
14. Implement advanced techniques (code splitting, service workers, speculation rules) as needed

Every optimisation you make compounds with the others. A page that has had its images compressed, its scripts deferred, its CSS purged, and its fonts self-hosted will deliver a materially better experience than one where only one of those changes has been made. Treat page speed optimisation as an ongoing process rather than a single project, and use the tools available — including the free RankNibbler audit — to track your progress over time.

Last updated: April 2026