Lesson 13 of 14
AMP traded a restricted HTML/JS subset for a privileged spot in Google Search — that privilege is now almost entirely gone, and Core Web Vitals, applied to any page, is what actually earns the speed advantage AMP used to grant.
12 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.
Be interviewed on this →Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
AMP (Accelerated Mobile Pages) was Google's 2015 answer to a real problem: mobile pages, especially publisher/news pages loaded with ad tech, were slow, and slow pages lose users. AMP was a restricted subset of HTML plus a mandatory JS runtime (amp.js) — it banned custom JavaScript, required specific <amp-img>/<amp-video> custom elements instead of native ones, and in exchange, qualifying AMP pages could be pre-rendered and served instantly from Google's own edge cache (the "AMP Cache"), and — for years — got a lightning-bolt badge in mobile search results plus placement in the Top Stories carousel that non-AMP pages couldn't access at all.
That was the actual incentive: AMP wasn't fast because of some technique available only to it — it was fast partly because Google was willing to give AMP pages a privileged distribution channel that non-AMP pages didn't get. That privileged channel is what has actually died.
The lightning-bolt badge and the AMP-only requirement for Top Stories carousel placement were both removed in 2021, when Google extended Top Stories eligibility to any sufficiently fast page. That was the first big cut. More significantly, Google updated its own AMP documentation in mid-2026 to drop references to the AMP viewer, the Google AMP Cache, and signed exchanges — clicking an AMP result in Google Search no longer routes through Google's cache at all; it goes straight to the page on the publisher's own domain. In practical terms, essentially nothing about being an AMP page confers a search advantage anymore, and the infrastructure that made AMP pages load instantly from Google's edge is being wound down.
What replaced it as the thing that actually matters: Core Web Vitals, measured as a page-experience ranking signal on any URL, AMP or not. The lesson Google drew from AMP — that a fast page keeps users and deserves to rank well — got generalized into a real, direct ranking input (LCP, INP, CLS) that applies uniformly, instead of a special fast lane reserved for pages that opted into a restrictive framework.
<!-- The old AMP way — a restricted subset requiring amp.js and custom elements -->
<!doctype html>
<html amp>
<head>
<script async src="https://cdn.ampproject.org/v0.js"></script>
<link rel="canonical" href="https://example.com/article" />
</head>
<body>
<amp-img src="hero.jpg" width="600" height="400" layout="responsive"></amp-img>
</body>
</html>
<!-- What actually matters now: a normal page, measured on Core Web Vitals -->
<img src="hero.jpg" width="600" height="400" loading="eager" fetchpriority="high" alt="…" />
<!-- No custom framework required — the ranking signal is the measured LCP/CLS/INP,
not whether the markup conforms to a restricted AMP subset. -->
AMP is a great test of whether a candidate's SEO knowledge is current or frozen around 2018 — anyone can say "AMP makes pages fast," but explaining why it made pages rank well (a privileged distribution channel, not an intrinsic technical property) and correctly naming what replaced that mechanism (Core Web Vitals as a page-agnostic ranking signal) shows you're tracking how the platform actually evolved, not repeating a talking point that stopped being true years ago.