页面速度优化工具：工具停服后哪些数据应该优先迁出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7c3d84a543e.html
📄
页面速度优化工具：工具停服后哪些数据应该优先迁出
优先迁出的是无法重新采集的历史观测值：带时间戳的现场数据、已保存的对比基线、以及人工标注过的问题记录。页面本身、静态资源和公开配置通常可以最后处理，因为它们随时能从线上重新抓取或导出。判断顺序不是“哪个文件大”，而是“哪个数据一旦丢掉就再也造不出来”。
先分清两类数据：可重建与不可重建
停服通知发出后，最容易被误判的是报告页面。你看到的是图表和分数，但工具真正持有的原始数据可能只有它自己才有。迁移前先做一次分类。
- 可重建数据：当前页面 HTML、CSS、JS、图片体积、请求瀑布图的实时抓取结果。只要页面还在线，换一个工具或自己用命令行都能重新得到近似结果。
- 不可重建数据：过去若干个月的现场速度分布、某次改版前后的对比快照、你手动标记为“已确认误报”的条目、以及带日期的第三方脚本耗时记录。这些依赖当时的真实用户环境和时间点，事后无法还原。
假设你手里有一个跑了半年的监测项目，保存了每周的现场数据。停服后如果只导出当前分数，你失去的是趋势；如果只导出趋势图图片，你失去的是可再计算的原始字段。两者代价不同，前者影响判断，后者影响复用。
迁移顺序：先冻结时间点，再导出可计算字段
实际操作可以按下面三步走，每一步的结果决定下一步做什么。
- 先截取一份完整快照。在工具还能访问时，把当前所有监测页面、时间范围、指标名称和筛选条件记录下来。动作结果是得到一份“数据字典”，它让你在导出文件缺少列名时仍能对应回原意。
- 导出带时间戳的原始行，而不是汇总图。优先选择 CSV 或 JSON 这类可再计算的格式。如果工具只提供图片或 PDF，退而求其次，但要在文件命名中写清抓取日期和页面范围。动作结果是后续可以用表格工具重新画趋势，而不依赖原工具的图表。
- 最后处理注释和人工标记。这类数据往往藏在单条记录的备注里，导出时容易被忽略。检查一遍你曾经标记过“忽略”“已修复”“待确认”的条目，把它们单独复制出来。动作结果是新工具接入后不必重新判断同一批已知问题。
如果时间只够做一件事，先做第 2 步。因为注释可以凭记忆重建一部分，而原始时间序列一旦停服就彻底消失。
两种常见做法的取舍条件
面对停服，读者通常会在“全量导出”和“只迁关键页面”之间犹豫。两种做法都成立，但条件不同。
选择全量导出，前提是你有足够的存储和后续处理能力，并且这些页面未来还可能被再次分析。代价是导出文件可能很大，字段冗余，迁移后需要花时间清洗。适合监测范围固定、页面数量有限、且团队有表格处理习惯的情况。
选择只迁关键页面，前提是你能明确哪些页面与业务结果直接相关，例如主要落地页或转化路径上的页面。代价是放弃长尾页面的历史趋势，未来若想回看会缺少依据。适合页面数量庞大、历史数据价值密度低、且人力有限的情况。
判断依据可以是一个简单问题：如果三个月后有人问“这个页面当时为什么变慢”，你手里有没有数据能回答。能回答的页面优先迁，不能回答的可以放弃。
迁移后的验证：用同一页面做一次对照
数据导出完成不等于迁移成功。挑一个页面，用新工具或手工方式重新采集一次当前状态，然后和迁出的最后一条记录比较。注意，这里比较的是同一页面、同一指标、相近时间点，而不是拿旧工具的历史分数直接和新工具的当前分数比。因为采集环境不同，数值本来就可能不一致。
如果差异在合理范围内，说明迁移的数据字段可以继续使用；如果差异很大，先检查时间范围和设备类型是否对齐，再决定是否需要在旧数据旁标注“采集条件不同”。这一步的动作结果，是让你在后续引用历史数据时知道它的可信边界。
停服迁移不是把文件搬走就结束。真正要保住的是“当时发生了什么”的可追溯性，以及“以后还能不能重新算一遍”的能力。先冻结时间点，再导出可计算字段，最后补上人工判断，这个顺序比追求一次性导出全部内容更稳妥。
