HTML加载慢主因是解析阻塞、资源加载顺序错乱及DOM结构臃肿；应将非关键脚本加defer或async、非首屏图片加loading="lazy"、精简DOM结构并内联关键CSS。
HTML 页面加载慢，八成问题出在解析阻塞、资源加载顺序错乱或 DOM 结构臃肿上——不是 JS 写得不够炫，而是 <script> 放错了位置，<img> 没设 loading="lazy"，或者 <head> 里塞了一堆没用的 <meta>。
怎么让浏览器不卡在 <script> 上
浏览器解析 HTML 时遇到 <script> 默认会停住，下载、执行完才继续。首屏白屏几秒，往往就因为这个停顿。
- 非关键脚本一律加
defer：它让脚本并行下载，等 DOM 解析完再按顺序执行，适合依赖 DOM 的初始化逻辑 - 完全独立的脚本（如统计、埋点）用
async：下载不阻塞，但执行时机不可控，不能保证执行顺序 - 绝对不要在
<head>里写内联<script>console.log(...)</script>，除非是极小的、必须同步运行的逻辑（比如 CSP nonce 注入） - 第三方脚本优先考虑沙箱化：
<iframe sandbox="allow-scripts" src="..."></iframe>或动态插入 +onload控制加载节奏
图片加载慢，别只靠压缩
压缩图片只能减体积，但加载时机不对，照样拖慢首屏。现代浏览器原生支持懒加载，不用额外库也能见效。
- 所有非首屏
<img>必须加loading="lazy"；首屏图片则去掉该属性，确保立即加载 - 响应式图片用
srcset+sizes，避免手机下载桌面尺寸图；例如：<img src="a.jpg" srcset="a-400.jpg 400w, a-800.jpg 800w" sizes="(max-width: 600px) 400px, 800px"> - WebP/AVIF 格式优先，但要 fallback：用
<picture>包一层，<source type="image/webp">在前，<img src="fallback.jpg">在后 - 图标类小图（≤1KB）可直接 Base64 内联到 CSS 背景里，省一次请求
DOM 结构和 HTML 写法怎么影响性能
DOM 树越深、节点越多，浏览器构建和遍历成本越高。很多“慢”其实是结构冗余导致的，不是代码逻辑问题。
立即学习“前端免费学习笔记（深入）”；
- 删掉无意义的包裹层：
<div><div><div><p>内容</p></div></div></div>→ 直接用<p>或语义化标签 - 避免用
<table>做布局；Flexbox/Grid 更轻量，解析快，且无需额外样式重置 -
<meta>只留必要项：删掉过时的http-equiv、重复的viewport、无实际作用的描述标签 -
charset必须放在<head>最开头（紧随<title>前），否则浏览器可能误判编码，触发重解析
预加载和内联策略怎么选才不翻车
preload 和 prefetch 不是越多越好，用错反而增加竞争、浪费带宽。
- 只对「当前页马上要用」的关键资源用
<link rel="preload" as="font">或as="style"；字体必须加crossorigin属性，否则无效 -
prefetch适合用户下一步大概率访问的资源（如分页第二页的 JS），但别对所有链接都加，容易污染缓存 - 关键 CSS（首屏渲染必需）建议内联到
<head>中，控制在 ~14KB 以内；超出部分用<link rel="stylesheet" media="print" onload="this.media='all'">异步加载 - 千万别内联大 JS —— 即使只有 50KB，也会阻塞解析，且无法被缓存复用
最容易被忽略的是：HTML 本身不执行逻辑，但它决定了整个页面的加载链起点。一个没设 loading="lazy" 的轮播图、一段放在 <head> 里的未加 defer 的配置脚本、或者多嵌套三层的 <div>，都会让后续所有优化打折扣。优化 HTML 不是“锦上添花”，而是“先立住骨架”。
