Web Vitals are a deliverable, not an afterthought
The single largest cause of slow websites is design choices made without performance constraints in the room. The hero video that nobody flagged. The custom font set with seven weights. The thirty-section landing page with a parallax background image per section. Each decision adds two hundred milliseconds. By production, the page costs five seconds.
The constraint is the design
We treat Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint as design constraints — not engineering remediations. That means: before we ship a design to the build team, we know what the LCP element will be, what its weight is, and what the budget is for everything else.
This sounds tedious. It is tedious. It is also the reason our shipped sites land in green for all three Core Web Vitals on launch day, instead of needing a six-week post-launch optimization sprint.
The substitutions we make on the way in
Hero video → animated WebP at 1/10 the file size, with a poster image as the LCP element. Sixty-fps motion → CSS-driven animation that respects prefers-reduced-motion. Font weight 100, 200, 300, 400, 500, 600, 700, 800, 900 → variable font axis with two ranges defined. Image-heavy editorial sections → above-the-fold images preloaded, below-the-fold lazy-loaded with native browser support, no external library required.
Why this matters beyond Lighthouse
The reason this matters is not that Google rewards fast sites in search. It does, but the bigger reason is that fast sites convert. A landing page that takes three seconds to interact loses 30% of mobile traffic before a single brand decision is made. The most beautifully designed page that is too slow to use is not a beautifully designed page. It is a slow page that nobody saw.
Laisser un commentaire
Rejoindre la discussion?N’hésitez pas à contribuer !