Performance Budgets: The Brief Your Designer and Developer Both Need

Why “We’ll Optimize Later” Never Works

Every web project starts with the same implicit agreement: build it first, make it fast later. The design is created without reference to file sizes or script weights. The development brief does not mention performance thresholds. The launch checklist includes a PageSpeed run but no pre-agreed pass criteria.

Then the site launches. The PageSpeed score is 54. Someone creates a ticket to “improve performance.” A developer spends two sprints compressing images, deferring scripts, and adding lazy loading. The score improves to 71. It plateaus there because the remaining issues are locked inside design decisions that have already been approved, built, and shown to clients.

The hero image is still too large because it is a brand asset and changing it requires a creative brief. The custom display font still causes layout shift because swapping it out would require redesigning the typography system. The third-party chat widget still saturates the main thread because removing it would require a product decision. The developer can optimize the implementation. They cannot optimise the decisions.

A performance budget is the document that prevents this. It moves performance from a post-launch remediation task to a pre-design constraint — the same way a brand guide prevents off-palette colours and an accessibility brief prevents inaccessible components.

This article explains what a performance budget contains, how to set one, and how to enforce it across a project lifecycle.

What a Performance Budget is (And What’s Not)

A performance budget is a quantified constraint document that defines the maximum acceptable cost — in bytes, milliseconds, or count — of specific performance-impacting elements of a web project. It is agreed at the project outset and applies to both design decisions and development decisions.

What it is:

• A set of numeric limits — maximum page weight, maximum image size, maximum number of third-party scripts, maximum LCP time, CLS threshold, INP threshold
• A shared agreement between designer, developer, and project lead — not a document handed from one discipline to another
• A decision-making tool — when a proposed design element exceeds a budget line, it triggers a conversation, not a silent compromise
• A living document — budgets can be revised when new requirements justify it, but revisions require explicit sign-off

What it is not:

• A development-only constraint — Performance budgets govern design decisions as much as implementation decisions
• A wishlist — Every line in a performance budget must be measurable and verifiable against a specific tool or metric
• A post-launch audit checklist — By the time you are auditing, the decisions that determine the budget outcome have already been made
• A punishment for slow sites — It is a prevention mechanism, not a remediation framework

The Five Budget Categories

A complete performance budget covers five categories of constraint. Each maps directly to one or more Core Web Vitals metrics and to specific design and development decisions.

Category 1: Page Weight

Total page weight is the sum of all bytes transferred to render a page: HTML, CSS, JavaScript, images, fonts, and third-party resources. It is the broadest single indicator of performance overhead and the easiest to track across the project lifecycle.

Page weight budgets vary by page type. A homepage or campaign landing page that must load fast for cold-traffic users has a tighter budget than a logged-in dashboard page where users are already invested. A content article page has a different profile from a product detail page with multiple image assets.

• Content pages (blog, article): target ≤1.5MB total, ≤800KB above-the-fold critical path
• Landing pages (campaign, service): target ≤1MB total, ≤600KB critical path
• E-commerce product pages: target ≤2MB total (images dominate), ≤700KB critical path
• App / dashboard pages (authenticated): ≤3MB total acceptable given user context

Category 2: Image Constraints

Images are typically the largest component of page weight and the primary driver of LCP failures. Image constraints in a performance budget define format requirements, maximum file sizes per image role, and dimension conventions.

• Format: WebP or AVIF for all non-icon images. PNG only for images requiring lossless quality (logos, illustrations with transparency). No unoptimised JPEGs
• Hero / LCP image: ≤150KB at 1200px wide (WebP). Must have fetchpriority="high" attribute
• Content body images: ≤100KB at display size. Must implement responsive srcset
• Thumbnails / card images: ≤40KB
• All images: must have explicit width and height attributes to prevent CLS

Category 3: Font Constraints

Web fonts are the second most common source of LCP delay and a primary cause of CLS through font-swap layout reflow. Font constraints define which typefaces are permissible, how they must be loaded, and what fallback strategy is required.

• Maximum custom font families: 2 (one display, one body). Each additional family adds a network request and a potential LCP delay
• Maximum font weight variants per family: 3 (e.g., 400, 600, 700). Variable fonts preferred where available
• Loading strategy: self-hosted preferred over CDN. If CDN, use preconnect for the font origin
• Font-display setting: swap with a calibrated fallback font using CSS size-adjust to minimise CLS
• Subset requirement: subset fonts to the character sets actually used. A full Latin font loaded for English-only content carries unnecessary weight

Category 4: JavaScript and Third-Party Script Constraints

JavaScript is the primary driver of INP failures and a significant contributor to LCP delay through main thread blocking. Third-party scripts are a subset of JavaScript constraints that require separate treatment because they are outside the development team’s direct control.

• Total JavaScript (first-party): ≤200KB compressed. Each additional KB above this threshold requires justification
• Third-party scripts: maximum 3 per page. Each additional script requires a documented performance impact assessment and explicit approval
• Approved third-party script categories: analytics (1 script), consent management (1 script), live chat OR social proof (1 script). All others require amendment
• Script loading strategy: all non-critical scripts must use async or defer. No synchronous third-party scripts in <head>
• Main thread blocking time budget: ≤300ms total from all scripts during page load

Category 5: Core Web Vitals Thresholds

The CWV thresholds in a performance budget are the output constraints that all upstream decisions — images, fonts, scripts, animations — must combine to satisfy. They are the pass criteria for the overall budget.

