Core Web Vitals: what really matters for SEO
3 min read
Key takeaways
- Headless is justified from two surfaces to feed, not before.
- The cost of headless is not the licence, it is building the front end.
- Editorial autonomy is lost very quickly if preview is not well done.
- A well-maintained traditional CMS remains excellent for a single showcase site.
- Check that you can export your content before committing: it is your way out.
"We're going headless." The phrase has become a reflex, often adopted for reasons that have nothing to do with the real need: it's modern, it's fast, it's what everyone else is doing.
Headless is an excellent choice in some situations, and a pure extra cost in others. The dividing line is fairly clear.
What headless really changes
A traditional CMS does two things: it stores the content and it generates the pages. A headless CMS only does the first. Rendering becomes your responsibility.
This has three direct consequences.
You gain freedom of rendering. The same content served to a website, a mobile app, an in-store screen, a newsletter. This is the real argument, and the only decisive one.
You lose "ready to use". What a theme gave you for free — pages, menus, search, forms, preview — has to be developed.
You shift the cost. The licence goes down, development goes up. The total is almost always higher on a single-site project.
The question that settles it
How many distinct surfaces do you need to feed with the same content?
- Just one — a website: a well-maintained traditional CMS, or a generated static site, will remain simpler and cheaper.
- Two or more — a site plus an app, or several country sites, or a site plus physical screens: headless becomes profitable, and that profitability grows with each surface.
Everything else — performance, SEO, security — depends far more on the quality of the build than on the type of CMS.
The editorial team test: ask the person who will actually publish to edit a page and see the result before publishing. If it takes more than two minutes or needs a developer, editorial autonomy is lost — and with it the main reason for having a CMS.
The criteria that really matter
1. Preview
This is the point that comparisons ignore and that decides adoption. Without a faithful preview, the editorial team publishes blind, fixes things in production, and ends up asking for the old tool back.
To check before choosing: does preview work on unpublished content, on pages made of several blocks, and without technical intervention?
2. Content modelling
A good model separates substance from presentation: an article has a title, a standfirst, a body, an author, an image — not "a left column with a blue box".
It is the most profitable investment of the project, and the hardest to fix afterwards. Sloppy modelling turns the CMS into a layout editor, which cancels the point of decoupling.
3. The rendering served to the browser
The content must be present in the HTML received by the browser. A headless site that loads everything on the client side is slower and less well indexed than a traditional site — this is the main, justified criticism made of the first generations of headless projects.
Static generation or server-side rendering: both work, the important thing is not to let the browser assemble the page. The thresholds to meet are those described in our article on Core Web Vitals.
4. Reversibility
Before committing, export your content. Really: do the export, open the file, check that the relationships between content and the attached files are in it.
A CMS whose export is partial or paid locks you in, and that lock-in will be paid for at the next change.
5. Permissions and approval workflows
Who can publish what, who approves, how a publication is scheduled. Trivial on a traditional CMS, often something to develop or pay extra for on headless offerings.
The three families of offerings
| Family | For whom | Watch out for |
|---|---|---|
| Turnkey online service | Teams without hosting skills | Cost per user and per content item, reversibility |
| Self-hosted solution | Teams with a technical profile | Maintenance and update workload |
| Content in a code repository | Documentation sites, technical blogs | Almost no editorial autonomy for a non-technical profile |
The third family deserves a warning: it is attractive for a technical team and generally unusable for a marketing team. If the content has to be published by people who do not write code, rule it out.
When the traditional CMS remains the right choice
Without nostalgia or provocation, this is the most common scenario:
- a single site to feed;
- an autonomous editorial team that publishes often;
- standard needs — pages, articles, forms, multilingual;
- a budget that should go to content rather than infrastructure.
In this configuration, a properly configured traditional CMS, stripped of its unnecessary extensions and hosted properly, gives an excellent result for half the budget. Moving it to headless later remains possible if a second channel appears.
2Number of surfaces from which headless becomes profitable
≈ 50%Share of a migration project spent restructuring content
< 2 minTarget time to edit a page and see the result
The best CMS is the one your editorial team uses without calling anyone. All its other qualities come after that one.
Our default recommendation
For a single professional site with a non-technical editorial team: a proven CMS, well configured, with a custom theme and proper hosting.
As soon as a second surface appears — a mobile app, a second site, screens — headless becomes the right investment, provided you deal first with content modelling and preview. These two points, not the choice of tool, will make the difference between a system that is used and a system that is worked around.
Sources
- Comprendre les bases du SEO JavaScript (in French) — Google Search Central
- Rendu sur le Web (in French) — Google (web.dev)
