浏览器HTML解析关键在避免卡顿，核心是四点：meta charset须在前1024字节内；script标签应置于</body>前或用defer/async；DOM嵌套不超过6层；首屏图片禁用loading="lazy"。
浏览器解析 HTML 不是“越快越好”，而是“不被卡住”——真正拖慢解析的从来不是代码写得多漂亮，而是几个关键位置写错了。
meta charset 必须压在前1024字节内
浏览器启动解析器时默认按 Latin-1 编码读开头数据。如果 <meta charset="utf-8"> 被注释、空行或 BOM 头顶到 2KB 之后，它会先错解一部分内容，再触发重载：中文乱码、document.write() 失效、甚至脚本执行中断都可能发生。
- 必须紧贴
<head>开始，前面只允许<!DOCTYPE html>和空白符 - 禁用 UTF-8 with BOM（BOM 会占前3字节，但破坏解析器初始判断）
- 用
curl -s your-page.html | head -c 1024 | hexdump -C验证是否落在范围内
script 标签放错位置直接停摆解析
未加修饰的 <script src="xxx"> 一遇到就暂停 HTML 解析，等下载+执行完才继续。这不是 JS 慢，是 parser blocking —— 首屏白屏两秒往往就卡在这儿。
- 非关键脚本一律移至
</body>前（最简单兜底） - 业务逻辑脚本优先用
defer：下载不阻塞，执行在 DOM 解析完成后、DOMContentLoaded前，且保持顺序 - 统计/埋点脚本用
async，但确认它不依赖document.getElementById等 DOM 查询 - 绝对禁用
document.write()：现代浏览器执行即清空文档流，本地双击打开时尤其致命
DOM 嵌套超 6 层会让解析开销翻倍
每多一层 <div>，浏览器就要多一次节点创建 + 样式匹配 + 渲染树遍历。5 层以上嵌套在低端 Android WebView 中已明显拖慢首屏；8 层以上重排成本指数上升。
立即学习“前端免费学习笔记（深入）”；
- 用
<header>、<nav>、<main>替代同级<div class="header">：浏览器对语义标签有内部优化路径，解析更快 - Flexbox/Grid 能实现的布局，别用三层
<div class="wrapper"><div class="inner"><div class="content"> - DevTools → Elements 面板右键父级
<div>→ “Break on subtree modifications”，交互看哪些包裹层根本没参与样式或逻辑 - CMS 或低代码导出的
<div data-id="xxx">占位符，只要没 JS 绑定，全删
loading="lazy" 加错地方反而拉垮 LCP
原生懒加载只对 <img> 和 <iframe> 生效，默认触发距离视口约 1250px。盲目全加，会让 Hero 图、轮播首帧、按钮图标等关键资源被延迟，直接拉低 LCP。
- 首屏图片必须删掉
loading="lazy"，显式设width和height（或aspect-ratio），否则加载瞬间触发 layout shift - 非首屏图片一律加
loading="lazy"：零成本、原生支持、Chrome 76+/Firefox 75+ 全覆盖 - 搭配
decoding="async"使用，避免图片解码阻塞主线程 - 别用 JS 库实现懒加载——额外脚本下载+执行反而增加 TTFB 和 JS parse 时间
真正影响“秒级解析”的，从来不是技巧堆得多，而是这四个位置有没有踩坑：meta 位置、script 放哪儿、嵌套深不深、图片懒不懒。其他压缩、合并、CDN，都是锦上添花；这几个点一错，页面就在解析阶段卡死了。
