AMP本身不是移动加速原因，而是Google提出的限制性HTML规范；实际效果取决于是否规范使用，如正确替换img标签、预加载JS、避免自定义字体阻塞、命中AMP Cache等。
AMP（Accelerated Mobile Pages）本身不是“导致移动加速”的原因，而是 Google 提出的一套限制性 HTML 规范，目标是让页面在移动端加载更快；但实际效果取决于你是否真正在用它、怎么用、以及有没有引入反效果的实践。
AMP 页面为什么反而变慢了
常见现象是启用 AMP 后首屏时间没降反升，或 Lighthouse 分数下降。根本原因不是 AMP 本身慢，而是落地时违背了它的设计前提：
-
amp-img没替换原生<img alt="HTML AMP导致移动加速怎么办_移动加速与HTML AMP关联【总结】" >，或漏写width/height属性，触发 layout shift + 多余 JS 计算 - 用了
amp-bind或amp-state做复杂交互，但没预加载amp-bind.js，导致 JS 加载后才渲染内容 - 自定义字体通过
@import引入，而非<link rel="stylesheet">，被 AMP runtime 阻塞或延迟加载 - CDN 缓存未生效：AMP Cache（如
https://example-com.cdn.ampproject.org/c/s/example.com/amp/）没被正确命中，回源走普通服务器
不改代码也能判断 AMP 是否真起作用
直接看网络请求和渲染行为，比看“是否加了 amp 标签”更可靠：
- 打开 Chrome DevTools → Network 标签 → 刷新页面 → 筛选
document类型，确认主 HTML 响应头含Content-Type: text/html且响应体里有或 - 检查
https://cdn.ampproject.org/v0.js是否加载成功；若控制台报Failed to load resource，整个 AMP runtime 就没启动 - 右键页面 → “查看页面源代码”，搜索
amp-boilerplate—— 如果被删了或注释掉，样式会闪动，CLS（累积布局偏移）必然超标 - 用
curl -I https://yourdomain.com/amp/看返回头是否有AMP-Cache-Transform: google，没有说明没进 AMP Cache
AMP 和非 AMP 页面共存时的典型坑
很多站点用“AMP canonical”方式双版本并存，这时最容易出问题：
立即学习“前端免费学习笔记（深入）”；
- 非 AMP 页的
<link rel="amphtml" href="/amp/">指向 404 或重定向链过长（比如 302 → 301 → 200），Googlebot 会放弃抓取 AMP 版本 - AMP 页里的
<link rel="canonical" href="/">指向的非 AMP 页面，meta description / Open Graph 标签与 AMP 页不一致，导致分享时卡片信息错乱 - 两套页面用同一套后端模板但不同 CSS，结果 AMP 版本偷偷加载了 500KB 的
main.css（违反 AMP 只允许内联 50KB CSS 的规则），被 runtime 强制阻断样式 - Analytics 配置只埋在非 AMP 页，AMP 页用
<amp-analytics></amp-analytics>却没配 type="gtag" 或漏传data-credentials="include"，导致数据缺失
AMP 不是开关式优化，它是一套约束条件下的重构——删掉一个 <script></script> 标签可能提速，但补上三个 amp-list + amp-mustache 嵌套就可能拖垮 TTI。真正影响速度的是资源调度逻辑，不是标签名带不带 amp- 前缀。
