// measure your page weight in one click
Analyze the total size of any webpage by URL or HTML input. Instantly measure HTML, CSS, JS, and image weights to boost performance.
Ready to analyze
Enter a URL or paste HTML and click AnalyzeSwitch between URL fetch or paste raw HTML directly.
Type or paste a full URL, or drop in your HTML source code.
See size breakdown, resource counts, score, and optimization tips.
Page Size Analyzer measures the raw and estimated compressed size of any webpage's HTML document. It breaks down inline CSS, inline JS, counts external resource references, and provides a performance score to help you identify bloat fast.
Page size refers to the total byte size of the HTML document delivered to the browser. This does not include externally loaded resources like images, CSS files, or JavaScript files fetched separately — only the initial HTML response.
Gzip is a compression algorithm that web servers use to reduce transfer size. Most modern servers serve gzip-compressed HTML, so the gzip estimate shows you the approximate size users actually download. Typically this is 60–80% smaller than the raw HTML.
The general recommendation is to keep your HTML document under 50 KB uncompressed. Pages under 15 KB (compressed) load extremely fast. Google's Core Web Vitals indirectly penalize large HTML payloads through metrics like LCP and FID.
No. The URL fetch mode makes a standard HTTP GET request without any authentication. Pages that require login, cookies, or JavaScript rendering (SPAs) will return an empty or incomplete HTML response.
The score is a heuristic based on HTML size, inline CSS and JS weight, number of external stylesheets and scripts, and image count. It is not a substitute for tools like Lighthouse — think of it as a quick sanity check for obvious bloat.
No. HTML paste mode runs entirely client-side in your browser. URL fetch mode passes the URL through our server only to retrieve the HTML — nothing is logged or stored after the response is returned.
A Page Size Analyzer is a developer tool that measures the total byte size of a webpage's HTML document and breaks it down into actionable components. Unlike full website auditing suites, a page size analyzer focuses on the single most critical payload: the HTML file your server delivers to the browser on the initial request. Understanding this number is foundational to web performance optimization.
When a user visits a URL, their browser first fetches the HTML document. Everything else — CSS files, JavaScript bundles, images, fonts — follows after. If your HTML is bloated, it delays the entire rendering pipeline. Every kilobyte of unnecessary HTML adds latency, especially on mobile networks where bandwidth is limited and connections are high-latency.
Page weight has a direct relationship with three key performance metrics that Google tracks as part of its Core Web Vitals: Largest Contentful Paint (LCP), Time to Interactive (TTI), and Total Blocking Time (TBT). A heavy HTML document delays the browser's ability to start parsing content, which pushes all downstream metrics later in the timeline.
Studies consistently show that users abandon pages that take more than 3 seconds to load. For mobile users, even 1–2 seconds of additional latency can mean the difference between a conversion and a bounce. Reducing HTML size is one of the highest-leverage, lowest-effort optimizations available because it requires no infrastructure changes — just cleaner markup.
You can analyze page size in several ways. Browser DevTools provide this under the Network tab — look for the document resource (type: document) and check its "Size" versus "Content" columns. The "Size" column shows the compressed transfer size, while "Content" shows the uncompressed parsed size. Our tool replicates this experience without requiring you to open DevTools manually.
The HTML paste mode is particularly useful when you're working locally or on a staging environment not exposed to the public internet. Simply copy your HTML source, paste it in, and get an instant breakdown. This makes it easy to compare sizes before and after a refactor without deploying to production first.
Our analyzer separates the HTML payload into distinct categories to help you pinpoint where size is coming from:
<style> blocks embedded in the HTML. Large inline styles often indicate that critical CSS has been over-inlined or that component styles haven't been extracted to external files.<script> blocks without a src attribute. Inline JavaScript cannot be cached by the browser, so every page view re-downloads and re-parses it.Beyond raw bytes, the number of external resources referenced in your HTML is equally important. Each external CSS file, each external JavaScript file, and each image tag represents an additional HTTP request. Even with HTTP/2 multiplexing, excessive request counts add overhead through connection negotiation, DNS lookups, and browser processing.
A well-optimized page typically has no more than 2–3 external stylesheet references and under 5 render-blocking script tags. If our analyzer shows you have 10+ external CSS files or 15+ script tags, that's a clear signal to consolidate through bundling.
Our performance score is a simple 0–100 heuristic designed for quick triage, not as a replacement for comprehensive auditing tools like Google Lighthouse or WebPageTest. The score deducts points for:
A grade of A (90–100) means your HTML document is lean and well-structured. A grade of C or below indicates meaningful opportunities for optimization that could measurably improve load time.
Once you've analyzed your page, here are the most impactful steps to reduce HTML size:
<style> blocks into .css files so they can be cached independently of your HTML.<script> content to external JS files with proper defer or async attributes.loading="lazy" on images and defer non-critical sections to reduce the initial parse burden.It's important to distinguish between HTML page size and total page weight. Page size refers only to the HTML document. Total page weight includes every resource the browser fetches: CSS files, JavaScript bundles, web fonts, images, videos, and API calls. Tools like Chrome DevTools' Network tab or WebPageTest give you total weight, which often runs into several megabytes for modern web applications.
Our tool focuses on HTML because it's the foundational document that controls everything else. A lean HTML document won't guarantee a fast page if you load 5 MB of images, but an oversized HTML document will slow down every other resource by blocking the initial render and delaying the browser's discovery of subsequent resources.
Google's crawl budget is a real consideration for large sites. If your HTML documents are unnecessarily large, Google's crawler processes fewer pages per crawl session, which can delay indexing of new or updated content. For small sites this is rarely an issue, but for e-commerce sites with thousands of product pages or news sites with high publishing frequency, HTML efficiency directly affects crawl coverage.
Additionally, page speed is a confirmed Google ranking factor. While the weight given to it is modest compared to content relevance and backlinks, it becomes a decisive tiebreaker between otherwise comparable pages. Keeping your HTML lean is one part of a holistic performance strategy that includes image optimization, CDN usage, and efficient server response times.