Measure the HTML size, image/script/stylesheet counts, render-blocking scripts and compression of any page — the page-weight factors that slow you down and drag your Core Web Vitals.
⚡ Interactive demo — sample data
This sample page is moderately heavy — render-blocking scripts and missing compression are the two fixes to make first.
HTML size: 74 KB — within a healthy rangeLooks good
Images: 38 referenced — likely the largest share of total weightWarning
Measure the HTML size, image/script/stylesheet counts, render-blocking scripts and compression of any page — the page-weight factors that slow you down and drag your Core Web Vitals.
How it works
Enter your page URL
Paste any public URL and run the check. We fetch the page's HTML exactly as a browser's first request would and measure the raw document, then parse it to count every resource the page asks the browser to load.
Review the weight breakdown
You get the HTML document size in KB, the number of images, script files and stylesheet files referenced, how many of those scripts block rendering, and whether the server compressed the response. Each metric is flagged good, warn or bad with a plain-English reason.
Trim the heavy items and re-run
Defer or async non-critical scripts, combine or remove stylesheets, compress oversized images and turn on gzip or brotli on the server. Re-run to confirm the page is lighter and fewer requests block the first paint.
What we check
HTML document size (KB) — Measures the raw bytes of the HTML the server sends before images and scripts load. A bloated document — often from inline data, huge embedded markup or page-builder cruft — delays the very first byte the browser can act on. We flag documents over roughly 100 KB as worth trimming.
Image count — Counts every <img> the page references. Images are usually the single biggest share of total page weight, so a high count is an early signal that the page may be heavy and slow to finish painting, especially on mobile data.
Script file count — Counts external JavaScript files the page pulls in. Each one is a separate request the browser must fetch and execute; piles of third-party scripts (tag managers, chat widgets, trackers) add weight and main-thread work. We flag pages loading more than about 20 script files.
Stylesheet file count — Counts external CSS files. CSS is render-blocking by default — the browser won't paint until it has the stylesheets — so several separate files mean several blocking round-trips. We flag more than about 5 stylesheets as a consolidation opportunity.
Render-blocking scripts — Counts scripts loaded without async or defer. These force the browser to stop building the page, fetch and run the script, then continue — directly delaying when content appears. This is one of the highest-impact fixes for perceived speed.
Compression (gzip / brotli) — Reads the response's content-encoding to confirm the server compressed the HTML in transit. Text compresses well — often 70%+ smaller — so a missing encoding header means you're shipping far more bytes than necessary on every visit.
Common issues we catch
No compression on text responses — Text assets like HTML, CSS and JavaScript shrink dramatically with gzip or brotli, but it's surprisingly common to find it switched off. Every visitor then downloads the uncompressed file, wasting bandwidth and slowing the first byte — a one-line server fix for a big win.
A wall of render-blocking scripts in the <head> — Scripts placed in the head without async or defer halt page construction until each one finishes. The page can look frozen even though the HTML arrived quickly. Moving non-essential scripts to defer is often the fastest perceived-speed improvement available.
Third-party scripts you forgot you added — Chat widgets, A/B testing snippets, heatmaps, old ad pixels and abandoned trackers accumulate over years. Each adds requests, bytes and main-thread work — and many sites carry several that no longer serve any purpose.
Oversized, uncompressed images — A photo exported at full camera resolution can weigh several megabytes on its own. Without resizing to the displayed dimensions and using a modern format, a single hero image can outweigh the rest of the page combined.
A bloated HTML document from page builders — Drag-and-drop builders often emit deeply nested markup, inline styles and base64-embedded images directly in the HTML. The document balloons in size, slowing the initial response before any external resource even starts loading.
Many small CSS files instead of a few — Plugins and themes each ship their own stylesheet, so a page can request a dozen separate CSS files. Because CSS blocks rendering, each extra file is another blocking round-trip — consolidating them reduces the time to first paint.
Weight that only shows on real connections — A page can feel instant on office fibre and crawl on a phone on mobile data. Page weight is the root cause that desktop testing hides, which is why a byte-level breakdown matters more than how fast the page felt when you last opened it.
Where this matters
Core Web Vitals (LCP, INP, CLS) — Page weight feeds directly into Google's Core Web Vitals. Heavy images and render-blocking resources delay Largest Contentful Paint, and excess JavaScript hurts interaction responsiveness — both are part of the page-experience signals Google uses.
Google & Bing crawling — A lighter, faster page is cheaper for search engines to crawl and render. Bloated pages and heavy script execution can slow how quickly your content is discovered and indexed, especially across a large site.
WordPress, Shopify, Wix & page builders — These platforms make it easy to stack plugins, apps and builder widgets, each adding scripts and stylesheets. This tool surfaces exactly how much weight those add-ons contribute so you can prune what you don't need.
Mobile networks — Most visits now come from phones, often on slower connections. Page weight that's invisible on desktop is what makes a page feel sluggish on mobile, so trimming bytes has an outsized effect on the experience that actually matters for ranking.
CDNs & server compression — Content delivery networks and modern servers can compress and cache assets to cut transfer size. The compression check tells you whether that layer is actually doing its job or silently passing through uncompressed responses.
Frequently asked questions
What is page weight?
Page weight is the total size of everything a page downloads — the HTML document plus images, scripts, stylesheets, fonts and other resources. The heavier the page, the longer it takes to load and the more data your visitors burn, which matters most on mobile connections.
How much should a page weigh?
There's no hard limit, but lighter is always better. Trimming the HTML document, deferring scripts and compressing images all reduce load time. Focus on the biggest offenders this tool surfaces — usually large images and render-blocking scripts — rather than chasing a single target number.
What does this tool actually measure?
It measures the HTML document size in KB, counts the images, script files and stylesheet files the page references, counts how many scripts block rendering, and checks whether the server compressed the response. It's a fast, structural snapshot of what's making a page heavy.
What are render-blocking scripts?
Scripts loaded without the async or defer attribute. The browser must stop building the page, download and run each one, then resume — directly delaying when content appears. Adding defer to non-critical scripts is one of the highest-impact speed fixes you can make.
How does page weight affect SEO?
Speed is part of Google's page-experience signals through Core Web Vitals. Heavy images slow Largest Contentful Paint and excess JavaScript hurts interaction responsiveness. A lighter page tends to rank and convert better because it loads faster, especially on mobile.
Why does the tool only measure the HTML, not images?
It reads the HTML document size precisely and counts the resources the page references, which is a fast structural snapshot. It doesn't download every image, so it shows you how many images there are and what's blocking rendering rather than the full byte total of every asset.
Should I enable gzip or brotli?
Yes — if the compression check shows none detected, turning on gzip or brotli on your server compresses text responses like HTML, CSS and JavaScript in transit, often cutting their size by well over half. It's a low-effort change with an immediate effect on every visit.
How quickly will speed fixes show up?
Visitors feel a lighter page immediately. Search engines pick up the improvement the next time they re-crawl and re-measure the page, and Core Web Vitals field data updates over a rolling window, so ranking effects build over weeks rather than overnight.
This is one of several free SEO tools from Custom Web Audits.
For a complete, prioritized analysis of your whole website,
run a full audit.
