Core Web Vitals and SEO: The Complete Guide to Website Performance, Rankings and User Experience

Core Web Vitals sit at an unusual intersection. They are simultaneously a technical SEO topic, an infrastructure question, a front-end engineering problem, a user-experience measure, and a conversion-rate lever. That breadth is why the subject generates so much confused advice: an SEO specialist, a developer, and a hosting provider will each describe Core Web Vitals accurately and still leave you with three different action plans.

The question most people arrive with is whether Core Web Vitals affect SEO. The honest answer needs three parts, because collapsing them into one is where most articles go wrong.

1. Ranking: Google states that Core Web Vitals are used by its ranking systems and recommends good scores for Search. They are part of a broader page experience assessment, not a standalone signal, and they do not override relevance. Passing them does not produce a first-page ranking.
2. User experience: this is where the effect is direct and uncontested. A page that renders quickly, responds promptly to taps, and does not shift under the reader's finger is measurably easier to use. No algorithm is required for that to matter.
3. Business outcome: several companies have published controlled tests connecting Core Web Vitals improvements to sales, conversion rate, and engagement. The evidence is real, it is worth understanding, and it is correlational in most cases rather than a guarantee that your site will see the same numbers.

Keeping those three separate changes what you do. If you treat Core Web Vitals purely as a ranking tactic, you will chase a PageSpeed Insights score, hit 100 in a lab tool, see nothing change in Search Console, and conclude the whole subject is noise. If you treat it as a user-experience and revenue question that also supports search performance, you will prioritise differently, measure differently, and get a return whether or not rankings move.

This guide covers what the three metrics actually measure, what Google has and has not said about their role in ranking, how to diagnose each one, and the part most performance content skips: which problems are caused by your hosting infrastructure and which are caused by your front end. Those require different fixes, different budgets, and different people. Confusing them is the most expensive mistake in this field. A business can spend months migrating to a faster server and see no improvement in Cumulative Layout Shift, because layout stability was never a server problem.

The Canadian dimension is covered too, since it comes with genuine considerations that are usually either overstated or ignored: latency for Canadian audiences, data residency, and what PIPEDA does and does not require of organisations choosing where to host.

What are Core Web Vitals?

Core Web Vitals are a subset of Google's Web Vitals initiative: a small set of metrics chosen to represent distinct facets of real-world user experience. The word “core” matters. Google tracks many performance metrics, but only three are designated Core Web Vitals, and they are the three reflected in Search Console and used by Google's ranking systems.

The current three, as of this writing, are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Each maps to a question a real visitor would ask without knowing any of the terminology.

Metric	What it measures	Good	Needs improvement	Poor	What the visitor experiences
Largest Contentful Paint (LCP)	Time until the largest visible content element finishes rendering	2.5 s or less	2.5 s to 4.0 s	Over 4.0 s	“Has this page loaded yet, or is it broken?”
Interaction to Next Paint (INP)	Latency from a user interaction to the next visual update, across the visit	200 ms or less	200 ms to 500 ms	Over 500 ms	“I tapped that. Did it register?”
Cumulative Layout Shift (CLS)	Cumulative score of unexpected layout movement during the page's lifespan	0.1 or less	0.1 to 0.25	Over 0.25	“The button moved and I clicked the wrong thing.”

The three facets: loading, responsiveness, visual stability

The set is deliberately structured so the metrics do not overlap. LCP covers loading, INP covers responsiveness, CLS covers visual stability. A page can pass one and fail another, and in practice most do. This is also why a single number cannot represent performance: a page that renders in one second but freezes for half a second on every tap is fast and unusable at the same time.

That independence has a practical consequence for how you plan work. Improving LCP and improving CLS are largely unrelated projects, drawing on different skills. LCP work is often infrastructure and asset delivery. CLS work is almost entirely templates and CSS. INP work is JavaScript. Bundling them into one “speed project” and assigning it to one person tends to produce partial results.

The 75th percentile, and why averages mislead

Core Web Vitals assessment is generally based on the 75th percentile of real-world page visits, segmented between mobile and desktop. The threshold has to be met by 75% of visits for the metric to be considered good. This single design decision explains most of the confusion people have when reading their own reports.

An average hides the visits that matter. A site can average a 1.8-second LCP and still fail, if a quarter of visits are slow enough to push the 75th percentile past 2.5 seconds. Those slow visits are not statistical noise: they are real people, typically on older devices, weaker connections, or hitting the site when the server is busy. Optimising for the average optimises for the visitors who were already having a reasonable time.

Google has published its reasoning for choosing both the thresholds and the percentile, and the underlying logic is worth knowing: thresholds were selected to be achievable by a meaningful share of real sites while still representing a genuinely good experience, and the 75th percentile was chosen as a balance between representing most users and remaining stable enough to act on.

What Core Web Vitals do not measure

Being clear about the boundaries prevents wasted effort. Core Web Vitals say nothing about whether your content answers the query, whether your information architecture makes sense, whether your checkout is trustworthy, or whether your site is accessible. They do not measure Time to First Byte, First Contentful Paint, or Total Blocking Time, though all three are useful diagnostics that feed into the three that count. And they are not a security or crawlability assessment.

A page with perfect Core Web Vitals and thin, irrelevant content will not rank. This is not a hedge; it is the single most important framing in this article, and section three explains exactly why.

Core Web Vitals and Google's ranking systems

The relationship between Core Web Vitals and rankings has been overstated by vendors selling optimisation and dismissed by practitioners who tried it once and saw nothing. Both reactions come from the same error: treating a contributory signal as if it were a decisive one.

A brief history, because it explains the confusion

Google announced in 2020 that page experience signals, including Core Web Vitals, would become part of ranking, and rolled the change out for mobile through 2021, followed by desktop in early 2022. The rollout was accompanied by a badge concept that Google later dropped, and by a Search Console report that many site owners saw for the first time.

The metric set has since changed once, and this is the change most out-of-date content still misses. First Input Delay, the original responsiveness metric, measured only the delay before the browser began processing the first interaction. It did not capture how long the page took to actually update, and it ignored every interaction after the first. Interaction to Next Paint replaced it as a Core Web Vital in March 2024, measuring the full latency from interaction to the next visual update, and considering interactions throughout the visit. Any guide still presenting FID as current guidance predates that change.

Google has also simplified how it describes the whole area over time, moving from the language of a discrete “page experience update” toward describing page experience as something its ranking systems consider on an ongoing basis. The practical guidance has been stable: aim for good Core Web Vitals because they reflect a good experience, not because a specific score unlocks a specific position.

