A landing page feels sluggish on a phone, a hosting bill shows unexpected bandwidth, or a performance audit says “reduce page weight” without telling you what is heavy. Before optimizing anything you need to know how many bytes the page actually sends, which files are biggest and whether text is compressed at all.
The Page Size Checker downloads a page’s HTML and the resources referenced directly in it — stylesheets, scripts, images, fonts and media — and reports the total transfer size, the decoded size, the number of requests, a breakdown by resource type, the largest files and the document’s response headers with notes on compression and caching.
What is page size?
In simple terms
Page size (or page weight) is the total amount of data a browser has to download to show a page: the HTML itself plus every file it needs. A page with a few kilobytes of text can easily weigh several megabytes once large photos, web fonts and JavaScript bundles are added.
Technical background
Each file is fetched with an HTTP request. The server can compress text-based responses, announced in the Content-Encoding response header — usually gzip or br (Brotli). What crosses the network is the transfer size; what the browser works with after decompression is the resource size. JavaScript is the most expensive per byte because it has to be decompressed, parsed and executed; images are large but cheap to process once decoded.
Other response headers influence repeat visits: Cache-Control tells browsers how long they may reuse a file without asking again, and Strict-Transport-Security (HSTS) tells them to use HTTPS directly. A first visit always pays the full weight; caching only helps later visits.
Browsers also choose among responsive image candidates (srcset), defer lazy-loaded images and load many resources only when scripts request them, so the bytes a real visit downloads depend on the device, the viewport and script behavior.
Why use a page size checker?
- Find the heaviest files. Usually one hero image or one JavaScript bundle accounts for a large share of the page.
- Verify compression. An HTML or CSS response without
Content-Encodingis a quick win. - Compare desktop and mobile. See whether the site really sends lighter assets to phones.
- Check a redesign or new theme. Compare totals and request counts before and after.
- Support performance discussions with numbers. A breakdown by type tells you whether to talk to designers (images), developers (JavaScript) or whoever runs the server (compression and caching).
Who should use it?
- Web developers and front-end engineers.
- Site owners and webmasters evaluating themes, plugins or page builders.
- SEO specialists looking at performance factors.
- Hosting and DevOps people checking compression and caching headers.
How the page size checker works
All downloads are made by the NetTools.tech server through the SSRF-protected fetcher used by the other web tools: only public http/https URLs on ports 80, 443, 8080 or 8443, every redirect re-checked.
- The document. The server requests the URL with a desktop or mobile Chrome user agent (marked “NetTools.tech”), following up to 5 redirects, with a 12-second timeout and up to 5 MB of HTML. It asks for
gzip,deflateandbrcompression. - Resource discovery without JavaScript. The HTML is scanned for directly referenced resources:
<link>elements withstylesheet,icon,preload,modulepreload,apple-touch-iconormanifest;srcof<script>,<img>,<source>,<video>,<audio>,<iframe>and<embed>; allsrcsetcandidates; video posters; image inputs; andurl()references in<style>blocks andstyleattributes. Comments are ignored, duplicates removed. - Downloading. Resources are fetched by six parallel workers, each following at most one redirect (common for CDNs). Downloaded stylesheets are scanned for
url()and@import, so fonts and background images referenced from CSS are included. - Measuring. For every file the server records the bytes received on the wire (compressed), the decoded size, the status, the content type and the encoding. Types are taken from
Content-Type, falling back to the file extension. - Limits. At most 150 resources, 25 MB in total and about 40 seconds for resources; requests to any one host are throttled. When a limit is reached the result is marked as truncated. Downloaded content is discarded after measuring.
How to use the NetTools.tech Page Size Checker
- Open the Page Size Checker.
- Enter the Page URL, for example
https://www.example.com/. - Choose Request as: Desktop browser or Mobile browser.
- Press Check page size. Large pages can take up to a minute. Preview with sample data shows an example report without any request.
- Read the summary figures, then the By resource type bars and table, the Largest resources list and the Document response headers.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
| Transferred | Sum of compressed bytes received for all measured files (HTTP headers not included) | Highlighted when above 3 MB |
| Resource size | Sum of decoded sizes | A large gap to “Transferred” means compression is working |
| Requests | Number of files measured, including the document | Highlighted when above 100 |
| HTML | Transfer size of the document itself | Very large HTML often contains inlined data or huge inline scripts |
| Saved by compression | 1 − transferred ÷ resource size, across all files | Low values on text-heavy pages suggest missing compression |
| By resource type | HTML, CSS, JavaScript, Images, Fonts, Media and Other, with file count, share of transferred bytes, transfer and resource size | The largest bar is where optimization pays off first |
| Largest resources | The ten biggest files by transfer size, with type, status and encoding | Images without modern formats, uncompressed scripts, oversized fonts |
| Header notes | Compression used or missing (warning if HTML over 1 KB is uncompressed), Cache-Control present or missing, Content-Type missing, HSTS missing on HTTPS | Missing compression and caching are configuration fixes, not code changes |
| Response headers table | Every response header of the document | content-encoding, cache-control, vary, server |
| Truncated / not measured notes | Limits were reached, or some resources could not be fetched | Totals are then lower than reality |
Example: reading the sample report
The sample report for https://www.example.com/ lists ten files, about 987 KB transferred in total. Rounded, the document is about 18 KB transferred (70 KB decoded, Brotli), CSS 21 KB, two JavaScript files about 145 KB and 36 KB, three images about 403 KB, 262 KB and 3 KB, two WOFF2 fonts of about 47 and 48 KB and a 4 KB favicon. The header notes say: compressed with br, Cache-Control: public, max-age=300, and HSTS present.
Type Files Transferred
Images 4 ~ 672 KB
JavaScript 2 ~ 181 KB
Fonts 2 ~ 95 KB
CSS 1 ~ 21 KB
HTML 1 ~ 18 KBReading it: images make up roughly two thirds of the transfer, so converting the hero JPEG and the team PNG to a modern format and the right dimensions is the first step. The vendor JavaScript bundle is the second target. Compression is already enabled — the HTML shrinks from about 70 KB to 18 KB — so no server change is needed there.
Common use cases
- Before-and-after comparison when replacing a theme, slider or page builder.
- Checking that a CDN or reverse proxy actually compresses HTML, CSS and JavaScript.
- Comparing Desktop browser and Mobile browser results to verify responsive images.
- Identifying a forgotten multi-megabyte image on a landing page.
- Reviewing response headers together with HTTP Status after a server migration.
Troubleshooting
The result shows only one request
The document was not served as HTML (for example a PDF or JSON), so no resources were extracted, or the page builds everything with JavaScript. Check the content type in the response headers table.
Totals are much lower than in developer tools
Script-loaded resources, ads, analytics, lazy-loaded content and iframes’ own sub-resources are not counted. The checker measures the statically referenced part of the page.
Totals are higher than in developer tools
The checker downloads every srcset candidate and every preload, icon and manifest it finds, while a browser picks one image size and may skip some of these. It also starts with an empty cache.
Many resources “could not be measured”
Those requests failed: they pointed at private addresses, used disallowed ports, timed out, or the host was throttled. They are excluded from the totals.
“Measurement stopped at the resource or size limit”
The page has more than 150 resources or more than 25 MB, or downloads took too long. The real page is heavier than reported — which is itself a finding.
The HTML is reported as uncompressed although compression is enabled
Some servers compress only for certain user agents, only above a size threshold, or only at the CDN edge. Check the content-encoding header in the table; if it is absent, the server sent the HTML uncompressed to this request.
Common mistakes
- Comparing transfer size from this tool with resource size from another.
- Expecting compression to shrink JPEG, PNG, WebP or WOFF2 files — they are already compressed.
- Optimizing small files while one oversized image dominates the total.
- Treating page size as page speed; latency, server response time and render-blocking resources matter too.
- Forgetting that a cached repeat visit is lighter, while the first visit pays the full weight.
- Measuring a page that redirects to a login or consent page and reading that page’s size instead.
Limitations
- JavaScript is not executed; resources loaded at runtime are not included.
- All
srcsetcandidates are downloaded, so image totals can be higher than what a browser actually fetches. - Transfer sizes count body bytes only, not HTTP headers or TLS overhead.
- Each resource follows at most one redirect; deeper chains end up unmeasured.
- Requests come from the NetTools.tech server, without cookies or cache; sites may serve different content by location, user agent or consent state.
- Iframe documents are counted, but not the files they load.
- Hard caps of 150 resources, 25 MB and about 40 seconds for resources; the HTML document is read up to 5 MB.
- It does not measure rendering time, Core Web Vitals or HTTP/2 and HTTP/3 behavior.
Security & privacy
The URL and the chosen device type are sent to the NetTools.tech server, which downloads the page and its resources, measures them and returns only the measurements and the document’s response headers to your browser. Downloaded content is discarded after measuring and the URL is not stored. Target sites see requests from the NetTools.tech server, not from your IP address.
Do not enter URLs with session tokens, private preview keys or other secrets in the query string; they would be requested and shown in the results like any other URL.
Related tools
- HTTP Status — status code and headers of a single URL. Guide: HTTP Status Checker guide.
- Meta Tag Analyzer — check the page’s metadata at the same time. Guide: Meta Tag Analyzer guide.
- Broken Link Checker — find broken images, scripts and stylesheets. Guide: Broken Link Checker guide.
- Redirect Checker — see redirects that add round trips before the page even loads.
- Open Graph Checker — check the preview image that shares of the page will use.
- Category overview: Web & SEO tools guide.
Summary
The Page Size Checker measures how many bytes and requests a page’s statically referenced files need, with transfer and decoded sizes, a breakdown by type, the largest files and the document’s compression and caching headers. Use it to find the heaviest assets and missing compression. It does not run JavaScript or use a cache, so treat the totals as a baseline for the static part of the page, not as an exact copy of a browser visit.
Frequently asked questions
What is a good page size?
There is no single correct number; lighter pages load faster, especially on mobile connections. Many well-optimized pages stay in the low single-digit megabytes or below, and images and JavaScript are usually the largest parts, so start there.
What is the difference between transfer size and resource size?
Transfer size is what crosses the network, after gzip or Brotli compression. Resource size is the decoded content the browser has to parse and process; for compressed text files it is several times larger than the transfer size.
Why is the result different from my browser’s developer tools?
The checker does not run JavaScript, so anything loaded by scripts — ads, analytics, lazy-loaded images, single-page-app content — is missing. It also has no cache, does not count HTTP headers, and downloads every srcset candidate rather than the one image a browser would pick.
Does the checker test page speed?
No. It measures how many bytes and requests a page needs, not rendering time or Core Web Vitals. Size is one important factor in speed, but latency, render-blocking resources and server response time matter too.
Why does it say the measurement stopped at a limit?
The checker stops after 150 resources, 25 MB in total or about 40 seconds of downloading resources. The real page is then larger than the reported totals.
What does “Request as Mobile browser” change?
The server sends a mobile Chrome user agent instead of a desktop one. Sites that serve different HTML or smaller images to phones will return those, so the totals can differ.
How do I enable compression?
Turn on gzip or Brotli for text types such as HTML, CSS, JavaScript, JSON and SVG in your web server, CDN or hosting control panel. Images such as JPEG, PNG and WebP are already compressed and gain little.