指南
网站性能审计：脱离虚假核心指标
快速的 HTML 响应是至关重要的实测依据，但这绝不等同于真实浏览器环境下的 LCP、INP 或 CLS 体验指标。
利用服务器耗时与标记体积预算排查前端交付瓶颈。在宣称 Core Web Vitals 达标前，必须结合浏览器实验室测试与实地数据。
从响应交付链路着手排查
精准记录 DNS 解析、TLS 握手、首字节耗时 (TTFB)、重定向多跳、服务端压缩 (Brotli 或 Gzip) 以及 HTML 传输体积。一个控制在 150 KB 以内的轻量级 HTML 文档能让浏览器极速分词并渲染初始 DOM。在着手优化次要资源前，应首先解决失败响应、多余的 301/302 重定向以及缓慢的后端源站处理。
区分工程指标预算与真实用户体验
HTML 体积、DOM 复杂度（保持总节点数少于 1,500 个）以及外部脚本数量属于服务器与标记层面的工程预算。Core Web Vitals 反映的是真实用户的交互感知，需要浏览器排版引擎参与；现场指标（LCP、INP、CLS）必须基于第 75 百分位真实用户访问数据（如 Chrome UX Report）进行评估，而非单次服务端 ping 请求。
严格审视关键渲染路径
重点排查文档 head 中缺少 async、defer 或 type='module' 属性的传统同步阻塞脚本。精简外部样式表请求（建议关键 CSS 文件少于 6 个）并压缩内联脚本体积。将大型内联 JavaScript 代码（> 100 KB）抽离至可长期缓存的外部静态资产中，能显著减少 HTML 初次解析时的主线程阻塞。
优化静态资产与图像加载策略
确保首屏以下的图片均显式标注原生的 loading='lazy' 并带有具体的 width 和 height 属性，避免造成累积布局偏移 (CLS)。对首屏主图 (Hero Image) 保持主动预载 (fetchpriority='high')，防止人为推迟 LCP 触发时间。积极采用 WebP 或 AVIF 等现代高压缩比图像格式。
依据对用户的影响确定实施顺序
在追求微观代码优化之前，优先解决缓慢的数据库查询瓶颈与渲染阻塞外部资源。在每次重大改动前后，务必结合受限网络条件下的自动化实验室跑分与真实用户监控，确保速度提升真实可测。