访问日志本身不直接反映加载性能，但通过自定义log_format记录$request_time、$upstream_response_time、$body_bytes_sent等字段，并结合awk分析请求耗时、带宽消耗、缓存状态（如304占比）及资源类型分布，可精准反推静态资源加载效率与瓶颈所在。
直接看访问日志本身无法实时反映“加载性能”，但结合合理配置与日志字段，可以精准统计静态资源的带宽消耗、请求频次、缓存命中情况和响应延迟，从而反推加载效率。关键不在日志本身，而在你记录了哪些信息、怎么分类分析。
确保日志包含必要字段
默认 access_log 只记 IP、时间、状态码、字节数，远远不够。需自定义 log_format，显式捕获以下维度：
- $request_time：整个请求处理耗时（秒，含后端等待），是评估“加载慢不慢”的核心指标
- $upstream_response_time：Nginx 到上游（如后端服务）的真实响应耗时，用于区分是 Nginx 本机慢还是后端拖累
- $bytes_sent 或 $body_bytes_sent：实际发给客户端的字节数，真实带宽消耗依据
- $request_uri 和 $status：识别资源路径与是否命中缓存（如 304 表示浏览器用了本地缓存）
- $http_referer 和 $http_user_agent：辅助判断是否被盗链、是否来自爬虫或异常 UA
示例配置：
log_format static_analyze '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$request_time $upstream_response_time '
'"$http_referer" "$http_user_agent"';按文件类型聚合分析带宽与请求数
静态资源集中在特定后缀，用 awk/grep/awk + sort 快速统计：
- 统计图片、JS、CSS 总带宽（单位 MB）：
awk '$9 ~ /\.(jpg|jpeg|png|gif|js|css)$/ {sum += $6} END {printf "%.2f MB\n", sum/1024/1024}' /var/log/nginx/access.log - 查看 TOP 10 最耗带宽的静态文件：
awk '$9 ~ /\.(jpg|jpeg|png|gif|js|css)$/ {count[$9]++; bytes[$9] += $6} END {for (i in bytes) print bytes[i], i | "sort -nr | head -10"}' /var/log/nginx/access.log - 检查缓存有效性：统计 304 响应占比（越高说明浏览器缓存越有效）
awk '$status == "304" {n++} END {print n/NR*100 "%"}' /var/log/nginx/access.log
用 request_time 定位慢资源
加载性能差往往由个别大文件或高延迟响应导致。筛选耗时超过 1 秒的静态请求：
- 查出所有 >1s 的图片请求及对应大小：
awk '$9 ~ /\.(jpg|png|gif)$/ && $7 > 1 {print $7, $6, $9}' /var/log/nginx/access.log | sort -nr | head -20 - 对比 $request_time 和 $upstream_response_time：若前者远大于后者，说明瓶颈在 Nginx 本机（如磁盘 I/O、CPU、sendfile 配置不当）；若两者接近，说明是后端或网络问题（但静态资源通常不走后端，此情况少见）
关联缓存头验证配置是否生效
日志不直接记录响应头，但可通过状态码 + URI 推断缓存行为，再用 curl 抽样验证：
- 对高频 JS/CSS 资源执行：
curl -I https://yoursite.com/static/app.min.js - 检查返回中是否有 Cache-Control: max-age=2592000 或 Expires，确认是否命中你配置的 long-term 缓存策略
- 若大量 200 响应却无缓存头，说明 location 匹配失败或配置未 reload；若全是 304 却 request_time 很高，可能是 ETag 计算开销大（可改用基于修改时间的 Last-Modified）
