Page Speed Analyzer

What Is a Performance Budget?

A performance budget is a quantified limit on metrics that directly affect how fast your website loads. It typically includes constraints on total page weight (measured in kilobytes), the number of HTTP requests, and the target time-to-interactive. Think of it as an engineering specification for speed: just as a structural engineer sets load-bearing limits for a building, web developers set performance budgets to prevent pages from becoming bloated and slow over time.

Without a performance budget, page weight tends to grow silently. A developer adds an analytics script (40KB). Marketing drops in a chat widget (200KB). A new hero image lands at full resolution (800KB). Individually, each addition seems harmless. Cumulatively, the page balloons from 300KB to 1.5MB, load time doubles, and Core Web Vitals scores crater. Performance budgets make this creep visible and preventable by establishing hard limits before new features ship.

The concept was popularized by Tim Kadlec and Tammy Everts around 2013, but it has become far more critical since Google made Core Web Vitals a ranking signal in 2021. Today, a performance budget is not just a speed optimization — it is an SEO requirement. Pages that exceed reasonable weight limits consistently score poorly on Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS), all of which affect search rankings.

Core Web Vitals and Performance Budgets

Core Web Vitals are three specific metrics that Google uses to evaluate user experience: LCP measures how quickly the largest visible element (usually a hero image or heading) renders; FID measures how quickly the page responds to the first user interaction; CLS measures how much the layout shifts during loading. All three are directly affected by page weight and resource composition.

LCP is most sensitive to image weight and server response time. A 500KB hero image on a 3G connection takes approximately 2.5 seconds to download alone, pushing LCP well beyond the 2.5-second "good" threshold. Converting that image to WebP at 80% quality might reduce it to 150KB, bringing download time under 1 second and LCP into the green zone. This is why image optimization is almost always the highest-impact performance budget item.

FID (replaced by Interaction to Next Paint, INP, in 2024) is most sensitive to JavaScript weight. Heavy JS bundles block the main thread during parsing and execution. A 400KB JavaScript bundle takes approximately 2 seconds to parse on a mid-range mobile device. If a user taps a button during that time, the response is delayed. Keeping JavaScript under 150KB (compressed) is the single most effective way to improve FID/INP.

CLS is affected by fonts, images without dimensions, and dynamically injected content. Font files that load late cause a flash of unstyled text (FOUT) followed by a layout reflow. Images without explicit width and height attributes cause the layout to jump when they load. Both are preventable with proper resource budgeting and loading strategies.

Setting the Right Budget by Site Type

The appropriate performance budget varies dramatically by site type. A personal blog or documentation site should target under 200KB total weight, 10-15 requests, and a 1.5-second load time on 3G. This is achievable with static HTML, minimal CSS, system fonts, and optimized images. Many of the fastest sites on the web (Dan Abramov's blog, Hacker News, craigslist) weigh under 100KB.

An e-commerce product page faces heavier demands: product images, reviews, price comparison widgets, and tracking scripts. A realistic budget is 500KB total, 30-40 requests, and a 2.5-second load time. The key is aggressive image optimization (responsive srcset, lazy loading below the fold, WebP/AVIF), deferred JavaScript, and critical CSS inlining.

Single-page applications (SPAs) built with React, Vue, or Angular start with a heavier baseline because the framework itself weighs 30-100KB compressed. A realistic SPA budget is 800KB total on initial load, but this should include code splitting so that only the current route's code loads initially. Subsequent navigations should transfer under 50KB of incremental data.

Resource Optimization Strategies

Images: The Biggest Win

Images are the largest contributor to page weight on most websites, accounting for roughly 50% of total bytes. The optimization playbook is well-established: serve images in next-gen formats (WebP saves 25-35% over JPEG; AVIF saves 50%), use responsive srcset attributes to serve appropriately sized images for each viewport, lazy load images below the fold using loading="lazy", and set explicit width and height attributes to prevent CLS. A site that implements all four strategies typically reduces image payload by 60-80%.

JavaScript: The Performance Killer

JavaScript is uniquely expensive because it must be downloaded, parsed, compiled, and executed — unlike images which only need downloading and decoding. A 200KB JavaScript bundle costs approximately 3-4x more in total processing time than a 200KB image. Key strategies include code splitting by route, tree shaking unused exports, deferring non-critical scripts with async or defer attributes, and replacing heavy libraries with lighter alternatives (Preact instead of React, date-fns instead of Moment.js).

CSS and Fonts

CSS is render-blocking by default, meaning the browser cannot paint anything until all CSS is downloaded and parsed. Inline critical CSS (the styles needed for above-the-fold content) directly in the HTML <head>, then load the remaining stylesheet asynchronously. For fonts, use font-display: swap to show text immediately with a fallback font, preload the most critical font file with <link rel="preload">, and subset fonts to include only the characters your site actually uses. A full Google Fonts family can be 200KB+; subsetting reduces it to 15-30KB.

Compression and CDNs

Enable Brotli compression on your server (or CDN) for all text-based assets. Brotli achieves 15-25% better compression than gzip for HTML, CSS, and JavaScript. A 100KB uncompressed JavaScript file compresses to approximately 25KB with Brotli. Serve assets through a CDN to minimize latency — the physical distance between server and user directly affects Time to First Byte (TTFB). A CDN with edge locations in your users' regions can reduce TTFB from 500ms to under 50ms.

Using This Performance Budget Tool

Start by selecting a preset that matches your site type (blog, e-commerce, or SPA), or enter custom budget values. Then input the actual or estimated size of each resource type on your page. Click "Analyze Performance" to see your score, resource breakdown chart, estimated waterfall timeline, and specific recommendations for any over-budget areas. The waterfall visualization shows the estimated load order on a 3G connection, giving you an intuitive sense of which resources are the bottleneck.

The performance score (0-100) is calculated based on three factors: how your total page weight compares to your budget, whether your request count is within target, and your estimated load time versus your target. Each factor is weighted equally. A score of 90+ indicates a well-optimized page. Scores below 50 indicate significant room for improvement.

All calculations run entirely in your browser. No data is sent to any server. The tool uses standard network throughput estimates: 1.6 Mbps for 3G, 10 Mbps for 4G, and 50 Mbps for broadband. Real-world performance will vary based on server response time, connection quality, caching, and device processing power, but these estimates provide a useful baseline for budget planning.

Beyond Budgets: Monitoring and Enforcement

Setting a budget is only useful if you enforce it. Integrate performance budgets into your CI/CD pipeline using tools like Lighthouse CI, bundlesize, or Webpack's performance hints. These tools fail the build if a bundle exceeds its size limit, preventing bloated code from reaching production. For ongoing monitoring, real user monitoring (RUM) tools like web-vitals.js track actual field performance from your users' devices, alerting you to regressions before they affect search rankings.

Review budgets quarterly. As browser capabilities improve and network speeds increase, absolute budget numbers can shift. But the principle remains constant: every byte you ship is a byte your user must download, parse, and render. Fewer bytes means faster pages, better user experience, higher conversion rates, and better search rankings. The performance budget is the foundation of that discipline.