HTML结构应让关键内容靠近开头、避免深层嵌套，script加defer/async，关键CSS内联，非首屏资源延迟加载，禁用无用display:none节点，慎用table布局。
HTML结构怎么写才不拖慢解析
浏览器解析HTML是自上而下流式进行的，遇到阻塞型资源就停住——所以结构顺序直接决定首屏时间。关键不是“多语义化”，而是“让关键内容早出现、少干扰”。
常见错误现象：div套div再包一层div，首屏按钮被埋在第7层嵌套里；<script src="vendor.js"></script>写在顶部，整个DOM构建卡住；<link rel="stylesheet">放在底部，导致FOUC或重绘抖动。
- 把
<main></main>、<article></article>等承载首屏内容的标签尽量靠近开头，避免前置大量导航、广告、埋点脚本 -
<script></script>标签必须带defer（顺序执行）或async（无序并行），除非是内联小逻辑；服务端渲染（SSR）场景下，defer比async更稳妥，避免JS执行时DOM还没就绪 - 删掉所有
display: none但仍在DOM里的冗余节点——它们不参与渲染树，但会占用DOM解析和内存，尤其在列表页、搜索页中易堆积 - 慎用
<table>布局：表格单元格需整行解析完才能开始渲染，比<code>flex或grid多一次重排成本Cache-Control怎么设才不翻车
HTML本身不该被长期缓存，但很多人误以为“加个
max-age=31536000就万事大吉”。错配的缓存头会导致用户看到旧按钮、404路由、甚至失效的表单提交入口。使用场景差异极大：
/index.html是动态入口，/static/main.a1b2c3.js是静态产物，缓存策略必须分开。立即学习“前端免费学习笔记（深入）”；
-
index.html应返回Cache-Control: no-cache（或max-age=0, must-revalidate），强制每次验证；CDN后台必须设为“遵循源站响应头”，否则它可能按默认10分钟缓存，覆盖你的真实意图 - 带哈希的静态资源（如
app.8f3e2d.css）可放心设Cache-Control: public, immutable, max-age=31536000；immutable告诉浏览器“URL变了内容肯定不同”，跳过协商请求 - 绝对不要用
<meta http-equiv="Cache-Control" content="...">——Chrome/Firefox/Edge全忽略它，只有部分旧版Safari可能读取，属于伪配置 - 检查是否生效：打开DevTools → Network → 点击
index.html请求 → 查看Response Headers里Cache-Control值，并留意x-cache（Cloudflare）或x-cdn-cache（阿里云）是否显示HIT或MISS
为什么CDN缓存HTML反而更慢
CDN缓存HTML不是加速手段，而是发布风险放大器。它把“服务端控制权”让渡给边缘节点，一旦配置偏差，问题会批量爆发且难回滚。
典型坑：
Cache-Control: no-cache已正确返回，但CDN后台对/路径设置了“默认缓存60秒”，结果CDN无视响应头，强行吐出旧HTML；用户刷新后仍看到昨天改掉的文案，连硬刷（Ctrl+F5）都无效。- 登录CDN控制台，找到HTML路径（如
/index.html或/*），显式关闭缓存，或设为Cache-Control: no-cache覆盖规则 - 如果必须缓存HTML（如纯静态博客），确保文件名含时间戳或哈希，例如
index.20260429.html，再配max-age=86400，靠URL变更触发自然失效 - 微前端项目中，子应用HTML（如
marketing-app.html）务必单独配置缓存策略，不能和主应用共用通配规则——否则一个子应用更新失败，全站白屏
最常被忽略的一点：HTML缓存策略生效的前提是HTTP响应头真实抵达浏览器。Nginx里只写了
add_header但没加always参数，304响应就不会带这个头；Express里用res.set()但中间件提前end()了，头根本发不出。调试时别只盯代码，要抓包看真实响应。 -
