# NYT Loads 49 MB and 422 Requests for One News Article

> NYT loads 49 MB and 422 requests for one news article, running a live ad auction before the headline renders. Content gets 11-15% of screen space.

Published: 2026-03-16
URL: https://daniliants.com/insights/the-49mb-web-page/
Tags: web-performance, ux, ad-tech, dark-patterns, page-weight, news-publishers, tracking, core-web-vitals

---

## Summary

A teardown of NYT's 49 MB page load - 422 network requests, a live programmatic ad auction running before the headline renders, and relentless cross-site tracking beacons firing throughout. News publishers have trapped themselves in an ad-tech death spiral where dark patterns are architecturally enforced by business incentives, not individual engineering decisions. The article is a rare combination of technical dissection and UX critique with specific, actionable fixes.

## Key Insight

- **The scale is absurd by historical comparison:** 49 MB for a news article page exceeds Windows 95 (28 floppy disks / ~40 MB) and equals 10–12 full MP3 songs. At 2006 average broadband (1.5 Mbps), this would take several minutes to load.
- **The culprit is the programmatic ad auction running client-side:** before content renders, the browser downloads, parses, and JIT-compiles megabytes of JS to run concurrent real-time bidding to exchanges like Rubicon Project and Amazon Ad Systems. This is compute running on your CPU, not the server's.
- **Surveillance is relentless and layered:** POST beacons fire to first-party endpoints (`a.et.nytimes.com/track`), invisible pixel redirects stitch cross-site identity via doubleclick.net and casalemedia. The GDPR consent endpoint is literally named `purr.nytimes.com/tcf`.
- **Content occupies ~11–15% of screen real estate** on mobile (Guardian: 11%, Economic Times: ~15%). The rest is ads, sticky headers, share bars, modals, and browser chrome.
- **Z-Index Warfare:** on mobile, a user must dismiss 3–4 overlays before reading a single sentence - cookie banner, newsletter modal, notification prompt, "open in app" - burning cognitive budget before any value is delivered.
- **CLS (Cumulative Layout Shift) is a structural symptom:** ad slots that resolve asynchronously inject iframes above the viewport, causing text to jump mid-read. Google penalises this for SEO but Google's own ad products cause it - "Google's search arm penalizes the crime while Google's ads arm sells the weapon."
- **Viewability and time-on-page CPM incentives are the root cause:** every hostile UX decision traces back to the publisher needing to maximize the window advertisers pay for. User frustration is literally the product.
- **Light versions prove the audience wants simplicity:** `text.npr.org`, `lite.cnn.com`, `cbc.ca/lite`, and RSS feed readers serve millions - proving demand exists for no-frills reading.

**Specific fixes the author proposes:**

- No pop-ups before 60 seconds dwell time or 50% scroll depth
- Serialized onboarding queue - one overlay at a time, triggered by behavior not page load
- Combine cookie consent + newsletter ask into a single non-blocking bottom section, state saved to localStorage
- Place newsletter CTA as a styled div between paragraphs 4–5 (engaged readers convert better)
- Reserve ad slot space with `min-height: 250px` + skeleton loader to prevent CLS