What Core Web Vitals are and why they matter
Google has long factored page speed into rankings, but early speed metrics were technical measurements that did not necessarily correlate with user experience — a page could score well on time-to-first-byte while still feeling slow to a real user. Core Web Vitals are an attempt to measure what users actually experience: when does the page look ready, does it respond immediately to input, and does it stay stable as content loads in.
The three Core Web Vitals are LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). INP replaced the earlier FID (First Input Delay) metric in March 2024. A fourth metric, TTFB (Time to First Byte), is sometimes discussed in this context but is not currently a Core Web Vital.
As ranking signals, Core Web Vitals are one input among many — they do not override content quality, relevance, or backlinks. But on a competitive search result page where multiple sites have similar content quality, page experience can be the differentiator. More practically, poor Core Web Vitals scores directly reduce conversion rates: sites that load slowly, respond sluggishly to taps and clicks, or shift their layout unexpectedly lose users before they can become customers.
Data for Core Web Vitals comes from real Chrome user visits — field data — aggregated in the Chrome User Experience Report (CrUX). This is different from lab measurements in tools like Lighthouse, which run a synthetic test under controlled conditions. A page can score well in Lighthouse and still have poor field data if real users on real networks and devices experience it differently. Google's ranking signals use field data, not lab scores.
LCP: Largest Contentful Paint
Largest Contentful Paint measures how long it takes for the largest visible element above the fold to load. This is usually the hero image, a large heading, or a prominent block of text. It represents the point at which the user perceives the page as having loaded its main content.
Good threshold: 2.5 seconds or less. Needs improvement: 2.5 to 4.0 seconds. Poor: over 4.0 seconds.
The most common causes of slow LCP are: unoptimised images (large file sizes, wrong format, not sized for the viewport), render-blocking resources (CSS and JavaScript that must load before the browser can paint anything), slow server response times, and poor caching configuration. For sites hosted in Canada or serving Canadian users, the physical distance between the server and the user can also be a factor — a site hosted in the US with no CDN will typically have slower LCP for Canadian visitors than a site hosted on Canadian infrastructure or served through a CDN with Canadian edge locations.
The single highest-impact fix for most sites is image optimisation. Convert hero images and large above-the-fold images to WebP format, size them to the actual display dimensions rather than serving large images and scaling them in CSS, and use the fetchpriority="high" attribute on the LCP image element to tell the browser to prioritise loading it. Also ensure there is no loading="lazy" attribute on the LCP image — lazy loading defers loading until the image is near the viewport, which defeats the purpose for an above-the-fold hero image.
INP: Interaction to Next Paint
Interaction to Next Paint measures how quickly the page responds visually to user input — clicks, taps, and key presses. Where FID (the metric it replaced) only measured the delay to first input, INP measures responsiveness throughout the full page lifecycle, using the 98th percentile interaction as the representative score.
Good threshold: 200 milliseconds or less. Needs improvement: 200 to 500 milliseconds. Poor: over 500 milliseconds.
Poor INP is usually caused by JavaScript work happening on the main thread that blocks the browser from responding to input. When a user clicks a button and nothing appears to happen for half a second, it is usually because the main thread is busy executing JavaScript — whether that is a heavy framework render, a analytics event handler, or a third-party script doing something in the background.
The most common culprits on small business websites are: tag manager containers loading many third-party scripts, page builder JavaScript frameworks with expensive re-renders, and chat widget or ad platform scripts that run on every interaction. Auditing and reducing the number of third-party scripts is often the fastest path to INP improvement. For WordPress sites in particular, aggressive plugin use frequently introduces JavaScript that runs on every page and every interaction without most site owners realising it.
CLS: Cumulative Layout Shift
Cumulative Layout Shift measures how much the visible content of a page moves unexpectedly during loading. If you have ever started reading a paragraph and had it suddenly jump down the page because an image above it loaded late, or gone to click a button and had it move just before your finger landed — those are layout shifts.
Good threshold: 0.1 or less. Needs improvement: 0.1 to 0.25. Poor: over 0.25.
Layout shift is usually caused by images and media elements without explicit width and height attributes (the browser does not know how much space to reserve for them until they load), ads injected into the page (ad platforms often insert content that shifts other elements), web fonts loading and causing text reflow (FOIT/FOUT — flash of invisible text or flash of unstyled text), and dynamically injected content above existing content.
The fix for images is explicit: every <img> element should have both width and height attributes set to the image's intrinsic dimensions, even if CSS is then used to make it responsive. This tells the browser how much space to reserve before the image loads. For web fonts, using font-display: swap or font-display: optional in your CSS reduces the jarring reflow caused by fonts loading late.
Cookie banners and CLS. Cookie consent banners that load after the page content and push content down are a common source of CLS on Canadian websites. A banner that appears above the fold after the user has started reading the page creates a layout shift that can noticeably impact your CLS score. Banners that load from the bottom of the screen or overlay the content without shifting it are preferable from a CLS standpoint.
How to measure your Core Web Vitals
The most accurate source for your site's field data is Google Search Console. The Core Web Vitals report in Search Console shows real-world scores from actual Chrome users, grouped by mobile and desktop, and identifies which URLs are failing. This is the data that matters for ranking purposes.
PageSpeed Insights (pagespeed.web.dev) combines both field data and a Lighthouse lab test in one report. Enter your URL and you get field data for your site (or a "Not enough data" notice if your site does not have enough Chrome traffic) alongside a lab score with detailed diagnostics. The diagnostics are the actionable part — they tell you specifically what is causing slow LCP, poor INP, or high CLS.
Lighthouse in Chrome DevTools (press F12, select Lighthouse, run for Desktop or Mobile) gives you a lab score without needing to visit an external tool. Useful for testing changes before they go live, but remember that lab scores can differ significantly from field data.
For WordPress sites, the Site Health panel in recent WordPress versions includes a basic performance check. Dedicated plugins like Query Monitor can help identify which plugins are adding the most JavaScript overhead.
Core Web Vitals on WordPress sites
Most Core Web Vitals problems on small Canadian business websites are WordPress sites with accumulated performance debt. A default WordPress installation is reasonably performant; the problems accumulate through plugin additions, theme overhead, and hosting choices.
The biggest WordPress-specific issues for Core Web Vitals are: themes built with heavy page builder frameworks (Elementor, Divi) that add substantial JavaScript and CSS overhead; plugin bloat where each plugin adds its own scripts and styles to every page regardless of whether they are needed; unoptimised image uploads (WordPress does not compress or convert images to WebP by default); and shared hosting that is slow to respond to requests.
Practical WordPress improvements in order of impact: use a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache if your host supports it) to serve static HTML to most visitors; use an image optimisation plugin (Imagify, ShortPixel, or Smush) to compress and convert images to WebP automatically; defer or remove non-essential JavaScript; and consider whether your current hosting is sufficient — moving to a faster host is often a bigger improvement than any on-site optimisation.
The highest-impact improvements
Across the thousands of small business websites that have been audited for Core Web Vitals issues, the same problems appear repeatedly. In roughly descending order of impact:
Optimise and properly preload the LCP image. Convert it to WebP, size it correctly, and add fetchpriority="high" to the image tag. This alone frequently moves LCP from "needs improvement" to "good."
Set explicit dimensions on all images. Add width and height attributes to every <img> element. This is one of the highest-impact CLS fixes and is a simple change to the HTML or template.
Reduce or defer third-party scripts. Audit what is loading on every page — tag managers, chat widgets, advertising pixels, social sharing buttons — and remove or defer everything that is not essential. Third-party scripts are often the primary driver of INP problems.
Enable server-side caching. A page that is served from cache responds significantly faster than one that requires PHP and database queries to assemble. For WordPress, a caching plugin is a prerequisite for competitive Core Web Vitals scores on typical shared or managed hosting.
Upgrade your hosting. Some Core Web Vitals problems are fundamentally hosting problems — a slow server cannot be fully compensated for by optimisation. TTFB (time to first byte) under 800ms is a reasonable benchmark; if your hosting consistently takes 1–2 seconds just to respond to a request, the site will be slow regardless of what else you do.
Core Web Vitals are not a one-time fix. New plugins, content changes, and theme updates can reintroduce problems. Running a PageSpeed Insights check after major site changes is a reasonable maintenance practice, alongside checking Search Console's Core Web Vitals report monthly.