大尺寸静态资源需按是否影响LCP/CLS/FID分级干预：font.woff2＞100KB、hero.jpg＞400KB、bundle.js＞300KB必须优化；analytics.js等非渲染脚本即使仅80KB也应异步加载；preload仅适用于当前导航立即使用的资源，配错会拖慢关键资源。
大尺寸静态资源（比如 2MB 的 WebFont、1.5MB 的首屏 Hero 图、或 3MB 的 WebGL 模型）本身不会阻塞 HTML 解析，但它们会挤占网络带宽和连接数，间接拖慢关键资源加载——尤其是当没做优先级干预时，浏览器可能把它们和 main.js 或 critical.css 放在同一批次竞争下载。
哪些资源算“大尺寸”且需要干预
不是所有大文件都该被特殊处理。判断依据是：是否参与首屏渲染、是否影响 LCP/CLS/FID 等核心指标。
-
font.woff2> 100KB、hero.jpg> 400KB、bundle.js> 300KB —— 这类必须干预 -
analytics.js、ads.js即使只有 80KB，也建议异步加载，因为它们不参与渲染 - 小于 50KB 的图标、小 SVG、内联 CSS —— 不用管，压缩后影响极小
preload 用对才加速，用错反拖慢
preload 不是“提前加载所有大文件”的开关，它只对「当前导航中马上要用」的资源有效。加错会抢占关键资源带宽。
- ✅ 正确用法：
<link rel="preload" href="Lato-Bold.woff2" as="font" type="font/woff2" crossorigin>（字体必须带crossorigin，否则无效） - ❌ 错误用法：
<link rel="preload" href="backup-data.json" as="fetch">（这个文件只在用户点击“导出”后才用，预加载纯属浪费） - ⚠️ 注意：
preload不会改变执行时机，只提前下载；它不触发解析或执行，所以不能替代defer或async
图片与字体的非阻塞加载组合策略
单纯加 loading="lazy" 或 preload 都不够，得按资源类型分层处理。
立即学习“前端免费学习笔记（深入）”；
- 首屏大图：禁用
loading="lazy"，显式设置width/height，用srcset+sizes提供响应式源，必要时加<link rel="preload" as="image"> - WebFont：
font-display: swap必须配preload，否则 FOUT/FOIT 问题更明显；避免用@import引入字体 CSS - 非首屏视频/模型：用
data-src+IntersectionObserver替代原生loading="lazy"，兼容旧 WebView 和 Safari 15.3 及以下
构建阶段就该做的资源分级
运行时靠 HTML 属性调控是下策，真正省事的是在打包阶段把资源按用途打标。
- Webpack/Vite 中用
/* webpackMode: "eager" */或/* viteIgnore */控制 chunk 分离，避免大资源被打进主 bundle - 关键 CSS 内联，非关键 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载 - 所有
src属性在构建时替换为data-src，再由轻量 JS 按需激活——比全靠 HTML 属性更可控
最容易被忽略的是：大资源的 HTTP 响应头。没配 Cache-Control: public, max-age=31536000 和 Content-Encoding: br（Brotli），再好的加载策略也白搭——浏览器每次都要重下，根本谈不上“非阻塞”。
