HTML加载慢主因是阻塞渲染、路径错误致404、base64内联增大体积、缺少压缩缓存及file://协议限制；应通过Network面板定位瓶颈，用本地服务器替代双击打开。
HTML 页面加载慢，八成不是 HTML 文件本身大，而是它触发的阻塞、错误路径、冗余内联或缺失压缩让浏览器反复卡住。直接开 Network 面板看 transfer size 和 waterfall 时间线，比猜快得多。
怎么让 <script> 不阻塞 HTML 解析
浏览器遇到未加修饰的 <script src="app.js"></script> 会立刻暂停 HTML 解析，等 JS 下载并执行完才继续——这是首屏白屏最常见原因。
- 同步脚本（无
async或defer）必须移出<head>，放到</body>前是最兜底做法 - 第三方统计、广告类脚本用
async：下载不阻塞，但执行时机不可控，适合无依赖逻辑 - 业务主逻辑 JS 优先用
defer：下载不阻塞，执行在 DOM 解析完成后、DOMContentLoaded前，且按书写顺序执行 - 绝对禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地环境尤其敏感
为什么 @import 会让首屏变慢
CSS 是渲染阻塞资源，而 @import 在 CSS 文件中是串行加载机制，浏览器必须先下载并解析完被 import 的文件，才能继续处理后续样式表。
-
@import "reset.css";比<link rel="stylesheet" href="reset.css">多一次网络往返和解析依赖，实测拖慢 FCP 300ms+ -
@import无法被预加载识别，也不能参与并行下载，构建工具（如 PostCSS）虽可内联展开，但 source map 易断 - 若需条件加载（如暗色主题），优先用
<link rel="stylesheet" media="(prefers-color-scheme: dark)">，而非@import
loading="lazy" 的生效边界与坑点
原生懒加载只对 <img> 和 <iframe> 生效，且默认触发距离视口约 1250px，不是“所有图片都该加”。
立即学习“前端免费学习笔记（深入）”；
- 首屏 Hero 图、轮播图第一张、关键按钮图标等，必须禁用
loading="lazy"，否则可能被当成非关键资源延迟加载 - 必须显式设置
width和height属性，否则滚动时图片加载会引发布局偏移（CLS），直接拉低 Core Web Vitals 分数 - Safari 15.4+ 才支持
loading="lazy"对<iframe>的支持；旧版安卓 WebView 可能完全忽略，需降级为data-src+IntersectionObserver - 不要同时写
src和loading="lazy"，再额外用 JS 监听——浏览器可能先加载src，造成重复请求
<link rel="preload"> 加错反而拖慢首屏
preload 是高优先级资源提示，不是“提前加载所有东西”的开关。它只对当前导航中「确定马上要用」的资源有效。
- 适用场景极有限：
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>（注意crossorigin必加，否则字体拒绝使用）；首屏<img>的src地址；异步模块中立刻要import()的 JS - 别对
main.js入口文件重复preload：它已被defer覆盖，属于冗余调度 - 别把
preload当prefetch用：后者是为下一页准备的，优先级低，混用会导致带宽被挤占、关键资源下载延迟 - 验证是否生效：Chrome DevTools → Network 面板，看预加载资源的 Priority 是否为
high；prefetch是low
真正卡住首屏的，往往不是某一行代码写得不够炫，而是对 defer 和 async 的语义理解偏差、对 preload 的滥用、或者一个藏在 CSS 里的 @import。这些细节不查 Network 面板很难暴露，但改对一处，FCP 就可能提前 200ms 以上。
