Enter a URL
The Website Size Checker measures how much data a browser has to download to fully load a given web page. Type in a URL, and the tool fetches the page the way a browser would, then adds up the size of every resource involved — the HTML document itself, external CSS files, JavaScript files, images, web fonts, and any other assets the page pulls in. The result is reported as a total page weight (typically in kilobytes or megabytes), often broken down by resource type and, in many implementations, alongside a rough request count.
This is not the same thing as "file size on the server." A page can be a tiny 3 KB HTML file that references a dozen scripts, five stylesheets, and forty images — the number that actually matters for a visitor's experience is the sum of everything the browser downloads before the page is usable, not the size of the one document you'd see if you right-clicked "View Source" and saved it.
Page weight is one of the oldest and still most reliable proxies for how a site will perform in the real world. Heavier pages take longer to download, longer to parse, and longer to render — especially on mobile connections, older devices, or anywhere bandwidth is inconsistent. Since Google folded page experience signals (including loading speed, via Core Web Vitals) into ranking considerations, and since site speed has always affected bounce rate and conversion regardless of ranking, keeping an eye on total page weight is a basic, recurring maintenance task for anyone who runs a website.
A few concrete reasons page size keeps showing up in SEO and dev checklists:
Using the tool is a two-step process: submit a URL, read the breakdown.
https://). If you check a bare domain, most tools will resolve it to the homepage, but for a real audit you should check individual URLs — a product page, a blog post, a category page — not just the homepage, since page weight varies a lot across templates.A single check gives you a snapshot. The more useful habit is checking the same page after every redesign, plugin install, or content update, since page weight tends to creep upward silently — a new hero banner here, an embedded widget there, and a page that used to load in under a second gradually turns into one of the heaviest pages on the site.
A full page-weight measurement adds together several categories of resources:
<style> blocks and linked .css files. Frameworks that ship the entire library even when only a fraction of the classes are used are a common source of CSS bloat.Most page-size checkers, this one included, measure what loads at the initial page load — not resources that only load later, such as images below the fold with lazy-loading that only fire on scroll, content loaded after a user clicks something, or assets requested by JavaScript well after the initial render completes. That's intentional: the initial page weight is what determines first-load performance, which is the number that matters most for bounce rate and Core Web Vitals. If you need to measure everything a user's session eventually downloads across an entire visit, that's a different and much more involved measurement than a single-page size check.
There's no single "correct" page size — a photography portfolio will legitimately weigh more than a text-heavy blog post — but these rough bands are a useful reference point when deciding whether a page needs attention.
| Page type | Reasonable target | Getting heavy | Common culprits when it's overweight |
|---|---|---|---|
| Text-focused blog post | Under ~1.5 MB | Over 3 MB | Unoptimized hero images, embedded social widgets, heavy web fonts |
| Landing page | Under ~2 MB | Over 4 MB | Large background videos/images, marketing pixel stacks, animation libraries |
| E-commerce product page | Under ~2.5 MB | Over 5 MB | Multiple full-size product photos, zoom/carousel scripts, review widgets, chat plugins |
| E-commerce category/listing page | Under ~2 MB | Over 4 MB | Dozens of unoptimized thumbnail images, filter/facet JavaScript |
| Homepage with heavy media | Under ~3 MB | Over 6 MB | Autoplay video, slider/carousel plugins, tracking scripts stacked from multiple tools |
These figures are practical guidelines, not hard rules, and they'll keep shifting as average connection speeds and device capabilities change. Treat them as a sanity check rather than a pass/fail grade.
Before pushing a redesign live, checking total page weight against the old version tells you quickly whether the new design got heavier — a new template with a big hero video or an extra font family can quietly double page weight without anyone noticing during design review.
If a specific page is loading slowly or scoring poorly on Core Web Vitals, checking its size is a fast first step before digging into more detailed waterfall analysis. If the page is 6 MB and your competitors' equivalent pages are 1.5 MB, that's usually enough to explain a good chunk of the speed gap on its own.
Sites that add plugins, widgets, and third-party embeds over months and years tend to accumulate weight gradually. Periodically re-checking key pages (homepage, top landing pages, top product pages) catches this creep before it becomes a real problem.
Running a competitor's equivalent page through the same checker gives you a rough sense of whether your pages are unusually heavy for your niche, which is useful context when you're trying to justify a performance-optimization sprint to stakeholders.
Checking page size before and after adding a new widget (a chat tool, a reviews plugin, a popup builder) shows you exactly how much weight that one addition brings, which is far more informative than trusting the vendor's marketing claim that it's "lightweight."
A page-size checker is a narrow, fast tool — it answers one specific question well. It's worth knowing where it fits relative to other common tools so you use the right one for the job:
| Tool type | What it tells you | What it doesn't tell you |
|---|---|---|
| Website Size Checker | Total bytes transferred, broken down by resource type | Load time, rendering behavior, Core Web Vitals scores, server response time |
| Browser DevTools Network tab | Full request-by-request waterfall, size and timing per resource, on your own connection | No standardized third-party comparison; results vary by your local connection/cache state |
| Lighthouse / PageSpeed Insights | Performance score, Core Web Vitals, actionable optimization opportunities | Doesn't summarize total page weight as clearly as a dedicated size tool; more complex output |
| GTmetrix / WebPageTest | Detailed waterfall, filmstrip of visual load progress, multiple locations/devices | More setup, more data than needed for a quick weight check |
In practice, a size checker is what you reach for when you want one number fast — before load, without configuring test locations or connection throttling. When that number flags a problem, that's the point to move on to DevTools or Lighthouse for the detailed diagnosis.
Once a check flags a page as heavier than it should be, the fixes generally fall into a handful of well-established categories:
It's worth being honest about what a tool like this can and can't do:
Treat page weight the way you'd treat any other recurring maintenance metric:
There's no universal number, but as a rough guide, a text-focused page under about 1.5–2 MB is comfortable, while anything creeping past 4–5 MB is worth a closer look, especially for pages that need to load quickly on mobile. Use the page-type table above as a starting reference rather than a strict rule.
Not directly as a standalone factor, but page weight strongly influences loading speed and Core Web Vitals metrics like Largest Contentful Paint, which are part of Google's page experience signals. A heavy page is more likely to load slowly, and slow pages tend to perform worse both for rankings tied to page experience and for user engagement metrics like bounce rate.
The HTML file itself might genuinely be small — a few kilobytes. The total page size reported by this tool includes every resource the browser has to download to render that page: linked CSS, JavaScript, images, fonts, and embedded content. All of that combined is almost always much larger than the raw HTML document alone.
No — it measures total data transferred, not load time. Page weight is one of the biggest factors influencing load time, especially on mobile connections, but actual load time also depends on server response time, connection speed, caching, and how efficiently resources are loaded (in parallel vs. blocking). For load-time measurement specifically, use a dedicated speed test that includes timing and waterfall data.
Typically not in the initial-load total, since lazy-loaded assets are designed to defer downloading until the user scrolls near them. That's actually the intended benefit of lazy loading — it keeps the initial page weight lower even though the full page, if a user scrolled through all of it, would end up downloading more.
A few common reasons: dynamic content (rotating banners, personalized recommendations, A/B tests) can serve different assets on different requests; a CDN or cache may serve a slightly different cached version; and third-party scripts (ads, trackers) can load different payloads depending on what they decide to serve at request time. Small fluctuations are normal — consistent, large swings are worth investigating.
Both, but individual pages matter more for most SEO work. Homepages often get disproportionate optimization attention while deeper pages — product pages, blog posts, category pages — quietly carry more weight and receive more organic traffic in aggregate. Check your highest-traffic and highest-value pages specifically, not just the homepage.