- Moving the hero from a CSS background to a server-rendered image with a priority hint cut median LCP by 2.3 seconds across nine sites.
- One interactive island per section took INP from 340 ms to 140 ms on seven sites without touching a click handler.
- A self-hosted subset variable font with a metric-matched fallback produced zero measured layout shift on all twelve.
- AVIF, service workers, deep code splitting and performance plugins changed nothing measurable in the field.
- Judge the work on a 28-day field reading segmented by device, never on a Lighthouse score.
Over eighteen months we rebuilt or substantially reworked twelve client sites and measured field Core Web Vitals before and after each one. They ranged from a WordPress brochure site to a Shopify store and two Next.js applications.
Four changes account for most of the improvement. Several things we expected to matter did not. Here is the whole picture, including the parts that make us look wrong.
1. The LCP element must be in the first HTML response
The single biggest gain came from making the largest image or heading part of the server-rendered HTML with an explicit priority hint.
On nine of the twelve sites the hero was a CSS background image, which the browser's preload scanner cannot see: it is only discovered once the stylesheet is parsed and the element matched. Moving it to a real img element with a priority hint and a correct sizes attribute cut LCP by a median of 2.3 seconds before we touched anything else.
| Change | Sites | Before | After |
|---|---|---|---|
| Hero as server-rendered image with priority | 9 | LCP 3.9 s | LCP 1.6 s |
| One interactive island per section | 7 | INP 340 ms | INP 140 ms |
| Self-hosted subset font, metric-matched fallback | 12 | shift on font swap | CLS 0.00 |
Two details that are easy to get wrong. Exactly one image per page gets the priority hint; marking three defeats the purpose. And the sizes attribute has to describe the real layout, so a hero that is 100vw on mobile and 50vw on desktop needs to say so, or the browser downloads the wrong file and you have made things worse.
On WordPress the equivalent fix is usually removing a page builder's background-image hero and disabling lazy loading on the first image. The mechanism is identical, the mess is bigger.
2. Interactivity: fewer islands, not smaller components
Interaction latency on marketing sites is rarely the event handler. It is hydration: a header, a carousel, a form and four accordions each shipping their own component tree and each becoming interactive independently.
Collapsing to one interactive island per section, and using native details elements for accordions, took INP from 340 ms to 140 ms across seven sites without changing a single click handler.
The rule now written into our definition of done: if a section has no state, it ships no JavaScript.
3. Fonts: the free CLS win
Every site we inherited used two or three externally hosted families with five to nine weights between them. Moving to one variable family, self-hosted, subset to the character ranges actually used, with a generated metric-matched fallback, produced zero measured layout shift on all twelve.
It also removes a render-blocking connection to a third-party origin, which helps LCP as well. This change costs an afternoon and we have never seen it fail.
4. Third parties after consent
Tag managers, chat widgets and advertising pixels were loading before first paint on eleven of the twelve sites. Moving them behind the consent signal, loading after the page is interactive, is a performance fix and a compliance fix in the same commit.
The pattern: set consent defaults to denied for the regions that require it, load the container once interaction is possible, and update consent state when the visitor chooses. Chat widgets in particular should load on intent, a click on a button, rather than on page load. That one change was worth more than a second of LCP on two of these sites, and nobody in the business noticed anything missing.
We run this as a fixed-price Core Web Vitals rescue: field measurement, the fixes above, and a second reading 28 days later so you can see what changed.
What did not matter
This is the part left out of most performance articles.
Service workers. We removed three and measured no regression. On marketing sites they mainly add cache-invalidation bugs.
Aggressive code splitting past the obvious boundaries. Beyond route-level splitting, the extra requests offset the savings.
Image format micro-optimisation. Moving from WebP to AVIF saved bytes and made no measurable difference to field LCP once the element was being discovered early. Discovery beat compression every time.
Performance plugins. On two WordPress sites a caching and optimisation plugin was concatenating scripts in a way that delayed the hero image. Removing the plugin improved LCP.
Preconnect hints beyond two origins. Diminishing to zero, occasionally harmful.
The measurement discipline
Use field data, not lab scores. Lab tools are diagnostic; the Chrome UX report and your own real-user monitoring tell you what visitors experienced. We take a 28-day field reading before the change and another 28 days after it has been live, and we do not compare against a Lighthouse score at all.
Segment by device. Every improvement above was larger on mid-range Android than on desktop, and mid-range Android is where a large share of our clients' traffic actually is. A team testing on a company MacBook over office fibre will conclude the site is fine, and will be wrong for most of its audience.
The order we work in
Find the LCP element in field data. Make it server-rendered and prioritised. Remove render-blocking third parties. Fix fonts. Then reduce hydration. Then measure again before doing anything else.
Most sites are done after the first three steps, which is a fortnight of work rather than a rebuild. Resist the rebuild pitch until you have tried them: we have twice quoted for a rebuild, run these fixes during the scoping fortnight, and told the client they no longer needed the rebuild.
When to hand this to someone
Steps one, three and four are within reach of any competent developer with access to the theme. The hydration work usually is not, because it means changing how the front end is put together rather than tuning it. If your field data is red, the build is a page builder, and nobody in the team owns the front end, that is when a web development engagement pays for itself, and often as part of a redesign rather than on its own. For ranking context, speed sits seventh in our SEO checklist for a reason, and store-specific traps are in the ecommerce piece.
Questions
How much do Core Web Vitals affect rankings?
Less than most people assume. They act as a tie-breaker between comparable results. The conversion effect is larger and more reliable, which is the better reason to do the work.
Do I need to rebuild my site to fix Core Web Vitals?
Usually not. On most sites we assess, the first three fixes (LCP element, third parties, fonts) take a fortnight and get the site into the good range. Rebuild when the architecture itself guarantees the problem.
Why is my Lighthouse score high but my field data poor?
Lighthouse runs on a simulated device on your connection. Field data comes from real visitors on real phones and networks. When they disagree, believe the field data.
Is WordPress inherently slow?
No. Most slow WordPress sites are slow because of a page builder, a stack of plugins and an unoptimised hero image. A carefully built WordPress site passes Core Web Vitals comfortably.
What is a realistic INP target?
Under 200 ms at the 75th percentile is the threshold to aim for. Getting there is almost always about shipping less JavaScript, not about optimising the handlers you have.