可能算得上是比较全面且细致的“浏览器的工作原理”这一话题的浅谈内容整理分享了，当然，也不只有这一个话题。 # 引子关于“浏览器的工作原理”这一话题，似乎是讲不出什么新的花样。对于已经了解的人来说，可能觉得并没有什么高深的内容；对于还不了解的人来说，我个人觉得还是有必要学习一下，因为站在 web 项目开发者的角度来讲，我甚至觉得有一些程度来说就是面向浏览器编程。不管是使用了多么厉害的框架、多么高深的技术，到最后都得在页面上渲染出来，用于展示，用于交互。*那么如何把我们编写的 web 项目代码在浏览器中渲染出来*，就算得上是“浏览器的工作原理”的最重要的主题之一了。当然，其实随着时代的发展，除了历史遗留原因，大部分 to C 的使用场景上，使用新版本的现代浏览器的决策似乎不需要考虑。之前也说过，其实新版本现代浏览器的大头，除了 Safari、Firefox 少数之外，Chrome、Edge、Opera、360、QQ 等都基于 Chromium 项目开发的。所以不是特殊情况的话，我们看到的不少文章的示例，都会以 chrome 的多进程浏览器架构而展开的。虽然我不想再强调 CSS、HTML、JavaScript 基础知识的重要性，但是了解了浏览器的工作原理(不用太深入)，对这些基本知识的使用上的帮助不可谓不大，除了最基本的“能够按照设计图还原”的要求外，还有喜闻乐见的性能优化、兼容性调试、安全保护、高效地前端开发等主题有良好的帮助。可能正是因为这部分的内容大体来讲没有太大的变化，以至于我在学习的时候，发现非常多的文章都算得上东拼西凑、左抄右抄来的，原文的图片和文字一字不漏地复制过来但有的甚至还不列出原文链接。我可能不是很有能力做搬运工，但我能看到的很多的内容都是来自以下文字或课程： * [How browsers work](https://web.dev/howbrowserswork/) - `web.dev`，2011 年 * [Inside look at modern web browser](https://developer.chrome.com/blog/inside-browser-part1/) - `developer.chrome.com`，2018 年 * [浏览器工作原理与实践](https://time.geekbang.org/column/intro/100033601) - 极客时间，2020 年左右前面两篇文字是非常的经典，加上来源算得上比较权威，如果静下心慢慢看完，可能就不再需要别的辅助了。站内有翻译计划的译文，也可以参看。由于是英文原文，自己写博客上面两篇文章的图片可以复制，但至少文字需要机翻一下。而“浏览器工作原理与实践”由于是“更符合国情的”付费内容，标题更接地气，图片文字还算简洁清晰，更加被频繁地直接照搬。我当然不是在给它打广告，由于是收费的课程，我也不方便直接贴上 github 的地址，各位可以直接 github 搜索关键字 “browser-working-principle” ([如此例](https://sanotsu.github.io/browser-working-principle/)) 自行评判。另外不错比较简介的博文也可以参考： * [How web browsers work](https://dev.to/arikaturika/how-web-browsers-work-part-1-with-illustrations-1nid) - `dev.to`，2022 年博文，带图且细致 * [Populating the page: how browsers work](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work) - MDN 当然，既然本文也是这个主题，如果时间宽裕的话，也可以看看我的理解是否符合诸君的胃口。**【特别说明】我也是按照上面的参考文章，基于 chrome 来学习的相关知识，文中有不少主观的判断和观点**。同样的，不喜欢长篇大论和口水话，最后面也有一点我计划用来应对面试官的回答模板，毕竟这个话题展开来讲三五十分钟都不一定搞得定，更何况三五分钟。 # 简单聊聊浏览器的发展过程(可略) ## 1. web 的发展众所周知，Web 的发明者 Tim Berners-Lee 提出的[第一个 Web](https://www.w3.org/People/Berners-Lee/1991/08/art-6484.txt)包含的东西: HTTP，HTML，名为 WorldWideWeb 的第一个 Web 浏览器，一个 HTTP 服务器和一些用于查看的网页。那封邮件有句原话是: "The WWW project was started to allow high energy physicists to share data, news, and documentation. We are very interested in spreading the web to other areas, and having gateway servers for other data."基于时代背景，那个时候的 web 简单说就是通过浏览器访问 HTTP 服务器提供的文档(虽然现在也是)，内容比较简单，就是图片和文本为主，所以那个时候的浏览器能够加载显示文本和图片就好了。当然，后面就是大家耳熟能详的 Web 发展的三个阶段: * 主要用于展示静态内容、但缺乏互动性和个性化的 Web1.0 时代； * (Web1.0 大约从 1989 年到 2004 年，“在 Web 1.0 中，内容创作者很少，绝大多数用户只是内容的消费者”) * 强调用户参与和互动，网站内容和功能应该是以用户需求为导向的 Web2.0 时代； * (Web2.0 这个词 Darcy DiNucci 在 1999 年 1 月创造) * 以及还处于发展初期的拥有去中心化、人工智能的整合、虚拟与现实的融合、用户拥有数据控制权、跨平台和跨设备的无缝体验等特点的 Web3.0 时代 * (Web3.0 较有名的首次提及是在 2006 年初,与区块链有关的 web3 概念是由以太坊联合创始人 Gavin Wood 于 2014 年提出,2021 年受到关注)。我当然不知道 Web3.0 是不是骗局，但我肯定明白现在的 Web 项目应该不可能只是单纯的展示图片和文字而没有交互，这也就要求现代的浏览器也要满足这样的需求，最简单地完成 Web 项目的展示和交互的需求。 ## 2. HTTP 的发展当然，现在浏览器能展示的内容不单单是图片和文本，虽然从分类来讲，XML、HTML、plain text 支持的其实也不是很多: application、audio、font、example、image、message、model、multipart、text、video。但 http 的请求头`Content-Type`可设定的资源的 MIME 类型[Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml)就有这么成千上万种。虽然这里有些本末倒置了，不是因为 HTTP 有这些资源分类，浏览器才能展示这些资源，可能是因为时代变化，浏览器需要展示这些资源，HTTP 才支持了这些分类。笼统来讲 HTTP 标准也经历了 5 次发展： * HTTP/0.9：最早版本的 HTTP，仅支持传输纯文本信息，并且缺乏标准化。 * HTTP/1.0：于 1996 年发布，引入了请求头、响应头、状态码等概念，支持多媒体传输。 * HTTP/1.1：于 1999 年发布，成为目前最常用的版本。它引入了持久连接、管道化请求、虚拟主机等改进，提升了性能和效率。 * HTTP/2：于 2015 年发布，基于 Google 开发的 SPDY 协议。HTTP/2 采用二进制分帧传输、头部压缩、多路复用等技术优化了性能。 * HTTP/3：正在开发中，基于 QUIC 协议（快速 UDP 互联网连接）。HTTP/3 旨在解决 HTTP/2 的一些限制(比如端头堵塞)，并提供更好的性能和安全性。其实不难看出，新的内容，更强调的是性能、安全等方面的内容，而不再是功能上的，所以假如有人义愤填膺地声称：“这个年代 IE8 就不应该继续存在”，那可能也没别的意思，只是这小子不想好好搞兼容性而已。因为目前 IE8 不仅仅还存在，可能在不少 to B 的地方还不可或缺，因为 IE8 是在 HTTP1.1 发布十年之后的 2009 年才推出的，某些层面来讲，非常完美。 ## 3. 浏览器的发展从 1991 年 Tim Berners-Lee 发明的 WorldWideWeb 浏览器到现在，30 多年间出现了很多的浏览器，也消失了不少，有的明明挺好用但好像已经死了，有的似乎大家很不喜欢，但还有着一亩三分地。大体上来讲，浏览器的发展也有这么几个时期： * 早期阶段(1990 年代初) * 最早的浏览器当然就是 WorldWideWeb 浏览器，在 1991 年发布。它是世界上第一个图形化的浏览器，但功能有限。 * 随后，Mosaic 浏览器在 1993 年问世，带来了图片显示和超链接等基本功能。 * 主导时期(1990 年代中期至 2000 年代初)： * 1994 年，Netscape Navigator 发布，成为当时最受欢迎的浏览器，引领了浏览器的发展方向。 * 同时，微软也推出了 Internet Explorer(IE)，并通过 Windows 操作系统捆绑发行，最终赶超了 Netscape。 * 第一次浏览器战争(2000 年-2004 年)： * 在互联网泡沫破灭之后，浏览器市场竞争加剧。Netscape 逐渐式微，IE 占据了主导地位。 * 然而，Mozilla 组织通过开源项目开发了 Firefox 浏览器，并在 2004 年发布，重新引起了人们对浏览器的关注。 * Web 标准时代(2004 年至今)： * Firefox 的成功推动了对 Web 标准的重视，促使各大浏览器开始支持和遵循 W3C 制定的 HTML、CSS 等标准。 * 同时，苹果公司推出的 Safari 浏览器也在 Mac 和 iOS 设备上取得了一定市场份额。 * 移动互联网时代(2007 年至今)： * 随着智能手机的普及，移动浏览器成为用户访问互联网的主要途径。 * 谷歌推出的基于 WebKit 引擎的 Chrome 浏览器在移动端取得了巨大成功，并逐渐占据了桌面和移动浏览器市场的领导地位。 * 当代(2020 年至今)： * 如今，主流的浏览器包括 Chrome、Firefox、Safari 和 Edge 等，它们不断更新和改进功能，提高性能和安全性。 * 同时，新兴的浏览器，如 Vivaldi 和 Brave 等，也在不断发展壮大。回顾历史的话，现在一家独大的 chrome 的第一版其实晚在 2008 年首次针对 Microsoft Windows 发布，使用 Apple WebKit 和 Mozilla Firefox 的免费软件组件构建。我们更熟悉的 360、搜狗、QQ、百度、猎豹等浏览器，也是在 2008 年之后慢慢出来的，所以其实可以简单地说，这些浏览器都是在 Web 标准化得到重视之后才慢慢推出的，这也是我之前认为很重要的一点，标准做得再好，有支持才算真的好。看过太多叫好不叫座的东西之后，有时候很难再分清“劣币与良币”。 ## 4. 浏览器架构的演变但是这个时候，浏览器已经不再是用于主要用于展示的 Web1.0 时代了，为了提供更好的用户体验、增强浏览器的性能和安全性，并适应不断变化的网络环境和用户需求，浏览器架构也在进行着演变，从最开始的单一进程到面向服务的 SOA(Services Oriented Architecture)等等： * 单一进程架构 * 早期的浏览器采用单一进程架构，即整个浏览器由一个进程来管理所有的功能和组件。 * 这种架构简单直接，但存在着性能和稳定性方面的问题。例如，一个页面的崩溃可能导致整个浏览器的崩溃。 * 多进程架构 * 为了提高浏览器的稳定性和安全性，引入了多进程架构。 * 多进程架构将不同的功能和组件划分为多个进程，如渲染进程、插件进程、网络进程等。每个进程相互独立，一个进程的崩溃不会影响其他进程，提高了浏览器的健壮性。 * 内核分离架构 * 近年来，一些浏览器采用了内核分离的架构，即将浏览器的界面和渲染引擎（内核）分离开来。 * 这样可以灵活地替换或升级渲染引擎，提高浏览器的可维护性和扩展性。常见的内核有 WebKit、Blink 等。 * 客户端-服务器架构 * 浏览器主要负责显示界面和执行用户操作，而实际的网页内容和处理任务是由远程服务器完成的。 * 这种架构有助于提高跨平台兼容性和数据安全性。 *(以上有一部分内容是使用 ChatGPT 获取整理的)* # 浅谈浏览器工作原理的几个重点问题的分类单从简单了解的角度来看，我个人觉得这个主题可以分为以下几点：浏览器的核心功能、浏览器的组成、网页的渲染过程、网页的合成……当然，配套还有网络请求例如 HTTP、资源访问 URI、硬件加速、隐私安全、插件扩展等话题。不过这里面最重要也是说的最多的，其实也就是网页加载过程的几个重点步骤: 响应、解析、渲染、交互。其中说得最多的就譬如“关键渲染路径”、“从输入 URL 到页面加载的全过程”。 ## 浏览器的核心功能正常来讲，浏览器都会带有搜索引擎，不管是不是自有的，毕竟除了少数或者比较常用的站点记得名字、加过书签之类的，对于大多数不清楚或者未知的内容，一般都是搜索起手。虽然目前国内最大的搜索引擎的搜索结果不太令人满意，更多生活化的搜索有不少都直接转入指定的 app 中搜索关键词，但浏览器不具备搜索的功能目前显然还不现实。不过这个核心功能就不展开了，我想说的其实是不管是搜索的结果也好，知道网站地址直接访问，或者只是加入书签、收藏后点击图标等，最终的结果是打开了某个网页进行查看或交互。综上所述，**浏览器的核心功能，我个人觉得，某些程度来讲，就只有一个：提供用户访问和浏览互联网上网页内容的能力**(加载并展示网页)。那基于这个目的的话，有几个点就可以展开来说： * 浏览器用户界面 * 如何获取到互联网上的网页内容 * 如何加载展示页面 * …… 当然为了了解各个部分如何实现，就得知道另一个重点：浏览器的组成。可惜的是，这样的东西从 Web 被发明出来就已经是重点了，但目前的浏览器功能可远不止这些，为了更好的用户体验，也需要有其他的功能，例如：安全性和隐私保护、插件和扩展支持、缓存和离线访问等等，这都不谈。 **浏览器的用户界面**比较简单，这里一嘴就提了，一般都是有：标签栏(一般一个网页一个 tab)、功能按钮(主页、刷新、前进、后退)、地址栏(识别 url 直接访问或者关键字特定搜索引擎查询)、书签栏、工具栏、主菜单、下载管理器等等，*“Every part of the browser display except the window where you see the requested page.”*。 ## 浏览器架构这个部分，图文基本可以全部参看[Inside look at modern web browser (part 1)-Browser Architecture](https://developer.chrome.com/blog/inside-browser-part1/#browser-architecture)，这里主要引入这张大家可能已经到处看到过的 Chrome 浏览器的架构图： ![chrome的多进程架构图.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/706fc222efe14b1b82ce0eefd65d524a~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=702&h=918&s=201258&e=png&b=fdfcfc) **各插件的作用：** * **Browser**: 负责包括地址栏，书签栏，前进后退按钮等部分的工作；负责处理浏览器的一些不可见的底层操作，比如网络请求和文件访问。 * **Renderer**: 控制显示网站的选项卡内的任何内容。 * **Plugin**: 控制网站使用的任何插件。 * **GPU**: 负责处理 GPU 相关的任务(例如使用 WebGL 的、协助视频解码和播放、图像处理和滤镜效果等)。 **Chrome 中多进程架构的优缺点：** * 优点： * 开启多个选项卡，每个选项卡都由**独立**的渲染器进程运行。如果一个选项卡变得无响应，则可以关闭无响应的选项卡并继续操作，同时保持其他选项卡处于活动状态。 * 借助操作系统对进程安全的控制，浏览器可以将页面放置在沙箱中，站点的代码可以运行在隔离的环境中，保证核心进程的**安全**。 * 不足： * 由于**不同进程间的内存不共享**，不同进程的内存常常需要包含相同的内容。 * **为了节省内存，Chrome 限制了最多的进程数**，最大进程数量由设备的内存和 CPU 能力决定，当达到这一限制时，新打开的 Tab 会共用之前同一个站点的渲染进程。原文这里还提到了“站点隔离(Site Isolation)”的内容，站点隔离为每个跨站点 iframe 运行单独的渲染器进程。这种在底层改变了 iframe 之间通信的方法的机制，后续在 Web 安全部分内容会再提及，此处按下不表。 *** ### 补充: CPU、GPU、进程、线程等简述 CPU、GPU、进程、线程这些就不展开说明，下面是我之前总结的一些说法可留个印象： * CPU（英语：Central Processing Unit，中央处理器）的功能主要是*解释计算机指令以及处理计算机软件中的数据*。 * GPU（英语：Graphics Processing Unit，图形处理器）是一种专门在个人电脑、工作站、游戏机和一些移动设备上*执行绘图运算工作*的微处理器。 * **进程 (process) 与线程 (thread)** * 进程：是操作系统（OS）进行资源（CPU、内存、磁盘、IO、带宽等）分配的*最小单位*； * 线程：是 CPU 调度和分配的*基本单位*。 * *进程与线程类比火车与车厢*: * **一个进程可由多个线程的执行单元组成**，每个线程都运行在同一进程的上下文中，共享同样的代码和全局数据。(一辆火车可以有多节车厢) * **每个进程至少有一个主执行线程**。(一辆火车至少一节车厢) * **进程间不会相互影响，一个线程挂掉将导致整个进程挂掉**。(一辆火车出事不影响其他火车，一节车厢着火，整辆火车都得停) * 进程、线程是操作系统调度的，**进程本身不会负责调度线程**。 * **进程间通信 (IPC)**: 管道 pipe、消息队列 message queue、信号 sinal、共用内存 shared memory 以及套接字 socket。 * **单线程**就是进程中只有一个线程。**多线程**就是进程有多个线程。 * **阻塞/非阻塞、同步/异步** * 同步异步说的是被调用者结果返回时通知进程的一种**通知机制**，阻塞非阻塞说的是调用结果返回前进程的状态，是挂起还是继续处理其他任务。 * 阻塞与非阻塞是**调用方**决定的，在等待结果的过程中，是否还可以干其他事。 * 同步与异步是**被调用方**决定的，决定是马上给你答案，还是过会儿通知你，给你答案。 * **并发 (Concurrent) 与并行 (Parallel)** * 并发：多个任务在**同一个 CPU 核**上按细分的时间片轮流 (交替) 执行，从逻辑上来看那些任务是同时执行。 * 并行：区别与串行，多个任务真正的分配到**不同的 CPU 内核**上去执行的，它们是真正的同时执行。 * 类似*并发*是四辆汽车在同一个车道上跑; *并行*是单向四车道，四辆车在各自的车道跑，彼此不受影响。 * 串行：是指多个任务时，各个任务按顺序执行，完成一个之后才能进行下一个。 ## 导航过程这个也就是“从输入 URL 到页面显示发生了什么”的问题，但重点是整个过程，不只是得到响应数据后的解析与渲染。不过我猜大家都背熟了，大概是这样: ### 1、从输入 URL 到页面加载的全过程 1. 首先在浏览器中**输入** URL 2. **查找缓存**: 浏览器先查看浏览器缓存-系统缓存-路由缓存中是否有该地址页面，如果有则显示页面内容。如果没有则进行下一步。 3. **DNS 域名解析**: 浏览器向 DNS 服务器发起请求，解析该 URL 中的域名对应的 IP 地址。DNS 服务器是基于 UDP 的，因此会用到 UDP 协议。 4. **建立 TCP 连接**: 解析出 IP 地址后，根据 IP 地址和默认 80 端口，和服务器建立 TCP 连接 5. **发起 HTTP 请求**: 浏览器发起读取文件的 HTTP 请求，该请求报文作为 TCP 三次握手的第三次数据发送给服务器 6. **服务器响应请求并返回结果**: 服务器对浏览器请求做出响应，并把对应的 html 文件发送给浏览器 7. **关闭 TCP 连接**: 通过四次挥手释放 TCP 连接 8. **浏览器渲染**: 客户端（浏览器）解析 HTML 内容并渲染出来 9. **JS 引擎解析过程**: 调用 JS 引擎执行 JS 代码（JS 的解释阶段，预处理阶段，执行阶段生成执行上下文，VO(Variable Object)，作用域链、回收机制等这里可以参看一下一个 github 上有 37.4k star (2024-02-02再看时已经38.1k了) 的可能是 2013 年的问答仓库[What happens when...](https://github.com/alex/what-happens-when)。其描述为：“这个仓库试图回答一个古老的面试问题：当你在浏览器中输入 `google.com` 并且按下回车之后发生了什么？” 当然，我列的是大体的简述，原文中虽说主要的流程是如此，但更细节的是每个过程中浏览器参与工作的部分。主体内容如下。 ### 2、浏览器进程(Browser Process)的组成 * UI thread ：控制浏览器上的按钮及输入框； * Network thread: 处理网络请求，从网上获取数据； * Storage thread: 控制文件等的访问； ![浏览器进程的组成：UI线程、网络线程、存储线程.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c204b5fb96cf45d386336bac35d92fcd~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=839&h=548&s=102868&e=png&b=fdfdfd) 结合上面的过程概述，总结起来可参考这个表: | 步骤 | 进程、线程 | 处理说明 | | ------ | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 处理输入 | UI | 需要判断用户输入的是 URL 还是 query | | 开始导航 | UI -\> Network | 当用户点击回车键，UI 线程通知 network 线程获取网页内容，并控制 tab 上显示加载中标识。
网络线程会执行适当的协议,如 DNS 查询，随后为请求建立 TLS 连接 | | 读取响应 | network -\> UI | 当请求响应返回的时候，network 线程会依据 Content-Type 及 MIME Type sniffing 判断响应内容的格式。
例如：如果响应内容的格式是 HTML，下一步将会把这些数据传递给 renderer 进程；如果是 zip 文件或者其它文件，会把相关数据传输给下载管理器。 | | 查找渲染进程 | network -\> UI -\> Renderer 进程 | 当所有检查完成，network 线程确信浏览器可以导航到请求网页，network 线程会通知 UI 线程数据已经准备好，UI 线程会查找到一个 renderer 进程进行网页的渲染。 | | 确认导航 | browser 进程 -\> renderer 进程 | 数据以及 Renderer 进程都可用了， Browser 进程会给 renderer 进程发送 IPC 消息来确认导航。
一旦 Browser 进程收到 renderer 进程的渲染确认消息，导航过程结束，页面加载过程开始。 | | 额外的步骤 | browser 进程 -\> renderer 进程 | 一旦导航被确认，renderer 进程会使用相关的资源渲染页面。
当 renderer 进程渲染结束（渲染结束意味着该页面上所有 iframe 的所有 onload 事件都执行完毕），会发送 IPC 信号到 Browser 进程， UI 线程会停止 tab 中加载中标识。
当然上面的流程只是网页首帧渲染完成，在此之后，客户端依旧可下载额外的资源渲染出新的视图。 | *** ### 3、几点补充这里原文还有几点内容，导航到不同的站点、如果是使用 Service Worker、导航预加载。第一个“导航到不同的站点”主要是在导航完成后再次输入不同的 url 时 browser 进程的操作。导航的过程是一样的，只不过会**检查当前站点是否有 `beforeunload` 事件**。这就和我们有时候直接关闭网页时会有弹窗阻止你关闭(比如修改未保存、提交未完成之类的)一样。选项卡内的所有内容（包括 JavaScript 代码）均由 Renderer 进程处理，因此当新的导航请求传入时，Browser 进程必须检查当前 Renderer 进程。第二个“如果是 Service Worker”主要是讲使用了 Service Worker 的一些差异。Service Worker 是一种在应用程序代码中编写网络代理的方法；允许 Web 开发人员更好地控制本地缓存的内容以及何时从网络获取新数据。如果 Service Worker 设置为从缓存加载页面，则无需从网络请求数据。比较重要的是 Service Worker 是在 Renderer 进程中运行的 JavaScript 代码。但是当导航请求到来时，Browser 进程如何知道该站点有 Service Worker？当注册 Service Worker 后，Service Worker 的作用范围将保留作为参考(reference)。发生导航时，Network 线程会根据注册的 Service Worker 作用范围来检查域(domain)，如果为该 URL 注册了 Service Worker，则 UI 线程会找到 Renderer 进程以执行 Service Worker 代码。 Service Worker 也是一个重点，后续会展开讲在这里我们可以明确一点，**所有的 JS 代码其实都由 renderer Process 控制的，所以在你浏览网页内容的过程大部分时候不会涉及到其它的进程。** 不过也许你也曾经监听过 beforeunload 事件，这个事件再次涉及到 Browser Process 和 renderer Process 的交互，当当前页面关闭时（关闭 Tab ，刷新等等），Browser Process 需要通知 renderer Process 进行相关的检查，对相关事件进行处理。如果导航由 renderer process 触发（比如在用户点击某链接，或者 JS 执行 `window.location = "http://newsite.com"`） renderer process 会首先检查是否有 `beforeunload` 事件处理器，导航请求由 renderer process 传递给 Browser process 如果导航到新的网站，会启用一个新的 render process 来处理新页面的渲染，老的进程会留下来处理类似 `unload` 等事件。 ## 渲染过程 “导航过程”主要说的是 web 网页资源从后台服务器加载到前端浏览器的大体浏览，而“渲染过程”则主要说明浏览器如何把这些资源渲染到页面上的，可能有些标题为“浏览器中渲染器进程的工作原理”。这里可能会涉及到一些 Web 性能相关的点，但主要还是 CRP 的一些内容。 “导航过程”和“渲染过程”也就是常见的“浏览器的工作原理”的主要内容，而后者则主要是浏览器的“渲染器进程”的工作内容。 ### 渲染进程组成如果说“导航过程”的大头在“浏览器进程”，那么“渲染过程”的大头就在“渲染器进程”。 > **渲染器进程的核心工作是将 HTML、CSS 和 JavaScript 转换为用户可以交互的网页**。同理，参看渲染器进程中各个线程的结构： ![渲染器进程的组成：主线程、工作线程、合成器线程和光栅线程.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c6cb62322d9481987ac78d563a8be46~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=677&h=417&s=81439&e=png&b=fdfdfd) 接下来的具体渲染过程中，会提到每个线程的作用。根据《极客浏览器工作原理与实践》的说法： > 按照渲染的时间顺序，流水线可分为如下几个子阶段：构建 DOM 树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。而下面的内容，则主要按照包含 CRP(关键渲染路径)的步骤说明:解析(Parsing)、渲染(Render)、交互(Interactivity)。 *当然，如果还不清楚树结构、DOM 这样的基本概念，可以考虑直接看《极客浏览器工作原理与实践》[渲染流程（上）：HTML、CSS 和 JavaScript 是如何变成页面的](https://blog.poetries.top/browser-working-principle/guide/part1/lesson05.html)，我这整篇文章可能都不会比它说得更好*。 ### 解析 [howbrowserswork/#parsing-general](https://web.dev/howbrowserswork/#parsing-general) 中有很详细的解析说明，从语法、词法、解析器类型等各个方面来讲。这里就不这么深入了，单纯来说：**解析是浏览器将通过网络接收到的数据转换为 DOM 和 CSSOM 的步骤，渲染器使用它们将页面绘制到屏幕上**。稍微具体一点： #### 1、构建 DOM 树 **第一步是处理 HTML 标记并构造 DOM 树**。当渲染器进程收到导航的提交消息并开始接收 HTML 数据时，主线程开始解析文本字符串 (HTML) 并将其转换为文档对象模型 (DOM)。 * DOM 是浏览器的页面内部表示，也是 Web 开发人员可以通过 JS 进行交互的数据结构和 API。 * 将 HTML 文档解析为 DOM 是由 HTML 标准定义的。 * 向浏览器提供 HTML 永远不会引发错误。因为 [HTML 规范旨在优雅地处理这些错误](https://html.spec.whatwg.org/multipage/parsing.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser)。 #### 2、构建 CSSOM 树 **第二步是处理 CSS 并构建 CSSOM 树**。CSS 对象模型和 DOM 是相似的。DOM 和 CSSOM 是两棵树。它们是独立的数据结构。浏览器将 CSS 规则转换为可以理解和使用的样式映射。浏览器遍历 CSS 中的每个规则集，根据 CSS 选择器创建具有父、子和兄弟关系的节点树。 * CSSOM 树包括来自用户代理样式表(user agent style sheet)的样式。浏览器从适用于节点的最通用规则开始，并通过应用更具体的规则递归地优化计算的样式。 * [“构建 CSSOM 非常非常快，创建 CSSOM 的总时间通常小于一次 DNS 查询所需的时间”](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work#building_the_cssom_tree)。 #### 3、子资源加载 * 网站通常使用图像、CSS 和 JavaScript 等外部资源。这些文件需要从网络或缓存加载。 * 主线程可以在解析构建 DOM 时一一请求它们，但为了加快速度，**预加载扫描器**(preload scanner)是并发运行的。 * 预加载扫描器将解析可用的内容并请求高优先级资源，如 CSS、JavaScript 和 web 字体。多亏了预加载扫描器，我们不必等到解析器找到对外部资源的引用来请求它。 * 如果 HTML 文档中存在诸如 `` 或 `` 之类的内容，则预加载扫描器会查看 HTML 解析器生成的标记，并将请求发送到浏览器进程中的网络线程。 * 等待获取 CSS 不会阻塞 HTML 的解析或者下载，但是它确实会阻塞 JavaScript，因为 JavaScript 经常用于查询元素的 CSS 属性。 #### 4、JavaScript 可以阻止解析 * 当 HTML 解析器找到 `