Why Page Speed Matters in 2026
Google has made page experience — which includes Core Web Vitals — a confirmed ranking signal. Beyond SEO, the business case is even clearer: a one-second improvement in mobile load time can increase conversions by up to 27%, according to Google's research. Mobile users on 4G connections now account for the majority of global web traffic, so a page that feels slow on a phone is losing real customers.
Server-Level Techniques (Techniques 1–4)
1. Reduce Time to First Byte (TTFB)
TTFB is the time from the user's request to the first byte arriving from your server. Google considers anything over 800 ms as poor. Reduce TTFB by upgrading your hosting to a faster server or VPS, enabling server-side caching (Redis, Varnish, or your CMS's full-page cache), and minimising database queries on each page load. A well-configured WordPress site with a caching plugin can bring TTFB from 2 seconds down to under 200 ms.
2. Use a Content Delivery Network (CDN)
A CDN stores copies of your static assets (images, CSS, JS, fonts) on servers around the world. When a user requests your page, assets are delivered from the nearest edge node rather than your origin server, dramatically cutting latency for international visitors. Cloudflare's free tier alone eliminates most geographic latency issues for small to medium sites.
3. Enable HTTP/2 or HTTP/3
HTTP/2 allows multiple requests to be multiplexed over a single connection, eliminating the "head-of-line blocking" problem of HTTP/1.1. HTTP/3 (based on QUIC) goes further by removing TCP-level blocking. Most modern hosting providers enable HTTP/2 by default. Check yours and upgrade if needed — the improvement on pages with many assets is substantial.
4. Enable Gzip or Brotli Compression
Text-based assets (HTML, CSS, JS, SVG) compress extremely well. Gzip typically reduces file sizes by 70–80%; Brotli compresses even further. Enable compression at the server or CDN level. You can verify it is working by checking the Content-Encoding response header in Chrome DevTools Network tab.
Image Optimisation (Techniques 5–8)
5. Convert Images to WebP or AVIF
WebP delivers 25–35% smaller files than JPEG at equivalent quality. AVIF can be 50% smaller. Use the <picture> element to serve modern formats with a JPEG fallback, or simply use WebP as your default if your user base is on modern browsers (which is now over 95% of global traffic). You can batch-convert images using a free image compression tool.
6. Compress and Resize Images Appropriately
Serving a 2400 px image in a 400 px column is one of the most common page weight mistakes. Always resize images to their maximum display dimensions before uploading. Then compress them — a JPEG hero image should rarely exceed 150 KB. Use srcset to serve different sizes to different screen widths.
7. Prioritise the LCP Image
Add fetchpriority="high" to your LCP image (the largest visible image on load). Remove loading="lazy" from this image — lazy loading delays it. Add a <link rel="preload"> tag in the <head> for the LCP image to instruct the browser to fetch it as early as possible.
8. Lazy Load Below-the-Fold Images
For all images that are not in the initial viewport, add loading="lazy". This is a native HTML attribute supported in all modern browsers and requires zero JavaScript. It defers loading until the image is about to scroll into view, reducing initial page weight significantly on content-heavy pages.
Code and Asset Optimisation (Techniques 9–12)
9. Minify HTML, CSS, and JavaScript
Minification removes whitespace, comments, and redundant characters from code files. The savings vary — 5–20% for CSS, potentially more for unminified JavaScript. Use build tools like Webpack, Parcel, or Vite to automate this. For HTML, tools like HTML minifiers can shave kilobytes off every page response.
10. Remove Unused CSS and JavaScript
Most websites load far more CSS and JS than any given page uses. Tools like PurgeCSS can strip unused CSS rules. For JavaScript, code-splitting ensures each page loads only what it needs. Audit your bundle with Chrome DevTools Coverage tab to see exactly which code goes unused on load.
11. Defer Non-Critical JavaScript
Add defer to script tags for JavaScript that doesn't need to run before the page renders. For scripts that can run any time, use async. Never load large JavaScript libraries synchronously in the <head> — it blocks HTML parsing completely until the script is downloaded and executed.
12. Inline Critical CSS
Critical CSS is the small subset of styles needed to render the above-the-fold content. By inlining it in a <style> tag in the <head> and loading the full stylesheet asynchronously, you can render the visible page before the external CSS file has even finished downloading. Tools like Critical or Penthouse can automate critical CSS extraction.
Rendering and Loading Strategies (Techniques 13–15)
13. Implement Effective Browser Caching
Set long Cache-Control headers (e.g., max-age=31536000) for static assets that don't change — images, fonts, versioned CSS/JS files. Use filename hashing in your build pipeline so that when a file changes, the filename changes too, busting old caches automatically. Effective caching means repeat visitors load your page almost instantly.
14. Preconnect to Critical Third-Party Origins
DNS lookup, TCP handshake, and TLS negotiation for external origins (Google Fonts, CDN providers, analytics) add latency before the first byte can flow. Adding <link rel="preconnect"> tags for critical third-party origins in the <head> allows the browser to establish these connections in parallel with other work. Use dns-prefetch as a fallback for browsers that don't support preconnect.
15. Reduce or Eliminate Render-Blocking Resources
A render-blocking resource is any resource in the critical rendering path that delays the browser from painting the page. Common culprits: synchronous <script> tags in the <head>, multiple CSS files loaded sequentially, and web font files with no fallback strategy. Audit your critical path with the PageSpeed Insights "Eliminate render-blocking resources" recommendation and address each item.
How to Measure Your Progress
Track these metrics before and after each change to quantify improvement:
- PageSpeed Insights — Lab score and field data CWV
- Google Search Console — Core Web Vitals report (field data, grouped by URL)
- Chrome DevTools Network tab — Total page size, request count, load time
- WebPageTest — Waterfall, filmstrip, and multi-run consistency checks
Always test on a representative connection speed (e.g., "Fast 4G" in DevTools throttling) and a real mobile device when possible. Lab scores on a fast desktop connection flatter real-world performance significantly.
For a comprehensive audit approach, see our Technical SEO Checklist 2026 which covers page speed alongside 40+ other technical factors.