页面加载加速：规模扩大后哪些工作不能继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3ba039e44c48.html
📄
页面加载加速：规模扩大后哪些工作不能继续手工做
当页面数量、模板变体和上线频率一起增长，最先失效的不是优化技巧，而是“每次靠人记得去做”的流程。手工压缩图片、逐页检查缓存头、人工记录资源体积，在几十个页面时还能维持；到几百上千个页面、多人并行改版时，遗漏会变成常态。下面用一个假设情境，把判断标准和一个可执行动作讲清楚。
先看一个假设情境：从八十页到六百页之后
假设某站点最初只有八十个页面，由两名编辑维护。图片上传前手动压缩，样式表改动后手动检查体积，每上线一个新栏目就顺手确认一次缓存设置。这套做法当时有效，因为改动少、范围小、每个人都能记住全貌。
后来页面涨到六百个，模板从三套变成九套，编辑增加到六人，还接入了活动页和专题页。此时仍沿用旧习惯，会出现三种可观察的后果：同一张图在不同页面重复上传且体积不一；某个模板的样式文件悄悄变大，但没人知道是哪次提交造成的；新栏目上线两周后才发现部分资源没有走缓存。这些现象不一定直接对应排名变化，但它们共同说明一件事——检查动作没有跟随规模一起被自动化。
哪些工作一旦规模扩大就不该继续手工做
判断标准不是“手工能不能做完”，而是“手工做是否会产生系统性遗漏”。满足以下任一条件，就应转为规则化或自动化处理：
- 重复次数随页面数线性增长：图片压缩、资源体积核对、基础缓存头确认。页面越多，人工逐条检查的覆盖率越低。
- 依赖个人记忆而非文档：某个模板要避开某种写法、某个目录的资源要单独处理。人一换、时间一久，规则就丢失。
- 需要在每次上线时重复执行：把检查挂在上线流程里，而不是靠事后补查。
- 结果需要横向对比才有意义：单页体积正常，但同类模板之间差出明显差距，只有批量汇总才看得出来。
反过来，仍适合人工介入的是那些判断依赖上下文的工作：决定某个首屏大图是否值得保留、评估一次改版对核心页面的取舍、判断某个第三方脚本是否真的必要。这些不是重复劳动，而是取舍。
一个实际动作：把检查挂到构建或上线环节
假设站点使用构建流程。可以加入一个体积预算检查：为不同模板类型设定资源体积上限，构建时若超出就中断并输出超限文件清单。这个动作的结果不是“页面一定变快”，而是把“谁在什么时候把体积推高了”变成一次可见的失败，让问题在合并前暴露，而不是上线后靠人翻找。
动作与下一步的关系很直接：如果构建检查频繁因同一类文件失败，说明问题出在模板或依赖，应改模板或替换依赖；如果检查很少失败但线上仍慢，说明瓶颈不在静态资源体积，应转向服务端响应、第三方脚本或渲染路径排查。检查结果决定了下一步往哪个方向走，而不是继续加检查项。
手工流程还容易漏掉的一个条件：规则没有版本
规模扩大后，真正被忽略的往往不是某项技术，而是“规则本身”的维护。手工时代，规则存在人的经验里；页面变多后，规则需要写下来、进版本库、随模板一起评审。否则会出现一种反常现象：优化动作一直在做，但新页面持续引入旧问题，整体指标看起来没坏，实际是新增页面在抵消老页面的改善。
可操作的做法是把规则写成可执行的检查项，和代码一起提交。规则变更时留下记录，这样当某次检查被放宽或收紧，能回溯原因，而不是变成又一条只存在于某个人记忆里的口头约定。
什么时候仍应保留手工判断
自动化负责覆盖率和一致性，人工负责取舍和例外。以下情况继续手工更合适：首次引入某类新资源、需要评估业务价值与加载成本的权衡、以及自动化规则尚未覆盖的新模板。前提是这些手工判断的结果要回流成规则，否则规模再扩大一次，同样的遗漏会重演。
把重复检查交给流程、把取舍留给人，并让规则本身可追溯，才是页面规模扩大后仍然能持续做加载加速的前提。
