Webpage Size
Checker Free

What Is the Ideal Webpage Size for SEO?

Google recommends keeping your HTML document under 100 KB uncompressed. This applies to the HTML source only, not counting external images, scripts, and stylesheets. The reason is straightforward: HTML is parsed by the browser before anything else can happen. A large HTML document delays every subsequent rendering step, worsening LCP, FCP, and TTFB all at once.

In practice, most well-optimised pages for competitive Google rankings sit between 30 KB and 80 KB of HTML. Pages bloated past 200 KB are typically suffering from large inline JavaScript blocks, server-side rendered JSON data embedded directly in the page, excessive inline CSS, large SVG icons, or repeated template markup. Use this webpage size checker to see exactly which category is adding the most weight to your page.

For total page weight including all resources (images, fonts, scripts), the HTTP Archive reports the median desktop web page weighs around 2.3 MB in 2024. Top-ranking pages on competitive Google searches consistently come in lighter. Aim for total page weight under 1 MB on desktop and under 500 KB on mobile.

GZIP vs Brotli: Which Compression Should You Use?

Both GZIP and Brotli compress text-based files before they are sent over the network, dramatically reducing the amount of data transferred. GZIP has been the standard for over two decades and is supported by every web server and CDN. It typically achieves 60 to 80% compression on HTML, CSS, and JavaScript. A 200 KB HTML page transfers as around 40 to 60 KB with GZIP enabled.

Brotli (developed by Google in 2015) achieves 15 to 25% better compression ratios than GZIP at comparable speeds. It is supported by all modern browsers and major CDNs. For maximum compression, use Brotli for static assets and GZIP as a fallback for older clients.

If this webpage size checker reports that compression is not enabled on your server, this is the single highest-impact, lowest-effort fix available. For Apache, add it to .htaccess using mod_deflate or mod_brotli. For nginx, add gzip on; to your server block. Most CDNs (Cloudflare, Fastly, AWS CloudFront) enable GZIP and Brotli by default. There is no valid reason for a production website to be serving uncompressed HTML in 2025.

DOM Size, Inline Code, and HTML Bloat

Three of the most common causes of excessive webpage size that developers miss: DOM element count, inline JavaScript, and inline CSS. Google recommends keeping DOM element count under 1,500 nodes. Pages with 3,000 or more DOM elements take significantly longer to style-calculate and paint, slowing both FCP and LCP.

Large inline JavaScript blocks are particularly damaging because they cannot be cached separately. Every time a user visits the page, the full inline script downloads again as part of the HTML. If you have more than 40 KB of inline JS, extracting it to an external .js file with a long cache lifetime will reduce your page size for every subsequent visit. Check your DOM Depth Checker for a detailed DOM complexity analysis.

Large inline CSS has the same caching problem but also delays FCP because the browser must parse all inline CSS before it can render the first pixel. The exception is Critical CSS: a small block of CSS (under 14 KB) covering above-the-fold styles is genuinely beneficial for LCP. Everything else should be in an external cached stylesheet.

JavaScript Bloat: The Biggest Driver of Page Weight in 2025

JavaScript is consistently the largest single contributor to total page weight for most websites. The HTTP Archive reports the median web page loads over 500 KB of JavaScript. Each external script file adds an HTTP request, a download, a parse cycle, and a compile step before any of it executes. On mid-range mobile devices, each 100 KB of JS adds approximately 350ms to Time to Interactive (TTI).

The most common sources of JS bloat: unused third-party libraries loaded in full when only a small function is needed, multiple analytics and tag manager scripts each loading additional libraries, large UI frameworks like full React or Vue bundles for mostly static pages, and A/B testing and personalisation scripts that load synchronously and block rendering.

Use our JavaScript Dependency Detector to find which scripts are render-blocking and adding the most weight to your pages. The combination of a webpage size checker for HTML weight and a JS dependency audit gives you a complete picture of your page's total weight problem.

How Page Size Affects Google AI Overviews, ChatGPT and LLM Indexing

Webpage size is not just a Core Web Vitals concern in 2025. AI search engines including Google AI Overviews, Perplexity, ChatGPT browsing, Claude, and Gemini all crawl web pages to build their knowledge. These AI crawlers operate with time and memory budgets per fetch. Pages that are very large, slow to respond, or heavy with uncompressed HTML are more likely to be only partially fetched or deprioritised by AI crawlers.

A well-optimised, lean webpage is read more completely and more accurately by both Googlebot and AI crawlers. For AEO (Answer Engine Optimisation), page size matters because a faster, lighter page means the AI crawler gets to your structured content (FAQ schema, HowTo schema, article markup) sooner in the fetch process. Add Schema.org markup to your pages and ensure your robots.txt explicitly allows GPTBot, ClaudeBot, PerplexityBot, and Googlebot-Extended to crawl your content.

Images, iframes, and the Hidden Page Weight You Cannot See in HTML

While this webpage size checker measures your HTML document weight, images and iframes are typically the largest contributors to total page weight. Images account for 40 to 60% of total bytes on most websites. Three changes deliver the most impact: convert to WebP or AVIF (25 to 50% smaller than JPEG/PNG), add loading="lazy" to all below-the-fold images (reduces initial page weight by 30 to 60% on image-heavy pages), and always set explicit width and height on every image to prevent CLS.

Iframes are often overlooked as page weight contributors. A single YouTube embed loads a full browser context with its own scripts, stylesheets, and network requests. Using a lightweight facade (a static image that becomes the iframe only when clicked) can eliminate several hundred KB of iframe weight on the initial load. Use our Image ALT Tag Checker for a complete image SEO audit alongside your page size check.