Page Size Checker

Paste any URL into the Page URL field above and hit check. The page size checker fetches the URL, reads the response headers, and returns the raw HTML document size, the gzip or brotli wire size, response time in milliseconds, the Content-Encoding and Cache-Control values, and a count of every external CSS, JS, image, font, and iframe declared. It estimates total page weight using Web Almanac 2024 medians (2.4 MB median, 5 MB at p75) and flags whether you sit lean, average, or bloated. Chrome DevTools shows the same numbers in the Network tab, but you have to load the page, clear cache, hard reload, and read across multiple panels. This tool gives the same answer in two seconds against any public URL.

Page size is the sum of every byte the browser downloads to render the page: the HTML document plus every CSS file, JS file, image, font, video, and iframe asset. The most useful number is the compressed wire size, since that is what crosses the network. To calculate manually, open Chrome DevTools, switch to Network, hard-reload with cache disabled, and read the bottom bar where Chrome prints requests and total transferred bytes. The checker above does the same arithmetic for the HTML doc directly and estimates total weight from declared assets using Web Almanac 2024 medians, so you do not have to wait for every sub-resource to finish.

Use the field above. Drop the URL into Page URL, hit check, and read the response card. The checker reports HTML doc bytes, gzip wire bytes, response time, encoding, cache headers, and the asset request inventory by type. It benchmarks the estimated total against Web Almanac 2024 medians and labels the page green, amber, or red. For a deeper render audit, run the google-crawler-simulator which executes JavaScript and shows the post-render DOM, then run the alt-text-checker on the image inventory. The combination tells you exactly which assets to compress, defer, or remove first.

Aim for under 1.5 MB total weight on landing and conversion pages. The Web Almanac 2024 measured the median page at 2.4 MB and the p75 at 5 MB, with the p90 above 9 MB. Pages under 1 MB pass the 2.5-second LCP threshold 82% of the time on 4G mobile. Pages above 3 MB pass it only 38% of the time. Within the budget, keep HTML under 100 KB compressed, JS under 300 KB compressed, CSS under 60 KB compressed, and the largest single image under 200 KB. The checker flags pages that exceed those thresholds. Re-check after every deploy because third-party scripts and CMS plugins routinely add weight without anyone noticing.

LCP measures how long the largest visible element takes to render. On most pages that element is a hero image, a banner video frame, or a large headline block. Heavy pages delay LCP because render-blocking CSS and JS in the head push the paint later, the LCP image itself is often unoptimized, and network contention starves the LCP request of bandwidth. Google's threshold is 2.5 seconds. The 2024 HTTP Archive data shows pages above 3 MB miss it 62% of the time on mobile. Fix LCP by preloading the hero image, serving it as AVIF or WebP, deferring non-critical JS with defer or async, and trimming critical CSS. Re-run the checker after each change.

Both are text-compression algorithms applied at the HTTP layer. Gzip has been the web standard since the 1990s and is supported by every browser. Brotli was released by Google in 2015 and ships in 96% of browsers as of 2026. Brotli compresses text 15-25% smaller than gzip on average for HTML, CSS, and JS, with the gap widest on highly repetitive markup. Most CDNs (Cloudflare, Fastly, CloudFront) enable brotli by default for static text and fall back to gzip for older clients. The checker reports the actual Content-Encoding your server returned. If it shows gzip or empty, switch your CDN to brotli for an immediate 15-25% drop in text weight with no code change.

Tackle the heaviest categories first. Images are usually the biggest line item: convert hero photos to AVIF with a WebP fallback (AVIF averages 50% smaller than JPEG at the same quality), resize to actual display dimensions, and lazy-load anything below the fold with loading="lazy". JavaScript is next: code-split by route, defer third-party scripts until after first paint, and remove unused dependencies. CSS: purge unused selectors with PurgeCSS or Tailwind's JIT, inline critical CSS in the head, and load the rest async. Fonts: subset to the glyphs you use and self-host with font-display: swap. A typical bloat audit cuts total weight 40-60% in the first pass.

Yes, severely. On a fast 4G connection (12 Mbps), a 5 MB page takes about 3.5 seconds to download before render starts. On a slow 3G connection (1.6 Mbps), the same page takes 25 seconds. Google's Lighthouse simulates a "Slow 4G" profile precisely because real-world mobile networks are slower than carrier marketing suggests. The 2024 Web Almanac found 53% of mobile users abandon pages that take longer than 3 seconds to load. Heavy pages also drain metered data plans on a single visit. Aim for under 1 MB on mobile-first templates and pair the checker with the google-crawler-simulator to confirm the mobile bot sees the same lean payload.

