网站为什么这么慢？如何找出原因并解决

“我的网站很慢”这句话，说的可能是好几种不同的问题。也许是服务器过了很久才发出第一个字节；也许是页面很快就到了，主图却迟迟出不来；也许是页面看上去已经就绪，点按之后却有一秒钟毫无反应；又或者是页面加载出来以后，广告和图片把文字往下挤，内容跳来跳去。每种情况的原因各不相同，所以第一件事就是弄清楚你遇到的是哪一种。

先测量，再动手

速度数据分为两类，回答的是不同的问题：

• 实际用户数据来自真实访客各自的设备和网络。Google 的 Chrome UX Report 会为流量足够的网站收集这类数据，你可以在 PageSpeed Insights 和 Google Search Console 的“核心网页指标”报告中看到。它告诉你用户的真实感受。
• 实验室数据来自在受控条件下把页面加载一次，Lighthouse 就是这么做的。它的代表性差一些，但可以重复，而且能解释页面为什么慢。

按照 Google 的 Core Web Vitals，良好的体验是指：Largest Contentful Paint (LCP) 不超过 2.5 秒、Interaction to Next Paint (INP) 不超过 200 毫秒、Cumulative Layout Shift (CLS) 不超过 0.1，均以真实访问的第 75 百分位为准。

诊断时请运行实验室测试。Rudra 的免费网站速度检查工具会用 Lighthouse 加载你的页面，报告 First Contentful Paint、LCP、Total Blocking Time、CLS、Speed Index 和 Time to Interactive，并把未通过的 Lighthouse 审计项按严重程度从高到低列出。请记住它的局限：这只是从我们的服务器、在 Lighthouse 模拟条件下进行的一次加载，所以数值不会与你的实际用户数据完全吻合；它也无法测量 INP，因为那需要真实的交互。在实验室指标中，Total Blocking Time 与响应速度的关系最为密切。

挑几种有代表性的页面类型来测（首页、一个产品或服务页、一篇文章），每个页面多跑几次，并且要看移动端的结果，不能只看桌面端。

最常见的原因及解决方法

1. 服务器响应慢

在服务器发出 HTML 之前，其他一切都无从开始。如果 Time to First Byte 偏高，原因通常是主机廉价或负载过重、每次请求都从头生成页面、数据库查询缓慢，或者访客离服务器太远。解决办法：开启页面缓存（大多数 CMS 都有缓存插件或设置项），在网站前面加一层 CDN，删掉用不着的插件；如果服务器确实性能不足，就升级主机。Google 的指南把 0.8 秒以内的 TTFB 视为良好。在全站抓取中，Rudra 会标出服务器响应时间超过 1.5 秒的页面，超过 3 秒的则标为严重。

2. 图片过大

从相机或手机直接导出的照片可能有好几兆字节、宽达几千像素，最后却只以 800 像素的宽度显示。请调整尺寸、压缩并使用现代格式。我们的指南如何减小图片体积会一步步带你完成。

3. JavaScript 太多

体积庞大的打包文件和第三方标签（统计分析、在线客服挂件、A/B 测试、广告脚本）都在争抢浏览器的主线程。长脚本运行期间，页面无法响应点按，在实验室里表现为 Total Blocking Time 偏高，在实际用户数据里表现为 INP 不佳。把每一个第三方标签都审查一遍，删掉没人用的；非必要的挂件等页面可交互之后、或者访客主动需要时再加载；把大的打包文件拆开，让每个页面只加载自己需要的部分。

4. 阻塞渲染的 CSS 和脚本

<head> 中没有 async 或 defer 的脚本，以及每一个样式表，都必须先加载完，浏览器才能绘制出任何内容。给不需要立即执行的脚本加上 defer，例如 <script src="/app.js" defer></script>；合并或删除不必要的样式表；还可以考虑把首屏所需的少量 CSS 直接内联。

5. 没有启用压缩

文本文件（HTML、CSS、JavaScript、JSON、SVG）经过 gzip 或 Brotli 压缩后体积会大幅缩小。在浏览器的 Network 面板里查看页面的响应头，看有没有 content-encoding: br 或 gzip。如果没有，就在服务器上启用（在 nginx 中是 gzip on; 加上一份 gzip_types 列表），或者在 CDN 上启用。

6. 静态文件没有缓存

回访的用户不应该把你的 logo 和样式表再下载一遍。对于内容一变文件名就跟着变的文件（大多数构建工具会加上哈希值，比如 app.3f9a2c.js），请发送 Cache-Control: public, max-age=31536000, immutable。HTML 则只做短时间缓存或采用重新验证，这样更新才能及时生效。

7. 网页字体过重

好几个字体家族，每个又带多种字重，体积很快就累积起来，而且字体下载期间文字可能一直不可见。减少字重数量，提供 WOFF2 格式，把字体裁剪成只含你需要的字符的子集，加上 font-display: swap 让文字先用后备字体立即显示，并且只预加载首屏用到的那一个字体。使用系统字体栈则可以完全省去下载。

8. 布局偏移

页面跳动，通常是因为图片和嵌入内容没有预留空间、广告被插进了正文，或者横幅在加载完成后才出现在文字上方。给每张图片加上 width 和 height 属性（或 CSS 的 aspect-ratio），用 min-height 为广告和嵌入内容预留空间，并把 Cookie 横幅和促销横幅做成浮层，而不是把内容往下推。

9. 页面臃肿、请求过多

体积极大的 HTML 文档（往往源于内联数据或没完没了的商品列表）、几十个脚本，以及同一个脚本被引入两次，都会拖慢页面。给长列表分页，把大段的内联数据移到可缓存的独立文件中，并删除重复的标签。Rudra 的抓取会标出超过 1 MB 的 HTML 文档、引用资源超过 100 个的页面，以及被重复加载的脚本。

10. 页面还没开始加载就先重定向

访客输入 example.com，先被重定向到 https://example.com，再到 https://www.example.com，接着又到 /home，每一跳都要等。请一步直接重定向到最终 URL，并且在所有地方都链接到最终 URL。

先修什么

1. 如果服务器响应慢，就从这里开始。其他所有指标都要等它。
2. 如果 LCP 不佳，先找到 LCP 元素。Lighthouse 会指出是哪一个。它通常是首屏大图（压缩它，不要对它使用懒加载，并考虑加上 fetchpriority="high"），或者是被字体或阻塞渲染的 CSS 拖住的标题。
3. 如果 Total Blocking Time 或 INP 不佳，就检查 JavaScript，尤其是第三方标签。
4. 如果 CLS 不佳，就为图片、嵌入内容、广告和横幅预留空间。
5. 每次改动之后都重新测试，这样才知道究竟是哪一项起了作用。

速度测试无法告诉你的事

实验室测试是在未登录状态下、从一个地点加载一个公开的 URL。它看不到登录之后那个缓慢的结账步骤，看不到只对另一个大洲的访客才慢的页面，也看不到滚动一分钟之后才出毛病的挂件。用它来发现和解释问题，然后在随后几周的实际用户数据中确认改进是否见效。

常见错误

• 一味追求 Lighthouse 满分，而不是关注访客真正感受得到的指标。
• 只在桌面端、用办公室的高速 Wi-Fi 测试。
• 对首屏大图使用懒加载，结果拖慢了 LCP。
• 装了好几个互相冲突的“加速”或缓存插件。
• 只凭一次测试就评判某项改动；每次测试的结果都会有波动。