你的网站为什么这么慢
几乎每个速度缓慢的网站背后的少数几个原因、如何证明你遇到的是哪一个，以及真正能够改进现场数据的修复顺序。
← Guides All guides in this topic
先测量，再猜测
如果你打开 DevTools，改三个插件，重新部署而不查看现场数据，你只是在猜测，只是多了几个步骤。速度缓慢是访问者的体验。在改代码之前用真实用户的数字来证明它。
从 PageSpeed Insights 或 Search Console Core Web Vitals 中的 Chrome UX Report 现场数据开始。你需要移动设备上最大内容绘制、下一次绘制的交互和累积布局偏移的第 75 个百分位数。Lighthouse 的实验室得分对于调试单个页面加载很有用。但这不是 Google 用于排名的指标，也不是你的用户在火车 Wi-Fi 上感受到的指标。
前十分钟要收集的内容
速度缓慢的页面 URL。设备类别（优先考虑手机）。问题是首次访问还是重复访问。登录页面是否与公开首页不同。如果能看到 TTFB。诊断面板中的 LCP 元素名称。这个简短的列表通常会指出正确的方向，不需要任何人为框架争论。
关键要点：现场数据决定网站是否缓慢。实验室数据帮助你找到解决办法。永远不要颠倒这个顺序。
前端还是服务器？
如果页面在任何内容出现之前就缓慢了，通常是服务器问题：首字节时间长、未缓存的数据库查询、每次请求都进行 PHP 或 Node 渲染，或者主机性能不足。如果内容出现了然后卡顿、停顿或移位，这是前端问题：图片、脚本、字体和布局。
一个有用的区分方法：TTFB 在大约 0.8 秒以下意味着源站大多不在关键路径上。在营销页面上超过 1.2 秒，在痴迷于图片编码格式之前先修复主机、缓存或服务器渲染成本。对于大型网站，诊断在本网站的 Core Web Vitals 检查清单和 LCP、INP、CLS 修复指南中有各自的方案。
| Symptom | Likely lane | First check |
|---|---|---|
| Blank screen, then everything | Server / TTFB | Host, cache hit rate, SSR cost |
| Hero late, rest fine | Front-end LCP | Hero image size, preload, CDN |
| Taps feel sticky | Front-end INP | JS weight, long tasks, third parties |
| Page jumps while loading | Front-end CLS | Image dimensions, font swap, ads |
关键要点：先确定问题所在的方向。服务器工作和前端工作需要不同的人员和不同的工具。
六个常见嫌疑人
按照我在商业网站上看到的问题频率排序：
1. 过大的英雄媒体
一个2MB的PNG或未裁剪的CMS上传作为LCP元素。解决方案：正确调整大小、使用现代格式（WebP或AVIF）、添加宽度和高度属性、预加载实际的LCP URL、从CDN提供。一个好的英雄图修复往往胜过十个微调。
2. 首次绘制时不需要的JavaScript
标签管理器、聊天小部件、A/B测试工具、未使用的框架水合以及"以防万一"的客户端组件。解决方案：延迟或移除第三方脚本、在营销路由上减少JS、保持交互岛屿体积小。
3. 主机和缓存未命中
共享主机、没有页面缓存的冷启动WordPress、每个公开URL上的Next.js SSR，或在每次部署时重建整个世界的ISR模式。解决方案：WordPress使用托管主机或边缘缓存，应用框架使用静态或具有合理revalidate策略的ISR。
4. 阻塞渲染的字体和CSS
从第三方CSS文件导入的五种权重显示字体，阻塞文本。解决方案：子集化、自托管、font-display swap或optional、折叠以上的关键CSS。
5. 无边界的第三方
注入更多像素的像素。修复方法：在交互后或空闲时加载，删除任何未能通过转化测试验证的内容。
6. 后加载内容引起的布局偏移
广告、嵌入内容和未预留空间的图片。修复方法：使用宽高比盒子、预留位置、避免在现有内容上方注入 UI。
核心要点：大多数"框架很慢"的抱怨实际上就是这六个问题之一，只是披着框架的外衣。
优先修复最大的问题
不要一次性优化所有内容。打开实际用户数据或实验室诊断中的 LCP 条目，找出 LCP 元素（通常是主图或标题），让这一个元素变快：正确的尺寸、预加载、通过 CDN 提供。重新测量。然后删除关键路径上运行的 JavaScript。再次重新测量。
营销网站的实践顺序：LCP 元素，然后是第三方 JS，然后是字体加载，然后是缓存和 TTFB，然后是 CLS 清理，最后是微优化。仅完成前两步通常就能让商业网站达到通过 CWV 标准。
WordPress 说明：插件精简和托管主机上的真实页面缓存比主题重写更常见地取得成效，尽管很多代理公司不愿承认。Next.js 和 Astro 说明：不要对宣传页面进行 SSR。公开页面使用静态或缓存 HTML；为已认证的产品界面保留服务器工作。详情见 Next.js vs Astro vs WordPress 指南。
核心要点：一次测量确认的 LCP 优化胜过一周的推测性重构。
特定技术栈的失败模式
WordPress
页面构建器在每个页面上加载所有组件 CSS。未缓存的 WooCommerce 模板。繁重的相关文章查询。多年积累的自动加载选项表。修复方案：在边缘缓存 HTML，减少插件，延迟加载构建器折叠以下部分，修复数据库自动加载膨胀。
Next.js
客户端组件包装整个页面。顺序 await 调用的瀑布流。通过错误的加载器传输图像。在永不个性化的页面上使用 ISR 或 SSR。修复方案：默认使用 Server Components，尽可能使用静态，按路由审计 JS 包。
Astro 和其他静态栈
通常速度很快，除非你重新引入了一个应用级产品的 SPA 岛屿，或直接链接庞大的 CMS 媒体。修复方案：保持岛屿很小，在管道中处理图像，不要把 WordPress 习惯粘贴到静态站点。
关键要点：让修复匹配你的技术栈。重新平台化很少是第一个性能改进举措。
什么是好的表现
目标，基于移动设备上真实访客的 75 百分位测量：最大内容绘制不超过 2.5 秒，交互到下一次绘制不超过 200 毫秒，累积布局偏移不超过 0.1。将首字节时间保持在约 0.8 秒以下，使服务器不成为关键路径。
达到这些目标，网站在任何访客或 Google 会惩罚的方式上都不会显得缓慢，无论合成虚荣指标说什么。任何更快的都是锦上添花。发布产品，而不是追求满分。
如果你想要这项工作的清单形式，使用核心网页指标清单。如果你需要按指标进行手术，使用 LCP、INP 和 CLS 修复指南。如果业务情况是重建，从性能支柱而不是重新设计演示开始。
关键要点：通过现场 CWV 是"速度慢吗？"的终点，而不是完美的 Lighthouse 截图。
何时停止自己动手，寻求帮助
当LCP元素显而易见、第三方脚本很少、且你掌控托管服务时，DIY就足够了。当实际用户数据在两个认真的修复周期后仍然红灯、堆栈是团队中没人拥有的混合方案、或收入页面无法再承受一周的推测性改动时，就该寻求帮助。
给外部人员的有用简报：三个关键网址、字段截图、LCP元素名称、主机和CDN，以及禁止移除的标签列表。这个信息包能把模糊的"网站很慢"变成一个单周期的任务。
如果讨论演变成全面重设计，暂停。性能工作和重设计工作混合效果很差，除非重设计有明确的CWV预算。当业务仍然依赖现有模板时，先修复当前模板。
关键要点：两次修复失败或没有明确责任人是DIY和付费性能优化之间的分界线。