页面速度优化在页面数量翻倍后，哪些工作不该再手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a28b1c8f2ce4.html
📄
页面速度优化在页面数量翻倍后，哪些工作不该再手工做
当站点从几十个模板扩展到成百上千个 URL 时，手工逐页压缩图片、逐页填 width 和 height、逐页删未用 CSS，会从"精细"变成"无法收尾"。判断标准很简单：这项工作是否需要对每个 URL 单独判断，还是同一模板的页面可以共享同一套处理规则。后者应当交给构建流程或服务端统一执行，前者才留给人工抽查。手工做模板级工作时，遗漏的页面不会报错，只会静默变慢，而你有几百个页面时根本发现不了。
条件一：页面由同一套模板生成，就停止逐页手工改
如果列表页、详情页、分类页各自只有一套模板，那么图片尺寸、懒加载属性、字体加载方式、关键 CSS 都属于模板级决策。手工逐页修改的问题不是慢，而是不可验证：你不知道改了多少页、还剩多少页、下次模板更新后改动是否被覆盖。
实际动作是把这些规则写进模板或构建步骤，例如统一输出带尺寸属性的图片标签：
<img src="..." width="800" height="600" loading="lazy" alt="...">
这个动作的结果是：新发布的页面自动带上尺寸，不会出现布局跳动；下一步你只需要抽查渲染后的 HTML 是否真的输出了这些属性，而不是逐页确认。注意例外：首屏主图、轮播第一帧这类影响最大内容绘制（LCP）的元素，通常不适合统一加懒加载，需要单独标记为优先加载，这类页面数量少，反而适合人工确认。
条件二：页面由编辑器自由拼装，就别指望统一规则覆盖全部
如果内容团队可以在页面里自由插入第三方脚本、视频嵌入、自定义组件，那模板级规则只能覆盖骨架，覆盖不了每个页面实际塞进去的东西。这时继续手工优化的对象不是"所有页面"，而是"被反复使用的组件"。
选择依据是复用次数：同一个嵌入组件出现在几十个页面上，修一次组件比修几十个页面更划算；只出现在一两个页面的特殊组件，手工处理即可，不值得为它建一套流程。动作上，先按组件统计出现频次，再决定哪些组件进入统一处理清单。结果是你的优化清单从"页面列表"变成"组件列表"，长度通常短一个数量级，也更容易在改版后维持。
监控也要从逐页检查改成抽样加阈值
页面数量上来后，逐页跑性能测试不现实，而且单页分数波动大，容易把噪声当问题。更可行的做法是固定抽一组代表性 URL（每类模板各取几个），用同一套条件反复测，关注趋势而不是单次数值。
需要提醒的是：抽样的那几页变快，不能证明整站变快；反过来，某次测试分数下降，也可能只是测试环境、网络或第三方脚本波动，而不是你的改动出了问题。把抽样结果和构建产物检查、真实用户指标结合起来看，比盯着单页分数更可靠。
这些工作仍然值得手工做
- 首屏关键资源的取舍：哪些脚本必须同步加载、哪些可以延后，需要结合具体页面意图判断。
- 新引入的第三方脚本评估：它带来的功能和它拖慢的范围，通常没有现成规则可套。
- 模板改版后的抽查：确认统一规则没有被新模板绕过。
- 异常页面的定位：抽样中发现某类页面持续偏慢时，回到具体页面查原因。
把可复用的部分交给流程，把需要判断的部分留给人，是页面规模扩大后能持续做下去的前提。下一步可以从统计每类模板的页面数量开始，页面数最多的那类模板，就是最该先停止手工处理的地方。
