Website Performance and Core Web Vitals After a Migration
Performance is usually presented as a score to chase. It is more useful as a set of design decisions taken during a migration, because almost every serious performance problem is created at that moment: how images are handled, how fonts load, how much script ships, and whether the layout reserves space for what it is about to render.
Largest Contentful Paint is mostly an image problem
On content sites the largest element is nearly always the hero image or the headline block above it. Make that element cheap: serve a modern format at a sensible resolution, declare explicit dimensions, preload it, and load it eagerly while everything below the fold is lazy.
The second contributor is render-blocking work. Fonts that block text, stylesheets that could be inlined for critical rules, and third-party scripts loaded in the head all delay the same moment. Migrations are the natural time to remove the accumulated ones nobody can justify.
Interaction latency and script weight
Interaction to Next Paint measures whether the page responds when a person touches it. The dominant cause of poor scores is JavaScript executing on the main thread — hydration, analytics, chat widgets, consent managers and tag managers competing at load.
A template-rendered site starts with a large advantage here because there is no hydration to perform. Preserve that advantage: add interactivity as small, targeted scripts rather than reintroducing a framework for a carousel.
Layout stability is a discipline, not a plugin
Cumulative Layout Shift comes from content arriving without reserved space: images without dimensions, fonts that swap to different metrics, embeds that resize, and banners injected above existing content.
Each has a straightforward fix, and all of them are cheaper to apply while building templates than to retrofit afterwards. Reserve space for everything asynchronous, match fallback font metrics, and never insert content above what a reader is already looking at.
Measure the right thing
Laboratory tools are useful for diagnosis and misleading as a target. What matters is field data from real visitors on real devices and networks, segmented by template. A single number for the whole site hides the one page type that is failing.
Set a budget per template — a weight limit, a request limit and a target for each metric — and check it in staging before every significant release. Budgets prevent the slow regression that turns a fast new site into an average one within a year.
Technical references
The documentation below covers the procedures behind this article in far more operational detail than an editorial piece can.
- speed optimisation guide
- image optimisation
- performance monitoring
- theme optimisation
- hosting and delivery
- plugin selection and weight
- responsive implementation
- analytics without the overhead
- static versus dynamic performance
- testing in staging
- SEO and performance checks
- maintaining theme changes