我的网站为什么这么慢？原因与解决方法
最后更新:
你的网站会加载，只是要等。访客不会等。如果你曾看着自己的首页在手机上慢慢爬，心想到底哪里出了问题，这篇文章就按通常重要的顺序梳理真正的原因，以及每项修复实际需要做什么。没有空泛建议。真正的元凶，依次列出。
弄清网站为什么慢，最快的办法是什么？
用 Google PageSpeed Insights（pagespeed.web.dev）检测你的网站。它免费，测试真实页面，并告诉你 Core Web Vitals，以及一份按优先级排列的拖慢页面的清单。测试最重要的页面（通常是首页或关键产品页），并选移动端，因为慢在那里最伤。
PageSpeed 会给出三个值得了解的数字。Largest Contentful Paint（LCP） 是主要内容出现所需的时间，谷歌认为低于 2.5 秒为良好。Cumulative Layout Shift（CLS） 衡量页面加载时的跳动幅度，低于 0.1 为良好。Interaction to Next Paint（INP） 衡量页面对点按或点击的响应速度，低于 200 毫秒为良好。若其中任何一项处于红区，报告会直接指向原因。先从这里入手，再动手改，否则就是在猜。
关于分数本身的一点提醒：顶部那个大数字在多次测试间会大幅波动。不要追求 100。请看 “Diagnostics” 和 “Opportunities” 两栏，那里才是真正的操作指引。
网站变慢的真正原因，依次列出
大多数慢速网站慢的原因不外乎六种，且通常按这个影响顺序出现。下面列出每一项及其修复方法。
| 原因 | 常见程度 | 常见修复 | 工作量 |
|---|---|---|---|
| 图片过大 | 非常常见 | 压缩 + 缩放 + 提供 WebP | 低 |
| 主机慢或超载 | 常见 | 迁移到更快、资源充足的主机 | 中 |
| JavaScript 过多 / 插件笨重 | 常见 | 移除或延迟非必要脚本 | 中 |
| 没有缓存或 CDN | 常见 | 启用缓存 + 内容分发网络 | 低到中 |
| 阻塞渲染的 CSS 和字体 | 中等 | 延后非关键 CSS，预加载关键字体 | 中 |
| 臃肿的生成器/主题 | 中等 | 更换笨重主题或精简重建 | 高 |
图片过大是头号原因
图片是大多数页面上最重的部分，未优化的图片是网站让人觉得慢的最常见原因。直接从手机相机拍出的照片可能有 4 到 8 兆字节。在一个总体本应只有几百千字节的页面上，一张这样的图片就会拖垮一切。
修复要三件事一起做：把图片缩放到它实际显示的尺寸（一张 4000 像素宽的照片显示在 800 像素的位置，浪费了 80% 的数据），压缩它，并用 WebP 这样的现代格式提供，通常比同等 JPEG 小 25% 到 35%。顺手为图片加上宽度和高度属性，让页面在图片加载时不跳动，这也能修复一部分 CLS 分数。
廉价或超载的主机是被忽视的原因
这一项最容易被误诊。站长花好几天压缩图片、精简代码，网站仍然慢，因为瓶颈是服务器本身。在廉价的共享主机上，你的网站和几百个其他网站挤在同一台机器上，争抢同样的内存和 CPU。某个“邻居”流量激增时，你的网站就变慢，而你这边无能为力。
你可以在 PageSpeed 中通过过高的服务器响应时间（也叫 Time to First Byte）发现这一点。如果服务器仅仅是开始发送页面就要超过约 600 毫秒，那问题在主机，而不是图片。还有第二个主机因素：服务器的物理位置。服务器离访客越远，每个请求就增加越多延迟，这也是内容分发网络（下文详述）即便在服务器本身没问题时也有用的原因之一。
这是我们在“以前还好好的”网站背后最常见到的原因。我们的快速托管主机运行在资源配置得当的基础设施上，配有免费 SSL、每日备份和监控，不会让一个吵闹的邻居来决定你业务的加载速度。
JavaScript 和插件太多
页面加载的每个脚本都必须先下载、解析并运行，页面才能完全可交互。一个多年来攒了十几个插件、一个聊天小工具、三个分析工具、一个弹窗生成器、若干社交信息流的网站，每次访问都要运行大量代码。这通常就是 INP 分数差的背后原因：页面看起来已就绪，点按却没反应，因为浏览器还在忙。
修复靠的是审查，不是猜测。列出每一个脚本和插件，逐个问它是否对得起自己的分量。不用的就删掉。保留的部分，把首次渲染不需要的内容延迟或异步加载，让可见页面先出现，后台脚本随后再完成。
没有缓存，也没有 CDN
没有缓存，你的服务器会为每一个访客从头重建整个页面，哪怕内容没有任何变化。缓存会保存一份现成副本并直接提供，这快得多，也更省服务器。CDN 更进一步，在世界各地的服务器上保留你网站的副本，让北京或上海的访客从就近的位置拿到你的页面，而不是隔着一个大洲。
两者通常都是快速见效的改进。许多主机已包含缓存，Cloudflare 提供的免费 CDN 套餐足以覆盖大多数小企业的需求。如果两者都没用，这往往是最便宜的一大块提速空间。
阻塞渲染的 CSS 和字体
这一项更隐蔽。浏览器在加载完页面头部的 CSS、往往还有字体之前，不会显示你的页面。如果这些文件很大，或从一个缓慢的第三方加载，访客就会在下载期间盯着一片空白。从外部服务调用的自定义字体是常见元凶。
修复方法虽偏技术但很成熟：把页面顶部所需的少量 CSS 内联，其余延后；自行托管字体而不是调用第三方；并设置 font-display: swap，让文字立刻以后备字体显示，而不是干等。在图片和主机处理好之后，这类工作对 LCP 分数的提升最大。
笨重的页面生成器和臃肿的主题
一些流行的拖放式生成器和多用途主题，会为支持你某天可能用到的每个功能而生成海量代码。每次页面加载你都要为全部买单，包括你从不碰的功能。如果你的网站建在一个笨重的主题上，其他都修了它仍然迟缓，那地基本身可能就是上限。
这里没有轻巧的修法。诚实的答案是：一个为用途而生的精简网站，永远胜过臃肿的网站；到了某个点，在干净的地基上重建，比无止境地围着臃肿打补丁更省。这是更大的决定，也是多数站长寻求帮助的时刻。
什么时候该停止自己折腾、找专业人士？
当你已经跑过 PageSpeed、修好图片和缓存等明显问题，网站仍然慢时，或当报告指向主机、阻塞渲染的资源或主题臃肿时，就该找帮手了，这些在运行中的网站上更难安全修复。这些情况下，反复试错有弄坏网站的风险。
一些该出手的迹象：变慢始于更换主机或流量上升（主机问题），分数被 “reduce unused JavaScript” 或 “eliminate render-blocking resources” 拉低（代码问题），或者你干脆已经无法正常编辑网站。Web Roots 正是通过网站迁移与抢救处理这些，把慢速网站零停机、无排名损失地迁到更快的主机上；以及在真正的解法是精简重建时，通过网站设计与开发来解决。
修好之后，如何让网站保持快速？
速度不是一次性的修复，随着你不断添加图片、页面和工具，它会慢慢回落。用几个习惯保持它：每张图片上传前先压缩；每年检查两次插件，删掉不用的；保持缓存开启；每次重大改动后重新跑一遍 PageSpeed，好在当周就发现退步，而不是几个月后客户开始流失时才察觉。
可靠的主机会在后台默默完成其中很多事。在有监控的托管网站主机上，那种让多数网站措手不及的缓慢下滑，会在它成为某人离开的理由之前被发现并处理。
做完简单修复后网站仍然慢？我们会找到真正的原因并解决，包括零停机、无排名损失地把你迁移到更快的主机。联系 Web Roots，让你的网站快起来。