Page Weight Explained: How Big Is Too Big for a Web Page?

There is no official size limit for a web page, but a page is too big when its weight makes it slow for real visitors, especially on mobile connections. As a practical rule of thumb, aim to keep a typical content page under about 1 MB transferred and the main HTML document well under 100 KB, and treat anything over a few megabytes as a sign that images, scripts or fonts need attention. What ultimately matters is how fast the page loads and responds, which you measure with Core Web Vitals, not bytes alone.

Key takeaways

• Page weight is the total size of everything a page downloads: HTML, CSS, JavaScript, images, fonts and video.
• No search engine publishes a "maximum page size" for ranking. Speed and user experience are what count.
• Googlebot only processes the first 15 MB of an HTML file, a limit almost no real page should get near.
• Images are usually the largest share by bytes; JavaScript is usually the most expensive per byte.
• Set a budget, measure transferred (compressed) size, and check Core Web Vitals alongside it.

What counts as page weight

When someone opens a page, the browser downloads the HTML document and then every resource it references. Page weight is the sum of all of it:

• HTML: the document itself, including any inline CSS, scripts or SVG.
• CSS: stylesheets, including ones from themes and plugins you may not use.
• JavaScript: your own scripts, frameworks, and third-party tags such as analytics, chat widgets, ad scripts and embeds.
• Images: photos, logos, icons and background images.
• Fonts: each weight and style is a separate file.
• Media: video and audio, if they preload.

There are two numbers to know. Transferred size is what actually travels over the network after compression such as gzip or Brotli. Resource size is the uncompressed size the browser has to parse. A 300 KB JavaScript file might transfer as 90 KB, but the browser still has to parse and run all 300 KB.

Why weight matters

• Load time. More bytes take longer to download, especially on slower mobile networks.
• Processing cost. JavaScript must be parsed, compiled and executed. On lower-end phones, heavy scripts can block the page from responding to taps, which hurts Interaction to Next Paint (INP).
• Data costs. Many visitors pay for mobile data or have capped plans.
• Core Web Vitals. Google's page experience signals include Largest Contentful Paint (LCP), INP and Cumulative Layout Shift (CLS). The "good" thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1. A heavy hero image directly delays LCP.

Google has said page experience is one of many signals and that great content can still rank on a slower page. Treat speed as something that helps users and conversions first, and rankings second.

How big is too big? Practical budgets

These are working targets, not official limits. Adjust them for your audience and the type of page.

A product gallery or photography portfolio can reasonably be heavier than a blog post, as long as images below the fold load lazily and the first view loads fast. A simple text article weighing 5 MB, on the other hand, almost always has a fixable problem.

The 15 MB Googlebot limit

Google documents that Googlebot fetches and processes only the first 15 MB of an HTML or supported text file, with each referenced resource such as CSS or JavaScript fetched separately under the same limit. Content after that point is not considered for indexing. In practice this only matters for unusual pages such as giant inline data dumps or endless single-page archives. If your HTML is anywhere near that size, you have a usability problem long before an indexing one.

How to measure your page weight

1. Run the URL through the Page Size Checker to see the size of the HTML document.
2. Open your browser's developer tools, go to the Network tab, disable cache and reload. The status bar shows total requests, transferred size and resource size. Sort by size to find the biggest files.
3. Run the Page Speed Checker, which uses Google PageSpeed Insights, to see Core Web Vitals and Lighthouse suggestions such as "Avoid enormous network payloads", "Properly size images" and "Reduce unused JavaScript".
4. Test on mobile. Throttled mobile results are a better reflection of many real visitors than a fast office connection.

Where the weight usually comes from, and how to cut it

Images

• Resize images to the largest size they are actually displayed at. A 4000-pixel-wide photo shown at 800 pixels wastes most of its bytes.
• Use modern formats: WebP is widely supported, and AVIF often compresses further.
• Serve responsive sizes with srcset so phones get smaller files.
• Add loading="lazy" to images below the fold, but not to the main hero image, which should load right away.
• Set width and height attributes to prevent layout shift.

<img src="/img/desk-800.webp"
     srcset="/img/desk-400.webp 400w, /img/desk-800.webp 800w, /img/desk-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 800px"
     width="800" height="533" alt="Oak standing desk at sitting height"
     loading="lazy">

JavaScript

• Audit third-party tags. Each chat widget, heatmap, social embed and ad network adds weight and main-thread work. Remove anything nobody looks at.
• Load non-critical scripts with defer or async.
• On WordPress and similar platforms, check whether plugins load scripts on every page when they are only needed on one.
• Replace heavy embeds (such as video players) with a lightweight preview that loads the full player on click.

CSS and fonts

• Remove unused CSS from themes and page builders where you can.
• Limit font families and weights. Two families with two weights each is usually plenty.
• Use WOFF2 and consider subsetting fonts to the characters you need.
• Use font-display: swap so text appears while fonts load.

HTML

• Avoid inlining large SVGs, base64 images or big JSON blobs in the document.
• Paginate or lazy-load very long lists such as comments and product grids.
• Strip leftover page-builder markup and empty wrapper elements.

Server settings

Confirm text resources are compressed. A response header like this shows Brotli is active:

HTTP/2 200
content-type: text/html; charset=UTF-8
content-encoding: br
cache-control: public, max-age=600

Set long cache lifetimes for static assets with versioned file names, so returning visitors do not download the same files again.

A quick way to find the biggest culprit

If you only have half an hour, do this: open the Network tab, reload with cache disabled, and sort by transferred size. Note the five largest files and who owns them: your theme, a plugin, a third-party service, or your own uploads. Fix or remove the largest one first, then measure again. On many sites, one oversized image or one unnecessary embed accounts for a large share of the total, and removing it does more than dozens of small tweaks.

Common mistakes

• Uploading photos straight from a phone or camera without resizing.
• Autoplaying background videos on mobile.
• Lazy-loading the hero image, which delays LCP.
• Judging speed only from a fast desktop connection.
• Adding a new tag for every marketing tool and never removing old ones.

Quick checklist

• Total transferred weight measured on mobile; aim for about 1 MB on content pages.
• Largest image resized, compressed and served in WebP or AVIF.
• Below-the-fold images lazy-loaded; hero image not lazy-loaded.
• Unused third-party scripts removed; the rest deferred.
• Compression and caching enabled on the server.
• Core Web Vitals checked after every major change.