Lighthouse评分与真实HTML性能感受不一致，因其基于静态分析和模拟加载判断，用HTML体积、内联资源、阻塞脚本等代理指标替代真实渲染速度；实际首屏体验更取决于TTFB、CDN缓存、服务端渲染效率及未标记async的脚本执行。
为什么 Lighthouse 评分和真实 HTML 性能感受不一致
Lighthouse 的 HTML 相关评分（如 “Avoid enormous network payloads”、“Minimize main-thread work”）本质是基于静态分析 + 模拟加载的启发式判断，并不直接测量 HTML 渲染速度。它会把 index.html 文件体积、内联脚本/样式的字节数、是否含阻塞渲染的 <script> 等作为代理指标，但这些和用户实际感知的“首屏快不快”常有偏差。
常见错觉：HTML 压缩到 5KB，Lighthouse 评分涨到 95，但首屏仍白屏 1.2s——问题可能出在服务端模板渲染慢、CDN 缓存未命中、或 HTML 里藏着一个未标记 async 的 <script src="analytics.js">。
- 检查真实加载链路：用浏览器 Network 面板看
index.html的Time to First Byte (TTFB)和Content Download分段耗时，而非只盯 Lighthouse 总分 - 确认 HTML 是否真被缓存：响应头必须含
Cache-Control: public, max-age=3600（或类似），且状态码是200（不是304或200 from disk cache） - 避免“假优化”：用构建工具无差别压缩 HTML（比如删空格、注释），对 gzip 后体积影响通常
HTML 中哪些 script 标签真正拖慢首屏
不是所有 <script> 都等价。Lighthouse 报 “Render-blocking resources”，关键看执行时机和依赖关系。
以下三类会同步阻塞 HTML 解析和首次绘制：
立即学习“前端免费学习笔记（深入）”；
-
<script src="vendor.js">（无async或defer）：下载+执行完才继续解析后续 HTML -
<script>fetch('/api/user').then(...)</script>（内联且含网络请求）：JS 执行卡住主线程，且请求还可能触发额外 RTT -
<script type="module">import './app.js'</script>：ESM 默认defer行为，但若模块内有顶层 await（如await import('./heavy.js')），仍可能延迟渲染完成事件
安全做法是：第三方统计/埋点脚本统一用 <script async src="...">；业务逻辑脚本改用 <script type="module" defer src="app.mjs">；绝对避免在 <head> 写带 fetch 或 document.write 的内联脚本。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
服务端能否提前输出部分 HTML 来提升感知速度
可以，而且效果比前端压缩 HTML 明显得多。核心思路是“流式传输（streaming）”：Node.js / PHP / Python 模板引擎支持边生成边发送，让浏览器尽早开始解析 <head> 和首屏 <body> 片段。
示例（Express + EJS）：
res.flushHeaders(); // 先发状态行和响应头
res.write('<!DOCTYPE html><html><head>...</head><body><header>...');
// 此时浏览器已开始下载 CSS/字体
res.write('<main><h1>Loading...</h1></main>');
// 关键首屏内容发出
res.write('<script src="/hydrate.js" defer></script></body></html>');
res.end();
注意点：
- 必须在
res.write()前调用res.flushHeaders()，否则 Node 默认缓冲整个响应 - 不要在流式输出中插入未转义的用户输入，XSS 风险更高（因为分段写入更难做统一过滤）
- CDN 或反向代理（如 Nginx）可能禁用流式响应，需检查其
proxy_buffering off配置
gzip/brotli 压缩后 HTML 还值得手动精简吗
不值得花大力气。现代压缩算法对 HTML 的冗余字符（空格、换行、重复属性）极其高效。例如一个含 20 个 <div class="card"> 的列表，手动删掉所有换行和引号，gzip 后体积通常只少 100–300 字节。
真正该关注的是“压缩前不可压缩的内容”：
- 内联大段 Base64 图片：
<img src="data:image/svg+xml;base64,PHN2Zy4uLg==">—— 直接替换成<img src="/icon.svg">并确保 SVG 文件本身已压缩 - 未压缩的 JSON 数据块：
<script id="ssr-data">{ "users": [... 500 条用户数据 ...] }</script>—— 改用服务端按需提供 API，或对 JSON 做JSON.stringify(data, null, 0)去空格（而非保留缩进） - 重复的
<meta>或<link rel="preload">：构建时用插件（如 Webpack 的HtmlWebpackPlugin）自动 dedupe，别靠人眼检查
最后提醒一句：HTML 性能瓶颈极少出现在 HTML 本身。当 TTFB > 600ms 或首屏 JS 执行超 100ms 时，优化 HTML 字符串就像给飞机换轮胎——方向错了。
