Performance budgets we still believe in

A performance budget is a hard limit on how heavy and how slow a page is allowed to be, a number the site cannot exceed without failing the build. Instead of hoping a site stays fast, you set explicit ceilings, Largest Contentful Paint under 2.5 seconds, JavaScript under ~170KB, total initial load under ~1MB, and you enforce them automatically. Performance is one of the few disciplines where the fundamentals haven't changed even as everything else did: fast still wins, for humans, for Google, and now for the AI crawlers deciding whether you're worth citing.

I'm writing this because "performance" keeps getting treated as a post-launch chore, something you audit once with Lighthouse, feel bad about, and never fix. That's backwards. A budget is a design constraint you adopt on day one, and it quietly makes a thousand later decisions for you. Here are the exact budgets we hold every build to, and why each one earns its place.

Why does site speed still matter in 2026?

Three reasons, and they compound. First, ranking: Google's Core Web Vitals are a confirmed page-experience ranking signal, and they're what Google uses to measure real-world speed. Second, conversion: slower pages lose money, study after study ties every added second of load time to measurable drops in conversion and higher bounce. Third, and newest, AI crawlability: the bots behind AI Overviews and assistants have finite budgets for rendering pages, and a bloated, JavaScript-heavy page that's slow to render is a page they may sample less thoroughly, or skip. Speed is now a GEO factor, not just an SEO one.

What are Core Web Vitals?

Core Web Vitals are Google's three headline metrics for real-world page experience. Largest Contentful Paint (LCP) measures loading, how long until the biggest element on screen appears. Interaction to Next Paint (INP) measures responsiveness, how quickly the page reacts to a tap or click. Cumulative Layout Shift (CLS) measures visual stability, how much the page jumps around as it loads. Together they capture the three things a user actually feels: is it here yet, does it respond, and does it hold still.

What performance budgets do we hold?

Here are the specific ceilings, the target for each, and why it matters. These aren't aspirational, a build that misses them doesn't ship.

Where do the wins actually come from?

Not from shaving kilobytes off a utility function. The big wins are boring and repeatable, and they're almost always these:

1. 01Images. Serve modern formats (AVIF/WebP), size them correctly, lazy-load below-the-fold, and never let a hero image ship uncompressed. Images are the #1 cause of a blown weight budget.
2. 02JavaScript. Ship less of it. Prefer server components and static rendering, defer non-critical scripts, and question every dependency. JS is the most expensive byte on the web because the browser has to download, parse, and execute it.
3. 03Third-party scripts. Every analytics tag, chat widget, and A/B tool has a cost. Audit them, load them lazily, and cut the ones nobody looks at.
4. 04Fonts. Subset to the characters you use, self-host, and use font-display: swap so text is never invisible while a font loads.
5. 05Caching and CDN. Serve static assets from the edge with long cache lifetimes so repeat and nearby visits are near-instant.

How do you enforce a performance budget?

A budget nobody enforces is a wish. The discipline is automation: wire the budget into your build pipeline so a regression *fails* rather than ships. In practice that means running Lighthouse CI (or an equivalent) on every pull request with the budgets set as thresholds, tracking bundle size on each build, and treating a blown budget like a failing test, it blocks the merge. The point is to catch the fourth marketing tag and the uncompressed hero image *before* they reach production, not in a sad Lighthouse audit three months later.

Where teams go wrong

The usual failure isn't ignorance, it's drift. A site launches fast, then a year of added scripts, swapped images, and "just one more" integrations quietly erodes it, and nobody notices until rankings and conversions sag. A budget enforced in CI is what stops the drift, because it makes the cost of each addition visible at the moment someone tries to add it.

Where Elite Web Design fits

We build to these budgets from the first line of code, not as a post-launch cleanup, modern image formats, minimal JavaScript, audited third-party scripts, and Core Web Vitals enforced in the pipeline so speed can't quietly regress. Fast sites rank better, convert more, and get read more thoroughly by the AI crawlers deciding whether to cite you, which is why performance is baked into every web design and build we ship and every visibility engagement we run. Start a project and we'll benchmark your current vitals and show you exactly where the weight is hiding.