Page speed and Core Web Vitals optimisation

A slow website costs you twice. Visitors on a phone give up before the page has finished drawing, and the Core Web Vitals data Google collects from Chrome users records that the site feels sluggish. Page speed optimisation is the work of finding out exactly what makes your pages slow for real UK visitors, fixing the causes in order of effect, and checking that the improvement shows up in Google’s own measurements rather than only in a one-off test.

What faster pages change for your business

Google measures how your pages behave for real Chrome users through three Core Web Vitals. Largest Contentful Paint (LCP) is how long the main image or heading takes to appear. Interaction to Next Paint (INP) is how quickly the page responds when someone taps a button or opens a menu. Cumulative Layout Shift (CLS) is how much the layout jumps while it loads. Google’s published thresholds on web.dev count a page as good when LCP is within 2.5 seconds, INP within 200 milliseconds and CLS at 0.1 or below, judged on the slowest quarter of visits.

Passing those thresholds will not lift a page above a competitor whose content answers the search better. Relevance comes first. What speed work does change is what happens after the click: fewer people leaving before the page loads, forms that respond the first time they are tapped, and checkout buttons that stay where the thumb expects them. For a business paying for every visit through ads or months of content work, that is the part of the journey you already paid to get to.

Who this service suits

It suits UK businesses whose website works but feels slow, particularly on mobile. The usual signs:

• Search Console’s Core Web Vitals report lists URLs as “Poor” or “Needs improvement” on mobile.
• The site was built with a heavy page builder or theme, and each new feature added another plugin or app.
• Marketing tags, chat widgets, review badges and a cookie banner have been added over the years and nobody knows what each one costs.
• Your developer has tried a caching plugin and the scores barely moved.
• Paid traffic lands on pages that take several seconds to show anything on a phone.

It is not the right starting point if Google is not indexing your pages, shows the wrong version of them, or your traffic fell after a rebuild. Those are crawling and indexing problems, which technical SEO deals with. If you do not yet know whether speed is your main problem at all, an SEO audit weighs it against content, links and structure first, so you spend on the right thing.

What the work covers

How the work runs

1. Baseline. I record field data from Search Console and the Chrome UX Report for your main page templates, alongside lab tests on a throttled mobile connection, so there is a fixed starting point.
2. Diagnosis. For each slow template I identify the LCP element, the scripts that block interaction and the elements that shift, and trace each back to its source.
3. Prioritised plan. Every fix is listed with its expected effect, the effort involved, who should make it and what it could affect, such as tracking, consent or a checkout integration.
4. Changes. The fixes are made on a staging copy where one exists, and tested before going live.
5. Verification. Lab tests confirm the change straight away. Google’s field data is a rolling 28-day window, so I check Search Console again once enough new visits have been recorded and report what moved and what did not.

Speed problems I see most often on UK sites

• A homepage slider of four full-width photos, where only the first is ever seen and all four load at once.
• The hero image set to lazy load, so the most important picture on the page is the last to be requested.
• Several tracking tags firing the same events, left behind by previous agencies or old campaigns.
• A cookie consent tool that loads its own heavy script and then shifts the whole page when the banner appears.
• Third-party review and booking widgets loaded on every page rather than only where they are used.
• Four or five font weights downloaded when the design uses two.
• Cheap shared hosting with no page caching, so every visit rebuilds the page from the database.

None of these needs a new website. Most are fixed by changing settings, templates or what loads where. On WordPress sites and Shopify stores the details differ, but the same few causes account for most of the slowness.

What you receive

• A baseline of field and lab results for each main template, so progress can be measured against something fixed.
• A prioritised fix list in plain English, with the technical detail your developer needs set out separately.
• A register of third-party scripts: what each does, who owns it, what it costs in speed and whether it stays.
• Before-and-after test results once the changes are live, and a follow-up check of Search Console after the field data has caught up.
• Short house rules for keeping the site fast: image sizes for uploads, how to judge a new plugin or app, and who approves new tags.

If the findings show the site cannot be made fast without being rebuilt, I say so and explain why, and a website redesign can be planned with speed built in from the start.