Core Web Vitals: the thresholds Craft is scored against

The Craft dimension of the rubric includes measured load performance. This page states exactly which thresholds are used, where they come from, how the assessment works, and how to reproduce any performance figure that appears in a teardown. If you want to argue with a Craft score, this is the page the argument has to go through.

The short answer

Core Web Vitals are three metrics. A URL passes only when all three sit in the good band at the 75th percentile of real visits, and mobile and desktop are assessed separately.

Two of three is not a pass. Everything else you may have seen described as a Core Web Vital is either a diagnostic metric, a lab simulation, or a composite score that is not Core Web Vitals at all. The difference matters enough that much of this page is about it.

What each metric actually measures

Largest Contentful Paint

LCP is the render time of the largest image or text block visible in the viewport, measured from when the page starts loading. On a blog the LCP element is almost always one of three things: the featured image, the article headline, or the first paragraph.

The useful part is that LCP decomposes into four consecutive stages, and knowing which one dominates tells you what to fix:

• Time to first byte. Server and network latency before anything arrives. Addressed with hosting, caching and a CDN, not with front-end work.
• Resource load delay. The gap between the first byte and the browser starting to fetch the LCP resource. Caused by late discovery: an image referenced from CSS, injected by JavaScript, or sitting behind a render-blocking stylesheet.
• Resource load duration. How long the LCP resource itself takes to download. Addressed with format, compression and dimensions.
• Element render delay. The resource has arrived but has not painted, usually because the main thread is busy or a web font has not resolved.

A publication with a 4.8 second LCP caused by time to first byte and one caused by a 2MB uncompressed hero image have the same number and nothing else in common. A teardown that reports LCP without saying which stage dominates has measured something and explained nothing.

Interaction to Next Paint

INP measures the latency of interactions across the whole visit and reports close to the worst one rather than averaging them. An interaction is a click, a tap, or a key press. Scrolling and hovering are excluded.

Each interaction breaks into three parts: input delay while the main thread finishes whatever it was already doing, processing duration while event handlers run, and presentation delay while the browser paints the result.

INP replaced First Input Delay in March 2024. FID measured only the delay before the browser began processing the first interaction, which meant a page could score well while every later interaction was slow and the actual work of the handler was never counted. INP is a more complete measurement and a considerably less forgiving one. Sites that comfortably passed FID have failed INP without changing a line of code.

For a blog, INP failures usually come from a short list of sources: heavy JavaScript from a page builder or theme, tag managers and analytics, consent management platforms, comment systems, and share widgets that bind handlers to the whole document.

Cumulative Layout Shift

CLS is the most misunderstood of the three, because it is not cumulative in the way the name implies. It reports the largest burst of layout shift, not the total across the visit.

Shifts are grouped into session windows. A window opens at the first shift, extends while shifts continue with gaps of less than one second, and closes after a maximum of five seconds. The reported CLS is the highest-scoring window. This was a deliberate revision: under the original definition, long articles were penalised for being long, because a slow scroll accumulated small shifts indefinitely.

Shifts occurring within 500ms of a user interaction are excluded, on the grounds that a reader who opens a menu expects the page to move. Everything else counts.

On a blog, CLS comes from a predictable list: images and iframes without width and height attributes, web fonts swapping and reflowing text, ad slots and newsletter units injected above content, cookie banners that push the page rather than overlaying it, and lazy-loaded elements that reserve no space.

How the assessment works

Google evaluates each metric at the 75th percentile of real user data drawn from the Chrome User Experience Report, over a rolling 28-day window. At least 75 percent of qualifying visits must meet the good threshold for that metric to pass.

The 75th percentile is a deliberate choice. The median would ignore the slower half of visitors entirely. A higher percentile would let a handful of visits on poor connections define the result for everyone. Three quarters is the compromise, and it means a site can fail while feeling fast to the person who built it, because the person who built it is testing on a fast device on their own network.

Three consequences follow, and all three are places a teardown goes wrong if they are not stated:

• Mobile and desktop are separate. A site can pass on desktop and fail on mobile. Reporting one number for a site is reporting half the result.
• The window is 28 days and it lags. A fix deployed today does not appear in field data today. It appears gradually as the window rolls forward, which takes roughly a month to fully reflect.
• Small sites often have no field data at all. The Chrome User Experience Report requires enough qualifying traffic to report. Most small publications do not meet it at the URL level, and many do not meet it at the origin level either.

Field data and lab data are not the same thing

This is the most common error in performance claims, and it is worth being blunt about.

Field data is measurement from actual visits by actual people on actual devices. Core Web Vitals as Google assesses them are field data. Lab data is a simulated load under fixed synthetic conditions. Lighthouse produces lab data.

