HTML性能优化核心是减负担：精简结构降DOM节点数、script放body末尾或用defer/async防阻塞、内联关键CSS（≤14KB）、preload仅用于首屏必用资源，避免冗余。
HTML 页面性能优化不是“加功能”，而是“减负担”——浏览器解析 HTML 是单线程、顺序进行的，任何冗余结构、错误位置或体积膨胀，都会直接拖慢 DOMContentLoaded 和首屏渲染。核心就一条：让浏览器用最少的字节、最短的路径、最少的阻塞，建出可用的 DOM 树。
怎么避免 <script> 阻塞 HTML 解析
浏览器遇到未加修饰的 <script src="app.js"></script> 会立刻暂停 HTML 解析，下载、执行脚本后才继续。首屏卡住、白屏时间长，十有八九是它干的。
- 非关键 JS 一律放
</body>前，不加async或defer也比放<head>强 - 必须在
<head>加的脚本（比如监控 SDK），强制加defer；若无执行顺序依赖，优先用async - 内联脚本（
<script>console.log(...)</script>）默认同步阻塞，除非逻辑极简且必要，否则别写 - 注意：
async脚本不保证执行顺序，defer会按出现顺序执行，且只对外链有效
为什么 <link rel="preload"> 不是万能的
<link rel="preload" as="style" href="main.css"> 确实能提前拉取关键资源，但它不会改变 CSS 的渲染阻塞行为——浏览器仍会等它解析完才绘制。
- 只对真正“首屏必用”的资源用
preload，比如首屏字体、关键 CSS、LCP 图片；乱用反而挤占带宽 -
preload后必须实际使用该资源，否则浏览器会警告 “The resource … was preloaded using link preload but not used within a few seconds” - 不要用
preload加载整个vendor.js—— 它太大、太晚才需要，更适合prefetch或按需加载 - 搭配
as属性必须准确（as="script"/as="font"/as="image"），否则浏览器无法设置正确请求头和缓存策略
内联关键 CSS 时容易踩的坑
把首屏渲染必需的 CSS 直接写进 <style> 标签，能跳过一次 HTTP 请求，但操作不当反而更慢。
立即学习“前端免费学习笔记（深入）”；
- 内联内容不能超过 ~14KB（TCP 初始拥塞窗口限制），超了会多一个往返（RTT），得不偿失
- 务必剔除所有非首屏规则（比如
.modal-hidden、#footer），工具如critters或penthouse可自动化提取 - 内联 CSS 无法被浏览器缓存，所以只适合变化极少的样式；频繁更新的项目慎用
- 如果用了
media查询（如<style media="(min-width: 768px)">），浏览器会异步加载，失去内联意义
精简 HTML 结构为什么比压缩空格更重要
删掉注释和空格能让文件小几 KB，但删掉一层没意义的 <div class="wrapper"> 嵌套，可能让 DOM 节点数减少 10%，直接影响解析和布局耗时。
- 用
<header>、<nav>、<main>替代一堆<div>，语义化标签本身解析更快，且现代浏览器对其有专门优化 - 避免“divitis”：检查每个
<div>是否真有必要，能否用display: contents或伪元素替代 - 移除开发期遗留的
data-test-id、debug="true"等属性，它们不参与渲染，却增加字符串解析开销 - 服务端开启 Gzip/Brotli 压缩后，结构精简带来的收益会被放大——重复标签名（如大量
<div>）在压缩中更容易被字典复用
真正难的不是知道该做什么，而是判断“哪段 HTML 是关键的”“哪个 CSS 规则影响首屏”“这个 script 到底能不能 defer”。这些没有银弹，得靠 Lighthouse 的 Critical Request Chains 报告、Network 面板的 Waterfall 图，以及在 3G 慢网下反复刷新来验证。优化不是一劳永逸，而是持续校准的过程。
