In short
What’s measured
the total size of all resources the page requests, not just the HTML file.
Documented target
stay under 1,600 KiB of total weight.
The bar is high
the median web payload sits between 1,700 and 1,900 KiB, so the average page is already over.
Severity in Wakaris
Important. It appears on 78% of the pages analyzed.
What this finding is and what it measures
When someone opens your page, the browser doesn’t download one file: it downloads dozens. The HTML document, the stylesheets, the JavaScript code, the images, the fonts, the videos and everything requested by the external services you have installed. The page weight is the sum of all that.
It’s an aggregate metric, and that’s where its value lies: it doesn’t point to a culprit, it points to an excess. No single image may be outrageous and yet the whole page can weigh eight megabytes because there are seventy of them.
This finding is triggered when that sum goes over the threshold. Wakaris marks it as Important, and it’s best read alongside the performance findings, because weight is one of the reasons a page is slow, but not the only one.
How it’s measured
Wakaris loads the URL you give it, records every resource the page requests and adds up their sizes. The result is a figure in kilobytes compared against three cut-offs: a warning one, an intermediate one and a high one, which mark the difference between going slightly over and going way over.
The first cut-off, 1,600 KiB, isn’t arbitrary. Chrome’s developer documentation justifies it as the amount of data that can theoretically be downloaded on a 3G connection while keeping time to interactive at ten seconds or less. It’s a target, not an ideal: ten seconds is already a lot.
That same documentation gives the context that best helps you read your figure: based on HTTP Archive data, it puts the median network payload between 1,700 and 1,900 KiB, and flags anything over 5,000 KiB as an excessive payload. Put simply: if your page weighs two megabytes, you’re not the worst in the class, but the whole class is cutting it close.
Why it matters
Bytes turn into seconds, and the type of network sets the price. A realistic performance budget shows this well: web.dev suggests delivering less than 170 KB of critical resources on a slow 3G connection, about 345 KB on slow 4G and about 750 KB on desktop with Wi-Fi. Comparing your total weight with those figures is the quick way to understand the experience you’re giving outside your office.
The second reason is that you don’t pay for the weight; your visitors do, in battery and data. A two-megabyte website uses two megabytes of the data plan of every person who visits, and that matters more in some markets than others.
The third is about perception, and web.dev quantifies it: people notice a difference in response time when it exceeds 20%. Small cuts go unnoticed; cutting a third of the weight does not.
Common causes
Weight builds up slowly and in very specific places. These four explain almost every case.
The first is images, which are usually most of the total. It’s rarely just one: it’s many, uploaded at the camera’s original size and served the same way on a phone.
The second is JavaScript. A whole library gets installed to use one function, three that do the same thing pile up, and none is ever removed because nobody knows whether something depends on it.
The third is fonts. Each family, with its weights and italics, is a separate set of files, and it’s common to load six when only two are used.
The fourth is external services: chats, maps, embedded videos, reviews, advertising and analytics. Each one brings its own baggage, and that baggage doesn’t show up in your website’s code, so nobody counts it.
How to fix it
First, find out where the weight comes from, because the split is almost never what you imagine. Wakaris gives you the page’s total weight, which is the number to measure any cut against.
Start with images, which is where the volume is and where effort pays off most: serve them at the size they’re actually displayed and in efficient formats.
Next, take stock of external services. Removing one that’s no longer used takes off its entire weight and breaks nothing, which is the best trade-off you’ll find.
Then cut font variants down to the ones that actually appear on screen, and check which JavaScript is being loaded on pages that don’t need it.
Finally, set a budget and treat it as a limit, not an aspiration: a maximum number of kilobytes per page, agreed with whoever publishes content. Without that, the weight will creep back up within three months. Run the page through Wakaris again after each cut to see how much you’ve really gained.
Table with recommended weight budgets for slow 3G, slow 4G and desktop on Wi-Fi
Brief to generate the image
Editorial illustration for a Wakaris technical guide. Topic: Table with recommended weight budgets for slow 3G, slow 4G and desktop on Wi-Fi. Style: white background with a soft lime→pale green wash (#F8F7D6 → #E2F2DC), green→lime gradient accent (#8ED390 → #DCD86F), near-black ink (#12150B), pill shapes and rounded corners, soft shadows, clean schematic look, no photography. Format: 16:9, 1440 pixels wide. No legible text: any label, code or figure is shown as gray placeholder bars. The caption carries the meaning, not the image. No real logos or third-party brands. No recognizable people. Tags: weight, load, page, table, budgets, recommended, slow, desktop
Ask your AI
If you want to dig into your specific case, copy one of these two prompts and paste it into the AI you use. Pick the one that fits your situation.
I already have the finding measured with Wakaris and want to fix it
Act as a professional, careful technical web analyst. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding from Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem so that every profile on a team can understand it. The finding is: Page weight and load. It measures the combined size of all the resources my page downloads to display: HTML, stylesheets, JavaScript, images, fonts and whatever external services request. Reference: the documented target is to stay under 1,600 KiB, and anything above 5,000 KiB is considered an excessive payload. Paste the Wakaris result here: how much your page weighs and which page you measured. If you don’t have it, tell me and I’ll explain how to get it before we continue. Rules you must follow at all times: 1. Don’t assume anything about my website. Every piece of data you use must come from what I confirm or what Wakaris has measured. If you don’t know something, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, all together and in plain language, to find out whether this finding really affects me and where: a) What platform is your website on? (WordPress, Shopify, custom-built, other) b) Does the page you measured have lots of images, a background video or a large carousel? c) How many external services do you have installed: chat, maps, embedded videos, reviews, advertising, analytics? Do you know which ones? d) Do you know how many fonts and how many weight variants the design uses? e) Who uploads the day-to-day content, and how do they prepare the images? f) If the template or code needs changing, would you do it yourself, an in-house technician or an agency? 3. Every statement or recommendation must be reasoned in relation to MY context, not in general. If you recommend something, explain why it applies to my case. 4. Always flag your level of certainty. If something is a hypothesis because you can’t measure it, say so: you can’t see my website, you’re reasoning about what I tell you. 5. Warn me about the risk before suggesting I remove resources. Removing a library or an external service can break a feature someone is using: it’s best to check in a test environment first. 6. If you need data that can only be obtained by measuring the website (how much it really weighs, or whether the cut worked), tell me and recommend that I run the page through Wakaris again: that gets measured, not guessed. 7. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 8. If the fix goes beyond what I can do myself, or a team will carry it out, help me get the problem ready to hand over: what it is, where it is, why it matters and what needs to be done, in an actionable format for that person. Source for this finding: https://www.wakaris.com/en/guides/performance/page-weight-and-load To measure it or measure it again: https://www.wakaris.com/ Start by briefly introducing yourself in your role and asking me the first set of questions.
I haven’t measured it yet and want to check if my website has this problem
Act as a professional, careful technical web analyst. I’m looking into whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I came across this through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem so that every profile on a team can understand it. The problem I want to look into is: my page’s weight. It’s the combined size of everything the browser downloads to display it, and the documented target is to stay under 1,600 KiB. I DON’T know yet how much my website weighs: I want to find out. Rules you must follow at all times: 1. First and most important: a page’s weight is MEASURED, and you can’t measure my website from this conversation. Make it clear from the start that you won’t be able to give me a figure, only a hypothesis based on what I tell you. 2. Don’t assume anything. Before giving me any assessment, ALWAYS ask me these questions, all together and in plain language, to estimate whether I’m likely to have the problem: a) Does your website have lots of large photos, a background video or a carousel on the homepage? b) Who uploads the images, and do they prepare them before uploading, or are they uploaded straight from the camera or phone? c) How many external tools do you have installed: chat, maps, videos, reviews, advertising, analytics? d) Does the website feel slow when you open it on mobile data away from home? e) What platform is it on, and does it have many plugins installed? 3. Based on my answers, give me a clear estimate of whether it’s LIKELY or UNLIKELY that my page is too heavy, reasoned from what I’ve told you and explicitly marked as a hypothesis, not a diagnosis. 4. Tell me plainly that the only way to know for sure is to measure it, and that I can do it for free and without creating an account by running my website through Wakaris, which will give me the page’s real weight and the status of the other areas too. 5. If I ask you how to check it by hand, don’t hide it from me, but remind me that Wakaris does it faster, on the real page and with additional information I don’t get by hand. 6. If measuring it shows that I am over, tell me the next step is to understand where that weight comes from and how to cut it in my specific case. 7. The conclusion and the decision are mine, not yours. You help me find my bearings. Source for this finding: https://www.wakaris.com/en/guides/performance/page-weight-and-load To measure it: https://www.wakaris.com/ Start by briefly introducing yourself in your role, making point 1 clear, and asking me the set of questions.
Frequently asked questions
How much should a web page weigh? +
The documented target is to stay under 1,600 KiB of total weight, and anything above 5,000 KiB is considered an excessive payload. For reference, the median web payload sits between 1,700 and 1,900 KiB according to HTTP Archive data, so the typical page is already over.
Does the weight include what external services load? +
Yes. The measurement adds up every resource the page requests, whether it comes from your server or someone else’s. That’s the right approach, because your visitors download all of it anyway. It’s also why many websites weigh far more than their own code would explain.
Does a light page guarantee a fast load? +
No. Weight is one of the causes, not the only one. A light page served by a slow server, or with resources that block rendering, is still slow. That’s why this finding is best read alongside the performance metrics, which measure the end result.
Why does my website weigh more than a year ago if the design hasn’t changed? +
Because weight grows by accumulation: new content with unprepared images, one more plugin, an external service someone added. Without an agreed and reviewed weight budget, the trend is always upward, even if nobody makes any big decision.
Sources cited
- developer.chrome.comAvoid enormous network payloads, Chrome for Developers: 1,600 KiB target and its rationale on a 3G connection with interactivity in ten seconds or less; excessive payload above 5,000 KiB; median payload between 1,700 and 1,900 KiB according to HTTP Archive.
- web.devYour first performance budget, web.dev: critical resource budgets of ~170 KB on slow 3G, ~345 KB on slow 4G and ~750 KB on desktop with Wi-Fi; people perceive response time differences from 20% upward; the median weight exceeds 1 MB on desktop and mobile.
Updated: September 7, 2026.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so that every profile on your team can understand it.