Site Speed Optimisation Guide 2026:
Every Technique That Makes Pages Load Faster

HTTP/2 addresses HTTP/1.1's concurrency limitation through request multiplexing — sending all requests simultaneously over a single TCP connection without head-of-line blocking between streams. HPACK header compression reduces the overhead of repeated headers across many requests. HTTP/2 is supported by all modern browsers and virtually all major hosting providers and CDNs. Verify with: curl -I --http2 https://yourdomain.com — the response first line should show HTTP/2. The HTTP/2 specification and web.dev's HTTP/2 performance guide cover the full protocol details. HTTP/2 typically improves load time by 15–40% for resource-heavy pages compared to HTTP/1.1, per web.dev benchmarks.

HTTP/3 replaces TCP with QUIC — a UDP-based transport protocol originally developed by Google and standardised as RFC 9114 — as its transport layer. HTTP/2 over TCP has a fundamental weakness: when a single TCP packet is lost, all multiplexed streams on the connection wait for retransmission. QUIC handles packet loss per-stream — a dropped packet only blocks the stream that needed it. HTTP/3 produces the most significant improvements on high-latency or lossy connections: mobile networks, cross-continental connections, WiFi with interference. Supported by Chrome, Firefox, Safari, and Edge — and by NGINX (with quiche patches), Caddy, LiteSpeed, and Cloudflare. Cloudflare reports that HTTP/3 reduces connection time by 12–15% on average, with larger gains on high-latency connections, per their HTTP/3 performance analysis .

Standard CDN configurations cache static assets: images, CSS, JavaScript, font files, video, PDFs, and other binary content identical for all users. Standard configurations do not cache dynamically generated HTML pages — a CMS page personalised by login state or cart contents requires per-user generation. Advanced CDN products extend caching to dynamic HTML: Cloudflare APO for WordPress caches HTML at edge nodes with intelligent cache-bypass rules for logged-in users and cart/checkout pages. Configure explicit cache rules for all static asset types with long TTLs, and verify your origin sets appropriate Cache-Control headers so the CDN knows what to store and for how long.

Cloudflare free tier provides global edge delivery, DDoS protection, automatic HTTPS, HTTP/2 and HTTP/3, and Brotli compression — making it the most accessible starting point for any site. Cloudflare APO for WordPress ($5/month) adds HTML edge caching, reducing TTFB by 50–80% for cached pages. AWS CloudFront integrates natively with AWS infrastructure for custom per-path cache behaviours. Bunny.net offers excellent performance-per-dollar with a large global PoP count and straightforward pricing. Fastly supports real-time cache purge APIs and programmable VCL edge logic for complex caching requirements. For Indian-audience-heavy sites, Cloudflare and Akamai have particularly dense edge networks across Tier-2 Indian cities — measurably lower TTFB than CDNs with fewer Indian PoPs.

The correct approach for long-duration caching is filename-based cache busting: include a content hash in each asset's filename ( main.a3f9d2.css rather than main.css ). When the file changes, its filename changes — making it a new URL the CDN fetches fresh from origin, while unchanged files continue serving from edge cache. Modern build tools (webpack, Vite, Parcel) generate content-hashed filenames automatically. For HTML pages without filename hashing, use the CDN's instant cache purge API to push updates when content changes. Cloudflare's Cache Purge API documentation is at developers.cloudflare.com/cache/how-to/purge-cache .

Without splitting, a page using 10% of your application's total JavaScript still downloads and parses the entire bundle on every load. With code splitting via dynamic import() (supported natively by webpack, Vite, and Rollup), route-specific components load only when that route is navigated to, and large third-party libraries (charting tools, rich text editors) load only when the component needing them is rendered. This is the most impactful JavaScript optimisation for React, Vue, Angular, or similar component-based applications — it commonly reduces initial bundle size by 40–60%, per Vite's own code splitting documentation .

Tree shaking statically analyses JavaScript imports and removes exported code not used anywhere in your application. When you import only { debounce } from lodash using ES module syntax, tree shaking ensures only the debounce function and its dependencies are included — not all 300+ lodash utilities. Tree shaking requires ES module syntax ( import/export , not CommonJS require() ) and is performed automatically by webpack in production mode, Vite, Rollup, and esbuild. Verify with webpack-bundle-analyzer or vite-bundle-visualizer — large libraries appearing in full despite partial imports indicate missing ES module support or tree shaking configuration issues.

Minification removes whitespace, line breaks, comments, and long variable names (replaced with single-character equivalents). Modern minifiers (Terser, esbuild, SWC) also perform constant expression evaluation and dead code elimination. Minification typically reduces JavaScript size by 20–40% before compression — combined with Brotli, production JavaScript is commonly 70–85% smaller than the development source. Running un-minified JavaScript in production is never appropriate and immediately identifiable in any Lighthouse or PageSpeed Insights audit.

