PeopleAreGeek
FR

Page Size Checker

Fetch a URL, weigh its HTML, and inventory every script, stylesheet, image and embed it references, with your own origins split from third parties.

This page size checker takes one URL, fetches the HTML server-side, and turns a single page weight number into something you can act on. It weighs the markup it pulled, lists every asset the document points at (scripts, stylesheets, images, media, embeds and preload hints), adds up your inline script and style bytes, flags sloppy image markup like missing width or height, then sorts your own origins from everyone else's. It scores the run against a review budget you pick (lean SEO page, tool or app page, or media-rich page), names the one thing worth your next hour, and reads the response headers so compression and cache clues sit right next to the markup. It is a first pass, not the last word: a URL list proves an asset is referenced, not what it weighs on the wire, so you still confirm the real waterfall in a browser. You can copy a plain report or a resource CSV for handoff.

Queries run through the PeopleAreGeek lookup service. We log nothing.

HTML weight and resource inventory audit

One "page weight" number used to tell me nothing about what to actually fix. Drove me a bit nuts. So this grabs your HTML, reads every asset the page points at (images, scripts, embeds, fonts, all of it), counts them up, splits your own stuff from everyone else's, then hands back a short list of what to fix first. Skinny blog post or some media-heavy monster, doesn't matter. Same treatment.

First pass. Not the last word. It weighs the markup it fetches and lists the assets that markup points at. For real transferred bytes, image payloads, Core Web Vitals, you'll still want a browser waterfall or a proper lab run.

What a page size checker can tell you before a full waterfall

"This page is heavy" gets thrown around like one number settles it. It doesn't. Your HTML, the scripts, images, embeds, fonts, every third-party tag, how caching behaves, how fast the server even bothers to answer. They all drag on you differently. They don't all break the same way either. A quick checker earns its keep when it points you at the layer worth your next hour. It won't replace a real performance profile, and honestly I'd be lying if I said it could.

So I start with what the page actually shows in its markup. It weighs the HTML I pulled for the audit, lists every asset URL the document references, adds up your inline script and style bytes, flags the sloppy image stuff like missing dimensions, then sorts your own origins from the strangers. It reads whatever response headers came back with the HTML too. Your compression and cache clues end up sitting right next to the markup instead of two tabs away.

Why HTML weight still matters on a modern page

Yeah, images and JavaScript are what people feel when a page drags. Sure. But a bloated HTML document is a tell I've learned not to wave off. Page builders. Navigation trees the size of a sitemap. The same FAQ block pasted three times, inline JSON, tracking snippets, way too much markup jammed above the fold. All of it makes the document slower to ship and slower for the browser to chew through. On an SEO page there's a bonus reason to keep it lean. When the source is tidy, your title and headings and links and structured data aren't buried under a mountain of template noise. Audits stop being a scavenger hunt.

  • Summary gives you the HTML byte count, how many assets the page references, plus the one thing I'd fix first.
  • Resource inventory is the full list. Every script, stylesheet, image, embed, preload hint it found in the markup.
  • Origin mix tells you fast whether you're leaning hard on other people's servers.
  • Markup signals is where the small stuff lives. Inline bytes, missing image dimensions, lazy loading, the document's own headers.
  • Resource CSV is your handoff sheet for when it's time to clean up a theme or a plugin or a tag manager that's gone feral.

How to use the result like a site owner

  1. Start with the top action. Then go dig into whatever blew the budget, whether that's HTML, scripts, images, or strangers' servers.
  2. On a content page, rip out the plugins and widgets and duplicate sections that don't help anyone actually read the thing.
  3. On a tool page, keep the app code that does the work. But get suspicious about doubled-up analytics, chat bubbles, and libraries loaded for some feature you barely use.
  4. On a media-heavy page, don't trash your image quality. Just serve the right dimensions and a modern format, lazy-load below the fold, and run one fewer embed than you think you need.
  5. Touched the code or swapped the theme? Prove the win with a response-time check and a real browser profile. Don't take my word for it. Don't take yours either.

What this audit does not claim

Quick honesty check. I'd rather tell you the limits than watch you trust the number too much. The byte count is the fetched HTML text, full stop. A list of asset URLs only proves they're referenced. It says nothing about what that image or script actually weighs once it's compressed and on the wire. Browser caching, your CDN's compression, the viewport, responsive images, whatever JavaScript pulls in later. Every one of those reshapes the real waterfall. I drew the line there on purpose, and maybe that's just me being cautious, but I think a tool that's honest about what it can't see beats one that pretends. You still walk away with a sharper read than a lonely page-size score ever handed you.

Frequently asked questions

Is a small HTML page automatically fast?

Nope. I've been burned by assuming exactly that. A tiny HTML file can still drag in a 2 MB hero image, a fat JS bundle, a whole ad stack, a pile of third-party widgets. Check the resource inventory first. Then go measure it in a real browser before you celebrate anything.

Why count third-party origins?

Every external host you call is another DNS lookup, another connection to set up, another privacy question. And another thing that can go down and take part of your page with it. Plenty of them earn their spot. The point isn't to nuke them. It's to actually see what you're carrying instead of inheriting it one plugin at a time without ever noticing.

Should every image be lazy loaded?

No. Lazy-loading your hero image is a classic own goal that wrecks LCP. Anything visible at the top of the page should load right away. Save lazy loading for what sits below the fold. Width, height, responsive sizing though? Those help everywhere. Top to bottom.

What is a reasonable page weight?

For a content page I try to stay under 1 to 2 MB and I sleep fine there. Images and JavaScript are almost always the bulk of it. So squeezing your images and cutting dead scripts is where the real weight comes off. Fussing over the markup barely moves the needle next to that.

Why does page size affect SEO?

Heavier page, slower load. That's just physics, and it hits your Core Web Vitals plus anyone on a phone over flaky mobile data. Google does use speed as a ranking signal. But honestly the part I care about more is this: slow pages make people bail before they convert, and you can watch it happen in your analytics.