Pages over 4MB take an average of 8+ seconds to load on mobile connections. Every megabyte you trim directly accelerates your LCP.

What's the Problem?

Lighthouse flags pages where total network payload exceeds 2,667KB (the 10th percentile threshold). The median website transfers around 4MB—and that's already too much for most users on mobile networks.

Large payloads hurt LCP in multiple ways. First, more bytes mean longer download times. On a 4G connection averaging 10Mbps, downloading 4MB takes at least 3.2 seconds—before any parsing or rendering begins. Second, large pages consume user bandwidth and data plans, causing throttling on metered connections. Third, memory pressure from large payloads can slow down parsing and rendering, especially on low-end devices.

Why it hurts LCP: Your LCP element can't paint until it loads. If that element competes with megabytes of other resources, it waits in line. Even after the LCP resource downloads, large payloads cause processing delays that postpone the actual paint.

How to Identify This Issue

Lighthouse

Look for the audit "Avoid enormous network payloads" under Diagnostics. It shows:

• Total transfer size in KB
• Top 10 largest resources sorted by size
• Red if total exceeds ~2.5MB, yellow above ~1.3MB

Chrome DevTools Network Tab

1. Open DevTools → Network tab
2. Reload the page with cache disabled (Ctrl+Shift+R)
3. Check the summary bar at the bottom: "X requests, Y MB transferred"
4. Sort by "Size" column to find largest offenders
5. Filter by type (JS, CSS, Img) to identify categories

WebPageTest

Run a test and check:

• "Bytes In" in the summary
• Content breakdown pie chart
• Request waterfall sorted by bytes

The Fix

1. Optimize Images (Usually the Biggest Win)

Images typically account for 50%+ of page weight. Target: under 200KB per hero image.

<!-- Before: 2MB unoptimized PNG -->
<img src="hero.png" />

<!-- After: Responsive WebP with fallback -->
<picture>
  <source srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
          sizes="(max-width: 600px) 100vw, 50vw"
          type="image/webp" />
  <img src="hero-800.jpg" alt="Hero" loading="eager" />
</picture>

Compress images with modern formats:

• WebP: 25-35% smaller than JPEG at same quality
• AVIF: 50% smaller than JPEG (limited browser support)

cwebp -q 80 hero.png -o hero.webp

npx sharp-cli --input "*.{jpg,png}" --output webp --webp

2. Enable Compression

All text-based assets (HTML, CSS, JS, JSON, SVG) should use Brotli or gzip compression.

Nginx configuration:

brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;
brotli_comp_level 6;

gzip on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_min_length 256;

Verify compression in DevTools:

• Network tab → select a JS/CSS file → Headers → look for content-encoding: br or gzip

Compression typically reduces text assets by 60-80%.

3. Remove Unused Dependencies

Audit your node_modules and remove packages you don't use.

npx cost-of-modules

npx webpack-bundle-analyzer stats.json

npx vite-bundle-visualizer

Replace heavy libraries with lighter alternatives:

• moment.js (300KB) → date-fns (tree-shakeable) or dayjs (2KB)
• lodash (70KB) → native ES6 methods or lodash-es (tree-shakeable)
• axios (13KB) → native fetch

4. Lazy Load Below-the-Fold Content

Only load what's needed for the initial viewport.

// Lazy load images
<img src="product.jpg" loading="lazy" />

// Dynamic import for heavy components
const HeavyChart = () => import('./HeavyChart.vue')

// Intersection Observer for custom lazy loading
const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      loadHeavyModule()
      observer.disconnect()
    }
  })
})
observer.observe(document.querySelector('#chart-container'))

5. Set Cache Headers

Proper caching prevents re-downloading unchanged assets.

location ~* \.(js|css|png|jpg|webp|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
  expires 5m;
  add_header Cache-Control "public, must-revalidate";
}

Why This Works

Reducing total bytes directly reduces download time. On a typical 4G connection (10Mbps):

• 4MB payload = 3.2 seconds minimum download time
• 1MB payload = 0.8 seconds minimum download time

That's 2.4 seconds saved before any other optimization. The browser can start parsing, executing, and rendering sooner when there's less to download.

Framework-Specific Solutions

import Image from 'next/image'

// Automatic WebP/AVIF, responsive sizes, lazy loading
<Image src="/hero.jpg" width={1200} height={600} priority />

module.exports = {
  compress: true, // gzip by default
}

<NuxtImg src="/hero.jpg" width="1200" format="webp" />

export default defineNuxtConfig({
  nitro: {
    compressPublicAssets: true,
  }
})

Verify the Fix

After implementing:

1. Run Lighthouse → "Avoid enormous network payloads" should show green (< 1.3MB) or yellow (< 2.5MB)
2. Check Network tab → total transferred should be significantly lower
3. Compare total bytes in WebPageTest before/after
4. Verify compression headers are present on text assets

Target thresholds:

• Excellent: < 1,282KB (p10)
• Acceptable: < 2,667KB
• Poor: > 4,000KB (median)

Common Mistakes

• Forgetting font subsetting — Full Google Fonts can add 500KB+. Subset to characters you actually use.
• Serving uncompressed assets — Check that your CDN/server enables Brotli/gzip.
• Loading all JavaScript upfront — Split bundles and lazy load routes.
• Using oversized favicons — A 256x256 PNG favicon is overkill. Use SVG or properly sized ICO.
• Ignoring third-party scripts — Tag managers, analytics, and widgets can add 500KB+ easily.

Related Issues

Often appears alongside:

• Unminified JavaScript — Bloated JS increases page weight
• Unused JavaScript — Dead code adds unnecessary bytes
• Large Images — Usually the biggest contributor to page weight

Test Your Entire Site

Page weight varies dramatically between templates—your homepage might be lean while product pages are bloated. Unlighthouse crawls your entire site and identifies the heaviest pages by total transfer size.

Related

• All LCP Issues
• LCP Overview