查清网页加载负担，保留功能做瘦身
输入为目标页面、源代码、可用的测量环境和变更范围。输出为基于实测的优先级、获准的修正，以及变更前后的确认结果。服务器存储量的增加由 data-growth-guard 负责。
执行步骤
- 从请求中区分“仅评估”“仅压缩”和“同时改变加载结构”。仅评估时不做修改；仅压缩时不得扩展到数据结构或获取方式的改变。阅读实际代码、页面规格以及生成和发布流程，保持现有 UI 与数据含义。
- 将首次加载的 HTML、JS/CSS、业务 JSON/API 和第三方资源分开，记录实际传输量与请求数。分别确认解压后体积、JSON 解析、渲染和停留期间的重复获取；未测量的项目必须明确标注。从共享组件追踪到详情页，检查重复打包的运行库和不必要的列表 bundle 加载。
- 区分 gzip 文件是否存在与浏览器是否实际使用。沿真实加载路径确认 Content-Encoding、MIME、解压后的内容以及切换到普通 JSON 的情况。不得把本地压缩估算称为已经公开取得的效果。
- 只在获准范围内修改确实有效的部分。检查不必要的重复获取、未使用字段、压缩以及现有缓存的重新验证。拆分或预计算也要依据使用范围与解压后的解析、渲染负担；压缩后传输量小不代表处理轻。不得把分页、压缩、缓存和延迟加载视为同一措施。
- 列表从所需范围内可重新生成的投影读取，详情则从可用稳定 ID、日期等条件定位的完整记录读取。不要一次获取首次显示之外的标签页或历史记录。不得混淆公开期间与原始数据的保存期限。
- 改变数据格式时，要同步安排写入端、压缩副本、读取端和发布顺序。先验证新数据，再切换读取端；不得通过静态发布覆盖生产数据。改变压缩配信或指纹资源时，阅读 发布验证与失败案例，在确定 hash 前安排最终内容及引用关系，并比较最终发布物与解压后的内容。
- 在生产构建和浏览器中确认桌面端与移动端的图表、菜单、文字、SVG、对话框和详情显示。不得删除必要的 CSS 或图表来减轻负担。若要改变 CSS 的发布方式，必须先准备等效的已构建样式。
- 涉及发布时，重新测量实际响应。分别报告传输量减少和交互、渲染速度的变化；页面改善空间很小时，不要继续建议额外改造。
复用现有的压缩 writer/reader、计算器和发布工具。只有在改变保存设计时才阅读 data-growth-guard；只有在涉及发布和生成物保护时才阅读 static-deploy-refresh-check。如果技能尚未导入，说明所需范围，不要声称已经调用。
