"Core Web Vitals Assessment: Failed": what it means, read off a site of mine that failed with a 90 in the circle under it.

On 3 October 2026 I put two of my sites through PageSpeed Insights, Google’s own speed test. kovalseo.com came back “Core Web Vitals Assessment: Passed” on the Desktop tab. cryptowl.io, same tab, came back “Core Web Vitals Assessment: Failed”, and a little further down the same screen, in an orange circle, 77. I pressed Analyze twice more. The circle said 83, then a green 90. The line said Failed all three times, with the same numbers under it to the decimal.

That is the whole of this article. The line and the circle measure different things, and the line is the one with your visitors in it. Below: what Google’s own pages say the line is, what to read on your own report before you ask anyone to fix anything, what to do about it, and, at the end, the failed site taken apart, since it is mine.

What the line is a verdict on

The box, the panel with the line and the numbers under it, sits under a heading that already says it: “Discover what your real users are experiencing”. Google’s page about PageSpeed Insights says where its numbers come from:

Google’s page about PageSpeed Insights, on the real-user section

PSI reports real users’ First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) experiences over the previous 28-day collection period.

Real people, in Chrome, over the last four weeks. Three of the four decide the line: LCP, INP and CLS. FCP, when the first thing appeared, is shown but does not count. In plain words: LCP is how long before the largest thing on the screen, usually the main heading or picture, was drawn. INP is how long the page took to react to a tap, click or key press. CLS is how much the page jumped about while it was open. Each has a “good” limit, 2.5 seconds, 200 milliseconds and 0.1 (a score, not seconds), and each is read at the 75th percentile, which Google’s page on the thresholds explains in one line: “By using the 75th percentile, we know that most visits to the site (3 of 4) experienced the target level of performance or better.” So the number in your box is the one at least three visits in four stayed under; the slowest quarter were at it or beyond.

The rule for the line is on the same PageSpeed page:

Google’s page about PageSpeed Insights, the pass rule

For aggregations with sufficient data in all three metrics, the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good. Otherwise, the aggregation does not pass the assessment. If the aggregation has insufficient data for INP, then it will pass the assessment if both the 75th percentiles of LCP and CLS are Good. If either LCP or CLS have insufficient data, the page or origin-level aggregation cannot be assessed.

Two things follow. All three must be green, so one that is not green is enough to fail. If there is not enough tap-and-click data, LCP and CLS decide alone. And, from the same page, phones and computers are reported separately, which is why the tab at the top of the report matters.

The circle under the box is not in that rule. It is one simulated load on a test machine (Google calls this lab data), and the same page warns: “Any green score (90+) is considered good, but note that having good lab data does not necessarily mean real-user experiences will also be good.”

Read your own box before you ask anyone to fix anything

Four things to read off the report in front of you, in this order. All are on the screen as I saw it on 3 October, and none needs a login.

The tab. The report opens on Mobile. Mobile and Desktop are two separate verdicts; click both. On both of my sites the Mobile tab showed “No Data” at the right of the heading and no box at all, while Desktop showed a verdict. Why mobile has nothing on mine I cannot tell you. Google’s page gives the general reasons: a page “might not have sufficient data if it has been recently published or has too few samples from real users”; the Chrome UX Report’s methodology page adds that how many visits a page needs is not given, that visits from iPhones and iPads never reach the box, even in Chrome, and that “At this time, you cannot manually submit pages or origins for inclusion.” No Data is not a pass and not a fail. It is no verdict.

“This URL” or “Origin”. The small switch at the top right of the box: the page you typed, or every page of the site together. Google’s page on improving LCP: “If a URL doesn’t have enough data to be shown at the URL level, but does have data for the origin, PageSpeed Insights always shows the origin data.” See which of the two is shaded before you blame the page, and take the same page’s instruction: “Make sure your CrUX data is for your page, not the full origin, before you act on it.” CrUX is the Chrome UX Report, the pool of real visits that fills the box. If only “Origin” has data, the verdict is for your whole site, not this page.

Which number is not green. Each of the three has a coloured mark beside its name: a green circle is good, an orange square needs improvement, a red triangle is poor. On cryptowl.io: LCP, orange square, 3.3 s; INP, green circle, 112 ms; CLS, green circle, 0. One not green, and the line reads Failed. The two listed lower in the box, FCP and TTFB (how long the server took to start answering), are shown but not in the rule: kovalseo.com’s TTFB was orange at 0.9 s and its line still said Passed. That 0.9 s is what at least three real visits in four stayed under, a different measurement from the timing I took from my own connection in the article on AI bots.

“N/A”. On kovalseo.com’s Desktop tab the box read LCP 1.7 s, INP N/A, CLS 0, and the line said Passed. That is the rule’s third sentence on a real screen: not enough click data, so the other two decided. A Passed with an N/A in it is a real Passed. Not one of the pages that came up when I searched this question mentions that sentence.

That is how to read the box. What follows: what Google Search says about these numbers, what to do about the one that is not green, how a fix shows, and then the failed site itself.

What Google Search says about these numbers

Short, because this article is about the line. Google’s page on page experience, updated 22 September 2026, and I will quote rather than paraphrase: “Core Web Vitals are used by our ranking systems.” The next sentence: “We recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” And, further down: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” None of it mentions this line: the page speaks of Core Web Vitals, not of PageSpeed’s pass or fail. No weight is given, and no penalty for Failed is written anywhere I could find.

