Website speed optimisation service for UK sites.

Why site speed still matters in 2026

Google confirmed Core Web Vitals as a ranking signal in 2021 and has been reweighting it upward every year since. On top of the direct ranking impact, users measure speed with the back button. Studies from Google and Cloudflare consistently show that a site loading in 1.5 seconds retains around 90% of visitors past first paint, while a site loading in 6 seconds retains under 60%. Every additional second between click and content costs measurable conversion.

Our website speed optimisation service in the UK is the work of finding what is slowing your site down and fixing it. Not a plugin install, not a caching switch, not a generic "we optimised your images" line item. A proper diagnostic and a set of specific fixes matched to what your site actually needs. This page covers what Core Web Vitals actually measure, what we fix during a typical engagement, realistic before-and-after examples, and how pricing works.

What Core Web Vitals actually measure

Google tracks three specific metrics per page, sampled from real Chrome users visiting your site. Failing any one of them measurably affects rankings.

Most WordPress sites fail at least one of these on mobile. Most e-commerce sites fail on product-listing pages loaded with faceted filters and third-party review widgets. Most custom sites pass if they were built by someone who cared. The audit finds which category your site sits in.

What we fix during a speed audit

The full fix list depends on the site, but most engagements cover:

Image optimisation

Uncompressed images are the single largest contributor to slow LCP on most sites. Fixes include: converting to next-gen formats (WebP, AVIF), sizing images correctly for their display size (not serving 4000-pixel images to a 400-pixel display), lazy-loading below-fold images, using srcset for responsive sizing, and adding proper width/height attributes to prevent layout shift. Typical impact: LCP improves 30-50% on image-heavy pages.

Font loading strategy

Web fonts are the second-largest LCP contributor. Fixes: preload critical fonts, use font-display: swap to prevent invisible text, subset fonts to only the characters actually used, self-host Google Fonts instead of loading from Google's CDN (faster on repeat visits), and reduce total font weight variants. Typical impact: LCP improves 15-25%, CLS improves significantly.

JavaScript optimisation

Blocked JavaScript is the primary INP killer. Fixes: defer non-critical scripts (analytics, chat widgets, marketing tags), remove unused JavaScript from theme frameworks, lazy-load third-party embeds (YouTube, maps, social widgets), and audit plugin overhead on WordPress. Typical impact: INP drops from 400ms+ to under 150ms on plugin-heavy WordPress sites.

Caching setup

Full-page caching for anonymous users, browser caching headers, CDN configuration, and object caching where the CMS supports it. Fixes typical WordPress "slow first load" problems by serving pre-generated HTML instead of running PHP + database queries on every request.

Layout stability

CLS fixes: reserve space for lazy-loaded images with width/height attributes, avoid injecting content above existing content after load, use font-display carefully to prevent late font swaps shifting layout, and load ads and embeds into pre-sized containers.

Hosting-level improvements

Sometimes the site is fine and hosting is the bottleneck. If a page takes 800ms just to receive the first byte, no amount of front-end optimisation will make it feel fast. We diagnose whether hosting is the ceiling and recommend migration where the case is strong.

Real before and after numbers

Sample results from recent engagements. Numbers vary by site, budget, and starting point.

The pattern is consistent: sites failing Core Web Vitals badly usually have 3 to 5 fixable root causes and can pass all three thresholds within 2 to 4 weeks. Sites already close to passing benefit less from optimisation and often benefit more from content or link work instead.

Why page builders make sites slow

Page builders like Elementor, Divi, WPBakery, and Beaver Builder ship enormous amounts of code with every page. This is not a bug, it is a design consequence. To make drag-and-drop editing feel responsive, they load their entire editor framework on every page even when nobody is editing. On top of that, every element you drag in ships extra CSS classes and JavaScript to handle animations, transitions, and responsive behaviour, most of which the page never uses.

A page built with Elementor typically ships between 800 KB and 3 MB of code before you add any images. A hand-coded page ships 40 to 80 KB. That is a 10 to 30 times difference on the wire, and no amount of caching can eliminate the actual bytes that need to be downloaded, parsed, and executed on the visitor's phone.

Speed optimisation on a page-builder site hits diminishing returns quickly. You can defer the editor scripts, lazy-load below-fold sections, cache aggressively, and swap image formats, but you cannot make the fundamental payload small. If the site was built with a page builder and speed is a persistent problem, the honest answer is often a rebuild rather than continued optimisation.

WordPress vs hand-coded speed reality

Not every WordPress site is slow. A properly-built WordPress site running a lean theme, minimal plugins, aggressive caching, and clean hosting can pass Core Web Vitals fine. The problem is that most WordPress sites accumulated 30 plugins over 5 years and were built on a bloated theme in the first place, and cleaning that up is often more expensive than starting over.

Hand-coded sites pass Core Web Vitals by default because there is less code running. This is not magic, it is math. Every plugin adds bytes. Every theme adds framework overhead. Every builder adds editor scripts. A site built without any of those cannot have those specific problems.

Our technical SEO services include speed audit as part of the retainer for existing sites, and our hand-coded website design service builds new sites that pass Core Web Vitals from day one. Which path is right depends on what you currently have and where you want to go.

Pricing

One-off speed audits start around the same tier as our Essential SEO tier on the pricing page and cover a full-site audit with prioritised fix recommendations. Fix implementation is quoted separately based on what the audit finds, typically 5 to 15 hours of dev time for a small business site.

Ongoing monitoring and quarterly re-audits are included in our SEO Growth and higher retainer tiers, so once your site passes, staying passed becomes part of the monthly rhythm rather than a recurring project.

Common questions

How slow is too slow for Google?

Failing any one Core Web Vital measurably affects rankings. Thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1. Most WordPress sites fail at least one on mobile. Any of the three failing is enough to lose rankings to competitors who pass.

Can you speed up my WordPress site or do I need a rebuild?

Both are options. If plugin bloat is the root cause, optimisation hits diminishing returns and a hand-coded rebuild delivers permanent speed. If images, caching or hosting are the bottleneck, targeted optimisation solves it. The audit tells you which.

How long does a speed audit and fix take?

Audit 3 to 5 business days. Fix implementation: 2 to 4 hours for image work, 4 to 8 hours for JS deferral, days for restructuring a slow theme. Quoted flat based on what the audit finds.

Do I need hosting changes to make the site faster?

Sometimes. Cheap shared hosting is often the ceiling. If we find hosting is the bottleneck, we recommend migration and quote it separately. Most small business sites hit sub 2s on standard shared hosting once on-site issues are fixed.

Will speeding up my site actually improve rankings?

If you currently fail Core Web Vitals and competitors pass, yes meaningfully. If you already pass and are going from 1.8s to 1.2s, the ranking impact is negligible and the effort is better spent on content or links.