How to set a website performance budget that guides decisions

Choose the journeys the budget must protect

Start with a short list of pages people actually need: a landing page, a service detail, a long guide and an inquiry form may have different assets and interactions. On each, name the task the visitor must complete. A service page might need its offer and next step to appear promptly; an inquiry page must stay responsive while a visitor types, corrects an error and submits. “The site must be fast” is too vague to arbitrate a new video, font or chat widget.

Write down the test conditions with the page type: narrow and wide viewport, a constrained mobile device, network profile, cold and repeat visit, and the consent state in which optional tags run. Keep the same lab conditions across releases so comparisons are meaningful. Test a real journey after the initial render, because a page can appear quickly yet become hard to use when scripts evaluate or a panel opens. A performance budget is a design constraint and an operating agreement, not a single score promised to every visitor.

Pair experience targets with resource ceilings

Core Web Vitals name three different experiences: Largest Contentful Paint (LCP) for when the main content appears, Interaction to Next Paint (INP) for responsiveness to a qualifying interaction, and Cumulative Layout Shift (CLS) for unexpected visual movement. Google’s “good” field thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, evaluated at the 75th percentile of visits. They are useful shared targets; they do not tell a team how much image, font or script weight it may add.

Put resource ceilings beside those targets. Record transferred bytes for the initial page, images, JavaScript, CSS, fonts and third-party resources, plus request count where useful. Choose the ceilings from the page’s actual baseline, constraints and planned content, and write the unit and measurement method beside every number. A page-weight target is a guardrail, not a substitute for LCP: two equally sized pages can load their main content at different times if one delays a critical resource. Conversely, a page that looks quick in one lab run may still frustrate users after it becomes interactive.

Copy this performance-budget worksheet

Create one row per page type and important state. Keep the same row IDs from design review through release and later changes. Fill the following columns with the designer, developer, content owner and whoever requests external services. Leave an unknown value visibly undecided; do not turn an arbitrary internet example into a contractual limit for your site.

• Row and journey: page type, representative URL or prototype, visitor task, device and consent state; include the form success or error state when it changes the experience.
• Experience target: LCP, INP and CLS target, the 75th-percentile field segment to review when enough data exists, and the repeatable lab interaction used before launch.
• Resource ceiling: initial transferred total, image, JavaScript, font, CSS and third-party bytes or requests; state whether the number is compressed transfer, decoded size or another measure. Mark overlapping categories—for example, third-party JavaScript is both script and third-party—and do not add overlapping subtotals together.
• Current and proposed: baseline measurement, proposed asset or feature, expected extra cost, test result and evidence link; separate an estimate from a measured value.
• Third-party decision: tool and owner, visitor value, consent condition, load timing, alternatives, overlap with existing tools and the person authorized to remove it.
• Release rule: pass, investigate or exception; who decides, what improvement or removal offsets an overage, and the date the exception expires.
• After-launch review: data source, page grouping, review owner and trigger, such as a new embed, hero asset, template or sustained field regression.

Use laboratory tests to diagnose and field data to review

Before launch, run controlled mobile and desktop tests for each representative page. Save the tested URL or build, device and network settings, date, resource breakdown and a trace of the important interaction. Lighthouse and browser developer tools can reveal heavy transfers, late images and long script work; a controlled run is repeatable enough to compare a proposed change with the baseline. Do not treat one Lighthouse performance score as a guarantee for every user or as a replacement for a real interaction test.

After launch, review real-user data by page or comparable page group and by device where data is available. PageSpeed Insights combines Chrome User Experience Report field data with a Lighthouse lab test. Field figures reflect a distribution of actual visits and can differ from the lab because devices, networks, cache states and behavior vary. If a page has too few eligible visits for its own field result, the absence of a figure is not a pass; use repeatable lab checks and revisit field evidence when it becomes available. An automated page-load audit may not capture INP unless an interaction is simulated, so exercise the actual menu, filter or form in a lab and use field INP when available.

Give every third-party script a named owner

Analytics, chat, maps, video embeds and experiments can add value, but they also bring network requests and main-thread work outside the site team’s direct control. The browser still has to download, parse and run script, and work at the wrong time can delay user input. List each service separately in the worksheet. Ask what decision or visitor task it supports, whether an existing tool already does the job, when it loads, what happens if it fails, and who may remove it. Include the correct consent state in the test; loading a tag only after permission may change the measured journey.

Set a ceiling for the combined third-party cost on the key pages and retest after tag-manager changes, supplier updates or new marketing campaigns. Where a feature is useful but not needed for the first screen, assess whether it can load after critical content or on deliberate interaction. A delayed load is still a cost to the eventual interaction, so inspect the full journey. Keep privacy and consent requirements alongside the performance decision rather than attempting to make a tracking script fast by sending more visitor information.

Hypothetical example: an illustrated service homepage

Consider a hypothetical small studio planning an illustrated homepage. Its prototype has a compressed hero image, two web fonts, a tag manager and an optional chat widget, with 100 KB of transferred JavaScript before the proposed changes. For its own planning exercise, the team proposes a 900 KB initial transferred-page ceiling on its chosen mobile lab profile, with at most 250 KB transferred JavaScript and 150 KB combined third-party transfer. Those are invented limits for this hypothetical project, not recommended universal thresholds or measured Kinetivy results. The team also records the shared “good” Core Web Vitals field thresholds as review targets once enough visits exist.

A draft animation adds 180 KB of JavaScript and moves an illustration into view after the headline appears. The team tests the page and sees that the proposed version exceeds its script ceiling and moves the main visual during load. It can simplify the animation, reserve layout space, defer nonessential code or choose a static treatment. A marketer then requests chat on every page. The worksheet asks what visitors need chat for, whether the form already serves that task, and what the widget costs under the consent state in which it will run. The owner either approves a measured, time-limited exception with a compensating change or leaves chat out. The example illustrates the decision process; it is not a client story or a claimed improvement.

Use the budget at design review and release

At design review, compare alternatives before expensive assets are final. At implementation review, check built transfer and script work against each row. At release, retest the representative pages, the inquiry flow and consent states with the same lab profile. If a limit is missed, record which asset or interaction caused it and choose to reduce, defer or remove that cost, or approve a specific exception with an owner and expiry. A score alone cannot make that decision; the trade-off should explain what the visitor gains and what slower experience remains.

Keep the budget with the website’s delivery records so new editors and vendors can use it. The redesign checklist covers which existing pages and journeys to preserve when a site changes; the accessibility acceptance plan covers WCAG evaluation and its evidence; the handover checklist covers who controls the finished site. This guide owns the narrower performance decision: how much the page may demand from a visitor’s device and connection, how that affects the main task, and who decides when a new feature spends the allowance. Review the worksheet whenever a template, hero, font set or external script changes, rather than waiting for an annual rebuild.