DomainLens

Modèles

Core Web Vitals Fix Priority Template

Core Web Vitals work goes wrong when teams optimise the metric that is easiest to measure rather than the one that is failing for users.

Vérifiez votre site avant de corriger

Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.

Lancer un audit SEO gratuit

Order the metrics before the fixes

Work on the metric that is failing in field data, for the URL group with the most traffic. That sounds obvious and is routinely skipped in favour of whatever the lab report flagged loudest.

If several fail, LCP usually comes first: it has the most common causes, the fixes are well understood, and it frequently improves CLS as a side effect.

MetricThresholdAttack when
LCP≤ 2.5sFailing, or close — usually first
INP≤ 200msFailing on interaction-heavy pages
CLS≤ 0.1Failing — often the cheapest to fix
TTFB≤ 800msWhenever LCP cannot reach target without it

LCP causes, ranked by how often they are the answer

The first row costs minutes and is the single most common LCP fault on modern sites, because image components lazy-load by default and that default is wrong for exactly one image per page.

#CauseFixEffort
1Hero image lazy-loadedRemove loading="lazy", add fetchpriorityMinutes
2Slow TTFBPage caching, CDNMedium
3Hero image oversizedResponsive srcset, modern formatLow
4Late discoveryPreload the LCP resourceLow
5Render-blocking CSS or fontsInline critical CSS, font-displayMedium
6Client-side renderingServer-render the above-fold contentHigh

CLS and INP causes

CLS is usually the cheapest of the three to fix, which makes it a good first win when several metrics fail and the team needs a result.

  • CLS — images without width and height. Almost always this first.
  • CLS — ads, embeds or banners inserted above existing content without reserved space.
  • CLS — web fonts swapping and reflowing text; set font-display and match fallback metrics.
  • INP — long tasks from third-party scripts blocking the main thread.
  • INP — expensive event handlers that do all their work before painting.
  • INP — very large DOM making every re-render costly.

Fix one cause at a time

Core Web Vitals work has an unusual property: the feedback loop is four weeks long, because field data is a 28-day rolling average. That makes the usual approach of shipping several improvements together actively harmful — when the metric moves you will not know which change did it, and when it does not you will not know which to undo.

The discipline is to ship one cause, wait, and read the result before starting the next. It feels slow and it is the only way the exercise produces knowledge rather than activity.

There is one exception worth taking. When several fixes are genuinely the same edit — removing a lazy-loading attribute from every hero across all templates — ship them together, because they are one change applied consistently rather than several competing hypotheses.

The verification loop

The waiting step is what separates measurement from guessing. See PageSpeed Insights vs Lighthouse vs CrUX for which data source answers which question.

  1. 1Record the field value for the URL group before changing anything.
  2. 2Reproduce the failure in a lab trace and identify the specific cause.
  3. 3Fix one cause. Not three — you will not know which worked.
  4. 4Confirm in the lab that the specific diagnostic improved, not that the score rose.
  5. 5Wait for field data. The 28-day window means real confirmation takes weeks.
  6. 6Only then move to the next cause.
Which Core Web Vital should I fix first?
The one failing in field data on your highest-traffic template. When several fail, LCP is usually the most productive starting point.
Why did my fix not change the field data?
The 28-day rolling window dilutes recent changes. Give it several weeks before concluding the fix did not work.
Should I chase a perfect Lighthouse score?
No. Once field metrics pass the thresholds, further lab-score work optimises a simulation Google does not read.

Ressources associées