What Google actually says about Core Web Vitals and rankings

Stripped of interpretation, Google's documented position amounts to a few points that are easy to state and easy to misread:

1. Core Web Vitals are used by Google's ranking systems, and Google recommends good Core Web Vitals for success with Search.
2. Page experience is not a single ranking signal that can be isolated and optimised in a vacuum. It is a set of considerations.
3. There is no threshold score that guarantees a ranking benefit, and no specific tool score is the objective.
4. Content relevance and quality remain the dominant factors. Google has consistently said that great page experience does not override having relevant, useful content.
5. Conversely, exceptional content can rank well despite a mediocre page experience, particularly where no better-performing page answers the query.

The most useful way to hold this is that performance behaves like a differentiator between pages that are otherwise comparable in relevance and quality. Where several results serve the query about equally well, the experience of using them can contribute to the ordering. Where relevance differs meaningfully, relevance wins. This is why a site can pass all three metrics and see no ranking movement: the constraint was never performance.

What this means for how you should plan Do not build a business case for Core Web Vitals work on projected ranking gains. You cannot forecast them, and if rankings do not move, a genuinely valuable project gets recorded as a failure. Build the case on user experience and conversion, both of which you can measure directly on your own site. Treat any ranking improvement as an additional return rather than the objective.

Why perfect scores are the wrong target

A PageSpeed Insights score of 100 is not the goal and does not guarantee anything for SEO. That score is a weighted composite of lab measurements from a simulated device and network, and it is not the assessment Google uses for ranking purposes. Real-user field data is.

Chasing 100 also creates perverse incentives. Teams remove analytics that the marketing department needs, strip functionality that users rely on, defer scripts until interactions break, or install a stack of optimisation plugins that conflict with one another. The score improves; the site gets worse. The target is passing the three thresholds on field data for the page templates that actually receive traffic. Beyond that, additional effort has diminishing returns and should be redirected to content, conversion, or whatever else is genuinely constraining the business.

Largest Contentful Paint explained

Largest Contentful Paint measures how long it takes for the largest content element in the viewport to finish rendering. It is the closest single proxy for the visitor's question “is this page working?”, and it is the metric most sites fail first.

What the LCP element usually is

In practice the LCP element is a hero image, a background image applied via CSS, a video poster frame, or a large block of text such as an H1 or article intro. Identifying it correctly is the first diagnostic step, and it is where a surprising number of optimisation efforts go wrong from the outset.

Nuvemshop, the Latin American ecommerce platform behind more than 180,000 stores, published a case study that makes this point better than any general advice could. Their initial hypothesis for poor LCP across the platform was image weight or server latency. That hypothesis was wrong. Because their themes let merchants reorder homepage sections freely, the element the browser identified as LCP was not consistently the element they had optimised. Once they addressed LCP element identification and prioritisation, LCP pass rates across their stores moved from 57% to 96%, and overall Core Web Vitals pass rates from 48% to 72%.

The transferable lesson is that you should confirm which element the browser actually treats as LCP on your own templates before optimising anything. Chrome DevTools reports it directly. Optimising the image you assume is the hero, while the browser is timing something else, produces exactly the frustrating outcome of hard work and unchanged metrics.

The four phases of LCP, and where time is actually lost

LCP is best understood as a chain of four phases, because the fix depends entirely on which phase is consuming the time.

Phase	What happens	Typical cause of delay	Where the fix lives
Time to First Byte	Browser requests the document; first byte arrives	Slow server, no caching, slow database, distance to origin	Hosting and infrastructure
Resource load delay	Time between TTFB and the browser starting to load the LCP resource	Late discovery: image referenced in CSS or injected by JavaScript	Front end and templates
Resource load duration	Time to download the LCP resource	Oversized or uncompressed image, wrong format, no CDN	Assets and delivery
Element render delay	Resource is downloaded but not yet painted	Render-blocking CSS or JavaScript, font loading strategy	Front end

This breakdown is the single most useful diagnostic in Core Web Vitals work. A site with a 4-second LCP where 2.5 seconds is TTFB has a hosting problem, and no amount of image compression will fix it. A site with a 4-second LCP where TTFB is 200 milliseconds and the image takes 3 seconds to download has an asset problem, and moving to a faster server will change almost nothing. Both sites have “bad LCP” and they need opposite interventions.

Practical diagnostic workflow for LCP

1. Confirm the page group matters. Check which templates receive traffic before optimising a page nobody visits.
2. Pull field data first, from the Core Web Vitals report in Search Console or the field section of PageSpeed Insights. This tells you whether real users are affected.
3. Identify the LCP element in Chrome DevTools on a throttled mobile profile. Do not assume.
4. Break LCP into the four phases above and find which dominates.
5. If TTFB is the largest share, investigate caching, database performance, and server capacity before touching the front end.
6. If load delay dominates, the resource is being discovered late. Reference it in HTML rather than CSS, and consider a preload or fetchpriority hint.
7. If load duration dominates, address dimensions, compression, and format, and serve from a CDN.
8. If render delay dominates, look at render-blocking CSS and JavaScript in the head, and at font display strategy.
9. Change one thing, then re-measure. Simultaneous changes make attribution impossible.

Two field notes from real diagnosis work. First, an oversized hero image is still the most common single cause of poor LCP on small-business sites, usually because it was uploaded straight from a camera or phone at full resolution and scaled down in CSS. The browser downloads the full file regardless. Second, render-blocking CSS in the document head is chronically underestimated: a stylesheet that takes 800 milliseconds to fetch and parse delays the paint of an image that was already in memory.

Interaction to Next Paint explained

Interaction to Next Paint measures how quickly a page responds visually to user input. It considers interactions throughout the visit and reports a value representing the site's responsiveness, rather than looking only at the first interaction. Where LCP asks whether the page loaded, INP asks whether the page works once it has.

Why INP replaced FID, and why it is harder to pass

First Input Delay measured only the input delay portion: how long the browser waited before it could begin processing the first interaction. A page could score well on FID and still feel broken, because the actual work triggered by the tap took another second, and because everything after the first interaction was invisible to the metric.

INP closes both gaps. It measures the full duration from the interaction to the next paint, which includes input delay, the event processing time, and the presentation delay before the browser can paint. Because it captures the whole chain and looks across the visit, many sites that comfortably passed FID do not pass INP. That is not a regression in those sites; it is the metric finally measuring what users were already experiencing.

