Axis笔记

外观

3.3 优化项定位

约 676 字

性能检测

本页对应「三、操作步骤」的 3.3，把 3.2 得出的嫌疑对象落到具体文件与具体请求上，形成按收益排序的优化清单，并逐项验证。返回上级：性能检测。

前置条件

  • 3.2 已给出瓶颈方向：传输、渲染或主线程，并至少有一个具体嫌疑对象。
  • 站点资源可通过 URL 直接访问，源站文件位于 /srv/axis 下，可对照实际文件。
  • 已建立本次采集的基线数值，用于判断优化是否有效。
  • 已确认 3.2 的瓶颈方向与嫌疑对象，避免在错误方向上做优化。
  • 源站文件可读，能对照线上资源与实际文件的大小和格式。

操作步骤

  1. 从报告列出体积最大的资源，按体积排序确认优化顺序：
jq '.audits["network-requests"].details.items
  | sort_by(.transferSize) | reverse | .[:10]
  | .[] | "\(.transferSize)\t\(.url)"' \
  /srv/axis/metrics/2026-02-10/home.json
  1. 核对单个资源的响应头，确认压缩与缓存是否生效：
curl -sSI "https://cdn.example.com/assets/app.9f2c1a.js" \
  | awk 'BEGIN{IGNORECASE=1} /^(content-encoding|content-length|cache-control|age):/'
  1. 对首屏主图做尺寸与格式核对，确认没有用大图缩显：
curl -sS -o /tmp/hero.jpg "https://cdn.example.com/assets/hero.jpg"
file /tmp/hero.jpg && du -h /tmp/hero.jpg
ls -l /srv/axis/assets/ | sort -k5 -nr | head -n 10
  1. 把优化项写进清单，每条注明目标、改法与验证指标，例如“hero.jpg 转 WebP、宽 1200，目标 LCP 降低 300ms”。

结果确认

  • 清单中每条优化项都能对应一个具体文件路径或请求 URL，没有“整体优化”这类无法执行的条目。
  • 资源响应头显示已启用压缩（如 content-encoding: br）与合理缓存时长。
  • 首屏图片实际尺寸与展示尺寸匹配，文件体积在可接受范围。
  • 每项改动后重新采集同页指标，记录变化值，收益为负的项已回退。

注意事项

  • 一次只改一类优化项，改完立刻复采，多项同时改会无法判断收益来源。
  • 压缩与缓存属于 CDN 与源站配置，改动前确认有回滚路径。
  • 优化排序按“收益 ÷ 改动成本”进行，不要先做收益小且风险高的项。
  • 每项改动单独提交并单独复采，多项合并验证时无法判断哪一项带来了收益。
  • 图片格式转换要保留原图，转换后对比体积与清晰度，压缩过度会换来更差的阅读体验。
  • 优化清单完成后归档一份结论文档，写明做了什么、指标变化多少、哪些项验证后放弃。