语义化标签能提升解析速度，因其让浏览器更快识别内容区块、减少DOM节点创建与样式匹配开销；如用<article>替代<div class="post">可避免class遍历，三层以上<div>嵌套应改用Flex/Grid直出结构。
HTML结构本身不直接“加速”，但错误的结构会卡死首屏渲染；关键CSS必须内联，且不能超过14KB，否则白屏时间翻倍。
为什么语义化标签能提升解析速度
浏览器解析 HTML 时，每个 <div> 都要创建 DOM 节点、计算样式、布局——嵌套过深或语义模糊的标签会拖慢这个过程。语义化标签如 <header>、<nav>、<main> 不是“为了 SEO 好看”，而是让浏览器更快识别内容区块，跳过冗余遍历。
- 用
<article>替代<div class="post">：减少 class 匹配开销，尤其在大量列表页中明显 - 避免三层以上
<div>嵌套：比如<div><div><div>...，改用 Flex/Grid 布局直出结构 - 删掉开发期残留的
<!-- TODO: remove this -->注释：它们仍被解析为 Comment 节点，积少成多影响 DOM 构建
关键CSS内联的硬性限制和实操边界
内联关键 CSS 是为了绕过网络请求，但不是“把所有 CSS 都塞进 <style>”。浏览器对内联样式的处理有明确瓶颈：超过 14KB 会触发延迟解析，反而延长首次绘制（FCP）。
- 只提取首屏可见区域（above-the-fold）真正用到的规则：比如导航栏、标题、首张图容器，不含折叠区、弹窗、分页按钮
- 工具推荐用
critters（Vite 插件）或penthouse，别手写提取——人工容易漏掉伪类（:hover）、媒体查询断点内的规则 - 如果内联后接近 14KB，宁可砍掉一个非必要动画效果，也不要压缩后仍超限；gzip 后体积不作数，浏览器看的是解压前字节数
script 标签位置与 defer/async 的真实影响
把 <script> 放 </body> 前只是“传统做法”，真正起效的是加载行为控制。未加属性的外部脚本会阻塞 HTML 解析，而内联脚本哪怕只有一行 console.log() 也会强制暂停。
立即学习“前端免费学习笔记（深入）”；
-
<script src="a.js" defer>和<script src="b.js" defer>按顺序执行，适合依赖链明确的模块（如 Vue + 插件） -
<script src="analytics.js" async>下载完立刻执行，适合无依赖的统计脚本；但它可能在 DOM 尚未就绪时运行，需自行判断document.readyState - 绝对不要在
<head>里放没加defer/async的外部<script>，尤其前面还跟着<link rel="stylesheet">——这会让 CSSOM 构建等 JS 执行完才继续
preload 和 lazyload 的误用高发区
<link rel="preload"> 不是“让资源更快加载”，而是“告诉浏览器：这个我马上就要，请现在就开始下”。用错等于抢带宽、挤掉真正关键的资源。
- 只对
DOMContentLoaded前必需的资源 preload：比如首屏字体（as="font"必须带crossorigin）、核心 JS chunk、hero 图（as="image"配合loading="eager"） -
loading="lazy"对<img>安全，但对<iframe>有兼容风险（Safari 旧版不支持），需 fallback 到 IntersectionObserver 动态插入 - 别给所有
<script>加 preload：它不改变执行时机，只提前下载，反而可能让 JS 在 DOM 就绪前就执行失败
最容易被忽略的其实是“关键 CSS 提取范围”——很多人按页面 URL 提取，但同一 URL 下不同用户看到的内容可能完全不同（比如登录态 vs 游客态）。这时候靠工具自动提取会漏掉动态区块的样式，得结合服务端渲染时的 actual markup 做二次校验。