• LCP: ≤2.5 seconds at the 75th percentile of real user sessions (from CrUX data post-launch; from Lighthouse on staging pre-launch)
• CLS: ≤0.1 across all page interactions
• INP: ≤200ms at the 75th percentile of all interactions
• TTFB (Time to First Byte): ≤800ms. This is a server and hosting constraint, not a design constraint, but belongs in the budget for completeness
• FCP (First Contentful Paint): ≤1.8 seconds. Not a Core Web Vital but a strong leading indicator of perceived performance

The Performance Budget Template

The following template is ready to adapt for your project. Fill in the target column based on your site type, device constraints, and competitive baseline. The rationale column explains the intent behind each line so it can be amended intelligently when requirements genuinely demand it.

Setting the Right Budget for Your Project

A performance budget is not a one-size-fits-all document. The thresholds above are starting points. The correct budget for a specific project is determined by three inputs: the competitive baseline, the device and network context of the target audience, and the functional requirements of the site.

Step 1: Audit your competitors

Before setting your own budget, run your top three to five competitors through PageSpeed Insights and record their Core Web Vitals scores, total page weight, and script counts. This establishes the performance baseline in your competitive landscape.

If your competitors all have LCP scores around 3.5 seconds, a budget that targets 2.5 seconds gives you a measurable competitive advantage on the Page Experience signal. If your competitors are already hitting 2.0 seconds, your budget needs to match or beat them. Performance budgets set in a competitive vacuum are targets without strategic context.

# Useful tools for competitive performance baseline
# PageSpeed Insights: pagespeed.web.dev
# WebPageTest: webpagetest.org (compare multiple URLs)
# CrUX Dashboard: g.co/chromeuxdash (real user data by origin)
# Treo: treo.sh (CWV trends by domain)

Step 2: Profile your audience’s device and network context

Core Web Vitals are measured on real devices under real network conditions. Google’s 75th percentile threshold means that 75% of your actual users must hit the Good threshold — not 75% of users on a fast laptop in a London office.

For Nigerian audiences specifically: mobile devices dominate, mid-range Android is the median device, and network conditions vary significantly between 4G and 3G. A site that passes CWV on a MacBook Pro on a fibre connection may be failing for the majority of its actual users.

The performance budget must reflect the device and network profile of the audience it serves, not the device of the designer or developer building it.

Test on a real mid-range Android device under throttled network conditions during development, not just on a desktop Lighthouse run. DevTools’ device emulation is useful but does not fully replicate the processing constraints of lower-end hardware.

Step 3: Account for functional non-negotiables

Some sites have functional requirements that create performance costs that cannot be designed around. A live customer support function requires a chat widget. An e-commerce site requires a payment provider script. A regulated business requires a consent management platform.

These are not failures of the performance budget process — they are inputs to it. When a functional requirement demands a heavy third-party script, the budget elsewhere must compensate: a lighter hero treatment, fewer font variants, a simpler animation system. The total performance envelope is fixed by the audience context and competitive baseline. The budget is the process of allocating that envelope across functional requirements.

Enforcing the Budget Across the Project Lifecycle

A performance budget that lives in a document but is never referenced is not a budget. It is a wishlist. Enforcement requires it to be embedded into the project workflow at three stages: the design review, the development build, and the pre-launch audit.

At the design review

Every design component that has a performance implication should be reviewed against the relevant budget line before it is approved. This is a five-minute checklist at the end of each design review, not a separate meeting.

• Is the proposed LCP element (hero image, headline) within the image budget?
• Has a new font family been introduced? Does it stay within the font family limit?
• Has a new third-party feature been specified (chat, reviews, social embed)? Has the script count been checked?
• Are any animations using prohibited properties (width, height, top, left)?

During development

Budget enforcement during development is most effective when it is automated. Several tools integrate into CI/CD pipelines to flag budget violations before they reach staging or production.

At the pre-launch audit

The pre-launch performance audit is the final checkpoint before the site goes live. Unlike a post-launch audit, it still has the ability to prevent problems rather than document them. It should be a formal sign-off step, not an optional last-minute check.

The audit should cover: Lighthouse scores on staging across mobile and desktop, a WebPageTest run on a representative mid-range device profile, a manual review of all third-party scripts loaded (including implicit scripts from tag managers), and a CLS check using the Layout Shift Regions tool in Chrome DevTools.

Any budget violation at this stage should have one of two outcomes: a documented remediation with a deadline, or a documented and approved budget amendment with a rationale. Violations that are neither remediated nor formally amended are performance debt — they do not disappear after launch, they compound.

Conclusion: The Budget is the Brief

The word “brief” is used deliberately in this article’s title. A performance budget is not a technical specification handed to a developer. It is a brief — the same kind of document that tells a designer which colours are in the palette, which fonts are approved, and which accessibility standards must be met.

It belongs at the start of the project, signed by both designer and developer, before wireframes are drawn or routes are written. It makes performance a shared responsibility rather than a development afterthought. And it turns the post-launch conversation from “why is this slow?” to “did we hit the targets we agreed?”

That shift in conversation — from remediation to accountability — is the entire value of the document. The numbers matter less than the agreement. A performance budget that both disciplines have signed is a site that both disciplines have committed to building fast.

Oladoyin Falana

Founder, Technical Analyst

Oladoyin Falana is a certified digital growth strategist and full-stack web professional with over four years of hands-on experience at the intersection of SEO, web design & development. His journey into the digital world began as a content writer — a foundation that gave him a deep, instinctive understanding of how keywords, content and intent drive organic visibility. While honing his craft in content, he simultaneously taught himself the building blocks of the modern web: HTML, CSS, and React.js — a pursuit that would eventually evolve into full-stack Web Development and a Technical SEO Analyst.

Follow me on LinkedIn →