Component of INP	What it covers	Common cause
Input delay	Waiting for the main thread to be free to handle the event	A long task already running: third-party script, hydration, analytics batch
Processing time	Running the event handlers	Heavy JavaScript, expensive DOM queries, synchronous work in the handler
Presentation delay	Recalculating style and layout, then painting	Large or deeply nested DOM, expensive CSS, layout thrashing

Long tasks and the main thread

Nearly all INP problems reduce to one mechanism: the browser's main thread is single-threaded, and while it is executing JavaScript it cannot respond to input. Any task occupying the main thread for more than 50 milliseconds is a long task, and a tap arriving during one waits for it to finish.

The practical culprits, roughly in order of how often they turn up:

1. Third-party scripts. Tag managers, chat widgets, heat-mapping tools, consent platforms and advertising scripts all execute on your main thread. A single tag manager container loading a dozen tags is a common cause of poor INP, and it is frequently invisible to the marketing team that added it.
2. Consent and cookie banners. These typically load early, block interaction by design, and run substantial JavaScript. A poorly implemented banner can dominate INP on every page of a site.
3. Framework hydration. On JavaScript-rendered sites, the period during which the page looks ready but is not yet interactive produces exactly the mismatch INP is designed to catch.
4. WordPress plugin accumulation. Every plugin that enqueues a script on every page contributes, and page builders often load substantial JavaScript regardless of whether a page uses their interactive features.
5. Expensive event handlers. Handlers that read layout properties and then write to the DOM in a loop force repeated synchronous layout, a pattern known as layout thrashing.
6. Excessive DOM size. A page with tens of thousands of nodes makes every style recalculation and layout pass more expensive, inflating presentation delay even when the JavaScript is efficient.

How to actually improve INP

The techniques that work are less about deleting code than about scheduling it. Break long tasks into smaller pieces so the browser has opportunities to respond between them. Yield to the main thread inside long-running work. Defer non-essential work until after the interaction has been acknowledged visually, so the user sees a response while the heavy work continues. Move genuinely expensive computation to a web worker where feasible. And audit third-party scripts on the basis of whether the business value justifies the measured cost, because that is a commercial decision rather than a technical one.

QuintoAndar, Brazil's largest housing platform, published a useful account of doing this at scale. Having identified that they had the worst INP among their competitors, they treated it as an organisational priority rather than a ticket, reduced INP by 80%, and reported a 36% year-over-year increase in conversions. The organisational detail is as instructive as the number: INP problems are usually distributed across many teams' scripts, which is why they persist when treated as one developer's task.

A trade-off most articles omit Removing JavaScript is the fastest route to better INP, and it is not free. Strip a tag manager and you may lose the attribution data your marketing spend depends on. Remove a chat widget and you may lose qualified leads. Defer analytics too aggressively and you will under-count conversions. The correct decision is a business judgement informed by measurement, not a performance-score maximisation. Measure what each third-party script costs in INP, put that next to what it earns, and decide deliberately.

Cumulative Layout Shift explained

Cumulative Layout Shift measures unexpected movement of visible content. It is the only Core Web Vital that is not a time measurement, and the only one that is almost entirely within the front end's control. It is also the metric with the most direct link to visible user frustration: a shifted button is the reason someone taps the wrong thing and leaves.

How the score works, including session windows

Each shift is scored by multiplying the fraction of the viewport affected by the distance the content moved. Both matter: a small element moving a long way and a large element moving slightly can produce similar scores.

The word “cumulative” once meant that every shift over the page's entire lifespan was summed, which unfairly penalised long-lived pages and infinite-scroll layouts. The metric now uses session windows: shifts are grouped into windows separated by gaps in shifting activity, and the reported score is the largest window rather than the total. This is why a long article page is not automatically penalised for a shift near the top and another near the bottom.

Shifts caused directly by user interaction are excluded within a short window afterwards, on the reasoning that a person who taps “show more” expects the layout to change. That exclusion is narrow, so a delayed response to an interaction can still be counted.

The six recurring causes

Cause	Mechanism	Fix
Images without dimensions	Browser cannot reserve space, so text reflows when the image arrives	Set width and height attributes, or use CSS aspect-ratio
Advertising slots	Ad arrives late and pushes content down	Reserve the slot at its largest expected size; avoid inserting ads above existing content
Web fonts	Fallback font renders, then swaps to the web font with different metrics	Preload critical fonts; use font-display sensibly; use size-adjust to match fallback metrics
Dynamically injected content	Banners, notification bars, personalisation blocks inserted above existing content	Reserve space, or inject below the fold, or render server-side
Cookie and consent banners	Inserted at the top after render, shifting everything beneath	Use a fixed overlay rather than an in-flow block, or reserve space
Embeds and iframes	Third-party embed resizes itself after loading	Reserve space using known aspect ratios; constrain with a container

A practical note from diagnosis: CLS problems are frequently invisible on a developer's machine, because assets are cached and the connection is fast enough that late-arriving resources arrive before anything paints. Always test with an empty cache on a throttled connection. The shift that ruins the metric for real users often cannot be reproduced locally at full speed.

Two case studies quantify the business side. Yahoo! JAPAN News reduced CLS by 0.2, cut the number of URLs reported as poor in Search Console by 98%, and recorded a 15.1% increase in page views per session, 13.3% longer sessions, and a 1.72 percentage point reduction in bounce rate. Farfetch, working across their conversion funnel, found an exit-rate decrease of 3.1% for each 0.01 reduction in CLS. Neither result is a promise for your site, but both illustrate that layout stability is an engagement issue rather than a cosmetic one.

Field data versus lab data: why your tools disagree

The most common source of frustration in Core Web Vitals work is that two Google tools appear to contradict each other. Lighthouse reports a score of 95 while Search Console reports the same URLs as poor. Both are correct, because they are measuring different things.

What each tool actually is

Tool	Data type	What it measures	Best used for
Chrome UX Report (CrUX)	Field	Aggregated real-user data from opted-in Chrome users, typically over a rolling 28-day window	The source of truth for how users experience your site
Search Console Core Web Vitals report	Field	CrUX data grouped into URL groups by similar templates	Finding which page templates fail, at scale
PageSpeed Insights	Both	Field data from CrUX where available, plus a Lighthouse lab run	Diagnosing a single URL with both perspectives side by side
Lighthouse	Lab	Simulated device and network on one synthetic load	Reproducible before-and-after comparison during development
Chrome DevTools	Lab	Live inspection with throttling, LCP element identification, long-task traces	Root-cause diagnosis of a specific problem
Real user monitoring (RUM)	Field	Your own instrumentation, segmentable by page, device, geography, cohort	Continuous monitoring and correlating performance with business metrics

