HTML加载慢主因是阻塞渲染、路径错误致404、base64内联增大体积、缺少压缩缓存及file://协议限制；应通过Network面板定位瓶颈，用本地服务器替代双击打开。
直接打开 Network 面板看 transfer size 和 waterfall 时间线，比猜快得多——index.html 本身慢，八成不是文件大，而是它触发的阻塞、错误路径、冗余内联或缺失压缩让浏览器反复卡住。
怎么让 <script> 不卡住 HTML 解析
浏览器遇到未加修饰的 <script src="app.js"></script> 会立刻暂停 HTML 解析，等 JS 下载并执行完才继续。首屏白屏几秒，往往就因为这个停顿。
- 非关键脚本一律加
defer：下载不阻塞，DOM 解析完再按顺序执行，适合依赖 DOM 的初始化逻辑 - 完全独立的脚本（如统计、埋点）用
async：下载不阻塞，但执行时机不可控，不能保证顺序 - 绝对禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地环境尤其敏感 -
<script>标签别塞在<head>里——必须同步执行的极小逻辑除外（比如 CSP nonce 注入），且内联代码控制在 1KB 以内
关键 CSS 必须内联且 ≤14KB
外部 CSS 默认是渲染阻塞资源：浏览器必须下载、解析、构建 CSSOM 后才肯画第一帧。哪怕 main.css 只用在页脚，只要在 <head> 里，整个页面就卡在白屏状态。
- 只提取首屏必需样式（如 header、hero banner、按钮、
@font-face），写进<style></style>标签，不发请求、不等待 - 内联内容 gzip 后建议控制在 ~4–8KB（原始体积约 14KB），避免跨 TCP 包影响 TTFB
- 禁止在
<style>中使用@import——它会触发额外 HTTP 请求并阻塞解析 - 所有
<link rel="stylesheet">必须放在内联<style>之后，否则仍可能被后续资源拖慢
loading="lazy" 加在哪、怎么加才不翻车
原生懒加载只对 <img> 和 <iframe> 生效，且默认触发距离视口约 1250px，并非“所有图片都该加”。
立即学习“前端免费学习笔记（深入）”；
- 首屏 Hero 图、轮播图第一张、关键按钮图标等，必须禁用
loading="lazy"，否则可能被当成非关键资源延迟加载 - 所有加
loading="lazy"的<img>必须显式设置width和height属性，否则滚动时加载会引发布局偏移（CLS） - 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必加，否则字体不生效） - 首屏 Hero 图可
preload，但别对所有<img loading="lazy">都加——浏览器可能先加载src，再触发懒加载逻辑，造成重复请求 - 别用
preload加 JS 入口文件（如main.js）——它本身已被script defer覆盖，再 preload 属于冗余调度 - 验证是否生效：打开 Chrome DevTools → Network 面板，看预加载资源的
Priority是否为high；prefetch是low，混用就等于浪费带宽
真正容易被忽略的是：服务端 Gzip/Brotli 压缩比任何前端技巧都管用——它能让 HTML 响应体缩小 50%~70%，且无需改动模板结构；还有 <meta charset> 必须出现在 <head> 最开头（紧随 <title> 前），否则浏览器可能误判编码，触发重解析。
