Front-End Performance Budget for Core Web Vitals

The Site Was Fast on Launch Day. Then Marketing Added a Chat Widget.

Most websites pass Core Web Vitals at launch. Six months later, half of them do not. The culprit is rarely a single catastrophic change. It is a slow accumulation: a new analytics tag here, an unoptimized hero image there, a carousel library nobody audited. A front-end performance budget is the mechanism that prevents this drift by setting explicit, enforceable thresholds for JavaScript payload, image weight, and third-party scripts before they reach production.

Without one, every stakeholder with CMS access becomes an unintentional performance threat. With one, the conversation shifts from “is this fast enough?” to “does this fit within the budget we agreed on?”

What a Performance Budget Actually Contains

A performance budget is not a single number. It is a set of constraints, each tied to a metric that directly affects user experience and Core Web Vitals. The three categories that matter most for front-end work are JavaScript payload, image weight, and third-party script cost.

JavaScript payload. Total compressed (transfer) size of all first-party and third-party JS delivered on initial page load. A practical ceiling for most content-driven sites: 200 KB compressed. For complex single-page applications, 350 KB is aggressive but achievable if you code-split rigorously. Every kilobyte beyond these thresholds adds parse and execution time that directly inflates Interaction to Next Paint (INP).

Image weight. Combined transfer size of all images in the viewport at load, plus any images eagerly loaded below the fold. A reasonable starting point: 500 KB per page on mobile. This number presumes modern formats (AVIF with WebP fallback) and responsive srcset delivery. Hero images alone should not exceed 150 KB at the largest breakpoint.

Third-party scripts. Total number and combined weight of scripts loaded from external domains: analytics, A/B testing, tag managers, chat widgets, consent management platforms. Cap the count at five or six third-party origins per page, with a combined weight ceiling of 100 KB compressed. Every additional origin adds DNS lookup, TLS negotiation, and main-thread contention.

A budget without a consequence is a suggestion. The thresholds only matter if something happens when they are exceeded: a build fails, a pull request is blocked, or an alert fires.

Deriving Thresholds from Real Constraints, Not Round Numbers

Picking “200 KB of JS” because it sounds reasonable is not budgeting. Effective thresholds start from the experience you need to deliver, then work backward to the resource limits that support it.

For a deeper look at how LCP, INP, and CLS interact with resource loading, our Core Web Vitals explainer breaks down each metric in detail.

Enforcement: Where Budgets Succeed or Die

The hardest part is not setting the numbers. It is making sure the numbers survive contact with a real organization.

Build-time enforcement. Tools like bundlesize, Lighthouse CI, and webpack’s built-in performance.maxAssetSize configuration can fail a build or block a pull request when a bundle exceeds its threshold. This is the strongest enforcement point because it prevents over-budget code from ever reaching staging. Configure it in your CI pipeline (GitHub Actions, GitLab CI, or whatever you use) and treat a budget violation the same way you treat a failing test: the merge does not happen.

Tag manager governance. Build-time checks do not catch what marketing adds through Google Tag Manager or Tealium after deployment. This is the most common source of budget violations on sites we work on. The countermeasure is a tag governance policy: a named owner must approve any new tag, and each tag must include its expected compressed size. Pair this with a Content Security Policy (CSP) header that allowlists approved third-party domains. If a domain is not on the list, the browser blocks it.

Synthetic monitoring. Schedule Lighthouse CI or WebPageTest runs against production URLs on a daily or weekly cadence. Alert when any Core Web Vital crosses from “good” to “needs improvement.” SpeedCurve and Calibre are purpose-built for this. The alert should go to both engineering and the stakeholder who owns the page, because the fix might be removing a tag, not rewriting code.

Real User Monitoring (RUM). Synthetic tests use controlled conditions. RUM data from the Chrome UX Report or a tool like SpeedCurve RUM shows what actual visitors experience at the 75th percentile. This is the ground truth for whether your budget is working. Check it monthly at minimum.

