Website performance budgets: how to set and stick to them
A performance budget is the single most effective tool for keeping websites fast. Here's how I set them and, more importantly, how I enforce them.
When was the last time you actually measured your site's speed? You probably agree your website should be fast. Most people do. Very few teams have a concrete definition of what "fast" means for their project, or a mechanism to prevent things getting slower over time. A performance budget fixes both problems: it sets measurable limits and gives you a reason to push back when someone wants to add a 2MB hero video or another analytics script.
What to measure
There are three types of metrics worth budgeting for. First, milestone timings: Largest Contentful Paint (LCP), First Contentful Paint (FCP), Time to Interactive (TTI). These are what users experience. Second, quantity-based metrics: total page weight, number of HTTP requests, JavaScript bundle size. These are what you directly control. Third, rule-based scores: Lighthouse performance score, Core Web Vitals pass/fail. These are useful as summaries but too opaque to be your primary targets.
I focus primarily on page weight and LCP. my default starting point for a new project is: total page weight under 500KB, LCP under 2.5 seconds on a 4G connection, JavaScript bundle under 150KB (compressed). These are achievable for most content-driven sites and aggressive enough to keep us honest.
How to set a budget
Start with your competitors. Run the top five competitor sites through WebPageTest and note their median page weight and LCP. Your budget should aim to beat the median by at least 20%. If every competitor is shipping 3MB pages with 5-second LCP, being 20% better is a low bar but it's still better than every alternative your users are comparing you to.
Then check what's realistic for your technology choices. A Next.js site with server-side rendering can achieve much lower JavaScript budgets than a client-rendered React SPA. A site heavy on product images will have a higher total weight than a text-heavy blog. The budget needs to reflect the project's actual requirements.
How to enforce it
A budget that nobody checks is just a wish. I build enforcement into the development workflow at three points. First, during development: Lighthouse CI runs in the CI pipeline and fails the build if the performance score drops below the threshold. Second, at code review: any PR that adds a new dependency or significant asset gets its bundle impact checked. Third, post-launch: I set up monitoring via SpeedCurve or just a scheduled Lighthouse run to catch regressions.
The hardest part is cultural, not technical. Performance budgets only work if the whole team, developers, designers, project managers, and clients, understands and respects them. When a client wants a large background video, the conversation isn't "no", it's "this will push us over budget, here are the trade-offs, and here are lighter alternatives that achieve a similar effect."
Common budget-breakers
Third-party scripts are the worst offenders. A single chat widget or analytics tag can add 200-500KB of JavaScript and tank your LCP. I audit every third-party script before it's added, and I load non-essential scripts asynchronously after the page has finished rendering. Hero images that aren't properly sized or compressed are the second most common issue, a 4000px-wide JPEG as a background image on a section that renders at 1200px is waste that's easy to fix.
If your site feels slow and you're not sure where to start, or you want to set up performance monitoring on an existing project, drop me a line.
Chris Ryan
Managing Director
17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.