HTML加载慢主因非体积大，而是阻塞渲染、错误路径、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> - 没加
as属性：缺少as="style"的preload会被当成脚本处理，无法参与 CSSOM 构建 - 对 logo.svg 用
prefetch—— 它属于首屏关键图像，应内联或preload+as="image" - 在
<head>里preload一个 2MB 的 Webpack bundle —— 浏览器会抢带宽，反而挤占关键 CSS/JS 的下载
真正卡住首屏的，往往不是 HTML 体积，而是资源加载时机与语义的错配。比如把关键字体写成 prefetch，或让首屏 CSS 被 @import 串行锁死——这些细节在 Network 面板里一眼可见，但容易被忽略。
