Website Performance Budget Template 2026: Speed Benchmarks, Page Weight Limits, and QA Checklist

Most slow websites don’t become slow overnight.

They get heavy one plugin at a time. A chat widget here. A tracking pixel there. Three hero images uploaded straight from a camera. A font family with six weights because the mockup looked nice.

By the time the site launches, nobody owns the damage.

That’s what a website performance budget fixes. It gives the project a set of hard limits before the design, development, content, and marketing teams start adding weight. Google recommends site owners achieve good Core Web Vitals for Search and user experience, with LCP under 2.5 seconds, INP under 200 milliseconds, and CLS below 0.1. The 2025 Web Almanac found that only 48% of mobile websites and 56% of desktop websites had good Core Web Vitals, so the bar is not theoretical. Most sites still miss it.

Use this as a working template. Agencies can paste it into proposals and QA docs. Business owners can use it to hold a web team accountable. Developers can use it to stop performance from turning into a last-week cleanup job.

The 2026 Performance Budget Template

A useful budget has two jobs: it sets a target, and it says what happens when the target is missed. Google’s Core Web Vitals thresholds are a good starting point because they measure loading performance, interactivity, and visual stability using real user experience data at the 75th percentile.

These targets are intentionally stricter than the median web. HTTP Archive reported that the median mobile home page weighed 2.56 MB in 2025, with 632 KB of JavaScript and 911 KB of images. If your budget simply matches the median, you’re budgeting for average work.

Why Page Weight Needs a Hard Limit

Page weight is the total data a visitor downloads to view a page. HTTP Archive defines it as the sum of the HTML, CSS, JavaScript, images, fonts, video, and third-party assets required to render a page in its Page Weight chapter.

The median mobile home page grew from 845 KB in July 2015 to 2,362 KB in July 2025. That’s a 202.8% increase over a decade. Desktop home pages also grew, reaching 2.86 MB in 2025. Bigger files require more transfer time, more CPU work, and more memory once the browser starts decoding and executing them.

Google’s mobile speed research found that as page load time went from one second to 10 seconds, the probability of a mobile visitor bouncing increased 123%. The same study found that when page elements increased from 400 to 6,000, the probability of conversion dropped 95%.

That is why the page weight budget needs a hard stop. If a homepage crosses 2.5 MB before launch, someone has to remove, compress, defer, or replace something. Don’t ship the overage and hope the next sprint fixes it.

Budget the Hero Section First

The hero section usually controls Largest Contentful Paint because the main headline image, banner, or above-the-fold content is often the largest visible element. Google’s LCP guidance says a good experience means the largest content appears within the first 2.5 seconds.

For business websites, the hero budget should be simple:

• One primary image or video poster, compressed and sized for the display slot.
• One clear headline in HTML, not baked into an image.
• No auto-playing background video on mobile unless the performance test still passes.
• No slider as the main message unless every slide is required for a measurable business reason.

HTTP Archive found images were the largest byte category on the 2025 median home page, with 911 KB of images on mobile home pages. If the first screen wastes that budget on a decorative hero image, the rest of the page starts in debt.

A practical limit: keep the above-the-fold image payload under 250 KB on mobile and under 400 KB on desktop. That number is not a Google rule. It is a field-tested guardrail that leaves room for CSS, fonts, analytics, and the content below the fold while still aiming at Google’s 2.5-second LCP threshold.

Give JavaScript a Smaller Allowance Than Images

JavaScript is not just a download. The browser has to parse, compile, and execute it. HTTP Archive calls this the JavaScript tax and notes that 100 KB of JavaScript creates CPU work in a way 100 KB of image data does not.

The median mobile home page shipped 632 KB of JavaScript in 2025. HTTP Archive also reported 251 KB of uncompressed unused JavaScript on the median mobile page. That is a big warning sign for small business sites. If half the code doesn’t support the page the visitor is on, the site is paying interest on unused features.

Set a JavaScript budget by page type:

If a marketing script, animation library, or plugin pushes a page above budget, require a business case. “The client might want it later” is not a business case.

Put Third-Party Scripts on Probation

Third-party scripts are useful, but they rarely come alone. Analytics, ad pixels, chat tools, booking widgets, heatmaps, cookie banners, and social embeds all add requests outside your direct control.

The 2025 Web Almanac found that the top 1,000 websites had a median of 129 third-party requests on desktop and 106 on mobile. Across all sites, the median was 83 third-party requests on desktop and 79 on mobile. That is not a target for a normal business website. It is a warning label.

Use this rule: every third-party script needs an owner, a purpose, and a removal date or review date. If nobody owns it, remove it. If it doesn’t support revenue, compliance, analytics, or a required user task, don’t load it by default.

