跳转到主内容
极星编程网:以代码为星,赴技术山海!

如何优化HTML加载速度_关键渲染路径优化【技巧】

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