Use AVIF as the primary format with a WebP fallback for the 4% of browsers that lack AVIF support. AVIF compresses photos 50% smaller than JPEG at equivalent visual quality and 20-30% smaller than WebP. For a 400 KB hero JPEG, the AVIF version typically weighs 90-130 KB. Use the <picture> element with <source type="image/avif"> and <source type="image/webp"> then a JPEG <img> fallback. For icons and simple graphics, use SVG: it scales infinitely, weighs under 5 KB for most icons, and compresses well with brotli. Avoid PNG except for screenshots that need lossless transparency. Replace GIF with a muted autoplay MP4 or WebM, which weighs 90% less.

Yes. A full font weight from Google Fonts or Adobe Fonts often weighs 80-120 KB because it includes every Latin, Cyrillic, Greek, and Vietnamese glyph plus the full punctuation set. Most sites use only Latin basic. Subsetting drops the file to 18-25 KB, a 75-85% saving per font. Tools like glyphhanger or Fontsource handle subsetting automatically. Self-host the subsetted file with font-display: swap so text renders immediately in a fallback font and re-paints when the custom font loads. Limit total weights to two or three (one body, one heading, optional one display). Each extra weight is another 18-25 KB plus a render-blocking request unless preloaded.

Run a CSS purge tool against your production build. PurgeCSS scans HTML and JS templates for class names and deletes any selector in your CSS that is never referenced. Tailwind's JIT compiler does this automatically. For hand-written CSS, frameworks like Next.js, Astro, and SvelteKit run a purge step at build time. The savings are usually dramatic: a Bootstrap site that ships the full 200 KB framework can drop to 8-15 KB after purging. Inline critical CSS for above-the-fold content in the head (typically 10-15 KB) and load the rest with <link rel="stylesheet" media="print" onload="this.media='all'">. Re-check with the size checker, then run the h1-checker to confirm the leaner HTML still has a valid heading structure.

Lazy loading defers the download of off-screen assets until the user scrolls near them. The native HTML attribute loading="lazy" works on <img> and <iframe> in 95% of browsers and requires zero JavaScript. On a long article page with 30 images, lazy loading typically defers 25 of them, cutting initial payload by 60-80% and dropping LCP by 1-2 seconds. Apply it to every image and iframe below the fold, but never to the LCP image itself, since lazy loading the hero delays the metric you are trying to improve. Combine with image format conversion (AVIF or WebP) for compounding wins. The checker flags pages with high image counts; if you see 40+ images on a single page, lazy loading is your biggest available win.

HTML doc size is the bytes of the HTML response itself: the markup the server returned before the browser fetched any sub-resources. Total page weight is the sum of the HTML doc plus every CSS file, JS file, image, font, video, and iframe the page loads. A page can have an 8 KB HTML doc and a 6 MB total weight if it loads heavy images and scripts. Or it can have a 250 KB HTML doc full of inline content and a 400 KB total. The checker reports HTML doc size directly from the response and estimates total weight from the declared asset count using Web Almanac 2024 medians. The HTML doc number matters most for crawl budget; total weight matters most for LCP.

Cache-control headers tell the browser how long to keep an asset before re-requesting it. A header of cache-control: public, max-age=31536000, immutable tells the browser to keep the file for one year and never revalidate. Repeat visitors download zero bytes for that asset. The checker reports the Cache-Control value on the HTML response so you can verify your CDN configuration. HTML itself should usually be short-cached (300-600 seconds) since content updates frequently. Static assets (JS, CSS, fonts, images) with hashed filenames should be cached one year because a content change creates a new filename. Without proper caching, every page load is a cold load.

Content-Encoding is the HTTP response header that tells the browser how the body was compressed. Common values are gzip, br (brotli), deflate, zstd, or empty (uncompressed). The checker reports whatever your server returned. If it shows gzip on a text response, you are saving 70-80% of bandwidth versus uncompressed. If it shows br, you save an additional 15-25% on top of gzip. If it is empty on an HTML, CSS, or JS response over 5 KB, your server or CDN is misconfigured and every visitor pays the full uncompressed weight. Binary formats (JPEG, PNG, WebP, AVIF, MP4) are already compressed at the format level and typically return empty Content-Encoding.