Total page weight directly governs how long a marketing page takes to load on the mobile devices that now account for the majority of web traffic. ISO-25010 resource-utilisation defines bandwidth consumption as a key quality attribute. Google's research pegs 1.6MB as the point at which bounce rates on mobile 4G connections begin to climb non-linearly — above that threshold each additional 100KB correlates with a measurable user drop-off. Marketing pages built with AI coding tools frequently blow past this budget by combining an unoptimised hero image with multiple third-party analytics SDKs and an unpurged CSS framework, each of which individually seems harmless but collectively produce a 3–5MB page that loads in 8–12s on a 4G connection.
High because total page weight exceeding the 1.6MB mobile budget directly increases bounce rates and degrades Core Web Vitals scores across LCP, FCP, and INP simultaneously.
Work through each asset category with a size target — the hero image is almost always the highest leverage starting point.
| Asset Type | Target |
|---|---|
| HTML | < 50KB |
| CSS (compressed) | < 30KB |
| JS (compressed) | < 150KB |
| Hero image | < 200KB |
| Fonts (WOFF2) | < 50KB per family |
Run next build and check .next/analyze/ (with @next/bundle-analyzer) for JS chunk sizes. For the hero, convert to WebP and drop quality to 80:
npx sharp-cli --input public/hero.jpg --output public/hero.webp --format webp --quality 80
For ongoing enforcement, add a Lighthouse CI budget assertion in .lighthouserc.json under "total-byte-weight" so page weight regressions block the deploy.
ID: marketing-page-speed.resource-optimization.total-page-weight
Severity: high
What to look for: Estimate the total transferred size for a cold-load of the marketing homepage. Sum: (1) HTML document size, (2) all CSS files loaded, (3) all JavaScript bundles (JS is the most expensive — it must be parsed and executed, not just downloaded), (4) all above-fold images, (5) fonts. Check build output for JS sizes. Check image file sizes in public/. If using a build analyzer, look at chunk sizes. The 1.6MB budget is Google's recommendation for mobile 4G connections and correlates with bounce rate uplift above this threshold. Count every resource loaded on the page (HTML, CSS, JS, images, fonts, other) and enumerate by category with total bytes. Report total page weight.
Pass criteria: Estimated total page weight (HTML + CSS + JS + images + fonts) is ≤ 1.6MB transferred for a cold load. Modern frameworks with Tailwind, code splitting, and WebP images typically achieve 400-800KB. Report the count of resources by type and total page weight even on pass. Threshold: under 3 MB total page weight for initial load.
Fail criteria: Page weight exceeds 1.6MB. Common causes: unoptimized images (>500KB hero), large JS bundles (>400KB unparsed), multiple marketing SDKs each >100KB.
Skip (N/A) when: Never — page weight applies to all public marketing pages.
Cross-reference: The image-optimization check in Resource Optimization addresses the largest contributor to total page weight.
Detail on fail: "Estimated page weight: hero JPEG (1.2MB) + JS bundles (380KB) + CSS (45KB) = ~1.6MB before fonts. With 2 font files (~80KB), total exceeds budget. Hero image alone exceeds the recommended total."
Remediation: Target each weight category:
| Asset Type | Target |
|---|---|
| HTML | < 50KB |
| CSS (compressed) | < 30KB |
| JS (compressed) | < 150KB |
| Hero image | < 200KB |
| Other images | < 100KB each |
| Fonts (WOFF2) | < 50KB per family |
The highest leverage action is almost always the hero image — a 1MB JPEG converted to WebP at quality 80 typically becomes 150-250KB.
Configure build-time size budgets in your framework config. In Next.js, set experimental.outputFileTracingExcludes in app/ layout or use next.config.js to optimize output.