What Is the Core Web Vitals Report in Google Search Console?
Three measures of how your pages behave for real visitors, reported against thresholds Google publishes. This is the most technical subject in the series and the one most often sold badly, so this guide covers what the readings mean, who can fix them and how much they actually matter.
What Survived And What Did Not
If you are looking for the mobile usability report or the page experience report, neither is there any more. The mobile usability report was retired on 1 December 2023 and the page experience report was deprecated in the same announcement. Core Web Vitals reporting and the reporting on secure connections both continued, which is why this page exists.
Why so much guidance is wrong. It predates the change.
An enormous quantity of published advice tells you to work through the mobile usability report. That advice describes a screen that has not existed for years. Nothing about it is recoverable.
What happened to the page experience report. It became a pointer.
Rather than reporting anything itself, it became a route to the reporting that survived. There is nothing left in it to describe, which is why we do not give it a page of its own.
Why mobile usability went. The advice had done its job.
The report existed to catch sites that did not work on a phone at all, which was a widespread problem when it launched and is now unusual. Modern themes handle it by default.
What that does not mean. That mobile stopped mattering.
The mobile version of your site is the one being assessed. The report went away and the underlying importance did not. Our technical material owns that subject.
What this page carries. All of it.
The surviving reporting, the retired history and what to do about any of it, in one place rather than across four pages describing three things that no longer exist.
The Three Measures
Each measure describes something a visitor would notice. Each has a threshold that Google publishes rather than one we have invented. Google states that these are assessed at the 75th percentile of visits, meaning three quarters of your visitors need to be within the figure.
How long the main content takes to appear. Called LCP.
The point at which the biggest thing on the page becomes visible. Google's published threshold for a good result is under 2.5 seconds.
How quickly the page responds. Called INP.
Whether a tap or a click produces something happening promptly. Google's published threshold for a good result is under 200 milliseconds. This measure replaced First Input Delay in March 2024.
How much the page moves about. Called CLS.
Content jumping around as things load, so you tap the wrong thing. Google's published threshold for a good result is under 0.1 on its scale.
What replaced what, plus when. Worth knowing.
Anything still discussing First Input Delay was written before March 2024. That single detail lets you date an article on this subject in seconds.
One correction. The thresholds have not moved.
A claim circulates that the first of these figures was tightened in 2026. That is not supported by Google's own documentation. If somebody has quoted you on the basis of a stricter number, ask them where it came from.
It Is Real Visitors, Not A Test
These readings come from actual visits to your site rather than from a test somebody ran on demand. That single fact explains why this reporting disagrees with whatever a supplier ran in a browser last Tuesday, plus why the disagreement is not a fault.
What a test measures. One visit, ideal conditions.
A single load, usually on a good connection, from a chosen location, on capable hardware. Useful for diagnosis and not a description of your audience.
What this reporting measures. Your actual visitors.
People on ordinary phones, on patchy connections, in real places. That is a harder test and it is the one that describes your business.
Why the two disagree. Different populations.
A page can test beautifully and report badly because your customers are on worse connections than whoever ran the test. Neither number is lying.
Which to believe. This one, for judgement.
Use the field reporting to decide whether there is a problem worth money, then use tests to work out what is causing it. That order round is the useful way.
Why it moves slowly. A rolling window.
The reporting covers a trailing period of visits, so a fix appears gradually as new visits replace old ones. We will not give you a date for that, since it depends on how busy the pages are.
Why Some Pages Are Not Reported
Most smaller sites find that the majority of their pages show no reading at all. That is expected rather than broken. It follows directly from the previous block: no visits means nothing to measure.
What causes it. Not enough traffic.
A page needs a reasonable number of real visits before Google will report a reading for it. Quiet pages never reach that, however well or badly they perform.
Who this affects most. Small local businesses.
A ten page site serving one town may only have readings for its homepage. That is normal and it makes this report largely inapplicable to plenty of our clients.
How pages get grouped. By similarity.
Google groups similar pages together so it can report on the group where individual pages are too quiet. So a reading may describe a set of pages rather than the one you are looking at.
What that means for interpretation. Be careful.
A poor reading on a group does not mean every page in it is poor. It means the group as measured falls short, which is a coarser statement than it appears.
What you cannot do about it. Force a reading.
There is no way to make Google report on a quiet page. If you need to know how a specific page performs, that is what a test is for.
What Actually Fixes These
The causes fall into a small number of categories. Knowing them lets you judge whether a proposal is addressing the actual problem or selling you a rebuild you do not need.
Images. The commonest single cause.
Photographs uploaded at full camera resolution, served at full size and scaled down by the browser. Frequently the whole explanation for a slow reading, plus among the cheapest things to correct.
Scripts. The second.
Tracking, chat widgets, review displays, booking systems and social embeds, each adding weight. Every one was added for a reason and few are ever reviewed.
Hosting. Sometimes the whole answer.
Cheap shared hosting responds slowly regardless of how well the site is built. No amount of optimisation compensates for a server taking its time to reply.
Things loading late. The cause of movement.
Adverts, banners, fonts and images without reserved space push content around as they arrive. That is what the stability measure is detecting.
The theme itself. The expensive one.
Some templates are built in a way that cannot be made fast without replacing them. Worth establishing before spending on anything else, since it changes the whole conversation.
Where the work is covered. The technical material.
How to do any of this properly belongs there rather than here. This page owns reading the report and judging whether it deserves attention.
This Is A Developer Job
Every genuine cause in the previous block is about how the site is built and served. None of it is content work, none of it is a settings change and none of it can be resolved by writing anything, which matters when deciding who to ask.
Who can actually fix it. Whoever builds the site.
A developer, your host or whoever maintains the template. They can see the server, the code and the loading order, which is where the causes live.
What we do instead. Establish whether it matters.
Read the reporting, work out whether the problem is real and material, then brief whoever does the work. That is a genuinely useful role and it is not the same as doing it.
Why this gets confused. It appears in a search tool.
Because the reporting sits alongside search data, businesses assume their search supplier owns it. Frequently they do not. Pretending otherwise wastes months.
What to ask for. The specific cause.
Not a faster site. Which of the categories above applies to your pages and what changing it involves. A vague brief produces a vague invoice.
What to be wary of. A rebuild as the first answer.
Occasionally the template genuinely is the problem. Frequently it is images and scripts. A rebuild is a very expensive way to compress a photograph.
How Much It Actually Matters
These measures are part of how pages are assessed and they are not why a site is invisible. A slow page that answers the question generally beats a fast page that does not. Any proposal built on a red reading alone is built on the smaller half of the problem.
Where they matter most. After the click.
A page that takes too long loses people who already chose you. That is a conversion cost you pay on every visit. It is the strongest reason to care about any of this.
Where they matter least. Getting found.
Relative to whether your page is the best answer, this is a minor consideration. Nobody outranks a better page by loading faster than it.
What we tell clients. Fix the cheap ones.
Compress the images, review the scripts, check the hosting. Those are affordable and worth doing. A rebuild justified only by these readings rarely pays for itself.
How it gets sold badly. A red screenshot.
A reading in the red, a quote for a rebuild and no discussion of whether the business is even visible in search yet. We have seen that proposal more times than any other.
The order that makes sense. Visibility, then speed.
If the site is not appearing for anything commercial, that is the problem to solve first. Making an invisible page faster produces a faster invisible page.
When to reverse that. Genuinely broken.
A site taking many seconds on a phone is losing customers now. That changes the priority regardless of search. Read common errors for the wider triage.
HTTPS Reporting, Briefly
Alongside the vitals reporting there is reporting on whether your pages are served over a secure connection. For most sites this is empty and can be ignored, which is why it gets a paragraph rather than a page.
What it reports. Pages not served securely.
Where an address is still reachable without encryption. Or where a secure page loads something insecure. Both are worth knowing about.
Why it matters. Trust, mostly.
Browsers warn visitors about insecure pages, which costs you enquiries directly. That is a considerably more immediate consequence than anything about ranking.
Who this affects. Older sites.
Anything set up before secure connections became standard. Or where a migration left some addresses behind. New sites rarely have anything here.
What to do about it. Pass it on.
Another developer or hosting job rather than a content one, usually a quick fix once somebody looks.
Where the rest of the series is. The hub.
Everything on this tool sits on the Google Search Console guide. how to use it covers what to look at and how often.
Making an
invisible page
faster gives you
a faster invisible page.
These measures are real and they are the smaller half of the problem. A red reading with a quote for a rebuild, plus no discussion of whether the site is appearing for anything commercial, is the proposal we see more than any other. The cheap fixes are usually images, scripts and hosting.
What we establish first:
If the answer is that your developer should compress some photographs, we will tell you that rather than quote for it.
Every guide.
One tool.
Getting set up and verified, using the reports properly, the performance and indexing data, finding what is broken, finding what is being passed over and turning any of it into work worth doing.
