AMP, short for Accelerated Mobile Pages, is an open-source web component framework that makes pages load quickly on phones by restricting HTML, CSS and JavaScript to a validated subset and allowing pages to be served from an AMP cache close to the user. In the mobile web, AMP was the most visible attempt to fix slow, script-heavy news and content pages by enforcing performance rules at the format level.
AMP was launched in 2015 as a Google-led initiative and later moved to the governance of the OpenJS Foundation. Its role changed significantly after 2021, when search engines stopped requiring AMP for features such as the Top Stories carousel and began rewarding fast pages regardless of the technology used.
How AMP makes pages fast
AMP achieves speed through constraints rather than optimization advice. A valid AMP page must follow rules that prevent the most common causes of slow rendering, and an official validator checks every page against these rules. Pages that fail validation are not served from AMP caches.
| Rule | What it requires | Performance effect |
|---|---|---|
| AMP runtime | A single script that manages loading and layout | Controls resource priority and rendering |
| No arbitrary JavaScript | Custom scripts only through sandboxed amp-script | Prevents blocking and heavy scripts |
| Inline CSS size limit | All styles inline, up to about 75 KB | No extra stylesheet requests, faster first render |
| Sized elements | Width and height declared for media | Prevents layout shifts while loading |
| AMP components | Custom elements such as amp-img and amp-carousel | Lazy loading and prioritization handled by the runtime |
| Static layout | Layout calculated before resources load | Stable, predictable rendering |
Because the runtime knows every element’s size in advance, it can lay out the page before images and ads arrive, and it can load only what is near the viewport. This is the same goal modern performance metrics such as Largest Contentful Paint and Cumulative Layout Shift measure on any page.
The AMP cache and prerendering
A distinctive part of AMP is the AMP cache, a content delivery network operated by platforms such as Google and Bing that stores validated copies of AMP pages. When a user taps a result, the platform can prerender the page safely in the background, because AMP’s restrictions guarantee that prerendering will not run unwanted scripts or leak data. The result can feel like an instant page load.
The trade-off was the URL problem: pages served from the cache appeared under the cache’s domain rather than the publisher’s. Signed exchanges, a web packaging technology, were introduced to let browsers show the publisher’s original URL while still delivering the page from the cache, but support remains limited to certain browsers.
AMP formats beyond web pages
The framework grew into several AMP formats, each using the same component model for a different channel. Some remain in active use, while others matter mainly for legacy content.
| Format | Purpose | Current relevance |
|---|---|---|
| AMP pages | Fast article and landing pages | Maintained, but no longer required for search features |
| Web Stories | Tap-through visual stories built on AMP | Used by publishers for visual storytelling |
| AMP for Email | Interactive email content | Supported by a few email providers |
| AMP ads | Faster and safer display ads | Niche use in ad ecosystems |
AMP compared with other mobile web approaches
AMP is often discussed next to responsive design, progressive web apps and general performance optimization. The comparison clarifies what each approach solves.
| Approach | Main goal | Technical freedom | Typical drawback |
|---|---|---|---|
| AMP | Guaranteed fast content pages | Low, restricted markup | Second codebase and limited interactivity |
| Responsive design | One layout for all screens | High | Fast loading is not guaranteed |
| Progressive web app | App-like features such as offline use and installation | High | Requires service worker and app shell work |
| Performance-optimized pages | Good Core Web Vitals on the canonical page | High | Depends on team discipline |
AMP and progressive web apps are not mutually exclusive. A site can use AMP pages as fast entry points and then install a service worker that turns later navigation into a PWA experience.
Should a site use AMP today
For most sites, AMP is now an optional technology rather than a requirement. Search ranking signals focus on page experience and Core Web Vitals, which any well-built page can meet. The decision depends on the site’s team, content type and existing setup.
| Situation | Recommendation | Reason |
|---|---|---|
| Fast canonical pages already | Do not add AMP | Extra maintenance with little benefit |
| Slow legacy news site, limited developer time | AMP can help | Constraints enforce speed without a rebuild |
| Paired AMP and canonical pages | Consider consolidating | Two versions double testing and analytics work |
| Web Stories are part of the content strategy | Keep AMP for stories | Stories are built on the AMP format |
| Highly interactive application | Avoid AMP | Restrictions limit custom logic |
When a site removes AMP, it should redirect AMP URLs to their canonical pages and keep the canonical pages fast. Otherwise visitors following old links or cached results may reach errors, and the speed advantage disappears.
Limitations and common mistakes
AMP’s restrictions are its strength and its main weakness. Teams frequently run into analytics, advertising and design gaps when they treat AMP pages as a simple copy of the main site.
- Mismatched content between AMP and canonical versions can violate search guidelines.
- Broken analytics when AMP pages are not configured with amp-analytics and session stitching.
- Validation errors after template changes silently remove pages from the cache.
- Limited interactivity, since complex forms and widgets need workarounds.
- Separate maintenance, because paired AMP templates must be updated alongside the main design.
The short version
AMP is a set of strict rules for building web pages so that they open almost instantly on a phone. It bans heavy code, requires every image to declare its size and lets search engines keep a ready copy of the page.
Think of it as a fast lane with strict entry rules: you give up some freedom in exchange for speed. Today many sites reach similar speed without AMP, so it has become one option among several.
Where it makes a difference
A regional news publisher with an older content management system had article pages that took many seconds to become usable on mobile connections, largely because of ad scripts and large stylesheets. With a small development team, a full rebuild was not possible, so the publisher introduced paired AMP versions of its articles.
Readers coming from search results saw articles that appeared almost instantly from the AMP cache, and bounce rates from mobile search visits dropped. Several years later, after rebuilding its main templates with lighter scripts and good Core Web Vitals, the publisher retired the AMP versions, redirected the AMP URLs to the canonical articles and saved the effort of maintaining two templates.