Five reasons lab and field disagree

1. Device and network. Lighthouse simulates a mid-tier mobile device on a throttled connection. Your real audience is a distribution, and the 75th percentile of that distribution may be slower than the simulation.
2. INP cannot be measured in a lab. INP requires actual interactions. Lighthouse reports Total Blocking Time as a proxy, which is useful but not the same metric. A good lab score tells you little about real INP.
3. Caching state. A lab run typically hits a warm cache on the origin or CDN. Real users arrive at all hours, including when a cache is cold or a server is under load.
4. If your CrUX data is dominated by visitors far from your origin, their latency is baked into the field numbers and absent from a test run near your server.
5. The 28-day window. Field data reflects a rolling period, so a fix deployed today does not appear immediately, and a fix deployed three weeks ago is still being diluted by the old experience.

That last point causes more confusion than any other. When a genuine improvement ships, the field report improves gradually as the window rolls forward, which means the full effect of a change takes several weeks to become visible. Teams that judge a fix after one week routinely conclude it did not work and revert it.

The operating rule Use field data to decide what to work on and whether it worked. Use lab data to diagnose why and to compare a change before and after during development. Never let a lab score be the success criterion, and never try to diagnose root cause from field data alone.

How web hosting affects Core Web Vitals

This is the section where most content either overstates hosting's role or ignores it. The accurate position is specific: hosting has a decisive influence on one Core Web Vital, a partial influence on a second, and almost none on the third.

Metric	Hosting influence	Why
LCP	High	Time to First Byte is a direct component of the LCP chain, and the LCP resource is usually served by your origin
INP	Low to moderate	Mostly main-thread JavaScript. Server latency contributes when an interaction triggers a request, and constrained CPU can slow any server-rendered response
CLS	Minimal	Layout stability is determined by templates, CSS and third-party insertion. A faster server does not reserve space for an image

Anyone claiming a hosting upgrade will fix all three is overselling. Anyone claiming hosting is irrelevant to Core Web Vitals has not looked at a TTFB breakdown on a shared plan under load.

Time to First Byte: the mechanism that matters

TTFB is the interval between the browser requesting the document and the first byte of the response arriving. It is not itself a Core Web Vital, but it sets a floor for everything downstream. Google's web.dev guidance treats a TTFB of 0.8 seconds or less at the 75th percentile as good, and above 1.8 seconds as poor, while noting these are rough guides rather than requirements because sites differ in how they deliver content.

The arithmetic is unforgiving. If TTFB is 2 seconds, LCP cannot be better than 2 seconds, no matter how well the image is compressed. This is the reason hosting cannot be dismissed: it is capable of making a good LCP arithmetically impossible.

TTFB itself decomposes into DNS resolution, TCP connection, TLS negotiation, the request, and server processing time. Only the last is purely your host's application performance; the others are affected by network topology and configuration, which is why a CDN can improve TTFB even when server processing is fast.

The infrastructure factors, and what each can realistically change

Factor	Potential Core Web Vitals impact	Notes
Full-page caching	High on LCP via TTFB	The single largest lever on most CMS sites. Serving a cached document skips application and database work entirely
Object caching	Moderate on LCP	Caches repeated database query results. Matters most for dynamic pages that cannot be fully cached
CPU availability	High and variable	On oversold shared hosting, TTFB degrades exactly when traffic peaks. Averages look acceptable; the 75th percentile does not
Database performance	Moderate to high	Slow or unindexed queries add directly to server processing time. A common hidden cause on long-lived WordPress sites
Storage (SSD/NVMe)	Moderate	Faster I/O reduces database and file-read latency. Largely a solved problem on modern plans; verify what a provider actually offers
Memory	Moderate	Insufficient memory forces swapping or kills processes under load, producing intermittent slow responses and errors
Geographic distance	Moderate on LCP	Every round trip costs time. Real and measurable, and the reason origin location matters for a concentrated audience
CDN	Moderate to high	Serves static assets and sometimes cached documents from an edge near the user. Reduces load duration and can improve TTFB
HTTP/2 and HTTP/3	Low to moderate	Multiplexing and improved connection handling reduce overhead, particularly on high-latency mobile connections
Compression (Brotli/Gzip)	Low to moderate	Smaller text payloads download faster. Brotli generally compresses better than Gzip for text
TLS configuration	Low	Session resumption and modern protocol versions shave handshake time. Small but free
PHP version and tuning	Moderate	Current PHP versions execute meaningfully faster. OPcache configuration matters on busy sites
Traffic spike headroom	High when it applies	A plan sized for average traffic fails at peak, and peak is when your most valuable visitors arrive

Shared, VPS, dedicated: what actually differs

The meaningful difference between hosting tiers, for Core Web Vitals purposes, is not headline speed but consistency. Shared hosting can be perfectly adequate when the server is quiet. The problem is resource contention: your response times depend partly on what other accounts on the machine are doing. Because Core Web Vitals are assessed at the 75th percentile, a plan that is fast most of the time and slow at your busiest hour can fail while appearing fine in casual testing.

VPS hosting allocates guaranteed resources, which converts variable performance into predictable performance. Canadian dedicated servers remove contention entirely and provide the most headroom for large databases and sustained load. managed WordPress hosting takes a different approach, applying server-level caching, tuning and maintenance specifically for WordPress workloads, which for many businesses removes the most common causes of poor TTFB without requiring anyone in-house to configure it. We have covered server-side caching versus plugin caching and how managed WordPress hosting improves Core Web Vitals separately.

This is also the practical answer to the question behind most searches for the best hosting company in Canada: the right tier is the one that holds a consistent response time at your busiest hour, not the one with the longest feature list. The upgrade trigger to watch for is variance rather than volume. If your TTFB is 250 milliseconds overnight and 2 seconds at 2pm, you have outgrown shared resources and no plugin will resolve it. If TTFB is uniformly slow including on cached pages, the tier itself is inadequate. If TTFB is fine and your Core Web Vitals still fail, the problem is in your front end and a hosting upgrade would be money spent on the wrong constraint.

What to evaluate when comparing providers

Businesses searching for the best hosting company in Canada are usually comparing feature lists, which is the least informative available signal. The criteria that actually determine whether hosting supports good Core Web Vitals are narrower:

1. Server-level full-page caching, rather than a recommendation that you install a caching plugin.
2. Guaranteed CPU and memory if your traffic is uneven or seasonal.
3. Data centre locations you can choose, near your actual audience.
4. Current PHP and database versions, maintained without you having to ask.
5. Measured TTFB you can verify yourself during a trial, at your own peak hours.
6. Transparent status reporting rather than an unverifiable uptime percentage on a sales page.
7. Support able to read a slow query log and discuss server-level configuration.
8. Migration assistance, since migration is where the practical risk in changing hosts sits.

