Core Web Vitals: what each metric measures and how to fix it
LCP, INP and CLS measure different failures with different causes. Knowing which metric is failing tells you almost exactly where to look.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Headless is justified by multiple consumers, not by fashion.
- Content modelling capability is where products genuinely differ.
- Preview and workflow determine whether editors accept it.
- Model pricing at future volume and confirm the export path.
Decide whether you need headless at all
Headless makes sense when the same content genuinely serves several destinations, or when your front-end team wants full control of the rendering stack. It is less compelling when there is one website and one team.
A traditional CMS gives you preview, in-context editing and a large ecosystem for free. Going headless means rebuilding some of that, and the cost lands on the editorial team rather than on engineering.
Content modelling capability
This is where products genuinely differ. Ask how the system handles references between content types, repeatable structured components, localisation and validation rules.
A model that cannot express relationships forces you to duplicate content, and duplicated content diverges. If your content has real structure, test the model on your two most awkward content types before committing.
Editorial experience and preview
Editors need to see their work in context before publishing. Some headless products handle this well through preview APIs and draft modes; others leave you to build it.
- Can an editor preview an unpublished page as it will appear?
- Is there a review and approval workflow, or only publish?
- How are scheduled publishing and content expiry handled?
- What does the interface look like with a hundred content types rather than five?
Cost of leaving
Hosted platforms price by records, users, API calls or a combination, and costs can rise sharply as content grows. Model this at three times your current volume rather than at today's.
Then ask how you would leave. Content export in a structured, documented format is the difference between a migration and a rebuild, and it is worth confirming before signing rather than afterwards.
Migration and lock-in in practice
The exit question deserves testing rather than trusting. Export a representative slice of content and examine what you actually receive: are relationships preserved, are rich-text fields portable or wrapped in a proprietary structure, do assets come with their metadata?
Proprietary rich-text formats are the most common source of migration pain, because a document stored as vendor-specific structured data does not convert cleanly to anything else. Products storing portable markup are considerably easier to leave.
None of this argues against hosted platforms. It argues for knowing the cost of leaving before you have five years of content inside one.
Frequently asked questions
Not inherently. What matters is whether pages are server-rendered with fast, crawlable HTML. A well-built headless site and a well-built traditional site perform similarly; a client-rendered site with no server rendering will struggle.
Yes. Both expose content APIs, and doing so lets you keep a mature editorial interface while rendering the front end separately. This is often a better trade than adopting a new platform.
Open-source options have no licence fee but need hosting and maintenance. Commercial platforms typically charge per seat and per environment, with costs increasing as teams and content grow. Model three years, not one.
