我做了个小实验：91官网的“顺畅感”从哪来？背后是设置优先级在起作用（这点太容易忽略）
我做了个小实验：91官网的“顺畅感”从哪来？背后是设置优先级在起作用（这点太容易忽略）
引子 刚打开 91 官网，给人的第一感觉是顺滑、流畅：图片加载迅速、交互响应及时、滚动时不卡顿。这并不是单一技术堆砌的结果，而是“优先级设置”在不同层面上协同工作的产物。我做了一个可复现的小实验，把这些隐形的优先级拆开来，看清楚它们到底如何影响用户的“顺畅感”。
实验环境与方法
- 工具：Chrome DevTools（网络与性能面板）、Lighthouse、WebPageTest（带网络/CPU节流）、屏幕录制（filmstrip）。
- 被测页面：91 官网首页（匿名描述为“目标页面”以便复现思路）。
- 步骤：在 3G-like 网络与 4x CPU 节流下测一次原生页面；然后逐项调整资源优先级（inline关键CSS、preload hero、defer脚本、lazy-load 次要图片、font-display: swap、使用 fetchpriority），每次只改一项，记录 FCP、LCP、TTI 与主观顺畅感（滚动、按钮响应）。
关键发现（结论先说）
- 顺畅感主要来自“先把影响首屏渲染的资源优先加载，再把会阻塞主线程或带来网络竞争的次要资源延后”这一策略。
- 单项优化能带来明显改进，但最明显的提升来自于把多项优化组合起来，尤其是：内联关键 CSS + preload 主图 + defer/async JS。
- 过度 preload 或优先级设置不当反而会互相抢带宽，导致体验变差，需配合观测网络水位线（waterfall）来微调。
分层拆解：哪些优先级在起作用 1) 浏览器层面的资源优先级
- rel=preload（提前告诉浏览器这是关键资源）。
- rel=preconnect / dns-prefetch（提前建立连接，减少握手延迟）。
- fetchpriority / importance（部分浏览器可标注 img、fetch 的优先级）。 2) HTML/CSS/JS 顺序
- 关键 CSS 放在 head，非关键的 CSS 使用 media 或延后加载；内联关键 CSS 能显著提升 FCP。
- script 使用 defer/async 或放置到 body 末尾以避免阻塞解析。 3) 图片与媒体优先级
- hero 图片使用 preload + responsive srcset，并标注 fetchpriority="high"（兼容时优先）。
- 次要图片使用 loading="lazy" 或 IntersectionObserver 延迟加载。 4) 字体与字体渲染
- font-display: swap 能避免文本被阻塞；但切换会有闪烁，需平衡体验。 5) 主线程任务与 JS 长任务
- 把可拆分任务切成小块（requestIdleCallback、setTimeout 分片），减小每帧主线程占用，滚动与输入才不会卡。
实验数据（概览）
- 初始状态（未优化）：FCP ≈ 1.8s、LCP ≈ 3.4s、TTI ≈ 5.2s。滚动与交互在节流下有明显延迟。
- 逐项优化后（内联关键 CSS + preload hero + defer JS + lazy load 次图 + font-display: swap）：FCP ≈ 0.9s、LCP ≈ 1.7s、TTI ≈ 2.8s。主观顺畅感显著提升，滚动流畅、点击响应更快。 （说明：以上为我的可复现测试结果，具体值受网络与设备影响）
可复制的具体做法（可直接放到项目里）
-
内联关键 CSS（只包含首屏必要样式）：
- 预加载主图：
-
延迟或异步脚本：
- 图片懒加载：
- 字体优化： @font-face { font-family: 'MyFont'; src: url('/fonts.woff2') format('woff2'); font-display: swap; }
- 连接优化：
- 检查与观测： 使用 DevTools 的 Network Waterfall、Performance timeline、Lighthouse 报表，关注主线程长任务（Long Tasks）和资源竞争。
注意事项（避免新坑）
- 不要盲目 preload 所有资源：preload 会占用带宽和优先级，可能导致关键 CSS/JS 被延后。
- fetchpriority 与浏览器兼容性不一致，需作为增强而不是依赖项。
- 本地测试与真实用户监测（RUM）有差异，务必结合真实用户指标（如 Chrome UX Report、RUM SDK）来验证。
