HTML加载慢主因是阻塞渲染、路径错误致404、base64内联增大体积、缺少压缩缓存及file://协议限制；应通过Network面板定位瓶颈，用本地服务器替代双击打开。
HTML在线运行速度慢，绝大多数情况不是代码写得“重”，而是浏览器在解析和加载过程中被同步资源卡住——比如没加 defer 的脚本、错放位置的 link[rel="stylesheet"]、或本地双击打开导致的 file:// 协议限制。优化方向非常明确：先定位阻塞点，再针对性切掉或推迟。
为什么 Network 面板里 index.html 显示“完成”了，页面还是白屏？
这是最典型的误判：HTML 文件下载完 ≠ 页面可渲染。浏览器必须等以下任一条件满足才能开始绘制：
-
link[rel="stylesheet"]下载并解析完成（哪怕它在<head>最末尾） - 没有
defer或async的<script>执行完毕（包括内部调用document.write()或同步fetch） - 关键字体（如
font-display: block且未缓存）加载失败或超时
实操建议：打开 DevTools → Network → 过滤 Doc 类型，确认 index.html 的 TTFB 和下载时间；再切到 All，按 Waterfall 排序，重点看排在前 3 位的 main.css、vendor.js、fonts.gstatic.com 是否耗时 >800ms。
本地双击 HTML 文件就卡，是不是代码有问题？
大概率不是代码问题，而是 file:// 协议本身的限制：gzip/Brotli 被禁用、DNS 预解析跳过、HTTP/2 不可用、跨域资源（如本地 fetch('./data.json')）静默失败。所有服务端优化全部失效。
立即学习“前端免费学习笔记（深入）”；
- 临时起个本地服务器测试：
python3 -m http.server 8000或npx serve - 检查所有
src和href路径是否真实存在，特别注意./js/app.js和js/app.js的差异 - 禁用所有
data:image/内联图片——它们直接增大 HTML 解析体积，50KB base64 图片会让首屏延迟 100ms+ - 绝对不要用
document.write()，它会清空当前文档流并重置解析器，本地环境尤其敏感
<script> 加了 defer 就不阻塞了？
不完全。defer 只解决 HTML 解析阻塞，不解决执行时机和主线程抢占问题。
- 如果
main.js含大量计算或 DOM 操作，仍会导致首屏交互卡顿 - 第三方脚本（统计、客服）必须用
async，且最好用fetch()+eval()动态注入，避免初始 HTML 里硬编码<script src="analytics.js"></script> - 非首屏 JS（如轮播图、表单校验）应延迟到
requestIdleCallback(() => { /* load */ })或至少DOMContentLoaded后再初始化 - 同步脚本（无
async/defer）必须移出<head>，放到</body>前是最兜底做法
内联 CSS 超过多少 KB 就该拆出去？
超过 2KB 就该警惕；超过 10KB 必须拆。深层嵌套选择器（如 div div div span:hover）会拖慢样式计算，Chrome Coverage 面板能标出未用到的 CSS 字节，删掉就是立竿见影的减负。
- 只内联首屏必需样式：
<style>放在<head>里，仅含body、.hero、.nav等首屏可见区域规则 - 异步加载剩余 CSS：
<link rel="stylesheet" href="app.css" media="print" onload="this.media='all'">——利用media="print"让浏览器不阻塞，加载完再切回all - 避免
@import：它在 CSS 内部发起新请求，会串行阻塞，比<link>多一层延迟
真正卡住页面的，往往不是某一行代码写错了，而是资源加载顺序和协议限制这类“看不见”的环节。Network 面板里的 Waterfall 时间线，比任何经验判断都可靠。