The honest framing when evaluating any provider, including this one: a host can remove obstacles to good Core Web Vitals. It cannot deliver them on its own, because it does not control your images, your JavaScript or your templates. 4GoodHosting is a Canadian provider based in Vancouver offering Canadian web hosting, SSD hosting, VPS hosting, Canadian dedicated servers, managed WordPress hosting and SSL certificates, with Canadian data centres. Whether that or any other provider is right for you should come down to the criteria above, tested against your own site.

Core Web Vitals for WordPress websites

WordPress powers a very large share of the web, and its Core Web Vitals problems are consistent enough to be predictable. They are also mostly solvable without rebuilding the site.

Where WordPress sites lose their metrics

1. Themes and page builders. Builders load JavaScript and CSS on every page whether or not a page uses their interactive features. This is a leading contributor to poor INP on otherwise simple sites.
2. Plugin accumulation. The count matters less than the behaviour. Ten well-built plugins that load assets only where needed are lighter than three that enqueue scripts globally.
3. Unoptimised images. The most common LCP cause on WordPress. Images uploaded at camera resolution and scaled in CSS force the browser to download the full file.
4. Database bloat. Post revisions, expired transients, orphaned metadata and abandoned plugin tables accumulate over years and slow every uncached request. See slow database queries in WordPress.
5. Caching misconfiguration. Multiple caching plugins fighting each other, or page caching that excludes the templates receiving the most traffic.
6. Web fonts. Multiple families and weights loaded from a third party, without preload or metric-matched fallbacks, produce both LCP delay and CLS.
7. Render-blocking assets. Themes that enqueue several stylesheets in the head delay first paint regardless of hosting quality.

Prioritised WordPress optimisation checklist

Ordered by typical impact per unit of effort. Work down; stop when your field data passes.

Priority	Action	Metric affected	Effort
1	Enable server-level full-page caching, or move to hosting that provides it	LCP via TTFB	Low
2	Resize and compress images before upload; serve modern formats	LCP	Low
3	Add width and height attributes to all images and embeds	CLS	Low
4	Audit plugins; remove or replace anything loading assets globally without need	INP	Medium
5	Audit third-party scripts and tag manager contents against their business value	INP	Medium
6	Preload the LCP image and set fetchpriority; stop referencing it only in CSS	LCP	Medium
7	Reduce render-blocking CSS in the head; inline critical CSS if feasible	LCP	Medium
8	Fix font loading: preload, font-display, metric-matched fallbacks	LCP and CLS	Medium
9	Clean the database: revisions, transients, orphaned metadata	LCP via TTFB	Low
10	Update PHP to a current version and verify OPcache	LCP via TTFB	Low
11	Add a CDN for static assets	LCP	Low
12	Replace or reconfigure a page builder if it is the dominant JavaScript source	INP	High

A caution that comes up repeatedly in real WordPress diagnosis: installing several optimisation plugins does not compound their benefits. Minification, combination, lazy loading and critical CSS features overlap between plugins and frequently conflict, producing broken layouts and worse metrics than doing nothing. Choose one, configure it deliberately, and measure. Our guide to speeding up slow WordPress sites on Canadian servers goes further into the sequence.

Core Web Vitals for ecommerce websites

Ecommerce sites face the same three metrics under harder conditions. They carry more third-party scripts, more images, more personalisation, and more revenue riding on each interaction.

The specific pressures

1. Product images. Category pages load many at once, and the LCP element is usually the first product image or hero banner. Lazy loading applied indiscriminately can delay it, which is a common self-inflicted LCP problem: never lazy-load the LCP image.
2. Recommendation engines. Personalised blocks injected after render are a frequent CLS cause, particularly when they appear above the fold.
3. Review widgets. Third-party review platforms inject content of unpredictable height and run their own JavaScript, affecting both CLS and INP.
4. Analytics and tag stacks. Ecommerce sites accumulate tags: analytics, remarketing, affiliate, A/B testing, session recording. Each executes on the main thread.
5. Checkout scripts. Payment SDKs and fraud detection tools load heavy JavaScript at the most conversion-critical moment.
6. Personalisation and geolocation. Content that changes after an API response shifts layout unless space is reserved.
7. Variant switching and filtering. These are interactions, so they are exactly what INP measures. Filtering that rebuilds a large product grid synchronously is a classic INP failure.

Two published results are worth knowing here. Rakuten 24 ran an A/B test and reported that good LCP scores corresponded to a 53.37% increase in revenue per visitor and a 33.13% increase in conversion rate. Tokopedia improved LCP by 55% and saw a 23% improvement in average session duration. Both are single-company results under their own conditions; they demonstrate that the connection is real without predicting your outcome.

The prioritisation principle for ecommerce is that template value differs enormously. Product detail pages and category pages usually deserve attention long before the homepage, because that is where organic traffic lands and where purchase decisions happen. Optimising a homepage because it is easiest to test is a common misallocation.

Core Web Vitals and conversion performance

This is where the business case lives, and where careful language matters most. A number of companies have published performance results alongside business results. The evidence is genuinely useful. It is also mostly correlational, drawn from single organisations with their own audiences, products and confounding variables.

What the published evidence shows

Company	Performance change	Reported business result	Evidence quality
Vodafone (Italy)	LCP improved 31%	8% more sales; 15% better lead-to-visit rate; 11% better cart-to-visit rate	Strongest available: a server-side A/B test on two otherwise identical pages
Rakuten 24	Good LCP achieved	53.37% higher revenue per visitor; 33.13% higher conversion rate	A/B test
QuintoAndar	INP reduced 80%	36% increase in conversions year-over-year	Before-and-after over a year; other factors possible
QuintoAndar	Core Web Vitals work plus a framework migration	5% higher conversion; 87% more pages per session; 46% lower bounce rate	Confounded by the migration itself
Nuvemshop	LCP pass rate 57% to 96% across 180,000+ stores	8.9% higher conversion rate; 8.4% more cart engagement on mobile	Large cohort, year-over-year comparison
Yahoo! JAPAN News	CLS reduced by 0.2	15.1% more page views per session; 13.3% longer sessions; bounce rate down 1.72 points	Before-and-after
Farfetch	Per 0.01 reduction in CLS	3.1% lower exit rate	Regression across their own funnel data
Tokopedia	LCP improved 55%	23% better average session duration	Before-and-after
Agrofy	LCP improved 70%; CLS improved 72%	Load abandonment fell 76%, from 3.8% to 0.9%	Before-and-after
redBus	INP improvements	7% increase in sales	Before-and-after

