Why set performance goals

Performance shapes the user experience and influences business outcomes. But a fast site rarely emerges by accident; it requires explicit targets. A performance budget — a set of limits on metrics that affect loading behavior — gives you those targets. It acts as a shared reference point for conversations about design choices, technology stacks, and feature additions.

With a budget in place, designers can weigh the cost of high-resolution images and web font selections. Developers gain a basis for comparing frameworks and libraries, factoring in both size and parsing cost.

Choosing what to measure

Not all metrics serve the same purpose. A useful budget mixes different types of measurements, starting with the simplest to grasp.

Quantity-based metrics

These are straightforward limits on resource weight and counts. They are most valuable early in development because they make the impact of heavy assets obvious to both designers and developers. Typical examples include:

  • Maximum image size
  • Maximum number of web fonts
  • Maximum script size, including frameworks
  • Total number of external requests, such as third-party scripts

Quantity alone, however, does not describe the experience. Two pages with identical weight or request counts can feel very different depending on resource order. If a critical stylesheet or hero image loads late, users wait longer to see something useful and perceive the page as slower.

Milestone timings

Milestone timings mark specific events during the loading process, such as DOMContentLoaded or the load event. The most actionable ones are user-centric metrics, available through browser APIs and in Lighthouse reports:

First Contentful Paint (FCP) — when the browser first renders any content from the DOM, like text or an image.

Time to Interactive (TTI) — when the page becomes reliably responsive to user input. Track this if your page involves clicking, typing, or form interaction.

Rule-based scores

Lighthouse and WebPageTest generate performance scores from general best-practice rules. These provide a guideline, and Lighthouse also flags simple optimization opportunities.

The strongest signal comes from combining quantity-based limits with user-centric timing metrics. Set asset-size budgets in the early project phases, and begin tracking FCP and TTI as soon as possible.

Setting initial targets

Real-world testing is the only way to know what fits your site, so research and measure competitors to understand your position. If starting from scratch, a reasonable baseline for basic pages is:

  • Under 5 seconds Time to Interactive
  • Under 170 KB of compressed, minified critical-path resources

These figures assume mid-range hardware and a 3G network, which remains a relevant starting point since a large share of traffic occurs on mobile networks.

A single budget rarely fits an entire site. Different page types deserve different constraints:

  • Product page: less than 170 KB of JavaScript on mobile
  • Search page: less than 2 MB of images on desktop
  • Home page: interactive in under 5 seconds on a slow 3G Moto G4
  • Blog: score above 80 on Lighthouse performance audits

Enforcing budgets during development

Budgets only matter if they can block regressions. The right tool depends on project scale and available resources. A few open-source options integrate directly into a build pipeline:

  • Webpack performance features
  • bundlesize
  • Lighthouse CI

When a build exceeds a threshold, the response is one of three actions: optimize an existing asset, remove something no longer justified, or postpone the new feature until it fits within budget.

Sustaining performance after launch

Launch is not the finish line. Continuous monitoring — ideally with real-user data over time — shows how performance changes correlate with business metrics and keeps the budget relevant.

The point of a performance budget is to make performance a persistent consideration rather than a post-launch retrofit. Defining it early prevents costly backtracking and gives you a framework for balancing speed against functionality and user experience.