A site can score 98 in Lighthouse and fail Core Web Vitals, because the simulation assumes a device and connection better than the ones real visitors have. It can also score badly in Lighthouse and pass, because the simulated throttling is harsher than most real visits.

The Lighthouse performance score is not Core Web Vitals. It is a weighted composite of lab metrics, several of which are not Core Web Vitals at all. Total Blocking Time is in the composite and is a lab proxy for INP rather than INP itself. First Contentful Paint and Speed Index are in the composite and are not Core Web Vitals. Quoting a Lighthouse score as a Core Web Vitals result is a category error, and it appears constantly in writing about site speed.

The diagnostic metrics, and why they are not thresholds

Google publishes several other metrics that are useful for diagnosis but are not scored and have no pass threshold. Time to First Byte is a component of LCP. First Contentful Paint tells you when anything appeared. Total Blocking Time is the lab stand-in for INP. Reference values exist for some of these and are worth watching, but a teardown that scores a publication against a TTFB target is inventing a standard rather than applying one.

How to reproduce a Craft performance figure

Every number in a teardown is meant to be checkable by a reader with a browser. For performance, that means the following sequence, which is what each teardown runs:

1. Run PageSpeed Insights against a representative article URL, not the home page. Readers arrive on articles, and the article template is what the rubric cares about.
2. Read the field data section first. If it reports URL-level data, that is the figure. If it reports origin-level data only, that is a weaker figure and is labelled as such.
3. If there is no field data at all, fall back to lab measurement and say so explicitly in the post.
4. Check mobile and desktop separately and report both.
5. Use DevTools to attribute the failure to a stage, an element or a script, so the finding is actionable rather than only a number.

Where field data is unavailable, which is the common case for smaller publications, the teardown relies on lab measurement and flags it. A lab number is never presented as though it were a field number. This follows from the wider evidence standard: if a figure cannot be reproduced by a reader with a browser, it does not appear.

How this is used in a teardown

Craft is scored on more than performance. The band definitions also cover consistency of the type scale across templates, line length, the mobile reading experience specifically, and whether the markup is semantic. A site can be fast and still be unpleasant to read.

Performance anchors the dimension because it is the part that can be measured identically across every subject, with no judgement involved. The band language is careful about this. Band 2 refers to measurable performance problems on primary templates. Band 3 refers to performance around commonly cited thresholds, and this page is what those thresholds are. Band 4 requires good measured performance on every template a reader meets, which is why a teardown checks the article template, the home page and at least one archive rather than sampling one URL and generalising.

Band 5 is not a performance band at all. It asks whether the reading experience is itself a reason people come back, which no tool measures.

Platform choice sets the difficulty rather than the outcome. A default install on a lean platform tends to land mid-band without intervention, while a page builder plus a dozen plugins will not get there by accident. That trade is covered in Ghost vs WordPress for a one-person publication.

Common misreadings

• We pass two of three. There is no partial pass. All three metrics must be good.
• Our Lighthouse score is 95. Different measurement, different data type, not the assessment.
• It is fast on my machine. Your machine sits at a percentile you are not measuring.
• We fixed it last week and nothing changed. The field window is 28 days and it rolls.
• Core Web Vitals will fix our rankings. They are a ranking input and a small one. Relevance is not overridden by speed. Performance is worth fixing because readers leave, which is a better reason.
• Our origin passes. Origin-level data is every URL on the domain averaged together. It can pass while the article template fails.

Questions

Do Core Web Vitals affect search rankings?

Yes, as part of Google page experience signals, and less than most coverage implies. A slow page with the best answer to a query will generally outrank a fast page with a worse one. Treat the thresholds as a reader-experience standard that happens to carry a search benefit, not as a ranking lever.

Why does my site have no field data?

The Chrome User Experience Report only reports where there is enough qualifying traffic. Below that, PageSpeed Insights shows lab data only. The fix is to collect your own field data with the web-vitals JavaScript library, which has no traffic threshold and measures the visitors you actually have.

Which URL should I test?

The article template, using a genuinely representative post rather than your best-optimised one. Home pages are usually faster than articles and are not where readers land from search or a feed.

Is a perfect score worth chasing?

No. The thresholds are bands, not targets to beat. An LCP of 1.2 seconds is not scored higher than 2.4 seconds. Effort past the good threshold is better spent on the parts of Craft that no tool measures.

Sources

• web.dev, How the Core Web Vitals metrics thresholds were defined
• web.dev, Web Vitals
• Google Search Console Help, Core Web Vitals report
• Chrome User Experience Report documentation

Thresholds and metric definitions verified August 2026. Google has revised Core Web Vitals before, including replacing First Input Delay with Interaction to Next Paint in March 2024 and changing the CLS calculation to use session windows. Every teardown records the version of the metrics it was scored against, and scores produced under different definitions are not directly comparable.