html性能优化关键在于减少浏览器解析负担：meta charset须置于前1024字节内以防重载；script用defer/async或移至前避免阻塞；用语义化标签替代深层嵌套div；图片精准使用loading="lazy"并设宽高防cls。
HTML代码质量直接影响浏览器解析DOM的速度，但提升的关键不在“写得多漂亮”，而在“让解析器少做几件事”。绝大多数性能瓶颈不是出在JS执行上，而是HTML文本刚进浏览器时就被卡住——比如错位的<meta charset>、深层嵌套的<div>、或一个没闭合的<code><script></script>标签。
为什么<meta charset="utf-8">必须放在前1024字节内
浏览器启动HTML解析器时，默认按Latin-1编码读取开头几个KB。如果<meta charset="utf-8">位置靠后（比如被一堆注释或空格顶到2KB之后），它会先按错误编码解析一部分内容，再发现charset声明、触发重载——页面闪动、中文乱码、甚至脚本执行失败都可能由此引发。
- 必须紧贴
开始，前面只允许DOCTYPE和空白符 - 不要在它前面加注释、空行或BOM头（UTF-8 with BOM是常见坑）
- 用
curl -s your-page.html | head -c 1024 | hexdump -C验证是否落在范围内
<script></script>放哪儿才不打断DOM构建
未加修饰的<script src="app.js"></script>一遇到就暂停HTML解析，等下载+执行完才继续。首屏白屏往往就卡在这儿，而不是JS本身慢。
- 同步脚本：一律移到
前，这是最简单兜底方案 - 业务逻辑脚本：优先用
defer——下载不阻塞，执行在DOM解析完成后、DOMContentLoaded前，且保持顺序 - 统计/埋点脚本：用
async，但确认它不依赖DOM节点（比如没查document.getElementById） - 绝对禁用
document.write()——现代浏览器执行即清空文档流，本地双击打开时尤其致命
语义化标签如何减少解析开销
浏览器对<header></header>、<nav></nav>、<main></main>等语义标签有内部优化路径，而对同级的<div class="header">需额外走CSS类匹配、JS查询等通用流程——这不是玄学，是Chromium和WebKit源码里明确写的分支逻辑。
<ul><li>替换掉无意义的<code><div>包裹层，特别是嵌套超过6层的结构
<li>
<code><article></article>和<section></section>不能互换：<section></section>是通用分组，<article></article>代表独立可分发内容（如博客正文）
<div>模拟语义标签再靠CSS撑样式——解析器仍当普通容器处理，没优化红利
<h3>
<code>loading="lazy"加错反而拖慢首屏
原生懒加载只对<img>和<iframe></iframe>生效，且默认触发距离视口约1250px。盲目全加，会让关键图片被延迟，直接拉低LCP指标。
- Hero图、轮播首帧、按钮图标等必须删掉
loading="lazy" - 必须显式写
width和height，否则加载时布局偏移（CLS）无法避免 - Safari 15.4+才支持
<iframe></iframe>懒加载；旧版安卓WebView可能完全忽略，得降级用data-src+IntersectionObserver - 别同时写
src和loading="lazy"再配JS监听——浏览器可能先加载src，造成重复请求
真正影响DOM解析速度的，从来不是标签写得够不够“高级”，而是有没有让浏览器多绕弯路。一个没闭合的<pre class="brush:php;toolbar:false;"></pre>、一行错位的<meta>、或嵌套过深的<div>，都比你压缩掉的那几百字节更致命。</div>
