大尺寸资源不阻塞html解析但拖慢首屏，因其抢占tcp连接、带宽和http/2流优先级；需按lcp/cls/fid影响分级处理，合理使用preload、loading="lazy"及构建期资源打标。
大尺寸资源为什么“不阻塞HTML解析”却拖慢首屏
浏览器确实不会因为一个 2MB 的 hero.jpg 或 3MB 的 webgl-model.glb 暂停 HTML 解析，但它们会抢占 TCP 连接、带宽和 HTTP/2 流优先级。当这些大文件和 main.js、critical.css 在同一时刻发起请求，关键资源反而被挤到后面下载——尤其是没做显式优先级干预时。
- 判断是否该干预，不看文件大小本身，而看它是否影响 LCP（如首屏大图）、CLS（如未设宽高的图片加载偏移）、FID（如阻塞主线程的字体解析）
-
font.woff2> 100KB、hero.jpg> 400KB、bundle.js> 300KB —— 必须分级处理 -
analytics.js即使只有 80KB，也应async或defer，因为它不参与渲染，却可能因执行逻辑阻塞主线程
preload 用错比不用更伤性能
preload 不是“提前加载所有大文件”的开关，它是高优先级下载提示，只对当前导航中「确定马上要用」的资源有效。加错会直接抢走 critical.css 或 main.js 的带宽。
- ✅ 正确：
<link rel="preload" href="Lato-Bold.woff2" as="font" type="font/woff2" crossorigin>（字体必须带crossorigin，否则加载失败） - ❌ 错误：
<link rel="preload" href="user-data.json" as="fetch">（这个数据只在用户点击“导出”后才用，预加载纯属浪费） - ⚠️ 注意：
preload只触发下载，不触发解析或执行；它不能替代defer或async，也不能解决 JS 执行卡顿
图片与字体的非阻塞组合策略
单靠 loading="lazy" 或 preload 都不够，必须按资源类型分层控制加载行为。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
<img>：必须显式设置width和height，再配sizes+srcset；首屏大图可加<link rel="preload" as="image">，但仅限真正首屏可见的那张 - WebFont：必须配合
font-display: swap+preload，否则 FOIT/FOUT 更明显；禁用@import引入字体，它会串行阻塞 CSSOM 构建 - 非首屏视频/3D 模型：原生
loading="lazy"在 Safari 15.3 及以下和旧 WebView 中不生效，改用data-src+IntersectionObserver更可靠
构建阶段就该打标，别等上线再补 HTML 属性
运行时靠手动加 preload、loading="lazy" 是下策。真正省事的是在打包阶段就把资源按用途分类打标，比如 Webpack 的 /* webpackMode: "eager" */ 或 Vite 的 import.meta.preload，让构建工具自动注入正确策略。
容易被忽略的一点是：很多团队把“优化”全压在 HTML 层面，却没意识到，如果构建产物里已经把 1.5MB 的 hero.jpg 打进了 bundle.js，再怎么加 preload 都救不回 TTFB 和首屏时间——资源路径、格式、切分粒度，才是真正的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
