首屏加载慢主因是HTML解析与关键资源加载顺序不当。应内联首屏CSS、用media延迟非关键CSS、避免@import；JS用defer或async，script放前；精准preload字体和首屏图；精简HTML结构并启用Gzip/Brotli压缩。
首屏加载慢，八成卡在 HTML 解析和关键资源加载顺序上。不是 JS 太多，而是浏览器被你写的 <link rel="stylesheet"> 和 <script></script> 拖住了——它得等 CSSOM 构建完才能开始渲染，得等 JS 执行完才能继续解析 HTML。
怎么让关键 CSS 不阻塞首屏渲染
外部 CSS 默认是渲染阻塞的：浏览器必须下载、解析、构建 CSSOM 后，才肯画第一帧。首屏样式若全靠 main.css，FCP（首次内容绘制）就注定延迟。
- 把首屏用到的 CSS 提取出来，内联进
的<style></style>标签里，不发请求、不等待 - 非首屏 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载，或配合media属性做条件加载（如media="(min-width: 768px)"） - 绝对别在
@import里引入关键 CSS —— 它会串行阻塞，比<link>多一次网络往返，实测拖慢 FCP 300ms+
script 标签放哪儿、加什么属性才不白屏
默认 <script src="app.js"></script> 是同步阻塞的：HTML 解析停住 → 下载 JS → 执行 JS → 继续解析。用户看到的就是白屏。
- 业务逻辑 JS 优先用
defer：下载异步，执行时机在 DOM 解析完成后、DOMContentLoaded前，且按顺序执行 - 统计类、无依赖脚本（如
analytics.js）可用async：下载完立刻执行，时机不可控，可能早于 DOM 就绪 - 兜底方案是把
<script></script>放在前——至少保证 DOM 已构建完毕，但不如defer可控 - 禁用
document.write()：现代浏览器已废弃，执行即清空文档流，必然阻塞且不可恢复
preload 该加在哪、怎么写才真正加速
preload 不是“越多越好”，它是高优先级资源提示，写错反而抢带宽、挤掉 HTML 或关键 CSS。
立即学习“前端免费学习笔记（深入）”；
- 只对当前导航「立刻要用」的资源用：
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>（注意crossorigin必加，否则字体不生效） - 首屏 Hero 图可
preload，但别对所有<img loading="lazy" alt="HTML怎么优化首屏加载_html首屏加载速度优化方案【收藏】" >都加——浏览器可能先加载src，再触发懒加载逻辑，造成重复请求 - 验证是否生效：打开 Chrome DevTools → Network 面板，看预加载资源的 Priority 是否为
high；prefetch是low，混用就等于浪费带宽 - 别用
preload加 JS 入口文件（如main.js）——它本身已被script defer覆盖，再 preload 属于冗余调度
HTML 结构和体积本身怎么减负
DOM 节点越多，浏览器解析、构建树、计算布局的时间越长。一个 2000+ 节点的页面，光解析 HTML 就可能耗时 50ms+。
- 删掉开发残留的
<div><div><div> 嵌套，用语义化标签（<code><header></header>、<section></section>、<article></article>）替代无意义包裹层 - 上线前压缩 HTML：移除注释、空格、换行；构建工具如
html-minifier-terser可集成进 Webpack/Vite - 服务端开启 Gzip/Brotli：HTML 压缩率通常超 70%，比前端压缩更直接有效
- 图片别只靠
loading="lazy"：首屏大图必须禁用该属性，否则可能被懒加载机制拦截，导致空白
最容易被忽略的是：首屏优化不是“堆技巧”，而是识别真正影响 FCP/LCP 的那几 KB HTML 和几十毫秒的资源调度。内联关键 CSS、defer 主逻辑 JS、精准 preload 字体和首屏图——这三件事做完，多数项目的首屏时间能压到 1s 内。其他都是锦上添花，别本末倒置。
