Core Web Vitals Example: A Deliberately Bad Page
My coach took three lunches to reach the end of a lane that was, I admit, too narrow for it.
The short answer
- What it is
- This issue means a tested page has poor or middling speed and stability scores. The overall verdict uses field data when it exists, and otherwise a Lighthouse performance score under 50 counts as poor.
- Why it matters
- These metrics describe how a page feels to real people. Google says Core Web Vitals are used by its ranking systems, though good scores do not guarantee a top position.
- How a crawler should report it
- Report the overall verdict, its data source, and each value. Lab limits are LCP over 4,000 ms as poor and 2,500 to 4,000 ms as needs improvement, TBT over 600 ms and 200 to 600 ms, and CLS over 0.25 and 0.1 to 0.25.
- Live examples
/lab/cwv/samples/lcp-ni/d/e/(positive)/lab/cwv/samples/cls-poor/d/e/f/g/h/(positive)/lab/cwv/samples/cls-ni/d/e/f/g/h/i/(positive)/lab/cwv/samples/poor/(positive)/lab/cwv/samples/lcp-poor/d/(positive)/lab/cwv/samples/good/d/e/f/g/h/i/j/(near miss)
Loading, Response, and Stability Scores on a Deliberately Slow Page
What are Core Web Vitals? They are three metrics from Google that measure real user experience. Largest Contentful Paint tracks loading, and a good score is 2.5 seconds or less. Interaction to Next Paint tracks how fast a page responds, and a good score is 200 milliseconds or less. Cumulative Layout Shift tracks visual stability, and a good score is 0.1 or less. Scores are judged at the 75th percentile of page visits.
There are two kinds of data, and they answer different questions. Field data comes from real Chrome users and is collected over a 28 day window in the Chrome UX Report. Lab data comes from one test on a set device and network. Interaction to Next Paint needs a real person to click or tap, so lab tools use Total Blocking Time as a stand-in. A page with too little traffic may have no field data at all.
Each metric tends to fail for its own reasons. Slow LCP often comes from a late server response, a heavy hero image, or CSS that blocks rendering. High blocking time comes from long JavaScript tasks on the main thread. Layout shift comes from images with no size, late ads, and web fonts that swap in. To detect these, run Lighthouse for a lab result, and check the Chrome UX Report for field results.
Fix the worst metric first. For LCP, speed up the server, compress the main image, and give it a high fetch priority. For blocking time and INP, split long tasks, delay scripts that are not needed, and remove third-party tags you no longer use. For CLS, set width and height on media and reserve room for ads. Lab results can improve at once, but field data takes weeks to catch up because of its rolling window.