html5加载优化有三处关键压缩点：服务器启用brotli（比gzip多压15%）、合理使用srcset/sizes避免大图浪费、正确配置async/defer防止执行错乱。
HTML5资源压缩：从源码到传输链路的三处关键压缩点
HTML5页面加载慢，往往不是代码写得差，而是没压对地方。真正起效的压缩不在HTML文件本身，而在它触发的整个资源链路上。
-
gzip或brotli必须在服务器启用，且优先配brotli（比gzip平均多压 15%）。Nginx 配置里漏掉gzip_types或brotli_types，会导致.html、.js、.css不被压缩 - HTML 源码里删空格/换行效果微乎其微，但手动生成的注释、冗余
data-属性、未清理的调试console.log模板字符串，会在首次解析时拖慢 DOM 构建 -
srcset和sizes不是“锦上添花”，而是防止高分辨率设备下载 3MB 的hero.jpg却只渲染 400px 宽区域——这种浪费比不压缩 HTML 更伤
@@##@@
script 标签的 async/defer 到底该用哪个
不是所有 JS 都适合加 async，也不是所有都能靠 defer 安全兜底。关键看依赖关系和执行时机。
-
async：只适用于完全独立的脚本，比如统计代码analytics.js、广告 SDK。一旦它依赖了尚未加载的lodash.js，就会报ReferenceError -
defer：能保证执行顺序，但仅对外链有效；<script defer>console.log('hi')</script>不会延迟——浏览器直接忽略defer属性 - 混用风险：页面同时有
<script async src="a.js"></script>和<script defer src="b.js"></script>，a.js可能比b.js晚执行却先触发，导致b.js里的函数未定义
现代 HTML5 加载优化：哪些特性你其实没开
很多项目还在手动拼 link rel="preload"，却忘了浏览器原生支持更精准的预加载机制。
-
<link rel="preload" as="script" href="main.js">要配合crossorigin属性，否则遇到跨域字体或模块脚本会静默失败 -
loading="lazy"对<iframe></iframe>支持度已达标，但对<img src="hero-400w.jpg" srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w" sizes="(max-width: 480px) 100vw, 50vw">在 Safari 旧版仍需回退用 IntersectionObserver -
fetchpriority="high"是 Chrome 101+ 新增属性，可提升关键资源（如首屏hero.webp）的网络调度优先级，但若和preload冲突，浏览器以preload为准
容易被忽略的缓存陷阱：HTML 文件本身不能乱设强缓存
很多人给 index.html 配了 Cache-Control: public, max-age=31536000，上线新版本后用户刷半天还是旧页。
立即学习“前端免费学习笔记（深入）”；
- HTML 文件必须用短缓存（比如
max-age=60）或禁用缓存（no-cache），靠 ETag 或 Last-Modified 让浏览器验证是否变更 - 真正该打长缓存的是带哈希的资源：
main.a1b2c3d4.js、styles.e5f6g7h8.css。改文件内容 → 哈希变 → URL 变 → 浏览器自然请求新资源 - 如果用 Webpack/Vite，确保
filename: "[name].[contenthash:8].js"，而不是[hash]—— 后者每次构建全变，缓存形同虚设
HTML5 加载优化不是堆技巧，而是看清每个标签背后的真实加载行为。最常出问题的地方，往往就藏在你每天写的第 3 行 <script></script> 里。
