页面性能优化技巧，把人工经验写成脚本需求时怎样描述例外情况

📍 WDQWDWQD987AAAAA:216.73.216.15
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /444038270193.html
📄

页面性能优化技巧，把人工经验写成脚本需求时怎样描述例外情况

核心做法是：不要只写“正常情况下怎么做”，而要把例外拆成可判定的条件、可观测的证据和明确的分支动作。人工处理时你凭直觉跳过的情况，脚本必须被显式告知，否则它要么误判，要么直接中断。下面用一个假设情境把这件事讲清楚。

先看一个假设情境：为什么常规脚本会卡住

假设你负责一个内容站，人工排查慢页面时有一套习惯：打开页面，看首屏主要资源是否加载完成，如果某个第三方脚本长时间没返回，你会手动跳过它，继续判断其余部分。现在你想把这套经验写成脚本，让它在批量页面上自动给出性能问题清单。

第一版脚本按“等待所有资源加载完成后统计耗时”来写。结果在部分页面上它一直等到超时，输出的结论是“无法判断”。你回看人工过程才发现：你从来不会等那个第三方脚本，你会先把它排除，再看剩下的资源。这个“排除”就是例外，而第一版脚本里根本没有它的位置。

例外要写成条件，而不是写成备注

把人工经验转成脚本需求时，最常见的失误是把例外写在说明里，比如“遇到第三方脚本可以忽略”。这句话对人有用，对脚本没用，因为“遇到”和“可以忽略”都不是可执行判断。

需要改成可判定的形式，至少包含三部分：

这样写之后，例外不再是注释，而是脚本可以走的一条路径。你也能在输出里看到它到底跳过了什么，而不是只得到一个“无法判断”。

把“我凭经验判断”翻译成可区分的原因

人工经验里最值钱的部分，往往是你如何区分两种看起来相同的现象。脚本需求要把这种区分写出来，否则它只能给出笼统结论。

假设同一批页面里，有的慢是因为主文档返回太晚，有的慢是因为主文档很快但后续资源拖长。人工看时你能感觉出差别，脚本若只统计总时长，就会把两类问题混在一起。需求里应当写明：

  1. 先记录主文档响应完成的时间点。
  2. 再记录首个关键资源开始加载的时间点。
  3. 如果两者间隔明显，归入“主文档等待”一类；如果间隔很小但整体仍长，归入“资源加载”一类。

这里的“明显”不能留给脚本猜，需要给出一个你愿意接受的阈值，并说明这个阈值是假设值，后续可以调整。阈值本身不是结论，它只是让脚本先把两类原因分开，便于你下一步分别处理。

一个实际动作：先跑例外清单，再决定改哪里

比较稳妥的动作是：不要一上来就让脚本输出“优化建议”，而是先让它输出一份例外清单，列出每个页面触发了哪些例外分支、跳过了哪些资源、跳过后剩余耗时是多少。

拿到这份清单后，你会面对两种不同情况：

这个动作的结果直接影响下一步：例外清单决定你是先修脚本，还是先修页面。跳过这一步，直接看总耗时，很容易把脚本自身的判定问题当成页面问题。

描述例外时必须写清的三个边界

除了条件和动作，还有三处边界容易漏写，漏掉任何一处都会让脚本行为不可预期。

例外的作用范围

要说明例外只影响当前页面的当前判定，还是会影响后续所有页面。例如“跳过该资源”是只跳过这一次，还是同一域名下全部跳过。范围不同，输出结果的解释方式完全不同。

例外与正常分支的优先级

如果多个条件同时成立，脚本先走哪条分支。人工处理时你会自动排序，脚本不会。需求里要写明顺序，例如先判断域名归属，再判断等待时长。

例外发生后的记录方式

例外不能静默处理。要写明记录哪些字段，例如页面标识、触发条件、被跳过的对象、跳过后的剩余指标。没有记录，你就无法判断例外是偶发还是系统性的。

比较改动前后时，别把例外清单当成唯一证据

假设你调整了例外条件后重新跑了一遍，发现进入例外的页面数量下降。这不能单独证明调整正确，因为页面本身、资源分布和采集时段都可能变化。更稳妥的做法是保留同一批页面标识，比较同一批页面在调整前后的分支归属，而不是只比较总数。

同时要意识到，请求量或某项统计归零，也可能只是采集方式变了、页面集合变了，或者例外条件把原本记录的对象排除掉了。把这些合理解释列出来，再决定是否需要进一步核对，比直接下结论更可靠。

把例外写清楚，本质上是把你脑子里的判断顺序外化成脚本能执行的分支。先让脚本如实报告它跳过了什么，再谈优化，顺序反了，后面每一步都会建立在错误的前提上。

图1 图2
nginx