初探 CSS 渲染引擎
最近一直在探索 Web 渲染性能相关技术,这也是自己一直比较弱的地方。虽然和渲染中的 Style 常打交到,但并未触及浏览器和渲染底层相关的知识。最近饿补了一下这方面的知识。整理了一些有关于 CSS 渲染引擎相关的文章。文章内容较长,图也多。但主要分为三个部分:浏览器理论基础、Web页面解析 和 CSS 渲染引擎。
最近一直在探索 Web 渲染性能相关技术,这也是自己一直比较弱的地方。虽然和渲染中的 Style 常打交到,但并未触及浏览器和渲染底层相关的知识。最近饿补了一下这方面的知识。整理了一些有关于 CSS 渲染引擎相关的文章。文章内容较长,图也多。但主要分为三个部分:浏览器理论基础、Web页面解析 和 CSS 渲染引擎。
在介绍Web页面解析时曾提到过:DOM树和CSSOM树结合在一起会构建出 Render Tree(渲染树),渲染树结合 Layout 绘制在屏幕上,从而展现出来。常常把这个过程称为 关键渲染路径(Critical Rendering Path)简称 CRP。也就是说,CRP 所用的时间直接决定了页面首次渲染页面的时间。即,通过优化关键渲染路径,可以显著缩短首次渲染页面的时间。如果我们要优化一个 Web 页面性能,那就必须对关键渲染路径中每一步中发生了什么,只有优化了关键路径才能彻底优化渲染性能。通过优化关键渲染路径,我们可以显著缩短首次渲染页面的时间。此外,了解关键渲染路径还可以构建高性能交互式应用打下基础。
在 Web 页面渲染过程中,有些资源文件(比如 HTML、CSS 和 JavaScript)会阻塞页面的渲染。当浏览器遇到渲染阻塞资源时,它就会停止下载其余的资源,直到这些关键文件得到处理(关键资源)。在此期间,整个渲染过程被搁置。另一方面,非渲染阻塞资源并不会延迟页面的渲染。浏览器可以在最初的页面渲染之后在后台安全地下载它们。然则,并不是所有被浏览器视为阻塞渲染的资源都是首屏渲染所必需的;这完全取决于页面的特征。你可以使用一些技术手段(最佳实践),将这些非关键的渲染阻塞资源变成非渲染的阻塞资源。此外,你也可以减少那些仍然关键的,无法消除的阻塞渲染的资源数量或大小。了解阻塞渲染资源将使你能够解决常见的 Web 性能问题。
Web 中 的重排和重绘是 Web 渲染中常见的问题,即 Relayout(重排)和 Repaint(重绘)。其中重排(Relayout)也常被称为回流(Reflow)。另外在 Web 中聊渲染相关的话题,除了 Repaint、Reflow、Relayout之外,还有 Restyle(重写样式)和 Rendering(渲染)。这五个带有 R 开头的单词简称 5R ,对于 Web 性能的优化有着决定性的影响。如果要提高页面的渲染性能就需要深究造成 Repaint 和 Reflow 的相关原因。
早在十多年前,在社区就有很多专业人士探讨和深究过 CSS 选择器对渲染性能的影响。特别是对于今天的现代浏览器而言,他们经过了多年的变化(和优化),浏览器变得更聪明!对于 Web 开发人员,“不应该需要担心优化选择器的问题”,他对页面的渲染性能影响已经非常的小。即使如此,CSS的选择器的使用还是有分高效和非高效的,我们在编码的时候,还是应该尽可能的使用高效的CSS选择器,因为高效的CSS选择器对于页面的渲染是有一定帮助的,哪怕这种帮助很微小。但对于追求极致的渲染体验,这一切都是值得的,因为你要付出的并不会太多,反而得到的会较多。如果对网站的所有领域,包括CSS都进行微小的改进,那么他们将产生更多的实质性变化;用户总是会受益的!
图片在 Web 中除了占有重要的一席之地之外,对资源的使用也是非常的大,而且对用户的体验影响也非常大。虽然 <img>
(或 CSS 中其他能用<image>
数据类型的属性,比如 background-image
、mask-image
和 border-image
以及 list-style-image
等)看上去不是很起眼,但图片使用的好坏直接会影响用户的体验,Web 的性能(加载,渲染相关的性能)。或者简单地说,它直接影响 CWV (Core Web Vitals)的几个关键指标,比如 LCP、CLS和 FID。为什么说图片会对 LCP、CLS 和 FID 有着直接影响呢?我们先从 <img>
的使用开始,然后逐步来分析。
Web Fonts 在 Web 中的使用已随处可见,比如聚划算页面中的 价格 使用的就是 Web Fonts(即 AlibabaSans102-Bd
。虽然使用 Web Fonts 能在视觉上达到更好的效果(满足设计师的需求),但对于 Web 性能是有影响的,给用户的体验也是有影响的。如果Web Fonts 未加载,浏览器通常会延迟任何使用 Web Fonts 的文本(比如聚划算的价格)。这在许多情况下,将延迟 FCP(First Contenttful Paint),在某些情况下也会延迟 LCP(Largest Contentful Paint)。甚至更为严重的是导致布局偏移(Layout Shifts),会触发页面的重排和重绘(Web Fonts 和它的备用字体或系统字体在页面上占用不同的空间), 也会触发 CLS(Cumulative Layout Shift)。更令人感到头痛的是,Web Fonts 造成布移偏移的原因是 FOUT(Flashes Of Unstyled Text),而且 FOUT 还是业内公认的难以解决的。简单地说,Web Fonts 对视觉效果是有显著帮助,但对Web性能和用户体验是有严重影响。如果在实际业务中能避免 Web Fonts 的使用应该尽可能的不用,如果实在不能避免,那就要在使用 Web Fonts时做一些策略上的选择。接下来,我们围绕着 Web Fonts 的使用和性能优化来展开讨论。
在上一节中,我们一起探讨了 Web Fonts 和 系统字体之间的差异。在这一部分我们一起来探讨使用 Web Fonts 时,浏览器加载 Web Fonts 和渲染 Web Fonts 的策略。其实,聊 Web Fonts 就离不开 FOUT 、FOIT 和 FOFT 话题,特别是 FOUT 和 FOIT 。简单地说,FOUT、FOIT 和 FOFT 都是浏览器渲染文本的三种不同的表现,特别是 Web Fonts 被引入到 Web 中时,浏览器对 FOUT 和 FOIT 的优化就没有停止过。
前面的篇幅(Web Fonts vs. 系统字体 和 FOUT, FOIT 和 FOFT)告诉我们,使用 Web Fonts 会造成布局偏移,页面渲染时会发生重排和重绘。这会让页面在渲染时变得更慢,用户体验会更差。如果我们要对此进行优化,减少 Web Fonts 引起的布局偏移,就要从字体加载方面去做相应的优化策略。我们接下来主要围绕着字体加载策略来展开今天的话题,感兴趣的同学请继续往下阅读。
前面花了三篇的篇幅(Web Fonts vs. 系统字体、FOUT、FOIT 和 FOFT 和 Web Fonts 字体加载策略)围绕着 Web Fonts 的优化做了些探讨。但这些优化手段都还是会引起 Web 布局偏移。不过,CSS 的一些新特性,即 F-mods(字体度量覆盖描述符)来覆盖字体的一些度量参数,让系统字体字体(备用字体)和 Web Fonts 更接近,尽可能的减少布局偏移。