The most common failure mode is not a missing tool. It is a missing owner. Assign one person the authority to reject tags and assets that break the budget, and make sure that person is not the one under pressure to ship the campaign.

Handling the Inevitable Negotiation

Someone will ask you to add a 90 KB chat widget to every page. Someone else will insist on an auto-playing background video. The budget does not mean “no.” It means “trade.”

If a stakeholder wants to add a 40 KB A/B testing script, ask what they will remove or defer to stay within the third-party allocation. Lazy-loading a non-critical analytics library to fire after the load event might free enough room. Replacing an older, heavier consent management platform with a lighter alternative might too. The budget turns a political argument into a resource-allocation conversation with clear numbers.

For images, the negotiation is usually about quality versus weight. AVIF at quality 50 often looks indistinguishable from a JPEG at quality 85, at a fraction of the file size. Responsive srcset with properly sized variants prevents a 2,400-pixel hero from being served to a 375-pixel screen. Our speed optimization guide covers image compression pipelines in detail.

A Sample Budget for a Content-Driven Marketing Site

This is a starting template, not a universal prescription. Adjust based on your device and network targets.

• Total page weight (compressed): 800 KB maximum on initial load
• First-party JavaScript: 150 KB compressed
• Third-party JavaScript: 80 KB compressed, maximum five external origins
• Images (above the fold): 200 KB, AVIF/WebP only
• Images (full page): 500 KB with lazy loading below the fold
• CSS: 50 KB compressed, critical CSS inlined
• Fonts: Two families maximum, subset to Latin, WOFF2 format
• LCP target: under 2.0 seconds at 75th percentile (field data)
• INP target: under 150 ms at 75th percentile (field data)
• CLS target: under 0.05 at 75th percentile (field data)

Note that the CWV targets here are tighter than Google’s “good” thresholds. That headroom is intentional. It gives you room to absorb the inevitable additions without crossing into yellow.

After Launch: Keeping the Budget Alive

A performance budget is a living document. Review it quarterly. When you replatform, adopt a new framework, or redesign a key template, recalculate the allocations. The technology changes; the principle does not. Every resource on the page must justify its cost against the experience it delivers.

If you are building a new site or rebuilding an existing one, bake the budget into the project from Discovery onward. It should appear in the technical requirements alongside accessibility standards and browser support targets. Retrofitting a budget onto a site that already ships 1.2 MB of JavaScript is possible, but it is significantly harder and more expensive. Start early.

Explore our digital product services to see how performance engineering fits into the broader build process.

FAQs

What is a front-end performance budget?

A front-end performance budget is a set of explicit thresholds for resource types (JavaScript, images, third-party scripts, CSS, fonts) and user-facing metrics (LCP, INP, CLS) that a web page must not exceed. It acts as a contract between engineering, design, and marketing to keep the site fast after launch.

How do I choose the right JavaScript payload limit?

Start from your target device and network profile, then work backward from your LCP and INP goals. For a content-driven site targeting mid-tier mobile devices on 4G, 150 to 200 KB of compressed JavaScript on initial load is a practical starting point. Single-page applications with heavy interactivity may need up to 350 KB but should use aggressive code-splitting to keep the critical path small.

What tools can enforce a performance budget in CI/CD?

Lighthouse CI, bundlesize, and webpack’s built-in performance hints can fail a build or block a pull request when a bundle exceeds its threshold. For ongoing production monitoring, SpeedCurve, Calibre, and scheduled WebPageTest runs provide synthetic checks, while the Chrome UX Report supplies real user data.

How do I prevent third-party scripts from breaking my budget after launch?

Implement a tag governance policy that requires a named owner to approve every new third-party script, including its expected compressed size. Use a Content Security Policy header to allowlist approved domains so the browser blocks unapproved scripts. Monitor production with synthetic and RUM tools to catch regressions.

How often should I review my performance budget?

Review the budget quarterly or whenever a significant change occurs, such as a replatform, a new framework adoption, or a major template redesign. Regular reviews ensure the thresholds remain aligned with your actual traffic patterns, device mix, and business requirements.