How to read this evidence honestly

The Vodafone study deserves particular weight because of its design. It was an A/B test where the only difference between the two versions was performance optimisation, with no functional or visual changes, and roughly 34,000 visits per day to each variant. That structure isolates performance as the variable in a way a before-and-after comparison cannot, because a before-and-after cannot rule out seasonality, a pricing change, or a concurrent marketing campaign.

The QuintoAndar framework-migration result illustrates the opposite problem. A 5% conversion increase accompanied both Core Web Vitals work and a migration to a different rendering framework. The performance improvement plausibly contributed. So might the rebuild. Attribution is unavailable, and treating the full 5% as a Core Web Vitals return would overstate it.

Deloitte and Google's “Milliseconds Make Millions” study is frequently cited for the finding that a 0.1-second improvement in load time corresponded to an 8.4% increase in retail conversion rates. It is a large study and worth reading, but the same caution applies: it describes correlations across participating brands, not a coefficient you can apply to your own site to forecast revenue.

What you can legitimately conclude Faster, more stable, more responsive pages tend to convert better across many independent datasets, and the direction of that relationship is consistent enough to justify investment. You cannot conclude that a specific percentage improvement in a metric will produce a specific percentage improvement in your revenue. Anyone quoting you such a figure in advance is guessing. The only way to know your own number is to measure it on your own site, ideally with an A/B test, and otherwise with a careful before-and-after that accounts for seasonality.

Why performance affects conversion at all

The mechanisms are mundane rather than mysterious. Slow loading increases abandonment before the page is seen, which is why Agrofy's abandonment figure moved so sharply. Layout instability causes mis-taps and erodes trust at exactly the moments that require it, such as checkout. Poor responsiveness makes users repeat actions, producing duplicate submissions or abandoned flows. And performance interacts with device and connection quality, which correlates with demographics and geography, so poor performance can disproportionately exclude particular customer segments.

Canadian hosting, performance and privacy

For Canadian organisations, hosting location raises two separate questions that are frequently blended into one confused claim. One is a performance question. The other is a privacy and governance question. They deserve different answers.

The performance question: latency is real, ranking benefit is not

Physical distance costs time on every network round trip. A visitor in Toronto loading a site served from a Canadian data centre will generally receive the first byte sooner than from a distant origin, and because TTFB feeds the LCP chain, that can improve a Core Web Vital. The effect is genuine and measurable, and it grows with the number of round trips required.

What server location does not do is act as a direct ranking bonus in Canadian search results. Google determines geographic relevance primarily from your domain, your content and language, your Search Console country targeting, and your links. A CDN further decouples serving location from origin location. So hosting in Canada is worth doing for latency and governance reasons, and claiming it lifts your local rankings is not supportable.

Whether Canadian hosting helps depends on where your audience actually is. If your CrUX data shows most visits originate in Canada, moving your origin closer is a sound decision. If your audience is global, a CDN matters more than origin placement. Our Toronto and Vancouver data centre comparison covers the practical differences for a Canadian audience.

The privacy question: what PIPEDA actually requires

The Personal Information Protection and Electronic Documents Act, PIPEDA, is Canada's federal private-sector privacy law. It is also the subject of a persistent myth in hosting marketing, so the accurate position is worth stating plainly.

Correcting a common myth PIPEDA does not universally require Canadian organisations to store all personal information inside Canada. Cross-border transfer and processing is not automatically prohibited. What PIPEDA does establish is accountability. An organisation remains responsible for personal information under its control, including information transferred to a third-party processor, and is generally expected to use contractual or other means to provide a comparable level of protection while the information is being processed. Transparency with individuals about such practices is also expected. Some provinces have their own legislation, and specific public-sector rules in certain provinces do impose data-location requirements. Sector-specific obligations may also apply. This is why organisation-specific advice matters.

This is why organisations shortlisting the best hosting company in Canada on privacy grounds should ask about contracts and data centre locations rather than accepting a compliance badge at face value. Given that, why do Canadian organisations still choose Canadian hosting and Canadian data centres? Because it can simplify a data-residency strategy rather than because it is legally mandated. Keeping data domestically reduces the number of cross-border considerations you have to document and manage, provides jurisdictional clarity that is easier to explain to customers and partners, supports privacy commitments an organisation has chosen to make in its own policies, can simplify procurement conversations in sectors where clients ask where data resides, and may reduce latency for Canadian audiences depending on network architecture.

That is a governance and commercial argument, and a sound one. It is not the same as a compliance requirement, and presenting it as one damages credibility with any reader who knows the legislation. When evaluating PIPEDA compliant hosting, the questions worth asking a provider are concrete: where are the data centres physically located, who has access, what does the contract say about processing and sub-processors, what happens to data on termination, and what breach notification commitments exist. 4GoodHosting's Canadian data centres and our longer discussion of PIPEDA compliance and Canadian data residency address the residency side of this.

In short, PIPEDA compliant hosting is best understood as hosting that supports your accountability obligations, with locations, contracts and access controls you can document, rather than a certification a provider can simply claim.

This article is not legal advice. Privacy obligations depend on your sector, your provincial jurisdiction, the nature of the personal information you handle, and your contractual commitments. Organisations with specific compliance questions should obtain advice from a qualified privacy professional or lawyer, and consult the Office of the Privacy Commissioner of Canada for authoritative guidance on PIPEDA.

When you need technical SEO or performance help

A great deal of Core Web Vitals work is genuinely doable in-house. Compressing images, adding dimension attributes, cleaning up plugins and enabling caching require diligence rather than specialist expertise, and the tools are free. There are, however, situations where the economics change.

Signals that you have reached that point

1. Field data has not improved after several weeks despite deliberate changes, which usually means the diagnosis was wrong rather than the effort insufficient.
2. INP is failing and the cause is distributed across a framework, a tag manager and several third-party vendors, so no single owner can fix it.
3. The site is large enough that page templates behave differently and you cannot tell which group is dragging the assessment.
4. Fixing the metric appears to require removing functionality the business depends on, which is a trade-off decision rather than a technical one.
5. A replatform, redesign or migration is planned, where performance and search risk should be designed in rather than repaired afterwards.
6. Performance is adequate but organic traffic is still flat, which indicates the constraint is relevance, content or authority rather than page experience.

What to evaluate when choosing a provider

