HTML页面慢主因是结构与资源加载顺序未对齐浏览器渲染机制：@import串行阻塞、link位置不当、script缺defer属性，导致FCP延迟300ms+；应改用并行link、内联首屏CSS、defer/async脚本、精准preload，并确保HTML流式解析。
HTML 页面慢，八成不是 JS 写得烂，而是结构定义和资源加载顺序没对齐浏览器的渲染机制——link 放错位置、@import 暗中拖后腿、script 没加 defer，这些细节一错，FCP（首次内容绘制）直接延迟 300ms+。
为什么 link rel="stylesheet" 必须在 <head> 里，但不能用 @import
@import 是 CSS 里的“同步阻塞加载器”：浏览器必须先下载并解析含 @import 的 CSS 文件，才能发起被导入文件的请求，且串行执行。比如 main.css 里写两行 @import，实际是「下载 main.css → 解析 → 请求 reset.css → 等它回来 → 再请求 layout.css」，中间无法并行。
- 改用多个
<link rel="stylesheet">并行加载，浏览器能同时发请求 - 如果主题切换依赖条件加载，用 JS 动态创建
<link>，而不是靠@import模拟逻辑 - 老项目里搜
grep -r "@import" src/，尤其注意node_modules里第三方 CSS 是否偷偷带了它
script 标签放 </body> 前 ≠ 安全，关键要看是否加了 defer
把 <script src="app.js"></script> 放在 </body> 前，只是让 DOM 构建完了再执行，但下载阶段仍会阻塞 HTML 解析——因为默认是同步下载+执行。真正解耦下载与执行，得靠属性：
-
defer：下载异步，执行在 DOM 解析完成后、DOMContentLoaded前，多个defer脚本按书写顺序执行 -
async：下载异步，下载完立刻执行，不等 DOM，也不保证顺序，适合无依赖的统计脚本 - 没加任何属性的外部
script，哪怕放在</body>前，也会在下载时暂停 HTML 解析（尤其在弱网下明显）
首屏 CSS 内联不是“复制粘贴”，而是提取 + 验证
内联首屏 CSS 的目标是让浏览器不用发请求就能构建 CSSOM，但它容易变成“假优化”：手动复制漏样式、构建后没验证是否真覆盖首屏、后续更新不同步。
立即学习“前端免费学习笔记（深入）”；
- 用工具提取（如
critters或penthouse），别手撸；Vite 用户可配build.rollupOptions.output.manualChunks+critical插件 - 内联后务必打开 DevTools → Network → Disable cache，刷新看 FCP 是否提前，再对比移除内联后的差异
- 内联部分只含首屏可见区域的规则（比如
.hero、.nav），别把.modal或.footer也塞进去 - 内联体积建议控制在 14KB 以内（HTTP/2 帧大小限制），超了反而触发额外分片
preload 不是万能加速键，用错反而抢带宽
<link rel="preload"> 只影响下载时机，不改变执行或应用逻辑。它告诉浏览器“这个资源我马上就要”，但如果资源根本不在首屏路径里，预加载只是白占带宽。
- 只对明确会在
DOMContentLoaded前用到的资源用：as="font"（配crossorigin）、as="image"（配合loading="eager"的首屏图）、as="script"（核心框架入口） - 别给所有
script加preload：它不会推迟执行，反而可能让字体、CSS 下载变慢 - 旧浏览器忽略
preload，所以它不能替代defer或内联，只是锦上添花
最常被忽略的一点：HTML 结构本身是否在服务端就定死了？模板里用 JS 拼 DOM、document.write 插 script、边渲染边 fetch 数据——这些都会打断流式解析，让浏览器反复重置解析器状态。优化加载顺序的前提，是 HTML 能被浏览器从上到下稳定流式解析。
