Axis笔记

外观

3.2 结果解读

约 680 字

性能检测

本页对应「三、操作步骤」的 3.2，完成指标的分层解读：先看数值是否越线，再看各阶段耗时占比，最后判断瓶颈落在网络传输、渲染还是脚本执行。返回上级：性能检测。

前置条件

  • 3.1 已完成，每个页面至少 3 份 JSON 报告，且已算出中位数。
  • 已明确这次对比的基线版本与其采集时间。
  • 知道站点的首屏结构：首屏主图、字体、主脚本分别是什么。

操作步骤

  1. 先取分项得分与阶段耗时，建立整体印象：
jq -r '.audits | to_entries
  | map(select(.value.numericValue != null and (.value.numericValue|type) == "number"))
  | .[] | "\(.key)\t\(.value.numericValue|floor)"' \
  /srv/axis/metrics/2026-02-10/home.json | sort -k2 -nr | head -n 20
  1. 判断传输侧问题：若 TTFB 偏高，问题多在 CDN 回源或源站响应；若 TTFB 正常而 LCP 高，问题多在首屏资源。
curl -sS -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer}\n" \
  "https://cdn.example.com/"
  1. 判断渲染侧问题：查看 CLS 与布局位移相关的审计项，确认是否由图片、字体或占位缺失引起。
jq '.audits["layout-shift-elements"].details.items[]? | {node, score}' \
  /srv/axis/metrics/2026-02-10/home.json
  1. 判断主线程问题：查看长任务与脚本执行时间，确认是否有单个脚本阻塞渲染。
jq '.audits["bootup-time"].details.items[]? | {url, total}' \
  /srv/axis/metrics/2026-02-10/home.json | head -n 20

结果确认

  • 能明确写出结论句式：“该页 LCP 主要消耗在首屏主图传输”，而不是笼统的“页面慢”。
  • TTFB 与 LCP 的关系已核对：两者同时高说明问题在服务端，仅 LCP 高说明问题在前端资源。
  • 已找出至少一个具体元素或脚本作为嫌疑对象，并记录其在报告中的位置。
  • 与基线的差值是同页面、同环境下的对比结果，未混入不同设备的数据。

注意事项

  • 分数高低受设备与网络影响，解读以具体毫秒值与元素为准，不要以分数作为唯一结论。
  • 单项指标改善而另一项明显恶化时，需回到 3.1 复采确认，不要用一次结果定论。
  • 第三方脚本的耗时经常被忽略，解读时把外部域名单独列出来看。
  • 结论要带数值与出处，例如“LCP 2.8s，主要为首屏图 1.4MB”，便于他人复核。
  • 同一页面的移动端与桌面端结论分开写，两者瓶颈常常不同，合并成一句会误导优化方向。
  • 报告中的审计项名称随工具版本变化，引用时同时写出指标值，避免版本升级后无法对照。