Headless CMS: which one to choose when you are not a technical team
4 min read
Key takeaways
- Core Web Vitals are a tie-breaker, not a ranking lever on their own.
- LCP is almost always the metric to fix first, and the header image is the cause.
- INP has replaced FID: it measures real responsiveness, and third-party JavaScript is the main culprit.
- CLS can be fixed in an hour: explicit dimensions on images and ad slots.
- Measure with field data, not with a lab test run from your fibre connection.
Every six months, an article announces that speed is going to "revolutionise SEO". Then nothing changes dramatically, and the same sites stay at the top.
The reality is more nuanced, and more useful to know: Core Web Vitals do not push you up, but they do push you down. With comparable content, the slowest page loses. And above all, it converts less, which is a far more costly problem than a ranking position.
The three metrics, without jargon
| Metric | What it measures | Good threshold | Main cause |
|---|---|---|---|
| LCP | The time before the main element is visible | < 2.5 s | Header image, blocking font, slow server |
| INP | The delay between an interaction and the visible response | < 200 ms | Third-party JavaScript, overly heavy scripts |
| CLS | Layout shifts during loading | < 0.1 | Images without dimensions, banners inserted after the fact |
These thresholds must be met for 75% of real visits. This is the point most teams miss: a perfect score on a single test run from a fibre-connected workstation says nothing about what your visitors experience on the move.
The six optimisations that deliver 80% of the gain
1. The header image
This is culprit number one for LCP, on almost every site we audit. A 2.4 MB full-width photo, loaded as an uncompressed JPEG, at a resolution three times higher than what is displayed.
The fix: a modern format (WebP or AVIF), real dimensions suited to the display, several sizes offered depending on screen width, explicit loading priority on this one image alone, and deferred loading for all the others. Typical gain: 1 to 2 seconds.
2. Fonts
A poorly loaded web font blocks the display of text, or causes an abrupt change of rendering during loading.
The fix: preconnect to the domain that serves the fonts, immediate display with a fallback font, and a limit of two families and three weights. Every extra weight is another file to download.
3. Third-party JavaScript
This is the main culprit behind a poor INP. On a typical professional site, we often find eight to fifteen third-party scripts: audience analytics, ad management, chat, map, A/B testing, conversion tracking, and two tools nobody remembers installing.
The fix comes down to three questions asked for each script: is it still used? can it be loaded after the display? can it be triggered only on interaction? A chat loaded only when its icon is clicked often saves 300 to 500 ms of INP.
4. Explicit dimensions
Every image, every iframe, every reserved slot must declare its width and height. The browser then reserves the space before even downloading the content, and the page stops jumping.
This is the cheapest optimisation of the lot: a few hours of work, and a CLS that turns green.
5. Caching and compression
Long cache on static resources, modern compression on text files, and a server response under 200 ms on the home page. On a properly hosted static site, this is a given; on a dynamic site, it is often the first gain to go after.
6. What is loaded without being seen
A carousel whose eight images are all loaded upfront, an interactive map at the bottom of the page, a video embedded in the background. Everything below the fold can wait until the visitor gets close.
2.5 sLCP threshold to meet on 75% of real visits
1–2 sTypical gain from treating the header image alone
3–8 dUsual effort to bring an existing site to green
Measuring properly
Two families of tools, two different uses, and a constant confusion.
Lab tests run the page under simulated conditions. They are perfect for diagnosing a cause and for comparing before and after. They say nothing about your real audience.
Field data comes from actual visits. It is the only reference for knowing where you stand, and it can be found in Search Console, in the dedicated report.
The lag to be aware of: field data is calculated over a rolling 28-day window. After an optimisation, the improvement takes several weeks to appear in the reports. Do not conclude it has failed after five days.
What is pointless
Chasing the perfect score. Going from 92 to 99 on a synthetic test has no measurable effect on SEO or on conversions. Going from 45 to 80 has a very clear one.
Optimising a page that gets no visitors. Focus the effort on the ten pages that bring the traffic. This is also what we recommend during a redesign.
Removing all the JavaScript. The goal is not a site without interactivity, it is a site where interactivity does not block the first display.
Web performance is not a score to show off in meetings. It is the time your visitors spend waiting. The only figure that matters is the one experienced by 75% of them, on their phone, on the metro.
Where to start tomorrow morning
Open Search Console, Core Web Vitals section. Note the pages in red and orange. Cross-check with your ten most visited pages. The intersection is your working list, and it generally fits on three lines.
Sources
- Web Vitals (in French) — Google (web.dev)
- Interaction to Next Paint becomes a Core Web Vital on March 12 — Google (web.dev)
- Comprendre l’expérience sur la page dans Google (in French) — Google Search Central
- Rapport Core Web Vitals — Google Search Console