Any JavaScript task running over 50ms is a "long task" — it blocks the main thread from responding to user input for its entire duration, directly causing Poor INP scores. Diagnose with Chrome DevTools Performance panel: record a page load and examine the Main thread row for red-capped tasks over 50ms. Common sources: large synchronous execution during initial page load, heavy third-party scripts, non-virtualised long lists rendering thousands of DOM nodes, synchronous JSON parsing of large payloads. Fixes: break long tasks using scheduler.yield() (Chrome 115+) or setTimeout(resolve, 0) to yield between work chunks; implement virtual list rendering (react-virtual, TanStack Virtual); move heavy computation to Web Workers to run off the main thread entirely. The Chrome team's Optimize Long Tasks guide on web.dev is the authoritative reference.

The font-display: swap declaration in @font-face rules instructs the browser to immediately render text using a system font fallback while the web font downloads, then swap the web font in when it arrives. This prevents the FOIT period where text exists in the DOM but the browser refuses to paint it while waiting for the custom font. The trade-off is a brief Flash of Unstyled Text (FOUT) — text appears in the system fallback then shifts to the web font — which is visually preferable to invisible text and significantly better for perceived load speed. For Google Fonts, append &display=swap to the font URL parameter. The full font-display specification is documented on MDN Web Docs .

rel="preconnect" link hints establish the TCP connection, TLS handshake, and DNS lookup to a third-party domain before any request from that domain has been made. For Google Fonts, add these two tags in your HTML <head> before the Fonts link tag:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
This eliminates 100–300ms of connection setup overhead from the critical path of the font request, per Google's font best practices guide on web.dev .

Hosting web fonts on your own domain or CDN eliminates the cross-origin connection overhead of third-party font CDNs entirely and gives you full control over Cache-Control headers. Download WOFF2 files from google-webfonts-helper or similar tools, place them in your static assets directory, and reference them via @font-face declarations in CSS. Self-hosted fonts benefit from your CDN's edge caching — returning users receive fonts from the same CDN edge as all other static assets. WOFF2 is the correct default format: universal support across all modern browsers and the most compact font format available — typically 30% smaller than WOFF for the same typeface.

A full Unicode web font covers thousands of characters across dozens of scripts. An English-language site needs only the Basic Latin subset: A–Z, a–z, numerals, and common punctuation. The Latin subset of a typical web font is 20–40KB versus 150–300KB for the full Unicode version — a 75–85% size reduction. Google Fonts delivers the Latin subset by default for most fonts; append &subset=latin to confirm. For self-hosted fonts, use pyftsubset (part of fonttools) or the online glyphhanger tool to generate a custom WOFF2 subset containing only the Unicode ranges present in your site's actual content.

Use WebPageTest's Filmstrip View or Chrome DevTools Network panel filtered to third-party domains to enumerate every external request your pages make. For each script: Is it actively used? Does it contribute to a measurable business outcome? Has its value been validated in the last 6 months? Scripts that cannot be justified should be removed. Common candidates: abandoned analytics tags from previous tools, social sharing buttons with near-zero click rates, marketing pixel duplicates from the same vendor, outdated chat widgets for products no longer in use. Every removed script is an unconditional performance improvement — no configuration can make it as fast as not loading it at all.

Every third-party script tag should have either async or defer attribute. Use async for independent scripts (analytics pixels, advertising tags) that have no dependencies on other scripts. Use defer for scripts that interact with the DOM. Never include third-party scripts synchronously in the document <head> — this is the most egregious performance anti-pattern and the most common cause of Total Blocking Time scores over 500ms, per Lighthouse's TBT diagnostic methodology documented at web.dev/tbt .

For scripts that don't need to be ready on initial page load — live chat widgets, social comment systems, video embeds — delay loading entirely until the first user interaction. Listen for a scroll , click , or mousemove event to trigger script injection via a once-fired event listener. This removes these scripts from the critical loading path entirely, allowing the page to reach interactive state faster and deferring their performance cost until the user is actively engaged. The pattern is well-established and documented in Google's efficient third-party loading guide on web.dev .

The facade pattern replaces a heavyweight third-party embed (YouTube player, Google Maps, Intercom chat widget) with a lightweight static placeholder — a screenshot or thumbnail image — that loads instantly. The real embed only loads when the user clicks the placeholder. YouTube embeds can add 400–600KB of JavaScript and multiple DNS connections per page; replacing them with a thumbnail image and click-to-load interaction reduces the associated load time from 1–2 seconds to under 50ms. The lite-youtube-embed npm package implements this for YouTube with built-in accessibility support. For chat widgets, display a styled "Start a chat" button that injects the widget script only on click — a pattern recommended by both Lighthouse and Google's Third-party facades guide on web.dev .