Webpage Size Checker
Analyze any webpage and see its total size including all resources
Why Check Webpage Size?
Page Load Speed
Smaller pages load faster, improving user experience and SEO rankings
Mobile Users
Large pages consume more data, important for users on limited mobile plans
Performance Audit
Identify heavy resources and optimize your website's performance
Bandwidth Costs
Understand how much data your site transfers to help manage hosting costs
Optimization Guidelines
- •Under 1MB: Excellent - Your page will load quickly on all connections
- •1-3MB: Good - Acceptable for most modern websites
- •3-5MB: Heavy - Consider optimization, especially for mobile users
- •Over 5MB: Too large - Significant optimization needed
How This Checker Measures Page Size
When you submit a URL, our server fetches the page and every resource it references (the HTML document itself, linked stylesheets, JavaScript bundles, images, web fonts, and other assets), then adds up the number of bytes each one transfers. The figure you see is the uncompressed transfer size of those files as they arrive over the network, not the amount of memory the page uses once decoded and rendered. Because the analysis runs on our backend rather than in your browser, it isn't affected by extensions, ad blockers, or content already sitting in your local cache, so two people checking the same page get the same number.
One consequence worth keeping in mind: the tool captures the resources present in the initial HTML response. Content that a single-page application injects later through JavaScript (images loaded on scroll, data pulled from an API after the page paints, or third-party widgets that bootstrap themselves) may not be counted in full. Treat the total as a solid baseline for the critical loading path rather than an exhaustive tally of everything a session could eventually download.
Reading the Resource Breakdown
The breakdown groups assets by type so you can see where the weight actually lives. Images are the usual culprit on content-heavy sites, and the fix is rarely to remove them: serve them in modern formats like WebP or AVIF, size them to the dimensions they're displayed at, and lazy-load anything below the fold. JavaScript is the second common offender, and because scripts block rendering and cost CPU time to parse, trimming an unused framework or code-splitting a large bundle often improves perceived speed more than shaving the same number of kilobytes off an image would.
Total bytes and total request count are separate problems. A page can be modest in size yet still feel slow because it opens dozens of connections to fetch many tiny files. If the resource list runs long, bundling related files and consolidating third-party tags will cut round trips even when the byte total barely changes.
Frequently Asked Questions
Does the reported size include compression like gzip or Brotli?
The figure reflects the size of each resource as it is fetched. If your server sends assets with gzip or Brotli compression enabled, the transferred bytes will already be smaller than the raw file on disk. Enabling text compression is one of the easiest ways to shrink the HTML, CSS, and JavaScript portion of your total.
Why is the size here different from what my browser DevTools shows?
DevTools measures what your specific browser downloaded, which is influenced by your cache, installed extensions, and any resources loaded lazily as you interact with the page. This tool fetches the page fresh from a server with an empty cache, so it reports the cold-load size a first-time visitor would experience.
What is a good target size for a web page?
There is no universal number, but keeping the critical loading path under about 1-2 MB keeps most pages responsive on average mobile connections. Media-rich pages will naturally run larger; the goal is to make sure the weight is intentional rather than the result of unoptimized images or unused scripts.
Can it analyze a page behind a login?
No. The checker requests the page anonymously, so anything requiring authentication, a session cookie, or form submission will either fail to load or return the public or logged-out version of the page.
Does a smaller page always load faster?
Smaller usually helps, but load time also depends on how many separate requests are made, how quickly your server responds, whether render-blocking scripts sit in the way, and the visitor’s connection. Use the byte total alongside the resource count and load time shown here to find the real bottleneck.
Discussion
Start the conversation
Leave a comment
Loading comments...