Businesses looking for the best Canadian SEO agency tend to compare proposals on price and promised rankings, which selects for the wrong things. More useful criteria:

Criterion	What good looks like	Warning sign
Technical depth	Can explain the LCP phase breakdown and diagnose which phase dominates	Talks only about keywords and content volume
Core Web Vitals literacy	Distinguishes field from lab data unprompted; knows INP replaced FID	Quotes Lighthouse scores as the objective
Search Console fluency	Works from your actual reports, including URL groups and crawl stats	Relies on third-party tool estimates alone
Development capability	Can implement changes or brief developers precisely	Delivers recommendations no one can action
Reporting	Metrics tied to business outcomes, with methodology stated	Vanity dashboards; unexplained scores
Expectation setting	Explains what cannot be promised, and why	Guarantees positions, indexing dates or traffic figures
Canadian market understanding	Familiar with .ca considerations, Canadian competitive sets and privacy expectations	Applies a generic template with no local context
Measurement discipline	Changes one variable at a time; validates in field data	Ships many changes at once and claims all resulting gains

Notice that none of those criteria is price, and none is a promised position. The characteristics that distinguish the best Canadian SEO agency from an average one are diagnostic rigour, willingness to say what will not work, and the ability to tell an infrastructure problem from a content one. The most reliable single filter is how a prospective partner handles uncertainty. Anyone guaranteeing rankings is describing something outside their control, because Google does not commit to positions for anyone. A credible provider will tell you which of your problems are worth fixing, which are not, and what they expect to be unable to influence. If you want a starting point, our technical SEO services team works with Canadian businesses on exactly this kind of diagnosis, and the criteria above should be applied to us as readily as to anyone else.

A step-by-step Core Web Vitals optimisation framework

Most failed performance projects fail for process reasons rather than technical ones: no baseline, no page grouping, several changes at once, and judgement passed before field data could move. This sequence addresses each.

Step 1: Establish a field-data baseline

Record current LCP, INP and CLS at the 75th percentile from Search Console and CrUX, separately for mobile and desktop, and note the date. Without a dated baseline you cannot demonstrate improvement, and you will be arguing from impressions later.

Step 2: Group pages by template, not by URL

Performance is a property of templates. Your product pages share a fate; so do your blog posts. Search Console already groups URLs this way. Establish which templates exist, how much traffic and revenue each carries, and which fail. Optimising URL by URL on a site of any size is wasted effort.

Step 3: Identify the failing metric per group

Do not begin general “speed work”. Determine whether each template group fails LCP, INP or CLS, since the three require different specialists and different fixes. A group failing only CLS does not need a hosting review.

Step 4: Separate server causes from front-end causes

This is the step most often skipped and the one that saves the most money. For LCP, break the metric into its four phases and establish whether TTFB dominates. If it does, the work is infrastructure: caching, database, capacity, origin location. If it does not, the work is front end, and a hosting upgrade would change nothing. For INP and CLS, assume front end unless you have specific evidence otherwise.

Step 5: Prioritise by traffic and business value

Rank the failing template groups by the traffic and revenue they carry, then by the estimated effort to fix. A checkout template with a moderate problem usually outranks a blog template with a severe one. Arbitrary scores are not a prioritisation input.

Step 6: Deploy changes one variable at a time

Ship discrete, attributable changes. Bundling image optimisation, a caching change and a plugin removal into one release means that if metrics worsen you cannot tell which caused it. Where traffic permits, A/B test, since that is the only method that isolates the effect cleanly.

Step 7: Validate in the lab immediately

Use Lighthouse and DevTools right after deployment to confirm the change did what you intended: the LCP element is now discovered earlier, the long task is gone, space is reserved. This is a correctness check, not a success measure.

Step 8: Monitor field data over weeks

Because CrUX reflects a rolling window, expect several weeks before the full effect appears in Search Console. Resist judging the change early, and resist reverting it because week one looks flat.

Step 9: Compare business KPIs, not just metrics

Look at conversion rate, bounce, pages per session and revenue for the affected templates against a comparable prior period, acknowledging seasonality. This is what justifies the next round of investment, and it is the number your organisation actually cares about.

Step 10: Set performance budgets and defend them

Performance regresses by default. New plugins, tags, campaign scripts and design changes each add weight. Define budgets, such as a maximum LCP for key templates and a ceiling on third-party scripts, and require review before anything is added. Without this, you will repeat the entire project in eighteen months.

A 30-day Core Web Vitals action plan

A realistic first month for a small team. It deliberately front-loads measurement, because the most common way this work is wasted is optimising the wrong thing quickly.

Week	Focus	Actions	Deliverable
1	Measurement and diagnosis	Record the field baseline for mobile and desktop; group pages by template; identify the failing metric per group; break LCP into phases; determine server versus front-end cause	A dated baseline and a ranked problem list
2	High-impact, low-effort fixes	Compress and correctly size images; add width and height attributes; enable or verify server-level caching; fix the LCP image so it is not lazy-loaded and is referenced in HTML	Measurable lab improvement on the top templates
3	Templates and infrastructure	Audit third-party scripts and tag manager contents; reduce render-blocking CSS; fix font loading; address the largest long tasks; act on the hosting decision if TTFB was the constraint	Structural fixes on the highest-value templates
4	Validation and monitoring	Confirm changes in the lab; begin tracking field data movement; compare business KPIs against a prior period; set performance budgets and a review process	A monitoring routine and a documented budget

What a month will not deliver is a final field-data verdict, because the rolling window has not caught up. Expect to be reading the outcome in weeks five through eight, and plan the reporting conversation accordingly so the work is not judged prematurely.

Twelve common Core Web Vitals mistakes

Mistake	Why it costs you	What to do instead
Chasing a Lighthouse score of 100	Optimises a simulation, not the assessment Google uses; encourages removing useful functionality	Target passing thresholds on field data for templates with traffic
Ignoring field data	Lab tools cannot measure INP and do not reflect your audience's devices	Start every diagnosis in Search Console or CrUX
Optimising desktop only	Assessment is segmented, and mobile is usually the weaker and more common experience	Diagnose and fix mobile first
Optimising the homepage only	Organic traffic usually lands on product, service and article templates	Group by template and prioritise by traffic and value
Stacking optimisation plugins	Overlapping minification, lazy loading and critical CSS features conflict and break layouts	One tool, configured deliberately, then measure
Blaming hosting for everything	A faster server cannot reserve space for an image or reduce main-thread JavaScript	Break LCP into phases; establish whether TTFB is actually the constraint
Assuming hosting is irrelevant	A 2-second TTFB makes a good LCP arithmetically impossible	Measure TTFB at the 75th percentile, at your peak hours
Changing many variables at once	Attribution becomes impossible; a regression cannot be traced	Ship discrete changes; A/B test where traffic allows
Ignoring third-party scripts	Tags added by non-technical teams are a leading INP cause and are invisible in most audits	Inventory tags; weigh measured cost against business value
Lazy-loading the LCP image	A well-intentioned optimisation that directly delays the metric being measured	Never lazy-load above-the-fold or LCP imagery
Judging results in week one	CrUX reflects a rolling window, so genuine fixes look ineffective initially	Assess field movement over four to eight weeks
Removing functionality purely for a score	Losing analytics, chat or personalisation can cost more than the performance gain returns	Treat it as a business trade-off with measured costs on both sides

