Total Byte Weight is the cumulative size of every resource the browser downloads to render a page — HTML, CSS, JavaScript, images, fonts, video, and third-party scripts combined. Performance audits flag any page where the compressed transfer size exceeds 1,600 KB (1.6 MB). The heavier the payload, the slower TTFB, FCP, LCP, and TTI become — directly hurting Core Web Vitals and search rankings.
Think of byte weight like luggage on a flight. A carry-on (under 1 MB) gets you boarded fast. A checked bag (1.6 MB+) costs time at every step — security, gate, baggage claim. On a slow mobile connection, that extra weight is the difference between a visitor who sticks around and one who bounces before your hero image even paints.
A bloated payload cascades into every other performance metric — and into your business numbers:
The metric is the sum of transfer size (compressed, over-the-wire bytes) of every resource the page requests during load — not the uncompressed file size on disk. The audit threshold of 1,600 KB applies to the compressed transfer total.
Worked example for a typical product page:
Resource type Transfer size
-------------------- ------------
HTML document 45 KB
CSS bundle 68 KB
JavaScript bundle 512 KB
Hero image (WebP) 180 KB
Below-fold images 620 KB
Web fonts (woff2) 110 KB
Third-party scripts 240 KB
Video poster + preview 150 KB
-------------------- ------------
Total 1,925 KB (FAIL — over 1,600 KB)On this page, the largest single category is below-fold imagery — exactly where lazy-loading and modern formats yield the biggest wins. The next-largest is JavaScript, where code-splitting and tree-shaking typically cut 30–50%.
Audits measure transfer size, not resource size. A 600 KB JavaScript file served with Brotli compression might transfer as 150 KB — that 150 KB is what counts toward the 1,600 KB budget. This is why text compression and image format choice matter so much: they shrink the transfer size without changing the rendered output.
Several tools surface Total Byte Weight, broken down by resource type and origin:
Modern formats are 25–50% smaller than equivalent JPEG/PNG at the same visual quality. AVIF is even smaller than WebP for photos but has slightly less browser support — use the <picture> element to ship AVIF first with a WebP fallback.
<picture>
<source type="image/avif" srcset="hero.avif" />
<source type="image/webp" srcset="hero.webp" />
<img src="hero.jpg" alt="Hero image" width="1200" height="630" />
</picture>Don't ship a 1920px-wide hero image to a 375px phone. srcset + sizeslets the browser pick the smallest file that still looks sharp at the visitor's screen size and DPR.
<img
src="hero-1200.webp"
srcset="hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1920.webp 1920w"
sizes="(max-width: 600px) 400px,
(max-width: 1024px) 800px,
1200px"
alt="Hero image"
width="1200" height="630" />Images and iframes that aren't visible on first paint should not be in the initial transfer. Native lazy-loading is one attribute and ships in every modern browser.
<img src="below-fold.webp" loading="lazy" decoding="async"
width="800" height="450" alt="Product detail" />
<iframe src="https://www.youtube.com/embed/..." loading="lazy"
width="560" height="315" title="Demo video"></iframe>If a visitor lands on the homepage, they shouldn't download the checkout bundle, the admin bundle, or the rich-text editor. Dynamic imports load code on demand.
// Load the heavy editor only when the user clicks "Edit"
button.addEventListener('click', async () => {
const { mountEditor } = await import('./editor');
mountEditor(target);
});Make oversized bundles fail the build, not the user. Webpack, esbuild, and Vite all support asset-size warnings or hard limits.
// webpack.config.js
module.exports = {
performance: {
maxAssetSize: 250 * 1024, // 250 KB per asset
maxEntrypointSize: 400 * 1024, // 400 KB per entry
hints: 'error', // fail the build
},
};Most sites ship 60–90% unused CSS — leftovers from utility frameworks and component libraries. Build-time tools like PurgeCSS (or Tailwind's built-in JIT) emit only the classes you actually use.
A full multi-weight font family can be 300+ KB. Subset to the characters you need (Latin only, no extended Cyrillic), use woff2exclusively, and ship the file from your own origin so it shares the page's HTTP/2 connection.
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-latin-400.woff2') format('woff2');
font-weight: 400;
font-display: swap;
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC;
}Tag managers, A/B testing tools, chat widgets, and analytics each add anywhere from 30 KB to 250 KB. Every quarter, list every third-party request the page makes and ask: "Does this earn its byte cost?" If the answer is no, drop it.
Brotli typically shrinks HTML/CSS/JS by 70–80%. Most modern web servers (Nginx, Apache) and CDNs support Brotli with one toggle. Combined with HTTP/2 or HTTP/3 (which adds header compression on top of body compression), this is the highest-leverage fix on most sites.
What's happening: A 1920×1080 JPEG hero (often 800 KB+) is sent to every device, including 375px phones.
Fix: Convert to WebP or AVIF, generate four width variants (400/800/1200/1920), and serve via srcset + sizes. Typical savings: 70–85% on mobile.
What's happening: Every page downloads the same 800 KB bundle even when only 40 KB is used on the current route.
Fix: Enable route-level code splitting (built into Next.js, Nuxt, SvelteKit, Astro) and lazy-import heavy widgets (rich-text editors, charts, date pickers) only when triggered.
What's happening: A background hero video starts buffering immediately, costing 1–3 MB before the user has even scrolled.
Fix: Replace with an optimized poster image and require a user click to play. If autoplay is essential, use preload="none" and a low-bitrate WebM/AV1 source.
What's happening: A single tag-manager snippet pulls in 8–15 third-party scripts (analytics, A/B testing, chat, retargeting), each adding 50–200 KB.
Fix: Audit every tag, deferred-load non-critical ones, and consider server-side tagging so the third parties don't ship code to the browser at all.
Use this table as a quick reference when reviewing audit results:
| Tier | Compressed Transfer Size | Typical Experience (4G) | Typical Experience (3G) |
|---|---|---|---|
| Best-in-class | < 1,000 KB | Fast load, LCP ≤ 2.5 s likely | Usable, LCP often under 4 s |
| Passing | 1,000 – 1,600 KB | Acceptable on most devices | Borderline; LCP risk |
| Audit flagged | > 1,600 KB | LCP delays likely | Slow; bounce risk high |
| Critical | > 3,000 KB | Visible delay before content | Often unusable |
Performance audits flag any page over 1,600 KB compressed. Best-in-class sites stay under 1,000 KB. The web median (per the HTTP Archive Web Almanac, 2024) is around 2.0 MB on mobile and 2.6 MB on desktop — meaning the typical page on the internet today already fails the audit.
Not directly — but it strongly influences metrics that are ranking factors. Heavier pages have slower LCP, FCP, and TTI, and LCP is a confirmed Core Web Vital used in ranking. Reducing byte weight is one of the most reliable ways to improve Core Web Vitals across the board.
Compressed (transfer) size — the number of bytes that actually move across the network. A 600 KB JavaScript file served with Brotli might transfer as 150 KB, and only that 150 KB counts toward the 1,600 KB budget. This is why enabling text compression is one of the highest-leverage fixes.
HTTP Archive data shows median page weight has grown from ~1.2 MB in 2017 to over 2.3 MB in 2024. The two biggest drivers are JavaScript bundle growth (frameworks, analytics, A/B testing, personalization) and higher-resolution imagery for retina displays. Most sites compensate by shipping the largest image variant to every device — which is exactly what responsive images are designed to prevent.
On most consumer sites: images, at 40–55% of total weight. JavaScript is usually second at 20–30%, then video, fonts, CSS, and HTML. Third-party scripts (analytics, ads, embeds) often span all of those categories and can account for 20–40% of total requests by themselves.
Indirectly, yes. AI-driven systems (Google AI Overviews, generative answer engines) preferentially cite pages that already rank well in traditional search. A bloated page hurts Core Web Vitals → hurts rankings → reduces your chance of being chosen as a citation. Lean, fast pages compete better in both surfaces.
Treat byte weight as a budget that drifts every release. Set a CI check using your bundler's performance.maxAssetSize for JavaScript, run a Greadme deep scan on key templates after every meaningful release, and audit third-party scripts at least quarterly. Drift is much cheaper to catch in week one than in month six.
Total Byte Weight is the most honest performance metric you have — it's just bytes, and bytes don't lie. Get under 1,600 KB compressed and most other Core Web Vitals follow naturally; stay above it and every other optimization fights uphill.
The biggest wins come from three places: modern image formats with responsive srcset, route-level JavaScript code-splitting, and Brotli/gzip on every text resource. Run a Greadme deep scan to see exactly which assets are pushing your page over the threshold and ship a fix in one PR.