Core Web Vitals are a ranking factor now. Calm down.
Google started rolling out the page experience update this month. It is real, it is measurable, and it is a tiebreaker — not the lever the panic emails are selling you. Here is what genuinely changes for a shop.
Photo: free stock photography (Unsplash licence) — see imprint
It shipped in June, and your rankings did not collapse
The page experience update started rolling out this month and will take until roughly the end of summer to finish. Since about February our inbox has been full of forwarded newsletters from tool vendors explaining that shops with a red PageSpeed score will vanish from Google. That did not happen, it is not going to happen, and the people who told you it would were selling an audit.
What did happen is smaller and more useful. Google has now said out loud that how a page feels to use is part of how it ranks, and it has given us three numbers to argue about instead of a vague plea to 'be fast'. That is genuinely good news for anyone who has ever tried to get budget for performance work. It is not news that reorders search results overnight.
A tiebreaker is not a lever
Google has been unusually clear about this one: page experience matters when other things are roughly equal. Relevance still wins. A slow page that answers the query beats a fast page that does not, and it is not close. If your category page ranks on position 14 for a term you want, the reason is almost never LCP — it is that fourteen other pages are a better answer, or that your page is a grid of products with 40 words of text on it.
Where the tiebreaker earns its keep is on the terms where you are already competitive. Positions three to eight on a commercial keyword are frequently a pile of pages saying almost the same thing about almost the same product. That is the fight where a fast, stable page can nudge ahead. It is a real edge — but it is an edge on the last ten percent, not a way to skip the ninety.
The three metrics, translated into shop
LCP asks when the main thing appears. On a product page that is nearly always the product image, which means LCP is usually a story about image weight, server response time and whatever lazy-loading plugin decided the hero image was below the fold. FID asks whether the page answers when a finger lands on it — on a phone, on a mid-range Android, on the train. CLS asks whether the page stops moving before the customer commits to a tap.
These are not developer metrics dressed up as business metrics. They are the three ways a shop page can annoy someone who was ready to buy: it took too long, it ignored me, or it moved the button. You do not need a tool to know which one your shop has. Open it on your own phone on mobile data and try to buy something.
- LCP over 2.5s on product pages — start at server response and the hero image, in that order.
- FID is the one most shops already pass — do not spend a sprint on a metric you are green on.
- CLS is usually the cheapest fix and the most visible one to a real customer.
- Fix templates, not pages: one product template fix moves 4,000 URLs at once.
The score you keep refreshing is not the score Google uses
This is the part that costs shops the most wasted money. The number in Lighthouse, and the one your agency screenshotted for the pitch, is a lab test: one simulated device, one throttled connection, one moment. Ranking uses field data — what actually happened to real Chrome users on your pages, aggregated over a rolling 28-day window. The two numbers disagree constantly, and when they do, the lab one is the one that does not matter.
Two consequences follow, and both are unpopular. First: you will not see the effect of Monday's fix on Monday, or on Friday — the window has to refill, so plan in months, not sprints. Second: your customers are not the throttled phantom device. If most of your traffic is desktop buyers in an office on fibre, your field data can be comfortably green while Lighthouse screams. Fix what your actual visitors experience, in the Search Console report, and let the pretty gauge be wrong.
What we would actually do with your next 5,000 euro
If your field data is red, spend it on performance — but on the boring end. Server response time, image sizes and third-party scripts account for most of what we find in Shopware shops, and the third one is usually the surprise: a shop is slow because marketing added a chat widget, two tag managers and a review badge that each load a small library on every page. Nobody wants to be the person who asks whether the badge earns its 400 milliseconds. Be that person.
If your field data is already green, spend it on content and product data instead. A green shop that is invisible for its money keywords does not have a speed problem — it has a relevance problem, and no amount of milliseconds fixes that. This is the advice that costs us performance projects, and we would rather say it than take the money for a sprint that moves nothing.
| Metric | Good | What it means in a shop | Usual culprit |
|---|---|---|---|
| LCP | under 2.5s | The product image is finally there | Slow server response, uncompressed hero image |
| FID | under 100ms | The add-to-cart tap is answered | Third-party scripts blocking the main thread |
| CLS | under 0.1 | The button stays where the finger is going | Images without dimensions, late banners, web fonts |
| Relevance | Not a vital — still the boss | The page is the answer to the query | A category page with 40 words on it |
- Core Web Vitals decide close races; relevance decides whether you are in the race at all.
- Ranking uses 28 days of real user field data — the Lighthouse gauge you keep refreshing does not count.
- Fix templates, not pages: one product template touches thousands of URLs at once.
- If your field data is already green, more speed work is a way of avoiding your content problem.
Frequently asked questions
Almost certainly not on its own. Page experience is a tiebreaker between pages that are otherwise comparable answers to the query, and Google has said as much repeatedly. Where you will feel it is on competitive commercial terms where you already sit at position three to eight against near-identical pages. If you rank badly today, speed is not the reason and speed will not be the fix.
Because they measure different things. PageSpeed Insights shows you a lab run on a simulated throttled phone; Search Console reports field data from real Chrome users over a rolling 28-day window. Ranking uses the field data. If your visitors are mostly desktop buyers on decent connections, green field data with a red lab score is normal — and the lab score is the one to ignore.
Plan in months. The field data behind the report is a rolling 28-day aggregate, so a fix deployed today needs roughly a month before the numbers even reflect it, and longer before any ranking effect settles out of the noise. Anyone promising you a measurable ranking lift two weeks after a sprint is describing a coincidence they intend to invoice.
Look at your field data first — most shops already pass FID, so fixing it is a sprint spent on a green number. In practice CLS is usually the cheapest win and the most obvious to a real customer, while LCP is where the actual engineering lives: server response time, image weight, and the third-party scripts marketing added without telling anyone. Fix the product and category templates, not individual pages.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer