首屏白屏时间长而 DOMContentLoaded 早触发,是因为渲染需完成关键CSS加载、JS执行、样式计算、布局、绘制等步骤,即关键渲染路径(CRP)阻塞在render tree生成前;优化需聚焦资源加载时机与语义。
为什么首屏白屏时间长,
却早就触发了?
因为浏览器渲染不只等 DOM 构建完成——它还要等关键 CSS 加载解析、关键 JS 执行、样式计算、布局、绘制。这个链条就是「关键渲染路径」(CRP)。白屏久,往往卡在
生成前:比如一个
阻塞了后续所有渲染,哪怕 DOM 已就绪。
实操建议:
用 Chrome DevTools 的
面板录制加载过程,重点关注
→
→
这段是否被阻塞
检查 Network 面板中所有
和
请求的
列:若显示为
,说明是 HTML 解析时同步加载,大概率是关键资源
把非首屏必需的 JS 改用
或
;CSS 中非首屏样式抽离,用
属性条件加载(如
或自定义
)
和
到底该在哪用?
是告诉浏览器“这个资源马上就要用”,强制提前获取并尽早开始解析(如关键字体、首屏 CSS、核心 JS);
是“可能之后会用”,优先级低,适合下一页的资源。
常见误用:
立即学习
“
前端免费学习笔记(深入)
”;
对
用
—— 它属于首屏关键图像,应内联或
+
在
里
一个 2MB 的 Webpack bundle —— 浏览器会抢带宽,反而挤占关键 CSS/JS 的下载,得不偿失
没加
属性:缺少
的
会被当成脚本处理,无法参与 CSSOM 构建
正确写法示例:
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
如果你了解HTML,CSS和JavaScript,您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造,可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序,然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流,并开始构建应用程序,提供更
下载
内联 CSS 和 JS 的边界在哪?
内联能消除 HTTP 请求,但会增大 HTML 体积、阻碍缓存复用。不是越小越好,而是要平衡「首次渲染速度」和「后续访问效率」。
推荐策略:
只内联首屏必需的 CSS(通常 ≤ 10KB),用工具如
(Vite/webpack)或
自动提取
避免内联含
的 CSS —— 浏览器仍需发起新请求,失去内联意义
JS 绝对不要内联逻辑代码(如 React 渲染函数),仅可内联极小的运行时钩子(如
注入)
服务端渲染(SSR)场景下,内联 CSS 后记得移除对应外链
,否则重复应用样式
为什么开了
还要减少请求数?
HTTP/2 支持多路复用,但每个资源仍有头部开销、服务器排队、TLS 握手延迟。更关键的是:浏览器对同一域名的并发连接数仍有软限制(Chrome 通常 6–10 个),且资源发现仍依赖 HTML 解析顺序 —— 比如第 7 个
的 CSS,即使 HTTP/2 能并发,也要等前面 6 个标签解析完才被发现。
所以优化重点仍是「让关键资源早出现、早加载」:
把关键
和
尽量放在
靠前位置(但不要在
前)
避免在 HTML 底部插入动态
或
—— 它们会延迟关键资源发现
使用
(如
、
)提前建立第三方域名连接,但别滥用:每个
都会触发 TLS 握手,开销不小
真正影响 CRP 的,从来不是协议本身,而是你把哪些资源放到了 HTML 的哪个位置、用了什么加载语义。细节藏在
的
和
里,不在“开了 HTTP/2 就万事大吉”的幻觉里。
DOMContentLoadedrender treePerformanceParse HTMLRecalculate StyleLayoutcssjsInitiatorparserasyncdefermediamedia="print"media="(min-width: 768px)"preloadprefetchpreloadprefetchlogo.svgprefetchpreloadas="image"preloadasas="style"preload
crittersPenthouse@import__INIT_DATA__HTTP/2resource hintsdns-prefetchpreconnectpreconnectlinkrelas