2026 年 AMP 的价值与局限：该用还是该弃?
AMP(Accelerated Mobile Pages)是 Google 于 2016 年推出的移动页面优化框架。随着 Core Web Vitals 的到来，AMP 的角色已发生根本性变化。
1. AMP 的现状(2026)
重大变化时间线：
| 日期 | 事件 |
|---|---|
| 2016 | AMP 推出；Google 的新闻轮播仅支持 AMP |
| 2021-06 | Core Web Vitals 上线；AMP 不再是进入 Top Stories 的唯一途径 |
| 2021-08 | Google 移除了 AMP 优先标识 |
| 2023 | AMP 团队缩编；项目进入维护模式 |
| 2026 | AMP 仍可使用，但已不再是 Google 推荐的方案 |
2026 年 AMP 仍有意义的场景：无法通过 Core Web Vitals 的新闻站点、资源有限的团队，以及已经部署 AMP 且运行良好的站点。
2. AMP 与原生优化的对比
| 指标 | AMP 页面 | 经过优化的非 AMP 页面 |
|---|---|---|
| LCP | 通常 < 1s(CDN 缓存) | 可达到 < 2s(需要优化) |
| 功能灵活性 | 受限 | 完全自由 |
| 开发成本 | 需要重写 | 优化现有代码 |
AMP 的主要局限：
- 不允许自定义 JavaScript
- CSS 上限 75KB，且需内联
- 复杂交互必须用 AMP 组件替代
3. AMP 基础实现
一个 AMP 页面必须包含：
- html 标签上的 ⚡ 属性
- 以 async 方式加载的 AMP 运行时脚本
- 指向原始页面的 canonical
- 一个 viewport meta 标签
- AMP 模板样式(boilerplate)
原始页面声明其 AMP 版本：
AMP 页面声明原始页面：
4. AMP 退出策略
适合迁移离开 AMP 的场景：
- 不依赖 AMP 也已能通过 Core Web Vitals
- 你需要更复杂的交互功能
- AMP 的限制正在损害转化率
- 维护成本过高
迁移步骤：
- 记录当前 AMP 页面的基准流量与 CTR
- 优化原始页面，确保通过 Core Web Vitals
- 进行 A/B 测试(先从一部分页面开始)
- 移除 rel="amphtml" 声明
- 密切监控 Search Console 数据的变化
5. 2026 年的推荐路径
Core Web Vitals 已通过 → 你不需要 AMP；专注于响应式设计 Core Web Vitals 未通过 → 先尝试针对性优化；AMP 作为备选方案
结论
在 2026 年，AMP 已不再是 SEO 的前提条件。如果你已经部署了 AMP 且运行良好，无需急于迁移。如果你正在考虑采用，先通过其他方式尝试达成 Core Web Vitals 目标会是更划算的投入。