提升网页打开速度 - 老站怎样寻找改进空间
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2f6d911e1a0e.html
📄
提升网页打开速度 - 老站怎样寻找改进空间
老站提升网页打开速度，改进空间不在“整体重做”，而在先把可测量的瓶颈找出来：用真实访问数据判断慢在服务器、资源还是第三方脚本，再按影响面排序处理。下面是一份可执行清单，每项都说明查什么、怎么查、结果意味着什么。
先确认“慢”发生在哪一段
打开浏览器开发者工具的 Network 面板，勾选 Disable cache 后刷新首页，看三个时间：TTFB（等待服务器首字节）、资源下载总时长、DOMContentLoaded 与 Load 的间隔。TTFB 长期超过 600ms，说明瓶颈在服务端或网络链路；TTFB 正常但 Load 很晚，说明问题多在前端资源。老站常见的情况是两者兼有，先记下占比再决定动手顺序。
查服务端与数据库的老化点
老站运行多年后，慢往往来自累积而非单点。可以按以下顺序排查：
- 查什么：首页与一个内页的 TTFB 差异。怎么查：同一网络下分别请求，对比数值。结果说明：只有内页慢，通常是该页查询或模板逻辑问题；全站都慢，指向服务器配置、数据库或缓存层。
- 查什么：是否启用了页面缓存。怎么查：看响应头中是否有缓存命中标识，或对比首次与二次请求的 TTFB。结果说明：二次请求没有明显变快，说明缓存未生效或命中率低。
- 查什么：数据库慢查询。怎么查：开启慢查询日志，观察访问高峰时段的记录。结果说明：出现大量全表扫描，说明老表的索引已跟不上当前数据量。
这一步的判断条件是：只有在 TTFB 明显偏高时才优先处理服务端；如果 TTFB 正常，把精力放到前端更划算。
查前端资源的体积与数量
在开发者工具的 Coverage 面板查看 CSS 和 JS 的实际使用比例。老站常见问题是历史样式和脚本不断叠加，单个页面加载了几百 KB 却只用到一小部分。同时检查图片：用 Network 面板按 Size 排序，看最大的几个文件是否为未压缩的 PNG 或未指定尺寸的图片。结果说明：未使用代码占比高，说明可以按页面拆分加载；图片体积远大于显示尺寸，说明需要压缩并改用现代格式。
查第三方脚本与阻塞资源
统计页面里来自外部域的请求数量，包括统计、客服、广告、字体等。逐个禁用后再测，观察 Load 时间变化。结果说明：某个第三方脚本移除后时间明显下降，它就是主要拖累项；如果禁用后变化不大，说明瓶颈不在它。另外查看 <head> 中是否有同步加载的脚本或样式，这类资源会阻塞首屏渲染，可以改为延迟加载或异步加载。适用条件是：第三方脚本属于业务必需时，优先考虑延迟加载而非直接删除。
按影响面排序并验证
把上面发现的问题列成表，标注“影响页面数”和“预计改善幅度”，从影响面最大的开始改。每改一项，用同一工具、同一网络条件复测一次，记录 TTFB 和 Load 的前后数值。判断标准是：改动后目标指标下降且没有引入新的报错，才算有效；如果数值没变，说明判断的瓶颈不在这里，回到上一步重新定位。老站尤其要注意，改动缓存或压缩配置后要清理旧缓存再测，否则看到的仍是旧结果。
下一步：先只做 TTFB 和 Network 面板这两项测量，把首页和一个高频内页的数据记下来，再决定从服务端还是前端入手。
