Key takeaways
- Budget before the moodboard. Core Web Vitals are route-level promises — name the money paths first.
- Third parties spend like features. Every tag, font file, and hero video debits the same ledger.
- CI is how a budget survives launch. A spreadsheet nobody runs in production is decoration.
The homepage won the design review. Then Lighthouse ran on a mid-range Android over LTE and the hero video ate the largest contentful paint.
A web performance budget is not a post-launch apology. It is a design constraint — route-level targets for Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), plus caps on JavaScript, media, fonts, and third-party scripts. Google's Core Web Vitals documentation treats them as field signals that reflect real user experience. How to build for the web in 2026 put performance after offer and system. This page is the ledger that keeps the visual system honest.
Name the routes that carry money
Do not budget "the site." Budget the paths ads and sales send traffic to.
| Route type | Examples | Why it gets a line item |
|---|---|---|
| Entry | Homepage, primary landing | First impression and bounce |
| Conversion | Quote, checkout, book, apply | Direct revenue or leads |
| Content | Top blog posts, comparison pages | SEO and assisted conversion |
| Product | Pricing, signup, onboarding start | Activation and expansion |
For each route, set field targets aligned with Google's "good" thresholds: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1 — measured at the 75th percentile of real users, not only lab tests. Lab tools like PageSpeed Insights help debug; field data in Search Console tells you whether strangers agree.
Run the budget worksheet
Fill this table before final creative approval. Numbers are starting points — tune to your analytics — but empty cells mean the moodboard is spending blind.
| Budget line | Starter cap (marketing site) | What spends it |
|---|---|---|
| LCP element | Hero image or text block under 150 KB transferred (WebP/AVIF) | Full-bleed video, unoptimized PNG, slider |
| Total JavaScript | ≤ 170 KB gzip on first load for content routes | Chat widgets, analytics bundles, unused framework |
| Third-party scripts | ≤ 3 tags on conversion routes | Tag managers that import ten more tags |
| Web fonts | ≤ 2 families, subsetted, `font-display: swap` | Six weights from a hosted kit |
| Hero media | No autoplay video on LCP for mobile entry | Background MP4 on the first screen |
| CLS | Explicit width/height on images and embeds | Late-injected banners, cookie bars without reserved space |
Technical SEO checklist for 2026 overlaps on crawl and index health. Performance budget is the UX side of the same coin — a fast page nobody can use still fails INP when the main thread is blocked.
Third parties are features with a meter
Every embed — reviews, maps, A/B snippets, support chat — loads code you did not write on routes you did not scope. Treat each as a feature request:
- Does it run on conversion routes or only on `/contact`?
- What is the transfer size and main-thread cost in WebPageTest or Chrome DevTools?
- Who owns removal when the budget breaks?
If marketing cannot name the owner, the script does not ship on money paths.
Fonts, images, and the design system
Performance budgets fail in handoff when design ships assets the ledger never saw.
| Asset | Budget habit |
|---|---|
| Images | Width capped to display size; AVIF or WebP with JPEG fallback; no 4000px exports for 800px slots |
| Fonts | Subset to character sets you use; limit weights; preload only what the LCP route needs |
| Video | Poster image as LCP candidate; lazy-load below the fold; respect `prefers-reduced-motion` |
| Icons | SVG sprite or icon font subset — not three libraries for twelve glyphs |
Design system vs component library is where tokens meet implementation. If components ignore the budget, every new page renegotiates the same fight.
Run PageSpeed Insights on staging with throttling before creative sign-off — not only after launch when ads are live.
When a route fails the budget after deploy, fix the largest transfer first — usually hero media or a third-party script — before you micro-optimize CSS. The ledger tells you which line item spent the milliseconds.
Put the budget in CI
Spreadsheets die at launch unless something enforces them. Minimum viable enforcement:
1. Lighthouse CI or equivalent on pull requests for template routes. 2. Bundle analyzer threshold on JavaScript — fail the build when first-load JS crosses the cap. 3. Real-user monitoring on production for LCP, INP, CLS by route — alert when p75 drifts. 4. Regression budget — no PR may worsen LCP on `/` by more than 200 ms lab without explicit approval.
web.dev — Performance budgets describes tying metrics to business goals and automating checks. The habit matters more than the vendor: someone must be on the hook when a hero swap blows the cap.
How to choose a website stack in 2027 belongs in the same conversation — a framework you cannot deploy and monitor is a performance risk before the first font loads.
What you can cap alone — and what stays unfinished
You can set route targets, reject autoplay heroes, and subset fonts before handoff. Many teams should.
What stays unfinished is the full system: design tokens that respect the ledger, accessible forms that stay fast under validation, managed hosting that patches, and SEO that measures field data after campaigns rotate. CLICK.BLUE ships sites with performance as a constraint — not a ticket filed after launch.
If the money routes are named and the worksheet is filled, start a scoped build. If the visual system is already approved without numbers, rerun the worksheet before you publish.
