How to Reduce Large Page Size (Cut Page Weight)
A "large page size" warning means the total download weight of your page (HTML, CSS, JavaScript, images, fonts, and other assets) is heavier than it needs to be. Oversized pages load slowly on mobile and metered connections, hurt Core Web Vitals like LCP, and burn crawl and render budget for both Googlebot and AI crawlers. The fix is systematic: find the biggest offenders (usually images and JavaScript), compress and modernize them, defer what isn't needed for first paint, and turn on compression at the server. Most sites can cut page weight substantially without touching the design.
What this means
Page size (or "page weight") is the total number of bytes a browser must download to fully render your page: the HTML document plus every asset it pulls in, including CSS files, JavaScript bundles, images, web fonts, videos, and third-party embeds. Our audit flags this when that total crosses a threshold where load performance predictably degrades on typical mobile hardware and connections.
Google publishes no official maximum page size. In practice, many performance engineers treat transferred weight above roughly 2-3 MB as heavy, and lean pages often land well under 1 MB. What matters is the transferred (compressed) size over the wire, not the uncompressed size on disk. A 4 MB page that compresses down to 900 KB is far healthier than a 1.5 MB page served with no compression.
The number the audit reports is the sum of all resources loaded for the URL, not the size of a single HTML file. Usually one or two resource types dominate, most often a handful of unoptimized images or a bloated JavaScript bundle, and fixing those few files resolves the warning.
Why it matters
Heavy pages are slow pages, and slowness shows up in the metrics Google actually measures. A large payload inflates Largest Contentful Paint (LCP), because the browser has to download and decode more before it can paint the main content. Google's "good" threshold is an LCP under 2.5 seconds. Big JavaScript bundles also block the main thread, which worsens Interaction to Next Paint (INP), the responsiveness metric Google considers "good" under 200 milliseconds. Page weight is not a standalone ranking factor, but it is the root cause behind several Core Web Vitals failures that feed into page experience signals.
The cost is worst where most traffic lives: mobile devices on cellular or throttled connections, and users on data caps. Every extra megabyte is a longer wait and a higher chance of a bounce before your content appears. Google indexes the mobile version of your site first, so a page that feels fine on office broadband can still be flagged.
For AI answer engines, page weight matters differently. Crawlers such as GPTBot and OAI-SearchBot (ChatGPT), PerplexityBot, and Google's AI systems fetch your pages to extract answers, and many work primarily from the raw HTML rather than executing a full render. If your meaningful content is buried under megabytes of client-side JavaScript, or the fetch times out on a bloated page, your answer-relevant text may never get parsed. A lean page whose content lives in server-rendered HTML is faster for humans and more reliably ingestible by AI crawlers, which improves your odds of being cited rather than skipped.
How to fix it
- 1
Find what's actually heavy before touching anything
Open Chrome DevTools, go to the Network tab, and hard-reload the page. Sort by the Size column and look at the largest transferred resources. Almost always one resource type dominates, usually images or a JavaScript bundle. The status bar at the bottom shows total transferred vs. uncompressed size, which tells you immediately whether compression is even on. Don't optimize blindly. Spend your effort on the two or three files that account for most of the weight.
- 2
Compress and modernize images (usually the biggest win)
Images are the single largest contributor on most pages. Convert JPEG and PNG assets to WebP or AVIF, which typically cut file size significantly at the same visual quality. Resize images to the largest dimension they actually display at; a 4000px-wide photo shown in an 800px column is wasted bytes. Serve responsive sizes with srcset so phones download small versions, and add loading="lazy" to below-the-fold images so they don't block the initial load. See the code example for the full pattern.
- 3
Cut and defer JavaScript
Large JS bundles are the second-biggest offender and the one that most hurts INP. Audit third-party scripts first: chat widgets, A/B testing tools, analytics, and ad tags are frequent bloat. Remove anything you don't actively use. For scripts that must stay, add the defer attribute so they don't block rendering, and load non-critical third parties (chat, heatmaps) only after user interaction. If you use a bundler, enable code-splitting so each page ships only the JavaScript it needs instead of one giant bundle.
- 4
Turn on Brotli or Gzip compression at the server
Text-based assets (HTML, CSS, JS, SVG, JSON) compress dramatically, often by 70-80%. Brotli generally beats Gzip and is supported by all modern browsers. On Nginx, Apache, or a CDN like Cloudflare, this is a config toggle, not a code change. Check whether it's already on by looking for a content-encoding: br or content-encoding: gzip response header in DevTools. If that header is missing on your HTML or JS responses, enabling compression alone can resolve the warning on text-heavy pages.
- 5
Trim CSS, fonts, and unused code
Ship only the CSS the page uses. The Coverage tab in DevTools (or a tool like PurgeCSS) shows how much of your stylesheet is dead weight; framework-heavy sites often load stylesheets that are mostly unused. For web fonts, subset to the character sets and weights you actually use, serve WOFF2 (the smallest widely supported format), and add font-display: swap so text renders immediately. Minify CSS and JS to strip whitespace and comments; most build tools and CDNs do this once enabled.
- 6
Re-run the audit and verify on mobile
After each change, re-test with a real performance tool such as PageSpeed Insights, DevTools Lighthouse, or WebPageTest, using mobile emulation with throttling since that mirrors how Google evaluates you. Confirm the transferred page size dropped and that LCP improved. Because Google uses mobile-first indexing, validate the mobile number, not just desktop. Keep iterating on the largest remaining resource until you're comfortably under the threshold.
Example
<!-- Serve AVIF/WebP with a JPEG fallback, plus responsive sizes -->
<picture>
<source
type="image/avif"
srcset="hero-480.avif 480w, hero-960.avif 960w, hero-1440.avif 1440w"
sizes="(max-width: 768px) 100vw, 960px" />
<source
type="image/webp"
srcset="hero-480.webp 480w, hero-960.webp 960w, hero-1440.webp 1440w"
sizes="(max-width: 768px) 100vw, 960px" />
<img
src="hero-960.jpg"
srcset="hero-480.jpg 480w, hero-960.jpg 960w, hero-1440.jpg 1440w"
sizes="(max-width: 768px) 100vw, 960px"
width="960" height="540"
loading="lazy" decoding="async"
alt="Descriptive alt text" />
</picture>
<!-- Defer non-critical JavaScript so it doesn't block the initial render -->
<script src="/js/analytics.js" defer></script>Responsive, lazy-loaded, modern-format image: the single highest-impact fix for page weight. The browser picks the smallest appropriate file, falls back to JPEG for old browsers, and skips loading until the image nears the viewport.
Platform-specific steps
Yoast and Rank Math don't control page weight directly, so pair them with a dedicated performance stack. Install an image optimizer (ShortPixel, Imagify, or Smush) to auto-convert uploads to WebP and compress them. Add a caching and optimization plugin (WP Rocket, LiteSpeed Cache, or the free Autoptimize plus a caching plugin) to minify CSS/JS, defer JavaScript, and enable Gzip or Brotli. WordPress adds loading="lazy" to images natively, but confirm your theme isn't overriding it. Audit active plugins and remove any that inject heavy scripts you don't need.
Shopify serves images through its CDN and can generate WebP or AVIF automatically. Use the image_tag filter (or image_url with a widths list) in Liquid so it builds a responsive srcset and sets width/height for you. The heaviest weight on Shopify usually comes from apps, since each installed app can inject its own JS and CSS on every page. Audit your apps, remove unused ones, and avoid stacking multiple review, popup, and upsell apps that each load their own bundle.
Both platforms handle image compression, modern formats, and lazy loading automatically, so your main lever is what you add. Keep hero images reasonably sized before uploading, limit heavy elements like background video and large galleries above the fold, and remove unused third-party embeds and custom code blocks. On Squarespace, prefer built-in gallery blocks over embedded external widgets. You have less low-level control here, so the discipline is content restraint rather than config.
Cloudflare can cut page weight at the edge without touching your origin. Brotli compression is enabled by default on current plans under Speed settings. Auto Minify for HTML/CSS/JS has been deprecated in favor of doing minification in your build, so minify at the source rather than relying on the toggle. On paid plans, Polish converts images to WebP or AVIF and strips metadata, and Mirage optimizes image loading on mobile. These edge features stack on top of whatever your CMS does.
In Next.js, use the built-in next/image component, which handles responsive srcset, lazy loading, and on-the-fly AVIF/WebP conversion. Use code-splitting and dynamic imports for heavy client components so they don't ship in the initial bundle. Gzip is on by default when serving with next start or a custom server; Brotli is handled by your CDN or reverse proxy (Vercel does gzip and Brotli automatically at the edge). For raw HTML sites, apply the responsive <picture> pattern above manually, add defer to scripts, and configure Gzip or Brotli in your Nginx or Apache config.
Frequently asked
There is no official limit from Google, but aim to keep total transferred (compressed) weight under about 1-2 MB, with lean content pages often under 1 MB. What matters most is real-world load speed on mobile. If your Largest Contentful Paint stays under 2.5 seconds on a throttled 4G connection, your page size is in good shape regardless of the exact byte count.
Not directly as its own ranking signal, but it is the root cause of Core Web Vitals problems that do influence rankings. A heavy page inflates LCP and can worsen INP, and those feed Google's page experience signals. Slow pages also raise bounce rate and cut engagement, which affects rankings indirectly. Fixing page weight is one of the highest-leverage speed improvements available.
Unoptimized images are the most common culprit: full-resolution photos served without compression or WebP/AVIF conversion. The second-biggest cause is JavaScript, especially third-party scripts like chat widgets, ad tags, and analytics stacked on top of a heavy framework bundle. Web fonts, autoplay video, and missing server-side compression round out the usual list. Check your Network tab to see which applies to you.
Our audit and most modern tools report the transferred size, which is what actually goes over the wire after Gzip or Brotli compression. That is the number that determines real load time. If your text assets are not being compressed, the transferred size equals the raw size, which is often the fastest thing to fix. Look for a content-encoding response header to confirm compression is active.
It can. Many AI crawlers fetch raw HTML and may not fully execute heavy JavaScript, so content buried in oversized client-side bundles can be missed. Very large pages can also time out or get truncated during fetching. Keeping pages lean and serving your key content in server-rendered HTML makes them more reliably parseable by ChatGPT, Perplexity, and Google's AI systems, improving your odds of being cited.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.