Lighthouse评分卡在80分上不去主因是HTML性能瓶颈：DOM节点过多、内联脚本阻塞渲染、document.write残留、服务端模板冗余空格/注释；需控制DOM节点
为什么 Lighthouse 评分卡在 80 分上不去
多数人卡在 80–90 分之间，不是因为没压缩图片或没写 alt，而是 HTML 本身成了性能瓶颈：DOM 节点过多、阻塞渲染的内联脚本位置不对、document.write 残留、或服务端模板拼接出大量冗余空格与注释。Lighthouse 的「减少主线程工作」和「避免长任务」这两项，常被误认为是 JS 问题，实际源头可能就在 HTML 结构里。
- 用
document.querySelectorAll('*').length查 DOM 节点数，超过 1500 个就该警惕（移动端尤其敏感） - 检查
里有没有<script></script>同步加载第三方 SDK（比如老版本百度统计、友盟），它们会阻塞 HTML 解析 - 服务端渲染（SSR）时若用字符串拼接生成 HTML，容易带入大量不可见字符——用
html-minifier-terser或构建时启用collapseWhitespace: true可压掉 15–20% 的首字节体积
内联 CSS/JS 放哪儿才不拖慢首屏
内联资源不是“放 就完事”。Lighthouse 的「消除阻塞渲染的资源」警告，往往来自内联代码体积过大或位置不当。关键不是“要不要内联”，而是“内联多少”和“内联到哪”。
-
<style></style>内联必须限制在「首屏关键样式」（Critical CSS），超出 2KB 就建议外链 +preload，否则会延长 HTML 解析时间 -
<script></script>内联只用于极小的初始化逻辑（如数据打点配置），且必须加type="module"或defer；否则浏览器会同步解析执行，冻结 DOM 构建 - 别把 Webpack 打包后的
runtime内联进 HTML——它通常含大量函数定义，首屏解析耗时飙升，应单独<script src="runtime.js" defer></script>
HTML 预加载提示（preload）怎么写才生效
preload 不是加了就一定提前加载，浏览器会按优先级、MIME 类型、当前网络条件动态决策。常见失效场景是路径错误、类型声明缺失、或加载时机错配。
- 必须显式声明
as属性：<link rel="preload" href="main.css" as="style">，漏掉as会被当普通prefetch处理，延迟加载 - 字体文件需加
crossorigin：<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>，否则可能因 CORS 策略被丢弃 - 不要对 HTML 自身
preload——浏览器已按协议强制优先获取主文档，加了反而触发重复请求（DevTools Network 标签页能看到duplicate提示）
服务端响应头和 HTML 的协同优化点
HTML 性能不只是写法问题，还依赖服务端配合。很多团队改完 HTML 却没动响应头，导致缓存失效、压缩未启用、或 MIME 类型识别错误。
立即学习“前端免费学习笔记（深入）”；
- 确保响应头含
Content-Type: text/html; charset=utf-8，缺charset会让浏览器触发字符集探测，增加首字节延迟 - 启用 Brotli 压缩（比 Gzip 高 15% 压缩率），但需在 HTML 响应头中明确设
Vary: Accept-Encoding，否则 CDN 可能缓存未压缩版本 - 静态 HTML 文件建议加
Cache-Control: public, max-age=3600，但注意：若用 CMS 动态生成，max-age设太高会导致内容更新延迟，宁可设max-age=60+ ETag 验证
真正卡分的地方，往往藏在 HTML 和服务器握手的那几十毫秒里——比如一个没设 crossorigin 的字体 preload，或一行没删干净的 console.log 模板注释。这些细节不报错，但会让 Lighthouse 在「诊断」阶段默默扣掉 2–3 分。
