The three Core Web Vitals to check, in order, are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.10. On most small business sites the metric that fails is LCP, and the usual cause is image weight above the fold. Run PageSpeed Insights on your busiest page and read the mobile tab first.
What follows is the order we work in on a performance rebuild — and one image-delivery approach we tried that produced a configuration which looked flawless in every dashboard and delivered nothing measurable to real visitors, because of how CDNs cache.
What are Core Web Vitals, and which one should you check first?
Core Web Vitals are three measurements Google collects from real Chrome users on your site: how quickly the main content appears, how fast the page responds when someone taps it, and how much the layout jumps around while it loads. Each is scored pass or fail against a published threshold, and mobile is assessed before desktop.
| Metric | What it measures | Passing threshold | The cause we find most often |
|---|---|---|---|
| LCP Largest Contentful Paint |
How long until the biggest thing on screen — usually the hero image or headline — has finished rendering. | Under 2.5s | An uncompressed hero image, a slider, or a background video loading above the fold. |
| INP Interaction to Next Paint |
How long the page takes to visibly respond after a tap, click or keypress. It replaced First Input Delay in 2024. | Under 200ms | Too much JavaScript on the main thread: chat widgets, booking embeds, tracking scripts, page-builder bloat. |
| CLS Cumulative Layout Shift |
How much content moves position while the page loads — the reason you tap the wrong button. | Under 0.10 | Images and embeds with no width and height in the markup, plus late-loading web fonts. |
Takeaway: check LCP first because it fails most often and because fixing it is largely a content decision you control. CLS is second because it is usually cheap to fix and it is the one visitors physically feel. INP is third: it fails less often on a brochure site, and when it does fail the fix is removing scripts rather than tuning them.
How do you check Core Web Vitals on your own site?
You do not need a paid tool. You need to look at the right tab, and you need to know the difference between a lab simulation and what actual visitors experienced. Work through these in order:
- Pick the page that matters, not the homepage. Whichever page brings in the most enquiries is the page to test. For most Brantford trades and clinics that is a single service page, not the front door.
- Run it through PageSpeed Insights and stay on the mobile tab. Desktop scores flatter almost every site and are not what Google assesses first.
- Read the field data at the top before the score at the bottom. The coloured 0–100 number is a lab simulation. The section labelled real-user experience is what actually counts, and a site can score 70 in the lab while passing all three vitals in the field.
- Cross-check in Google Search Console. Its Core Web Vitals report groups every URL on the site, so you find out whether one page is slow or the whole template is.
- Note which single metric fails and what the diagnostics blame. One named cause beats a list of twenty suggestions you will never action.
- Change one thing, then retest. Field data updates on a 28-day rolling window, so lab-test immediately for direction and expect the real numbers to move over weeks.
Worth knowing: if your page has too few visitors, the field data section will be missing entirely. That is not a failure — it means Google has no real-user sample for you yet, and the lab score is the only signal you have.
Why does image weight break LCP more often than anything else?
Because the largest element on a typical small business page is a photograph, and photographs are the one asset most sites upload straight from a camera or a stock library at full size. A 3 MB hero image cannot render in 2.5 seconds on a phone using mobile data on the edge of town, no matter how good your hosting is.
The standard fix is a modern image format, correct dimensions and lazy loading below the fold. That advice is correct and it is also where most implementations quietly go wrong.
What did not work: serving modern image formats by Accept-header negotiation behind a CDN
The classic approach is a rewrite rule in .htaccess that inspects the browser’s Accept header and returns a WebP file instead of the JPEG when the browser supports it. Same URL, different bytes. It is elegant, it is widely recommended, and we have watched it deliver nothing.
The reason is caching. A CDN caches a response against its URL. Unless it has been explicitly configured to vary its cache on the Accept header, whichever version it stores first is the version every subsequent visitor receives — and that is usually the JPEG. Cloudflare’s own cache behaviour documentation spells out that caching is keyed on the URL. Origin-side negotiation and edge caching are working against each other by design.
| Approach | What the configuration looks like | What the visitor actually receives |
|---|---|---|
Accept-header negotiation via .htaccess, behind a CDN |
Correct. Rules validate, and testing directly against the origin returns WebP. | The original JPEG, to nearly everyone, because the edge cached one response per URL. |
| Rewriting the image URLs in the HTML | Less clever. The page markup points at a distinct .webp file, with a <picture> fallback for anything that cannot use it. |
The smaller file, reliably, because the URL itself differs and the CDN caches each one separately. |
The lesson generalises past images: any optimisation that depends on the origin varying its response per visitor is fragile once an edge cache sits in front of it. If two visitors should receive different bytes, give those bytes different URLs.
What did not work: running two image optimisation plugins in sequence
The second thing we have tested and abandoned is stacking compression tools, on the theory that two passes squeeze harder than one. They do not. Once a format conversion has done the real work, a second lossy pass adds almost no further saving and visibly degrades the assets with flat colour and hard edges — a logo is where you notice it first, and a degraded logo above the fold costs you more credibility than the kilobytes were ever worth.
What should you do about images instead?
- Resize before uploading. No image on a small business site needs to be 4000px wide. This single step usually outperforms every plugin.
- Convert to a modern format, but verify each result. Conversion is not automatically a win — on a real site we converted, a small number of files came out larger as WebP than the original and were correctly left alone. Blanket “convert everything” advice is wrong.
- Serve the converted file by its own URL, for the caching reason above.
- Set explicit width and height attributes on every image, which fixes CLS at the same time.
- Do not lazy-load the hero image. Lazy loading below the fold helps; lazy loading the LCP element delays the exact thing being measured.
How do you get Cumulative Layout Shift close to zero?
CLS is the most fixable of the three, because its causes are a short and well-understood list. Nothing here requires a rebuild:
- Width and height attributes on every image, video and iframe. The browser then reserves the correct space before the file arrives instead of reflowing the page around it.
- Reserve space for anything injected after load — cookie bars, review widgets, booking embeds, map iframes.
- Preload the fonts used above the fold and set a matching fallback, so the headline does not resize when the web font swaps in.
- Never insert content above existing content once the page has painted. That is what moves the button out from under a thumb.
What makes INP fail, and how do you fix it?
INP fails when the browser’s main thread is busy running JavaScript at the moment someone taps. On a small business site the culprit is nearly always something bolted on rather than something built in:
- Live chat widgets, which are typically the single heaviest third-party script on a local business page.
- Multiple tracking and pixel scripts loading in the head rather than deferred.
- Sliders and carousels, which cost you INP and LCP simultaneously and which, in our experience, rarely earn their place — visitors read the first slide and scroll.
- Page-builder widgets doing work in the browser that could have been rendered once on the server.
The honest fix is subtraction. Audit what each third-party script contributes in enquiries, remove what cannot answer that question, and defer whatever survives. Tuning heavy scripts is a much worse trade than deleting them.
Do Core Web Vitals actually affect where a Brantford business ranks?
They are a real but modest ranking factor, and it is worth being precise rather than selling panic. Google treats page experience as a tiebreaker: it will not lift weak content above strong content, but between two comparable local businesses competing for the same search, the faster site wins the position. Relevance and proof still do most of the work.
The stronger argument is commercial, not algorithmic. A slow page loses the visitor before the ranking ever mattered — which is the same pattern we described in our breakdown of why slow websites lose local leads. For a Brantford contractor or clinic competing against businesses in Hamilton and Cambridge for the same searches, speed is one of the few advantages you can buy outright.
What does it cost to fix Core Web Vitals in Brantford?
It depends entirely on whether the weight is something added to the site or something baked into how every page renders. Compressing images and removing three scripts is an afternoon. A theme that ships 900 KB of JavaScript on every page is not a tuning problem.
| Situation | What the work involves | Typical route |
|---|---|---|
| One or two pages fail, the rest pass | Oversized images and a couple of third-party scripts on those templates. | A targeted fix on the site you already have. |
| Every page fails the same way | The weight is in the theme or builder, so each fix is undone by the next update. | A rebuild is usually cheaper than repeated patching — Starter from $1,499 or Growth from $2,999 depending on how many services need their own page. |
| A store failing on product and checkout pages | Product imagery, filtering scripts and checkout steps all compounding. | A commerce build with performance treated as part of scope — Commerce from $4,999. |
Our builds are fixed-price and quoted from scope rather than by the hour, and performance is part of the build rather than a later upsell. The same standards run through our custom web design and technical SEO services, and the local context for how we work in the county is on our page covering web design for Brantford businesses. We work with businesses along the whole Grand River corridor, so if you are further downriver the same approach applies to web design in Caledonia.
Frequently asked questions about Core Web Vitals in Brantford
What is a good Core Web Vitals score?
There is no single score — there are three separate pass or fail thresholds. Largest Contentful Paint should be under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.10. You need all three at once, measured on mobile, for the page to be assessed as passing.
Why does my PageSpeed score change every time I run it?
Because the coloured 0 to 100 number is a lab simulation run on a throttled connection, and it varies between runs. The field data section above it does not fluctuate that way: it reports what real Chrome users experienced over a 28-day rolling window. Trust the field data and treat the lab score only as a direction to work in.
Will converting my images to WebP fix my LCP?
Usually it helps, but not automatically, and how you deliver the file matters as much as the format. On a real site we converted, a small number of files came out larger as WebP than the original and were correctly left alone. More importantly, serving the modern format by Accept-header negotiation behind a CDN often delivers the original file anyway, because the CDN caches one response per URL. Give the converted image its own URL instead.
Does Core Web Vitals affect local rankings?
It is a genuine ranking factor but a modest one. Google treats page experience as a tiebreaker: it will not lift weak content above strong content, but between two comparable local businesses competing for the same search, the faster site wins the position. The bigger cost of a slow page is the visitor who leaves before the ranking ever mattered.
How long does it take for Core Web Vitals to improve after a fix?
Lab tests respond immediately, so you can confirm the direction the same day. The real-user field data that Google assesses updates on a 28-day rolling window, so expect roughly four weeks before the reported numbers fully reflect the work. Change one thing at a time or you will not know which fix earned the result.
What should you check first on your Brantford website?
Open your busiest service page in PageSpeed Insights, read the mobile tab, and find the single metric that fails. If it is LCP, look at the largest image above the fold before you look at anything else. If it is CLS, check whether your images carry width and height attributes. If it is INP, count your third-party scripts and ask what each one earns.
And whatever you change, verify it against what visitors actually receive rather than what the settings screen reports — the failure described above passed every configuration check it was given. If you want a starting point that covers more than speed, our small business website checklist works through the rest in priority order. When you want a number, request a fixed-price website quote and we will come back with a scope, a price and a launch date.