HTML性能优化核心在于避免解析阻塞与渲染延迟：<link rel="stylesheet">须放<head>以避免白屏；<img>必设宽高防重排；<script>依依赖关系选async或defer；<picture>用于多条件图片适配，非简单响应式。
HTML 本身不直接执行逻辑，但它的结构、标签选择、加载顺序和资源引用方式，会深度影响页面首屏时间、渲染阻塞、内存占用和可访问性。性能问题往往不是“HTML 写错了”，而是“HTML 没写对时机、没选对标签、没管好资源链路”。
为什么 <link rel="stylesheet"> 必须放 <head> 里
浏览器解析 HTML 是流式进行的，遇到 <link rel="stylesheet"> 时会发起 CSS 请求，但**不会阻塞 HTML 解析**（这点常被误解），却会**阻塞后续 <script> 的执行和 DOM 渲染**。如果把它错放到 <body> 底部，会导致：浏览器先解析完全部 HTML、构建出 DOM 树，再等 CSSOM 加载完成才开始合成 Render 树——白屏时间拉长，且 JS 执行被卡在最后。
- 真实错误现象：
DOMContentLoaded延迟触发，首屏内容迟迟不显示，控制台 Network 面板可见 CSS 请求排在很后面 - 例外情况：非关键 CSS（如打印样式、主题切换用的 secondary.css）可用
rel="preload"+onload注入，或加media="print"让其不阻塞渲染 - 不要用
@import替代<link>：它在 CSS 文件内部生效，会引发额外请求+串行加载，比<link>多一次 RTT
<img> 标签不加 width 和 height 会怎样
不设这两个属性，浏览器无法预知图片尺寸，只能等图片数据下载完成、解码后才计算布局（layout）。这导致：页面反复重排（reflow），文字/容器先按“无图”位置渲染，图片加载后突然撑开区域，用户看到内容跳动（jank）；更糟的是，移动端可能因反复重排触发多次绘制，耗电加剧。
- 正确做法：在 HTML 中显式写
<img src="x.jpg" width="300" height="200">；若响应式场景，用 CSSaspect-ratio+object-fit补位（注意 IE 不支持） - 现代补充：
srcset和sizes属性必须配合宽高使用，否则浏览器无法做资源选择 - 常见坑：用 JS 动态设置宽高，等于没设——浏览器已开始布局，JS 修改只是触发二次重排
什么时候该用 <picture> 而不是单个 <img>
当需要根据设备像素比、视口宽度、甚至用户偏好（如减少动画、深色模式）提供不同格式或分辨率的图片时，<picture> 是唯一可靠方案。单靠 <img srcset> 只能切分辨率，不能切格式或条件逻辑。
立即学习“前端免费学习笔记（深入）”；
- 典型场景：
webp优先（Chrome/Firefox 支持），降级到jpg（Safari 旧版）；或为高清屏提供 2x 图，普通屏用 1x；或为 prefers-reduced-motion 用户提供静态帧 - 必须注意：
<source>的media和type属性顺序有影响——浏览器从上到下匹配第一个满足条件的，所以通用 fallback（<img>）必须放在最后 - 别滥用：
<picture>增加 HTML 体积和解析开销，纯响应式尺寸切换用srcset更轻量
<script> 的 async 和 defer 到底怎么选
两者都让脚本不阻塞 HTML 解析，但执行时机完全不同：async 下载完立即执行（可能打断 DOM 构建），defer 等 DOM 解析完、DOMContentLoaded 触发前执行，且严格按书写顺序。
- 用
async：独立、无依赖的脚本，比如统计代码（ga.js）、广告 SDK —— 它们不操作 DOM，也不依赖其他 JS - 用
defer：需要操作 DOM 或依赖其他脚本的逻辑，比如初始化组件、表单验证 —— 保证 DOM 已就绪，且多个defer脚本顺序执行 - 绝对别混用：一个页面里既有
async又有defer脚本，执行顺序不可控，极易出现document.getElementById is not a function类错误
最易被忽略的一点：HTML 性能优化不是堆砌技巧，而是理解浏览器如何解析、构建、渲染。很多“优化”反而因破坏了自然加载节奏（比如把所有 CSS 内联导致首包过大）而适得其反。关键在测量——用 Lighthouse 的 FCP、LCP、CLS 数据说话，而不是凭经验改标签。
