Most teams treat performance as a launch-week chore: run Lighthouse, compress a few images, ship. By then the expensive decisions — framework, rendering strategy, data-fetching, third-party scripts — are already baked in. Core Web Vitals aren’t a checklist item. They’re a design constraint that should shape your architecture from the very first commit.
Why Core Web Vitals decide more than rankings
Google uses Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS) as ranking signals — but the business case is simpler than SEO. Faster pages convert better, bounce less and cost less to serve. A site that hits its vitals on a mid-range Android phone on 4G is a site that respects the majority of real users, not just the developer on a fast laptop.
Where speed is actually won
- Rendering strategy. Server-render or statically generate the content that matters for LCP, and hydrate only what needs interactivity. Shipping a blank page that a megabyte of JavaScript fills in later is the single most common cause of poor vitals.
- The critical path. Inline the CSS a page needs above the fold, self-host fonts with
font-display: swap, and defer everything that isn’t needed for first paint. - Third parties. Every analytics, chat and tag-manager script is someone else’s performance budget spent on your page. Load them lazily, or not at all.
- Layout stability. Reserve space for images, embeds and ads with explicit dimensions so nothing jumps as the page loads.
Bake it into the process
We set a performance budget at the start of a project and treat a regression the same way we treat a failing test — it blocks the merge. Real-user monitoring tells us what field data actually looks like, because lab scores and real phones rarely agree. The result is a site that launches fast and stays fast, instead of one that needs a rescue mission six months in.
Performance isn’t the last thing you do before launch. It’s the first thing you decide when you choose how to build.
