Site Speed Optimisation 2026: What Actually Works

Your website takes 4 seconds to load. Your competitor’s takes 1.5. Google knows. Your visitors know. And you are losing conversions with every extra second. Here is what actually makes websites fast in 2026, not 2020 advice recycled with a new date.

Core Web Vitals in 2026: What Google Measures Now

Google’s performance measurement framework has matured. The metrics that matter for search ranking in 2026:

Largest Contentful Paint (LCP) measures how long the main content of a page takes to load. Good: under 2.5 seconds. Needs improvement: 2.5-4 seconds. Poor: over 4 seconds. LCP is typically the image or text block at the top of your page.

Interaction to Next Paint (INP) replaced First Input Delay as the interactivity metric. It measures how quickly the page responds to any interaction throughout the session, not just the first one. Good: under 200 milliseconds. This matters most for pages with lots of interactive elements.

Cumulative Layout Shift (CLS) measures visual stability. Does content jump around as the page loads? Text that moves when an image loads, buttons that shift position, content pushed down by late-loading ads. Good: under 0.1.

Google uses field data (real user measurements from Chrome users) for ranking decisions, not lab scores. Optimising purely for PageSpeed Insights scores without tracking real user experience can create a misleading picture.

The High-Impact Fixes: Do These First

Ranked by typical impact relative to effort:

1. Image optimisation (highest impact, moderate effort)

Images are typically 50-80% of a page’s file size. Modernising your image formats and sizes delivers the largest single improvement most websites can make.

AVIF is the most efficient format available in 2026, typically 50-70% smaller than JPEG at equivalent quality. WebP is the fallback for browsers that do not support AVIF, typically 25-35% smaller than JPEG. Serve AVIF first with a WebP fallback. JPEG and PNG should only appear when neither format is supported, which is increasingly rare.

Beyond format: ensure images are sized for their display dimensions. A 3,000px wide image displayed at 400px width is transferring 7x more data than needed. Responsive images using the srcset attribute serve appropriate sizes for each device.

2. Font loading strategy (high impact, low effort)

Custom web fonts often block rendering while they load. Two fixes:

Use font-display: swap to show fallback fonts immediately and swap in the custom font when loaded. Prevents the blank period where no text is visible.

Self-host fonts rather than loading from Google Fonts or similar CDNs. Each external font request adds a DNS lookup and connection overhead. Hosting fonts on your own server eliminates these.

3. Eliminate render-blocking JavaScript (high impact, moderate effort)

JavaScript loaded in the <head> blocks the browser from rendering the page until the script downloads and executes. Defer non-critical scripts with the defer attribute. Move scripts that are not needed for initial rendering to the bottom of the page or load them asynchronously.

Audit which JavaScript is actually needed for first load versus which can be loaded later. Most analytics, chat widgets, and third-party tools can load after the main content is visible.

4. Critical CSS inlining (moderate impact, moderate effort)

The styles needed to render the above-the-fold content of your page can be inlined directly in the HTML, eliminating a separate CSS file request that would otherwise delay rendering. For above-the-fold performance, this is particularly effective.

Edge Computing for Speed

Edge computing serves your content from servers physically close to each visitor. A visitor in Manchester gets your page from a server in Manchester or London, not Virginia.

The difference is measurable. Round-trip time to a US server from the UK is 80-150ms. To a European edge location, it is 5-20ms. Over the multiple round trips required to load a page, this compounds into seconds of difference.

Content Delivery Networks are the practical implementation of this for most websites. Your static files (images, CSS, JavaScript, fonts) are cached at edge locations globally. Visitors receive these files from the nearest location rather than your origin server.

For UK business websites, choosing hosting with UK and European edge locations matters. Cloudflare Pages, which we use for all Fernside builds, operates one of the largest edge networks globally with extensive UK and European coverage.

Modern Architecture Choices That Affect Speed

Static generation pre-builds your pages at deployment time rather than building them on each request. The result: page load time approaches the speed of file delivery, typically under 100ms from edge locations. This is why a well-built static site is significantly faster than a dynamically rendered WordPress site of similar visual complexity.

Server-side rendering on each request (traditional WordPress, PHP-based sites) means every page load triggers database queries, template processing, and PHP execution. Under load, this compounds. The architecture ceiling for dynamic sites is lower, and reaching it is more expensive.

Hybrid approaches (static with dynamic islands) give you the speed of static generation for most content with dynamic capability for specific components: personalised content, real-time data, user-specific elements. This is where modern frameworks are heading.

For most marketing websites, static or near-static architecture delivers better performance, lower hosting cost, and lower maintenance complexity than dynamic rendering. The argument for dynamic rendering is personalisation, user accounts, and real-time data, not performance.

Measuring Speed Properly

Two types of data, used together:

Lab data (PageSpeed Insights, Lighthouse) measures performance under controlled conditions. Useful for development and diagnosing specific issues. Can be gamed by optimising for the test conditions specifically.

Field data (Chrome User Experience Report, your analytics real user monitoring) measures actual performance for your real visitors on their real devices and connections. This is what Google uses for ranking. This is what matters for your actual visitors.

Compare both. A site that scores 95 in PageSpeed Insights but has a 4-second LCP in field data has a real performance problem that the lab score is hiding. Conversely, a site with a moderate lab score but excellent field data is actually performing well for real users.

Run your site through PageSpeed Insights now. The field data section is the most actionable starting point.

Our builds load in under a second for UK visitors because of the static architecture and Cloudflare edge deployment we use by default. If your site is significantly slower, a speed audit identifies the specific causes and priorities.

Want a speed audit of your current site? Get in touch and we will assess what is causing your performance issues and what the fix involves.