Sign in Start free

Core Web Vitals triage

Lab tools give a synthetic score; the ranking signal comes from field data collected from real visitors. This skill works from field data down to the specific element causing each failure.

CATEGORY
Technical SEO
FORMAT
core-web-vitals-triage.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when field data shows failing LCP, INP or CLS and you need to know which fix will actually move the metric rather than guessing from a lab score.

The skill file

core-web-vitals-triage.md
---
name: core-web-vitals-triage
description: Use when field data shows failing LCP, INP or CLS and you need to know which fix will actually move the metric rather than guessing from a lab score.
---

# Core Web Vitals triage

Lab tools give a synthetic score; the ranking signal comes from field data collected from real visitors. This skill works from field data down to the specific element causing each failure.

## What you need first

- CrUX or Search Console Core Web Vitals report
- A lab trace (Lighthouse or WebPageTest) for a representative URL per template

## Method

1. Group failing URLs by template, not individually - one template fix usually resolves thousands of URLs.
2. For LCP, identify the LCP element per template from the trace. It is almost always a hero image, a webfont-rendered heading, or a client-rendered block.
3. Split the LCP into its four parts: time to first byte, resource load delay, resource load time, render delay. Fix the largest part, not the one that is easiest.
4. For INP, capture interactions with the longest processing time and look for long tasks on the main thread - usually third-party scripts or a heavy hydration step.
5. For CLS, find what shifts: images without dimensions, injected banners, late-loading webfonts without a matched fallback metric.
6. Verify against field data after 28 days, since that is the collection window - a lab improvement that field data never confirms is not a fix.

## What this produces

Per template: the failing metric, the specific element responsible, the breakdown that proves it, and the change to make.

## Where this goes wrong

- Optimizing to a lab score while field data is unchanged
- Fixing the smallest LCP sub-part because it is the easiest
- Judging results before the 28-day field window has rolled over

---

From the QuQi skill library - https://www.quqi.io/skills/core-web-vitals-triage
Free to download · no account, no email

What you need first

  • CrUX or Search Console Core Web Vitals report
  • A lab trace (Lighthouse or WebPageTest) for a representative URL per template

Method

  1. 01 Group failing URLs by template, not individually - one template fix usually resolves thousands of URLs.
  2. 02 For LCP, identify the LCP element per template from the trace. It is almost always a hero image, a webfont-rendered heading, or a client-rendered block.
  3. 03 Split the LCP into its four parts: time to first byte, resource load delay, resource load time, render delay. Fix the largest part, not the one that is easiest.
  4. 04 For INP, capture interactions with the longest processing time and look for long tasks on the main thread - usually third-party scripts or a heavy hydration step.
  5. 05 For CLS, find what shifts: images without dimensions, injected banners, late-loading webfonts without a matched fallback metric.
  6. 06 Verify against field data after 28 days, since that is the collection window - a lab improvement that field data never confirms is not a fix.

What this produces

Per template: the failing metric, the specific element responsible, the breakdown that proves it, and the change to make.

Where this goes wrong

  • Optimizing to a lab score while field data is unchanged
  • Fixing the smallest LCP sub-part because it is the easiest
  • Judging results before the 28-day field window has rolled over

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/core-web-vitals-triage/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is field-first triage the right approach rather than working from a Lighthouse score?

When field data shows real visitors failing LCP, INP or CLS. A Lighthouse run is a simulation on one device and one connection, while the ranking signal comes from what real sessions recorded. If the lab score looks poor but field data passes, there is nothing here to triage and the engineering time is better spent elsewhere.

What do I need in hand before starting?

A CrUX or Search Console Core Web Vitals report for the field side, and a lab trace from Lighthouse or WebPageTest for one representative URL per template. Field data alone names the failing metric but not the element responsible; a trace alone says nothing about whether real visitors are affected. Without URLs mapped to templates you end up fixing pages one at a time.

What do I end up with, and which part gets used?

Per template, the failing metric, the element responsible, the measurement that proves it and the change to make. The LCP breakdown into time to first byte, resource load delay, resource load time and render delay is the part that gets used, because it names which of four unrelated fixes will move the number and rules the other three out.

What is the mistake that ruins this, and what does it cost?

Calling the result before the field window has rolled over. Field data moves on a twenty-eight day collection window, so a fix deployed today is diluted by four weeks of older sessions, and a team reading the graph in week one concludes the work failed and stops. The related error is fixing the smallest LCP sub-part because it is easiest, which leaves the metric where it was.

More in Technical SEO