HTML weight and resource inventory audit
Measure the fetched HTML document, inspect the resource references it advertises, count images, scripts, stylesheets, embeds and hints, split same-site from third-party origins, and turn the result into a practical performance checklist for content pages, tools and media-heavy layouts.
This is a first-pass HTML and resource-reference audit. It measures fetched markup and referenced assets; a lab test or browser waterfall is still needed for transferred bytes, image payloads and Core Web Vitals.
What a page size checker can tell you before a full waterfall
People often say a page is heavy as if one number explains the whole experience. In practice, the HTML document, scripts, stylesheets, images, embeds, fonts, third-party tags, cache behavior and server response path each matter in a different way. A quick checker is most useful when it tells you which layer deserves the next hour of work instead of pretending to replace a proper performance profile.
This tool starts with what the page exposes in its markup. It measures the HTML bytes actually fetched for the audit, inventories resource URLs referenced by the document, counts inline script and style bytes, checks image hygiene signals such as missing dimensions, and separates first-party from third-party origins. It also reads available response headers for the HTML document so compression and cache clues stay next to the markup review.
Why HTML weight still matters on a modern page
Images and JavaScript usually dominate visible slowness, but a bloated HTML document is still a warning sign. Page builders, giant navigation trees, repeated FAQ blocks, inline JSON, tracking snippets and too much above-the-fold markup can make the initial document harder to ship and parse. For SEO pages, a lean source document also makes audits easier: the important title, headings, links and structured data are less likely to hide inside a noisy template.
- Summary shows measured HTML bytes, resource references and the top action.
- Resource inventory lists the scripts, stylesheets, images, embeds and hint URLs found in markup.
- Origin mix shows whether the page depends heavily on third-party hosts.
- Markup signals highlights inline bytes, image dimensions, lazy loading and document headers.
- Resource CSV gives a handoff for a theme, plugin or tag cleanup review.
How to use the result like a site owner
- Read the top action, then inspect the category that pushed the budget: HTML, scripts, images or third-party origins.
- On content pages, remove plugins, widgets and repeated sections that do not help a reader complete the page intent.
- On tool pages, keep essential application code but question analytics duplication, chat widgets and libraries loaded outside their use case.
- On media-rich pages, protect image quality while serving correct dimensions, modern formats, lazy loading below the fold and fewer unneeded embeds.
- After code or theme changes, confirm the win with response-time checks and a real browser performance profile.
What this audit does not claim
The byte count here is for the fetched HTML text. Resource URLs tell you that assets are referenced; they do not reveal the final compressed image or JavaScript transfer cost by themselves. Browser caching, CDN compression, viewport choices, responsive images and JavaScript-loaded assets can all change a waterfall. That limit is deliberate: the tool stays honest while still giving you a sharper first pass than a lonely page-size score.
Common questions
Is a small HTML page automatically fast?
No. A small HTML document can still load a huge hero image, heavy JavaScript bundle, ads or third-party widgets. Read the resource inventory and then measure in a browser.
Why count third-party origins?
Each external dependency can add connection work, privacy implications and failure modes. Some are valuable. The point is to see them clearly instead of inheriting them by accident.
Should every image be lazy loaded?
No. Images needed immediately near the top of the page should be handled carefully. Lazy loading is often useful for below-the-fold images, while dimensions and responsive sizing matter across the page.
What is a reasonable page weight?
Aim under about 1 to 2 MB for a content page. Images and JavaScript dominate most pages; compressing images and trimming scripts gives the biggest reductions.
Why does page size affect SEO?
Heavier pages load slower, which hurts Core Web Vitals and mobile users on slow connections. Speed is a ranking factor and strongly affects bounce and conversion.
What usually makes a page too large?
Uncompressed or oversized images, heavy third-party scripts and trackers, large web fonts, and unminified CSS and JavaScript. Audit the largest requests first.