What to do about the number that is not green

The question is not “how do I raise the score” but “why is this number slow for real visitors”.

For LCP: is the main heading or picture on the screen when the page first shows anything, or does a script or an animation have to run first? The box gives a first clue without any code: compare LCP with FCP below it. A wide gap usually means the page showed your visitors something and then made them wait for the main thing. The lab section under the circle helps find the cause; its strip of small frames shows the page being drawn. On cryptowl.io the word “Time” appears in the fourth of eight frames, on kovalseo.com the whole page from the second. The test helps you find the cause. It does not decide the line.

For INP, ask what runs when someone taps. Google’s page on the most effective ways to improve Core Web Vitals heads its INP advice “Yield often to break up long tasks” and “Avoid unnecessary JavaScript”. For CLS, ask what arrives late and pushes the page down; the same page’s first heading for CLS is “Set explicit sizes on any content loaded from the page”.

What the fix is depends on what the page does, and I will not pretend to a list. On cryptowl.io the first thing to change is the entrance animation, a design choice of mine; the last section shows how it holds the headline back. The fix is to let the headline be on the screen when the page arrives and animate around it, or not at all. I have not made that change yet, which is why this article has no “after”.

If someone else built or runs your site, the wording matters, because the score in the circle is the easy thing to point at. Send this, with your own report’s values in the brackets:

How a fix shows, and how long it takes

The box is filled from the Chrome UX Report, and its documentation says three things about time. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” “Data is updated daily around 04:00 UTC.” And the data is “approximately two days behind today’s date”. So the box is refreshed every day, and every day it covers 28 days that end a little before today. A fix made today enters the box only after that lag, and then shares it with weeks of visits from before it. It does not wait 28 days and then change; it moves a little each day as new visits replace old ones, and only after about a month does the window hold nothing from before. That “about a month” is my inference from the size of the window; Google gives no number of days, and its page on the tools says only that “it will take a fair amount of time for improvements to be reflected in the CrUX dataset.” Pages that came up when I searched this question say the box updates “every 28 days” or carries “a delay of 28 days”. Neither is what Google writes.

Running the test again does nothing to the box, and the same documentation explains why: “Data won’t differ within the same day after it has been updated around 04:00 UTC, repeated calls will yield the same results.” My three runs, spread over about four minutes, were that sentence on a screen.

What to watch for, then: same tab, same “This URL”, on a date you have written down. The number that was not green lower than it was, then lower again, over days, not within an afternoon. If the number that was not green falls below its limit and the line says Passed, real visits got faster, whatever the circle says. If the circle rises and the box does not, you have no evidence yet that your visitors noticed.

A site of mine that failed with a 90 under it

Both sites are built with the same tool, Astro; what differs is what the page does when it arrives. The two reports, Desktop tab, “This URL”, 3 October 2026:

The three runs were at 12:09, 12:10 and 12:13. The circle changed each time; the box did not move by a decimal. Why the circle moves is a question of its own, not this article’s. Here it shows one thing: pressing Analyze again asks the test machine again. It does not ask your visitors again.

The contradiction is in the LCP rows. The test’s figure for the largest thing on the screen was under a second; three real visits in four had it within 3.3 s, and the rest waited longer. Google’s page on improving LCP says which to believe when that happens: “If Lighthouse and CrUX disagree, then CrUX likely provides a more accurate picture of your user experience.” Lighthouse is the test that makes the circle. On this page the test was the optimistic one. The code shows what real visitors wait for; why the test reports so much less, I can only infer.

The headline is invisible until a script shows it

cryptowl.io opens with an entrance animation. In its stylesheet, which I read, the main headline and the header are set to opacity 0, fully transparent, until a script has loaded, built the animation and run it far enough to show it. The word “Time” in that headline was the largest thing on the screen in all twelve of my runs on my own laptop, and the animation is what draws it. For this question that opacity 0 matters, because Google’s page on LCP lists what Chrome refuses to count as the largest element:

Google’s page on Largest Contentful Paint, on what is excluded

Elements with an opacity of 0, that are invisible to the user

A transparent headline is nothing on the screen. Chrome’s own change note from when that rule went in, in Chrome 86, says what happens to a page built this way:

Chrome’s LCP change note for Chrome 86

Sites using this technique will now see a longer LCP, reflecting the time until the largest contentful paint is visible to the user, instead of the time it is loaded in the DOM but invisible.

So for a real visitor the clock runs until the server answers, the scripts arrive, the animation is built and run far enough, and only then does the largest thing on the screen exist. Add what I timed on my own laptop to the box’s own server time, and the pieces come to roughly the box’s 3.3 s: about a second for the server to start answering (the box shows 1.1 s), up to a second more for the scripts, and about a second until the animation shows the headline. That is my estimate, not proof, and it does not prove the animation is the whole of it. Why the test reports 0.8–0.9 s for the same page I cannot prove either; my reading is that the simulated load does not wait for the animation’s clock.

The box shows the same thing without any code, in the gap between FCP and LCP. kovalseo.com: 1.6 s and 1.7 s, a tenth apart; that day its home page had no script of its own, and its main picture was asked for ahead of everything else. cryptowl.io: 1.7 s and 3.3 s, 1.6 s apart: real visits got something on the screen early and the largest thing, on my own runs always the headline, well after. The box recorded the wait. The circle did not.

Written by Oleh Koval at Specia1ne, who reads these reports for a living.