Core Web Vitals: What Actually Moved the Needle for Our Clients
Every client asks about Core Web Vitals expecting the answer to involve switching frameworks. Across a dozen audits, the highest-impact fixes were almost always unrelated to whether the site ran React, Vue, or plain HTML. The most common single offender for a bad Largest Contentful Paint score was a hero image served at 4x the display resolution with no width or height attributes, causing both a slow LCP and a layout shift once it finally loaded.
Fixing that meant setting explicit width and height (or aspect-ratio in CSS) on every above-the-fold image, and serving responsive sizes through srcset instead of one oversized JPEG. On one retail client's homepage, that single change took LCP from 4.1s to 2.3s — a bigger jump than any code-splitting work we did on that project.
Cumulative Layout Shift was almost always caused by three things: web fonts swapping in without a matched fallback, ads or embeds injecting content above existing elements, and images without reserved space. We started using font-display: optional combined with a size-matched fallback font stack, which eliminated visible reflow on font load for every client where we applied it.
Interaction to Next Paint, which replaced First Input Delay in 2024, punished sites with heavy third-party scripts more than anything else. A marketing site running six different tag manager snippets had an INP of 340ms; deferring non-critical scripts until after first interaction and consolidating tracking into a single tag manager call brought it under 180ms.
The framework-level work — code splitting, server rendering, prefetching — still matters, but it's the second pass. The first pass is almost always image sizing, font loading strategy, and third-party script discipline, and clients are consistently surprised that the fix wasn't a rewrite.