For embedded videos, maps, and scheduling tools, use click-to-load facades where possible. The visitor sees a lightweight placeholder first, then loads the heavy embed only if they interact with it. That keeps the initial page load focused on the content the visitor actually came for.

Don’t Let Fonts Quietly Blow the Budget

Fonts are easy to ignore because they feel like a design detail. HTTP Archive found the median mobile home page used 122 KB of fonts in 2025, and desktop home pages used 139 KB of fonts.

That is not terrible by itself, but font weight grows fast when a design uses multiple families, weights, and italics. It also creates rendering issues if the browser waits for custom fonts before showing text.

A clean budget for most business sites: one brand font, one fallback system stack, and no more than four web font files. Use font-display: swap, subset character sets when appropriate, and don’t load a bold italic file unless the content actually uses bold italic text.

Include SEO and Indexing Checks in the Same Budget

Performance work should not be separated from technical SEO. The same launch process that catches slow pages should catch crawl and metadata problems.

The 2025 Web Almanac SEO chapter found that 85% of robots.txt requests returned a valid 200 status, while 13% returned 404 errors. It also found title tags on 98.6% of desktop pages and 98.5% of mobile pages, but meta descriptions appeared on only 67.7% of desktop pages and 67.2% of mobile pages.

Those numbers show why basic SEO checks belong in the budget. Before launch, every indexable page should have a unique title, a useful meta description, a canonical tag, an accessible HTML heading structure, and a crawl path from the site’s navigation or XML sitemap.

This is not about stuffing keywords into templates. It is about preventing expensive rework after a site has already been crawled, shared, and judged by customers.

Accessibility Belongs in the Launch Gate

Accessibility issues are not just legal risk. They block real customers from using the site. The 2025 Web Almanac reported that automated tools detect less than 50% of accessibility errors, which means a clean automated score does not prove the site is accessible.

Still, automated checks are useful. HTTP Archive reported the median Lighthouse Accessibility score improved to over 85% in 2025. Your launch budget should set a higher bar than that median and pair automated testing with manual checks.

At minimum, test keyboard navigation, visible focus states, form labels, color contrast, image alt text, heading order, skip links, error messages, and modal behavior. If a visitor cannot request a quote, book a call, or buy a product without a mouse, the site is not ready.

The Simple QA Process

Run the budget at four points, not just the night before launch. Test the approved design prototype for obvious risk, test the first coded template, test the full content-loaded staging site, and test again after analytics, forms, CRM scripts, cookie tools, and ad pixels are installed.

Use Lighthouse for quick lab checks, PageSpeed Insights for field data when available, WebPageTest for waterfall details, Search Console for Core Web Vitals groups, and your own analytics for conversion impact. Google’s Search Console Core Web Vitals report groups URLs using real user data from LCP, INP, and CLS.

When a page fails, don’t just write “optimize images” in the ticket. Name the overage. For example: “Homepage mobile image payload is 1.4 MB against a 600 KB budget” or “Calendly embed adds 14 third-party requests before interaction.” Specific problems get fixed. Vague performance notes get carried into the next redesign.

Copy This Performance Budget Into Your Next Project

Here is the plain-English version to paste into a scope of work:

The website must meet Core Web Vitals targets before launch: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS below 0.1 at the 75th percentile where field data is available. Mobile page weight should stay under 2 MB for standard marketing pages. JavaScript should stay under 500 KB transferred unless approved for a specific feature. Image payload should stay under 900 KB on standard pages. Third-party scripts require approval, ownership, and review. The site must pass launch checks for crawlability, metadata, accessibility, forms, analytics, and conversion tracking.

That paragraph will not solve every technical issue, but it changes the project conversation. Performance stops being a vague preference and becomes part of the acceptance criteria.

If you want a web team that builds speed, SEO, accessibility, and conversion tracking into the project from day one, start with Your Web Team here.

FAQ

What is a website performance budget?

A website performance budget is a set of limits for speed, page weight, JavaScript, images, third-party scripts, fonts, SEO, and accessibility. It tells the team what is acceptable before launch and what must be fixed before the site goes live.

What should my page weight budget be in 2026?

For a normal small business marketing page, aim for 1.5 MB or less on mobile and treat 2 MB as the warning line. HTTP Archive found the 2025 median mobile home page was 2.56 MB, so staying below 2 MB gives you a real advantage over the median site.

Which Core Web Vitals matter most?

All three matter. LCP measures loading performance, INP measures responsiveness, and CLS measures visual stability. Google recommends LCP within 2.5 seconds, INP under 200 milliseconds, and CLS below 0.1.

Who owns the performance budget?

The project owner should own the budget, but design, development, content, and marketing all affect it. The best setup is simple: one person approves exceptions, and every exception has a business reason.