A written performance budget with clear targets and an alerting plan — so your site stays fast after every deploy.
How to use this checklist
A performance budget is just a set of limits you refuse to cross. Copy this into a doc, fill in your targets, and treat a broken budget like a broken test — something to fix before shipping, not after a user complains.
Set the numbers with the people who ship features, not just whoever cares about speed. A budget nobody agreed to is a budget nobody keeps.
The four budget areas
- 1User experienceCore Web Vitals targets (LCP, INP, CLS).
- 2Page weightTotal bytes, images, fonts.
- 3JavaScriptBundle size and main-thread cost.
- 4Third partiesScripts, tags and their budget.
Tracks real-user performance and ties regressions to the code that caused them — good for enforcing a budget.
Visit site
Scheduled Core Web Vitals monitoring with alerts when a metric crosses your budget.
Visit siteA budget only works if something measures it continuously. Confirm current free tiers before committing.
Gate 1: Core Web Vitals targets
- LCP is under 2.5s at the 75th percentile of real users.
- INP is under 200ms at the 75th percentile.
- CLS is under 0.1 at the 75th percentile.
- We measure these on field data, not just a lab run.
- We check the 75th/95th percentile, not the average.
Gate 2: Page weight
- Total page weight has a hard cap (e.g. under 1 MB for a content page).
- Images are compressed, correctly sized and in a modern format.
- Images below the fold are lazy-loaded.
- Fonts are subset, preloaded and limited to what we actually use.
- Every image and embed has explicit width/height to prevent layout shift.
Gate 3: JavaScript
- The initial JavaScript bundle has a size budget (e.g. under 170 KB compressed).
- Code is split so pages only load the JS they need.
- Non-critical scripts are deferred or loaded on interaction.
- We have removed dead dependencies and duplicate libraries.
- Main-thread long tasks are watched (they wreck INP).
Gate 4: Third parties
- Every third-party script is justified and has an owner.
- Analytics, tags and widgets have a combined budget, not a blank cheque.
- Third parties are loaded async/deferred and never block render.
- We audit third parties quarterly and remove the unused ones.
Enforcement
- The budget is written down where the team can see it.
- A monitoring tool measures the budget continuously.
- Alerts fire when a metric crosses the budget — before customers notice.
- Performance is re-checked after major features and dependency bumps.
Scoring the result
Healthy. Keep monitoring and hold the line.
Fix the biggest ones this sprint.
Run the full profiling workflow before adding features.
Related
- Find and fix the gaps with how to profile and fix a slow web app.
- Pick a tool to enforce the budget in best web performance monitoring tools.
- Understand the targets in Core Web Vitals explained.