Conclusion: treat Core Web Vitals as five things at once

The reason Core Web Vitals work so often disappoints is that organisations approach it as a single discipline. It is five overlapping ones, and each contributes something the others cannot.

As technical SEO, it belongs in the same programme as indexing, crawlability and site architecture, and it is subordinate to relevance. As infrastructure, it depends on server response time, caching, capacity and origin placement, none of which a front-end developer controls. As front-end engineering, it depends on images, CSS, JavaScript and templates, none of which a hosting upgrade can repair. As user experience, it is worth doing regardless of any search benefit, because the metrics describe real friction. And as business performance, it is measurable in conversion and engagement on your own site, which is where the investment case should be built.

The practical discipline follows from that. Measure in the field. Group by template. Diagnose the specific failing metric. Establish whether the cause is server or front end before spending anything. Fix in priority order by business value. Validate in the lab, monitor in the field, and be patient with the rolling window. Then defend the result with performance budgets, because the default direction of travel is backwards.

Two closing cautions worth carrying. Passing Core Web Vitals will not rescue content that does not answer the query, and a perfect tool score is not the objective. But a site that is genuinely fast, stable and responsive is easier to use, converts better in most published evidence, and removes one class of obstacle from your search performance. That is a reasonable return even if rankings never visibly move.

If you are deciding where to start, the honest sequence is diagnostic. Measure your field data, break your worst metric into its causes, and find out whether your constraint is infrastructure or front end. That answer determines whether the next conversation should be about Canadian web hosting and server capacity, or about templates and scripts, or about SEO services and whether performance was ever your real limitation. Getting that diagnosis right costs nothing and saves the most.

Core Web Vitals FAQ

Do Core Web Vitals affect SEO?

Yes, but as a contributory factor rather than a decisive one. Google states that Core Web Vitals are used by its ranking systems and recommends good scores for Search. They form part of a broader page experience assessment and do not override relevance or content quality. Passing them does not guarantee a first-page ranking, and failing them does not prevent a highly relevant page from ranking.

Are Core Web Vitals a ranking factor?

They are used by Google's ranking systems, which is how Google describes it. The framing that misleads people is treating page experience as one isolated signal with a fixed weight. It is a set of considerations, and its influence is most visible between pages that are otherwise comparable in relevance and quality.

What is a good LCP?

2.5 seconds or less at the 75th percentile of real-world visits. Between 2.5 and 4.0 seconds needs improvement, and above 4.0 seconds is poor. Mobile and desktop are assessed separately.

What is a good INP?

200 milliseconds or less at the 75th percentile. Between 200 and 500 milliseconds needs improvement, and above 500 milliseconds is poor.

What is a good CLS?

0.1 or less at the 75th percentile. Between 0.1 and 0.25 needs improvement, and above 0.25 is poor. CLS is a unitless score rather than a time measurement.

Did INP replace FID?

Yes. Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital in March 2024. FID measured only the delay before processing the first interaction; INP measures the full latency from interaction to the next visual update and considers interactions across the visit. Many sites that passed FID do not pass INP, because INP measures more of what users actually experience.

Does web hosting affect Core Web Vitals?

Substantially for LCP, since Time to First Byte is a direct component of the LCP chain and the LCP resource is usually served by your origin. Moderately for INP, which is mostly main-thread JavaScript. Minimally for CLS, which is determined by templates and CSS. Hosting can make good Core Web Vitals impossible; it cannot deliver them on its own.

Can changing hosting improve LCP?

It can, if Time to First Byte is currently the dominant phase of your LCP. Break LCP into its four phases first. If TTFB is 2 seconds of a 3.5-second LCP, better hosting or caching will help materially. If TTFB is 200 milliseconds and an oversized image accounts for the rest, changing hosts will change almost nothing.

Does a CDN improve Core Web Vitals?

It usually helps LCP by serving assets from an edge location nearer the user, reducing load duration, and it can improve TTFB where cached documents are served from the edge. It does not fix main-thread JavaScript problems, so it will not resolve poor INP, and it does not reserve space for images, so it will not resolve CLS.

Why does Search Console show different data than Lighthouse?

Search Console reports field data: real Chrome users, at the 75th percentile, over a rolling window. Lighthouse reports lab data from one simulated load on a synthetic device and network. They routinely disagree, and neither is wrong. Field data tells you whether you have a problem; lab data helps you find out why. Lighthouse also cannot measure INP at all.

How long does it take Search Console to reflect improvements?

Because the underlying field data uses a rolling window of roughly 28 days, expect several weeks before a fix is fully reflected, with partial movement appearing sooner. Judging a change after one week is the most common reason genuine improvements get reverted.

Do Core Web Vitals matter for ecommerce?

Ecommerce is where the strongest published business evidence sits, including A/B tested results from Vodafone and Rakuten 24. Ecommerce sites also face harder conditions: more images, more third-party tags, and interactions such as filtering and variant switching that INP measures directly. Product and category templates usually deserve attention before the homepage.

Do Core Web Vitals matter for WordPress?

Yes, and WordPress problems are predictable enough to be worked through systematically. The usual causes are unoptimised images, page builder JavaScript, plugin accumulation, missing image dimensions, database bloat and caching misconfiguration. Most are fixable without rebuilding the site.

Can Core Web Vitals improve conversions?

Published evidence from multiple companies shows improvements in performance accompanying improvements in conversion, engagement and revenue. Most of that evidence is correlational; the Vodafone A/B test is the strongest exception. It justifies investment without predicting your specific result, which you can only establish by measuring on your own site.

Should I aim for a PageSpeed score of 100?

No. That score is a weighted composite of lab measurements and is not the assessment used for ranking. Chasing it encourages removing functionality that has real business value. Target passing the three thresholds on field data for the templates that carry your traffic, then redirect effort elsewhere.