Page Weight: How to Reduce Page Size for Mobile

Updated October 17, 2026 · Covers: The page is too heavy

What it means

Page weight is the total amount of data a browser downloads to show a page: the HTML plus every image, stylesheet, script, font, video segment and third-party tag it requests during loading. What matters for visitors is the transfer size — the bytes that actually travel over the network, after compression. A 600 KB JavaScript file served with Brotli compression might transfer as roughly a quarter of that, while an already-compressed JPEG transfers at about its file size.

Weight isn't the same as speed. A light page can still be slow because of a slow server or render-blocking scripts, and a heavy page with lazy-loaded images can feel quick. But on mobile networks, every extra megabyte has to come through a connection that may be slow, congested or metered.

Why it matters

• Slower loading on mobile data. On a weak 4G signal or a crowded network, large downloads directly delay when content becomes usable, and they compete with the files the first screen actually needs.
• Visitors pay for it. Many people have limited data plans or pay per megabyte. A page that costs them data for content they never scroll to is a poor deal.
• More work for the phone. Big JavaScript bundles must be parsed and executed, and large images decoded, which costs time and battery on mid-range and older devices.
• Knock-on effects. Heavy pages often have slow Largest Contentful Paint, because the hero image fights for bandwidth with everything else.

How MobileCheck measures it

For each device, MobileCheck adds up the transfer sizes the browser reports for the page and every resource it loaded during our check, and counts the requests. If the total is over 3 MB, the report shows The page is too heavy, with the size and number of requests.

3 MB isn't an official limit; it is a practical warning line for a single mobile page. Many well-built pages come in well under it. Keep in mind:

• The number reflects one load in a fresh browser with an empty cache, which is what a first-time visitor downloads.
• Files requested later, such as images further down that are lazy-loaded only when someone scrolls, may not be included.
• Browsers hide exact sizes for some third-party files that don't opt in to sharing timing data, so the real total can be a bit higher than reported.
• Weight can differ between devices, because responsive images send different files to different screens.

How to audit it

Open the page in Chrome DevTools with device emulation on, go to the Network panel, tick "Disable cache" and reload. The bottom bar shows the number of requests and the amount transferred. Sort by the Size column to find the largest files, and filter by type (Img, JS, Font, Media) to see which category dominates. Use the Coverage panel (from the command menu) to see how much of each CSS and JavaScript file is actually used on the page; large unused portions are good candidates for removal or splitting.

On most content sites the biggest wins are images and third-party scripts. Start there before micro-optimising your own CSS.

How to fix it

Images

Compress images and use modern formats (AVIF or WebP), and resize them to the largest size they are actually displayed at. Serve different sizes to different screens with srcset and sizes, and lazy-load images below the first screen. Keep the first-screen image loading normally so it isn't delayed.

<img src="/img/gallery-640.webp"
     srcset="/img/gallery-640.webp 640w, /img/gallery-1280.webp 1280w"
     sizes="(max-width: 700px) 100vw, 640px"
     width="1280" height="853"
     loading="lazy" alt="Kitchen after renovation">

The width and height attributes also prevent content from jumping; see the layout shift guide.

Video

Autoplaying background videos are often the single heaviest item on a page. Give videos a lightweight poster image and tell the browser not to download the video until it is played:

<video controls preload="none" poster="/img/demo-poster.webp"
       width="1280" height="720">
  <source src="/video/demo.mp4" type="video/mp4">
</video>

For embedded players from video platforms, consider showing a thumbnail first and loading the player only when someone taps it, since the embed itself can bring in a lot of script.

JavaScript

• Review third-party tags. Analytics, chat widgets, A/B testing, social embeds and ad scripts add up fast. Remove the ones nobody uses, and load the rest with defer or after the page is interactive.
• Split your code. Use your bundler's code splitting and dynamic import() so each page loads only the code it needs.
• Drop heavy dependencies when a small function or a native browser feature does the job.

Fonts

Use WOFF2, the most compact web font format. Subset fonts to the characters and languages you actually use, and limit the number of weights and styles. A variable font can replace several separate files if you need many weights.

@font-face {
  font-family: "Brand";
  src: url("/fonts/brand-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF;
  font-display: swap;
}

Subsetting too aggressively can leave characters missing; the web font guide explains how to spot that.

Compression and caching

Make sure your server or CDN compresses text files (HTML, CSS, JavaScript, SVG, JSON) with Brotli, or gzip as a fallback. Check the content-encoding response header in the Network panel. Images and video are already compressed, so they don't benefit. Then set long cache lifetimes for versioned static files so returning visitors don't download them again:

Cache-Control: public, max-age=31536000, immutable

Caching doesn't reduce the first visit, which is what our check measures, but it makes every later page view much lighter.

How to check the fix

1. Run the free mobile check again and compare the page size and request count for each device.
2. Repeat the DevTools Network audit with the cache disabled to confirm the largest files are gone or smaller.
3. Use PageSpeed Insights for field data on how real Chrome users experience your page's loading speed, alongside its lab diagnostics on large network payloads.

For more background on the screens your pages need to serve, see mobile viewport sizes.

Related guides