The Technical Solution to the 49-Megabyte Web Page Already Existed

Google AMP, announced in October 2015 and deployed in Google Search by February 2016, was in many ways a direct technical response to the problem documented in page weight audits like this one. The premise was simple: publisher pages had become unacceptably bloated, mobile users were suffering, and the open web needed a constrained format that traded authoring freedom for predictable, fast loading.

AMP worked. Pages meeting the specification loaded reliably in under one second on mobile connections. The engineering was sound. What happened to it afterward is worth understanding carefully, because it says something specific about why auditing a news page in 2025 still turns up 49MB of transferred data.

What AMP Actually Restricted

The AMP HTML specification is a strict subset of HTML enforced through a validator with hard constraints rather than guidelines:

• No author-written JavaScript. Custom scripts were entirely prohibited. The only JavaScript allowed was the AMP runtime itself, loaded from Google’s CDN, which managed layout, lazy loading, and component behavior.
• Inline styles only, capped at 75KB. External stylesheets were forbidden.
• Media through custom elements. Images required <amp-img> instead of <img>, which enforced explicit aspect-ratio declarations that prevented layout shift. Video required <amp-video>. Both handled lazy loading as a system behavior.
• Third-party scripts sandboxed. External scripts were restricted to a sandboxed <amp-iframe> with constraints on positioning and loading timing.

Advertising and analytics had dedicated components with their own constraints:

<!-- AMP ad unit -->
<amp-ad
  width="300"
  height="250"
  type="doubleclick"
  data-slot="/12345/example_slot">
</amp-ad>

<!-- AMP analytics -->
<amp-analytics type="googleanalytics">
  <script type="application/json">
  {
    "vars": { "account": "UA-XXXXX-Y" },
    "triggers": {
      "trackPageview": {
        "on": "visible",
        "request": "pageview"
      }
    }
  }
  </script>
</amp-analytics>

The <amp-analytics> component is particularly instructive. Rather than loading Google Analytics as a separate script that connects to multiple Google domains and executes on the main thread, it routes reporting through a standardized component the AMP runtime manages. Publishers still got their pageview data. The mechanism changed to be less costly.

The <amp-ad> component handled programmatic advertising through Google’s own ad infrastructure, coordinating auctions through a controlled channel rather than a sprawling set of third-party scripts executing in parallel. Publishers still had advertising. The header bidding free-for-all was replaced by a structured, performance-bounded alternative.

These were real constraints on real revenue, and publishers knew it. But pages meeting the spec loaded fast in ways their normal pages did not.

The Cache Architecture and the URL Problem

AMP pages were served from the Google AMP Cache (cdn.ampproject.org), which gave Google the ability to pre-render pages before a user tapped a search result. The pre-rendering is why AMP pages appeared to load instantly; they were already loaded in a background process triggered by proximity to a search result in the viewport.

This was technically impressive and solved a real problem. It also surfaced the URL as google.com/amp/... rather than the publisher’s domain, which broke analytics attribution, disrupted canonical link relationships, and gave publishers a legitimate grievance: Google was hosting their content under Google’s URL.

Signed Exchanges (SXG), part of the Web Packaging specification, were developed partly to address this. An SXG is a cryptographically signed bundle of an HTTP response and its headers, allowing a third party to serve it while the browser attributes it to the original domain. Chrome can serve content from Google’s cache at https://www.publisher.com/article and verify via cryptographic signature that it is content the publisher actually signed and authorized.

Signed exchanges are sound technically. Chrome has supported them since version 73, released in 2019. The adoption problem is that generating them requires specific certificate infrastructure, non-trivial tooling integration, and ongoing operational overhead. The return for that investment was primarily that Google’s cache stopped rewriting your URL. Most publishers concluded that was not enough to justify the complexity, and the broader web packaging vision did not advance far beyond Chrome.

Facebook Instant Articles and Apple News Ran the Same Experiment

Facebook launched Instant Articles in May 2015, months before AMP. The format was a simplified HTML subset delivered via RSS and rendered by Facebook’s native client. Apple launched Apple News in September 2015 with a JSON-based article schema rendered natively in the app.

All three platforms operated on the same hypothesis: publisher pages are too slow, we will host a constrained version that loads immediately inside our environment. All three demonstrated that the hypothesis was correct. All three saw declining publisher participation by 2019 to 2021.

The New York Times, which was one of Facebook Instant Articles’ launch partners, dropped the format in 2018. The stated reasons included poor monetization and lack of control over reader relationships. The Washington Post and other major outlets followed.

The pattern is consistent across all three platforms. Fast loading was achieved. Publisher participation was obtained. Revenue from the fast loading format was lower than revenue from the bloated publisher-controlled format. Publishers withdrew.

What Google Did When AMP Failed Politically

In November 2021, Google announced that AMP would no longer be required for eligibility in the Top Stories carousel. Pages meeting Core Web Vitals thresholds, good Largest Contentful Paint, Interaction to Next Paint, and low Cumulative Layout Shift, could qualify regardless of format.

This was the right decision for a search engine that should evaluate page experience directly rather than through proxy formats. It also meant publishers could get Top Stories placement with their standard pages if those pages passed the vitals thresholds. Many major news sites still fail those thresholds and rank fine for queries they own through domain authority. The incentive to optimize is present but weak.

AMP as a project continues to exist. The amp.dev documentation is maintained. The validator is still running. But the period where AMP was a significant ranking signal, and therefore a business requirement for publishers who wanted Top Stories placement, is over.

The Structural Conclusion

AMP’s history provides a cleaner test of the web performance problem than most engineering discussions do, because it ran at scale with real publishers and real users over several years.

The test result: when publishers were required to use a constrained format by a ranking signal they depended on, pages got fast. When the requirement was relaxed, publishers returned to the unrestricted format. The HTTP Archive’s Web Almanac data on page weight shows no meaningful improvement in median news site page weight since AMP’s retreat. Third-party request counts on media pages continue to grow.

The constraint that made AMP fast was no author JavaScript. That constraint is what blocked the header bidding libraries, the analytics stacks, the session replay tools, and the fifty other scripts that constitute the ad tech infrastructure news sites depend on for revenue. The revenue pressure outlasted the ranking signal pressure.

Alex Russell’s analysis of the performance inequality gap documents what this means for the median global user: a page that parses and executes fast on a MacBook requires several seconds of main thread work on a $200 Android device. The AMP experiment showed that the technical solution was buildable and deployable. It did not change the economics that determine what publishers actually ship.

When someone audits a news page in 2025 and finds 49 megabytes of transferred data, the accurate interpretation is that the publisher evaluated the costs and benefits and chose this outcome. The technology to build something smaller exists and has been demonstrated at scale. The choice to not use it is deliberate, made by organizations that understand exactly what they are doing and why.