How to Reduce Page Weight for a Faster, Greener Website

Reducing page weight is the single most effective thing you can do to make a website both faster and greener at once. Page weight is the total number of bytes a page transfers to load, and it drives three things simultaneously: load speed, Core Web Vitals, and carbon emissions. Because one lever moves all three, trimming weight is the rare optimisation where performance, SEO and sustainability point in exactly the same direction. The biggest reductions almost always come from images and JavaScript, and you can measure your progress with free tools at every step. This guide walks through how to measure page weight and cut it in impact order.

It is the practical companion to what is a website's carbon footprint and how to reduce it: that post explains why lighter is greener, and this one explains how to get there.

What page weight is, and why it matters three ways

Page weight is the combined size of everything a browser downloads to render a page: the HTML document, stylesheets, JavaScript, images, fonts, video, and every third-party resource the page pulls in. It is measured as the bytes transferred across the network when the page loads.

That single number drives three outcomes that organisations usually treat as separate concerns:

• Load speed. More bytes take longer to download, especially on slow connections and mobile networks. Heavy pages feel sluggish and frustrate users.
• Core Web Vitals and SEO. Slow loading and heavy assets degrade metrics like Largest Contentful Paint, which feed Google's page-experience signals. A lighter page is easier to make fast, which helps search. You can dig into this in Core Web Vitals explained: how to test and improve.
• Carbon footprint. Every byte transferred consumes energy in data centres, across networks and on the visitor's device. More weight means more energy and more emissions per view.

This is why page weight deserves attention out of proportion to how mundane it sounds. It is not just a performance metric or just an environmental one — it is the place where user experience, search rankings and sustainability genuinely converge. Improve it and you advance all three; neglect it and you undermine all three.

How heavy is the average page?

It helps to know the benchmark you are working against. According to the HTTP Archive Web Almanac, which crawls millions of pages, the median web page weighs on the order of a couple of megabytes, with the desktop median typically somewhat heavier than mobile. The two largest contributors, by some distance, are images and JavaScript — together they usually account for the majority of a typical page's bytes.

Treat those figures as a moving benchmark rather than a hard target. The exact median shifts over time and varies between desktop and mobile, so the useful takeaway is qualitative: the typical page is heavier than it needs to be, much of that weight is images and scripts, and beating the median is a sensible early goal. From there, compare each page to its own previous measurements and keep driving the number down.

Crucially, the median is not a goal to aspire up to — plenty of fast, content-rich pages come in well under a megabyte. The median simply tells you where the broad web sits so you know whether you are ahead of it or dragging behind.

Reduce page weight in impact order

The most efficient way to cut weight is to attack the biggest contributors first. Here are the tactics roughly in order of impact for a typical site.

1. Optimise and lazy-load images (usually the biggest win)

Images are the single largest contributor to page weight on most sites, which makes them the highest-leverage fix. Four moves matter:

• Compress images so they are not carrying unnecessary data.
• Size them correctly for their display dimensions — do not ship a 4000px image into a 400px slot.
• Use modern formats like WebP and AVIF, which are far smaller than older JPEG and PNG at equivalent quality.
• Lazy-load images below the fold so they download only when the user scrolls to them.

This one pass typically removes a large share of a page's weight for very little effort and no design compromise. For the full method, see how to optimize images for the web.

2. Trim and defer JavaScript

JavaScript is heavy twice over: it costs bytes to download and CPU energy to execute on the device, so excess scripts hurt both weight and the visitor's battery. Ship less of it, split it so pages load only the code they need, defer anything non-critical so it does not block rendering, and remove dead code. The deep dive is in how to reduce JavaScript and speed up your site.

3. Audit third-party scripts ruthlessly

Third-party tags — analytics, ads, chat widgets, social embeds, A/B testing tools — are a notorious source of hidden weight. They often add bytes and execution cost out of all proportion to the value they deliver, and each one can pull in further requests you never see. Audit every third party on the page, question whether it earns its place, remove what you can, and load the rest as late as possible. For many sites this is the second-biggest win after images.

4. Subset and limit fonts

Each custom font weight is a separate download. Use the modern woff2 format, subset fonts to only the characters and scripts you actually use, and avoid loading half a dozen weights when two will do. Self-hosting fonts can also remove a third-party request. The savings per font are modest individually but add up, and they trim render-blocking too.

5. Enable compression, caching and a CDN

Make sure your server compresses text-based assets with Brotli or Gzip — this shrinks HTML, CSS and JavaScript dramatically in transit. Set good caching headers so repeat visitors re-download far less; repeat-visit weight can be a fraction of the first visit when caching is done well. And serving assets through a CDN moves data closer to users, reducing both latency and the energy spent transmitting it. Whether a CDN is right for you is covered in what is a CDN and do you need one.

6. Remove unused CSS

