AMP started appearing in more conversations this year because the mobile web still had a very obvious problem. Too many pages were slow, heavy and frustrating on phones. A visitor would tap a link, wait for scripts, ads, images and tracking to load, then abandon the page before the content had properly appeared. From that perspective, the appeal of AMP was easy to understand.
The idea of a faster, constrained version of a page was not difficult to sell, especially for publishers. If a news article could load quickly from mobile search, the user experience would improve immediately. The problem was that speed was only one part of the decision. The way a page becomes fast matters, because it affects control, development workflow, analytics, advertising and how much of the original site experience is preserved.
Why AMP Was Appealing
The strongest argument for AMP was practical. Mobile pages were often carrying too much. Large images, blocking JavaScript, slow third-party scripts and complicated advertising setups made the experience poor. AMP forced a stricter approach, and sometimes a strict approach is exactly what a page needs. By limiting what could be loaded and how it could behave, AMP made performance harder to ignore.
For content-heavy websites, that was valuable. A visitor reading an article usually wants the article first. They do not want to wait for a collection of extras before the headline and body copy appear. AMP pushed the page towards that priority, which aligned with what users were already asking for through their behaviour.
The Trade-Off
The trade-off was that AMP was not just performance advice. It was a specific format with its own restrictions and ecosystem. That meant a website might need an alternate version of its content, different validation rules and a workflow for keeping the AMP version consistent with the canonical page. That can be manageable, but it is still another layer to maintain.
I would also want to understand how the page is served and measured. If the visitor reaches a cached AMP version through search, the experience may be fast, but the relationship between the site, the search platform and the user becomes more complicated. For some publishers that may be a sensible trade. For others, the loss of control may matter more.
Performance Without AMP
The wider lesson from AMP is that most websites should not need a special version to be fast. Images can be compressed. JavaScript can be reduced. Critical content can be prioritised. Third-party scripts can be questioned. Caching can be handled properly. Those decisions are available to normal pages too, even if they require more discipline.
That is where I think AMP is useful even when I do not use it. It forces the uncomfortable question. If a stripped-down version of the page is much faster, what is the normal page doing that makes it so slow? Sometimes the answer is a genuine feature. Often it is accumulated weight nobody has reviewed in months.
Retrospective Thoughts
Retrospectively, AMP is less interesting to me as a format than as a symptom. It appeared because the mobile web had become too heavy in too many places. The fact that a stricter alternative became attractive says a lot about how easily performance can be lost when every department adds something to a page.
I would consider AMP where the search and publishing benefits are clear, but I would not treat it as a replacement for fixing the main website. A fast alternate page can help, but the better long-term goal is a site that is already careful about what it loads, why it loads it and how quickly the visitor can reach the content they came for.