The typical website homepage is heavier than it has ever been.
That isn’t just a developer problem. Every byte has to cross a network, land on a device, and be processed before a customer can use the page. A polished homepage can quietly turn into a multi-megabyte delivery job after a team adds a hero video, a few tracking scripts, six font files, and images exported for print.
This report gives web professionals and business owners a current reference point. The numbers come mainly from the HTTP Archive’s 2025 Web Almanac, which analyzed July 2025 measurements across millions of websites. Use the benchmarks to compare sites, set project limits, support a redesign recommendation, or explain why “one more widget” isn’t free.
Page Weight Statistics at a Glance
- The median desktop homepage weighs 2.86 MB, while the median mobile homepage weighs 2.56 MB.
- Median homepage size grew 7.8% in one year.
- The median mobile homepage grew from 845 KB in July 2015 to 2,362 KB in July 2025, a 202.8% increase.
- A median mobile homepage ships 911 KB of images, 632 KB of JavaScript, 122 KB of fonts, 77 KB of CSS, and 22 KB of HTML.
- A median desktop homepage ships 1,058 KB of images, 697 KB of JavaScript, 139 KB of fonts, 82 KB of CSS, and 22 KB of HTML.
- The median page carries 280 KB of unused uncompressed JavaScript on desktop and 251 KB on mobile.
- Video payload on pages that use video rose 28% year over year, from 246 KB to 315 KB.
- Only 48% of mobile sites and 56% of desktop sites passed all three Core Web Vitals.
These figures aren’t targets. They describe the middle of the web, including plenty of sites that feel slow. A site that matches the median is average by definition.
What Page Weight Actually Measures
Page weight is the total amount of data transferred when someone loads a page. It includes HTML, CSS, JavaScript, images, fonts, video, and third-party files. The number shown in a test tool is normally the compressed transfer size, not the larger amount of data the browser may hold after decompressing and decoding everything.
That distinction matters. A compressed image needs to be decoded into pixels. JavaScript must be decompressed, parsed, compiled, and executed. An apparently modest script can create more work than an image of the same transfer size. HTTP Archive describes this as the JavaScript tax.
Weight also differs from request count. A 2 MB page made from a few well-cached files behaves differently from a 2 MB page assembled through a long chain of third-party requests. Track both. Transfer size tells you how much data moved; request count helps expose connection overhead, dependencies, and outside services.
Finally, page weight isn’t the same thing as load time. Hosting, caching, network conditions, device power, and the order in which files load all affect speed. Still, weight is one of the most useful controllable inputs. You can’t control a customer’s signal strength, but you can stop sending a 4 MB hero image to their phone.
The Web Added Two Megabytes to the Median Mobile Homepage
The long-term trend is blunt. In July 2015, the median mobile homepage was 845 KB. By July 2025, it had reached 2,362 KB. That is more than triple the original payload in a decade.
Desktop growth was slower but still substantial. The median desktop homepage increased 110.2% over the same ten-year period. From 2024 to 2025 alone, desktop homepage weight rose 7.3%, from 2.7 MB to 2.9 MB. Mobile rose 8.4%, from 2.4 MB to 2.6 MB.
Inner pages are lighter, but they are growing too. Since HTTP Archive began tracking them in 2022, median mobile inner-page weight increased 27.8% to 1.8 MB. Desktop inner pages climbed 25.2% to 2 MB.
This gap should change how teams test. Running Lighthouse only on the homepage misses the service, product, article, and checkout templates customers actually use. Testing only an inner page can hide a bloated first visit. A credible audit samples both.
Images Still Take the Largest Share
Images remain the biggest byte category on the median homepage. Desktop homepages use 1,058 KB of images, while mobile homepages use 911 KB.
The homepage is where image budgets tend to break. The median desktop homepage transfers 239% as many image bytes as an inner page. At the 90th percentile, desktop homepage images total 6,856 KB, compared with 3,431 KB on inner pages. On mobile, the median homepage sends 911 KB of images versus 354 KB for an inner page.
Format choice can make a real difference. At the 90th percentile in HTTP Archive’s desktop homepage sample, individual JPEG and PNG files reached 278 KB, WebP reached 97 KB, and AVIF reached 37 KB. Those aren’t like-for-like quality comparisons, but they show why modern formats belong in the production workflow.
Don’t convert every file blindly. Logos and interface graphics may be better as SVG. Photos need responsive dimensions, not merely a new extension. The browser should not download a 2,400-pixel source for a 480-pixel slot. MDN’s guide to responsive images explains how srcset and sizes let the browser choose an appropriate file.
JavaScript Is the Costliest Weight
Images are heavier in raw bytes, but JavaScript demands more from the device. The median desktop page transfers 708 KB of JavaScript and the median mobile page transfers 646 KB. At the 90th percentile, the totals pass 2 MB on desktop and reach 1.9 MB on mobile.
The problem is rarely one giant file. The median individual script is only 4.6 KB on desktop and 4.7 KB on mobile. Small files accumulate through frameworks, plugins, analytics, chat, personalization, A/B testing, advertising, consent management, and tag managers.
Some of that code never helps the current page. Lighthouse found 280 KB of uncompressed unused JavaScript on the median desktop page and 251 KB on mobile. That makes unused-code coverage one of the best places to start an audit. Chrome DevTools’ Coverage panel shows how much CSS and JavaScript was executed during a recorded interaction.
Ask a plain business question for every third-party script: what measurable job does this do? If nobody can answer, remove it from a staging copy and test what breaks. A tag installed for a campaign three years ago should not tax every visitor forever.
Video Is the Fastest-Growing Heavy Asset
Video can consume a budget before the rest of the page gets a chance. Among pages that used video, median video transfer increased 28% from 246 KB in 2024 to 315 KB in 2025.
Mobile homepages were especially heavy. The median mobile homepage with video shipped 512 KB, double the 256 KB on mobile inner pages. At the 90th percentile, those mobile homepage videos reached 6.1 MB.
That doesn’t mean a business should never use video. Product demonstrations, before-and-after proof, and process footage can answer questions that text cannot. The waste usually comes from autoplay background footage, files loaded before the visitor can see them, and separate encodes that are not matched to the display size.
A poster image is often the right first payload. Load the video after a click when playback is optional. If autoplay is essential, test it on an ordinary phone using a throttled connection and supply a smaller mobile source.
Fonts and CSS Are Smaller, but They Still Stack Up
The median mobile homepage sends 122 KB of fonts and 77 KB of CSS. Desktop sends 139 KB of fonts and 82 KB of CSS. Neither category looks alarming alone. Multiple families, styles, weights, icon fonts, and page-builder stylesheets change that quickly.
Web fonts appear on about 87% of websites. WOFF2 is used on 81% of desktop sites and 78% of mobile sites, which makes it the practical default for broad modern-browser support and compressed delivery.
Start with the fonts a real page uses. A normal business site may need regular and bold body text, not every weight from 100 through 900. Subset only when the language requirements are understood. Self-hosting can remove an outside dependency, but a poorly configured self-hosted family is still heavy.
For CSS, look for whole design systems shipped to pages that use a fraction of their rules. Be careful with automated removal because classes can be inserted by forms, menus, and interactive states. Record the main user flows before deciding a rule is dead.
Page Weight and Core Web Vitals Are Connected, Not Interchangeable
Google’s Core Web Vitals measure loading, responsiveness, and visual stability. A page has a good experience when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of visits.
In the 2025 data, 48% of mobile sites and 56% of desktop sites passed all three. Page weight contributes to those outcomes, but there is no universal size that guarantees a pass. A light page can still have a slow server or a badly prioritized hero image. A heavier page can feel quick if the critical content arrives first and below-the-fold assets wait.
That is why a useful scorecard has both outcome metrics and input limits. Core Web Vitals tell you what customers experienced. Byte budgets help the team control what it ships.
A Practical Page Weight Scorecard
The limits below are working guardrails for a small-business marketing site, not official Google thresholds. They are intentionally below the web median so the team has room for future tools and content.
| Item | Strong | Review | Action required |
|---|---|---|---|
| Total mobile transfer | Under 1.5 MB | 1.5 to 2.5 MB | Over 2.5 MB |
| Images | Under 600 KB | 600 to 900 KB | Over 900 KB |
| JavaScript transfer | Under 350 KB | 350 to 650 KB | Over 650 KB |
| Fonts | Under 150 KB | 150 to 250 KB | Over 250 KB |
| Video on initial load | 0 KB | Up to 500 KB | Over 500 KB |
| Unused JavaScript | Under 100 KB | 100 to 250 KB | Over 250 KB |
Use different budgets when the product demands it. A mapping application, 3D configurator, or browser-based editor will not look like a service-business brochure site. The important part is to document the exception and measure the customer task it supports.
How to Audit a Website in 45 Minutes
Start with a clean browser profile and test the homepage plus three high-value templates. Choose a service or product page, a lead or checkout page, and the page receiving the most organic traffic.
- Run each URL through PageSpeed Insights. Save the field data when available and the lab test for a repeatable diagnostic baseline.
- Open Chrome DevTools, disable the cache, and record a Network load. Sort by size, then filter images, scripts, fonts, and media.
- Run the DevTools Coverage panel through the primary interaction. Record unused CSS and JavaScript, but verify behavior before deleting anything.
- List every third-party domain and name the business owner for that service. Flag entries with no owner, no current campaign, or duplicate functionality.
- Compare each template with the scorecard and choose the three largest realistic reductions. Retest after the changes.
Don’t start by shaving 2 KB from icons while a background video transfers 8 MB. Fix assets in descending order of waste and business risk. The biggest wins are usually oversized images, eager video, unused scripts, duplicate trackers, and excessive font files.
How Agencies and Owners Can Use These Benchmarks
An agency can attach the scorecard to a statement of work and define what happens when the client requests an asset that breaks budget. A developer can add automated limits to a build pipeline. A business owner can use the category totals to ask better questions than “Can you make it faster?”
Keep a dated baseline after launch. Page weight tends to creep because no single addition feels decisive. Quarterly checks catch the accumulation before a campaign landing page becomes the new normal.
Most of all, connect each byte to a job. A crisp product photo can earn its place. A scheduling widget may remove sales friction. Code for an abandoned experiment cannot defend itself.
If your site is heavier than the benchmarks and nobody can explain why, start a website review with Your Web Team. We’ll identify what is slowing the site, what is worth keeping, and where the first round of fixes will have the most business impact.
Frequently Asked Questions
What is a good page weight in 2026?
For a typical small-business marketing page, under 1.5 MB on mobile is a strong working target. It is not an official Google rule. The current comparison point is the 2.56 MB median mobile homepage, so staying below that level gives the team useful headroom.
Does a smaller page always load faster?
Not always. Server response, caching, network latency, asset priority, and device processing all matter. Smaller transfers usually reduce the work required, but use Core Web Vitals and real-user data to judge the actual experience.
What makes up most website page weight?
Images are the largest category on the median homepage, followed by JavaScript. The 2025 median mobile homepage carried 911 KB of images and 632 KB of JavaScript.
Should mobile pages be lighter than desktop pages?
Usually, yes. Mobile screens often need smaller image dimensions, and mobile visitors may have weaker connections and less powerful hardware. Yet the median mobile homepage still weighed 2.56 MB in 2025, which shows how often responsive layouts fail to deliver meaningfully smaller payloads.
How often should page weight be checked?
Check it before launch, after adding major tools or media, and on a quarterly schedule. Also test after changes to analytics, advertising, chat, consent tools, plugins, and tag-manager containers because those can add weight without changing the visible design.