Large stylesheets — especially from heavy frameworks or page builders — often ship rules the page never uses. Identify and remove unused CSS, or use tooling that strips it automatically at build time. The savings are smaller than images or JavaScript, but it is low-risk cleanup that also speeds up rendering.

7. Avoid autoplay video and decorative heavy media

Video is enormously heavy. Never autoplay it, never use it as pure background decoration, and host it efficiently with adaptive streaming rather than serving a giant file to everyone. The same caution applies to large animated assets and GIFs, which are often far heavier than an equivalent compressed video or a static image.

Asset type → tactic → benefit

Asset type	Tactic	Benefit
Images	Compress, resize, use WebP/AVIF, lazy-load	Largest single weight cut; faster LCP; lower carbon
JavaScript	Trim, code-split, defer, remove dead code	Less to download and execute; better INP; less device energy
Third-party scripts	Audit, remove, load late	Removes hidden weight and requests; faster, leaner pages
Fonts	woff2, subset, limit weights, self-host	Smaller downloads; fewer render-blocking requests
All text assets	Brotli/Gzip compression + caching + CDN	Far smaller transfers; tiny repeat-visit weight
CSS	Remove unused rules	Smaller stylesheet; faster rendering
Video / animation	No autoplay, adaptive streaming, static where possible	Avoids the heaviest assets entirely

How to measure page weight

You cannot improve what you do not measure, and the good news is that every tool you need is free.

• Browser DevTools — Network panel. Open developer tools, switch to the Network tab, and reload the page. It lists every request with its size and shows the total bytes transferred at the bottom. This is the most direct, granular view: you can sort by size to find your heaviest assets immediately.
• PageSpeed Insights / Lighthouse. Google's tools report page weight and resource breakdowns alongside Core Web Vitals and specific opportunities like "properly size images" or "reduce unused JavaScript."
• WebPageTest. Gives a detailed waterfall, total bytes, and lets you test from different locations and connection speeds to see how weight plays out in the real world.
• Carbon calculators. Tools like the Website Carbon Calculator and Ecograder estimate emissions directly from the transferred bytes — the Website Carbon Calculator famously pegs the average page at roughly 4.6 grams of CO2 per view — so they double as both a weight and a carbon readout. The Green Web Foundation check tells you whether the host is green, which factors into that estimate.

The discipline that matters most is simple: measure first, change one thing, then measure again. That way you can attribute each reduction to a specific change, learn what works on your site, and avoid guessing. Broader site audits — StackOptic among them — fold page weight and an efficiency estimate into a wider report so you can see it next to performance, SEO and security rather than as an isolated figure.

The performance, SEO and carbon triple win

It is worth restating why this work is such an easy sell internally. The exact same actions that reduce page weight — lighter images, less JavaScript, fewer third parties, good caching — make pages faster, which improves Core Web Vitals and the page-experience signals that feed SEO, while simultaneously cutting carbon emissions. You almost never have to trade one against another.

That alignment is rare in web work, where optimisations often pull in opposite directions. Here, a performance project doubles as a sustainability project, and a sustainability project doubles as a performance project. So even a team with no green mandate can justify the work purely on speed and SEO — and a team that does care about emissions gets the performance gains for free. Pair this with the foundation of green web hosting, and you have both halves of a genuinely low-carbon, high-performance site.

A step-by-step plan

1. Measure the current page weight of your most important and your heaviest pages (DevTools Network panel or PageSpeed Insights).
2. Sort assets by size and identify the biggest contributors — almost always images first, then JavaScript.
3. Optimise images: compress, resize, convert to WebP/AVIF, lazy-load below the fold. Re-measure.
4. Trim and defer JavaScript; audit and remove or delay third-party scripts. Re-measure.
5. Subset fonts and limit weights; enable Brotli/Gzip compression and caching; serve via a CDN.
6. Remove unused CSS and eliminate autoplay video and decorative heavy media.
7. Re-run a carbon calculator to confirm the emissions drop, and check deeper template pages, not just the homepage.

A quick checklist

• Know your starting page weight and how it compares to the median benchmark.
• Fix images first — compress, resize, modern formats, lazy-load.
• Trim and defer JavaScript; ruthlessly audit third parties.
• Subset fonts; enable compression, caching and a CDN.
• Remove unused CSS; kill autoplay video.
• Measure after every change, and check your heavy templates, not just the homepage.

Go deeper

• The why behind the work: what is a website's carbon footprint and how to reduce it.
• The biggest single win: how to optimize images for the web.
• Tame the scripts: how to reduce JavaScript and speed up your site.
• The performance twin: Core Web Vitals explained.
• The hosting foundation: what is green web hosting and how to choose it.

Want your page weight and efficiency measured alongside performance, SEO and security? Analyse any URL with StackOptic — one report, free, no sign-up.