qq_46143850的博客

好了，今天就介绍到这里，下面我来总结下本文的主要内容。我们首先分析了HTTP/2中所存在的一些问题，主要包括了TCP的队头阻塞、建立TCP连接的延时、TCP协议僵化等问题。这些问题都是TCP的内部问题，因此要解决这些问题就要优化TCP或者“另起炉灶”创造新的协议。由于优化TCP协议存在着诸多挑战，所以官方选择了创建新的QUIC协议。HTTP/3正是基于QUIC协议的，你可以把QUIC看成是集成了“TCP+HTTP/2的多路复用+TLS等功能”的一套协议。

好了，今天就介绍这里，下面我来总结下本文的主要内容。我们首先分析了影响HTTP/1.1效率的三个主要因素：TCP的慢启动、多条TCP连接竞争带宽和队头阻塞。接下来我们分析了HTTP/2是如何采用多路复用机制来解决这些问题的。多路复用是通过在协议栈中添加二进制分帧层来实现的，有了二进制分帧层还能够实现请求的优先级、服务器推送、头部压缩等特性，从而大大提升了文件传输效率。HTTP/2协议规范于2015年5月正式发布，在那之后，该协议已在互联网和万维网上得到了广泛的实现和部署。

好了，今天就介绍到这里，下面我来总结下本文的主要内容。本文我们重点强调了HTTP是浏览器和服务器的通信语言，然后我们从需求演变的角度追溯了HTTP的发展史，在诞生之初的HTTP/0.9因为需求简单，所以和服务器之间的通信过程也相对简单。由于万维网的快速崛起，带来了大量新的需求，其中最核心的一个就是需要支持多种类型的文件下载， 为此HTTP/1.0中引入了请求头和响应头。在支持多种类型文件下载的基础之上，HTTP/1.0还提供了Cache机制、用户代理、状态码等一些基础信息。

好了，今天就讲到这里，下面我来总结下本文的主要内容。首先，我们介绍了组件化开发是程序员的刚需，所谓组件化就是功能模块要实现高内聚、低耦合的特性。不过由于DOM和CSSOM都是全局的，所以它们是影响了前端组件化的主要元素。基于这个原因，就出现WebComponent，它包含自定义元素、影子DOM和HTML模板三种技术，使得开发者可以隔离CSS和DOM。在此基础上，我们还重点介绍了影子DOM到底是怎么实现的。

我们先来看看 Service Worker是怎么解决离线存储和消息推送的问题。其实在Service Worker之前，WHATWG小组就推出过用App Cache标准来缓存页面，不过在使用过程中App Cache所暴露的问题比较多，遭到多方吐槽，所以这个标准最终也只能被废弃了，可见一个成功的标准是需要经历实践考量的。所以在2014年的时候，标准委员会就提出了Service Worker的概念，它的主要思想是在页面和网络之间增加一个拦截器，用来缓存和拦截请求。

好了，今天就介绍到这里，下面我来总结下本文的主要内容。我们主要讲解了如何系统优化加载阶段和交互阶段的页面。在加载阶段，核心的优化原则是：优化关键资源的加载速度，减少关键资源的个数，降低关键资源的RTT次数。在交互阶段，核心的优化原则是：尽量减少一帧的生成时间。可以通过减少单次JavaScript的执行时间、避免强制同步布局、避免布局抖动、尽量采用CSS的合成动画、避免频繁的垃圾回收等方式来减少一帧生成的时长。

好了，今天就介绍到这里，下面我来总结下今天的内容。首先我们介绍了显示器显示图像的原理，以及帧和帧率的概念，然后基于帧和帧率我们又介绍渲染引擎是如何实现一帧图像的。通常渲染引擎生成一帧图像有三种方式：重排、重绘和合成。其中重排和重绘操作都是在渲染进程的主线程上执行的，比较耗时；而合成操作是在渲染进程的合成线程上执行的，执行速度快，且不占用主线程。然后我们重点介绍了浏览器是怎么实现合成的，其技术细节主要可以使用三个词来概括：分层、分块和合成。

好了，今天就介绍到这里，下面我来总结下今天的内容。我们首先介绍了CSS在渲染流水线中的位置，以及CSS是如何影响到渲染流程的；接下来我们通过渲染流水线分析了从发出请求到页面首次绘制的三个阶段；最后重点介绍了第二个白屏阶段以及优化该阶段的一些策略。通过今天的内容我们可以知道虽然JavaScript和CSS给我们带来了极大的便利，不过也对页面的渲染带来了很多的限制，所以我们要关注资源加载速度，需要小心翼翼地处理各种资源之间的关联关系。

从网络传给渲染引擎的HTML文件字节流是无法直接被渲染引擎理解的，所以要将其转化为渲染引擎能够理解的内部结构，这个结构就是DOM。DOM提供了对HTML文档结构化的表述。在渲染引擎中，DOM有三个层面的作用。从页面的视角来看，DOM是生成页面的基础数据结构。从JavaScript脚本视角来看，DOM提供给JavaScript脚本操作的接口，通过这套接口，JavaScript可以对DOM结构进行访问，从而改变文档的结构、样式和内容。

好了，今天就介绍到这里了，下面我来总结下今天的内容。首先我们简单介绍了Chrome开发者工具10个基础的面板信息；然后重点剖析了网络面板，再结合之前介绍的网络请求流程来重点分析了网络面板中时间线的各个指标的含义；最后我们还简要分析了时间线中各项指标出现异常的可能原因，并给出了一些优化方案。其实通过今天的分析，我们可以得出这样一个结论：如果你要去做一些实践性的项目优化，理解其背后的理论至关重要。因为理论就是一条“线”，它会把各种实践的内容“串”在一起，然后你可以围绕着这条“线”来排查问题。

好了，今天就介绍到这里，下面我来总结下今天的主要内容。Promise的编程模型依然充斥着大量的then方法，虽然解决了回调地狱的问题，但是在语义方面依然存在缺陷，代码中充斥着大量的then函数，这就是async/await出现的原因。使用async/await可以实现用同步代码的风格来编写异步代码，这是因为async/await的基础技术使用了生成器和Promise，生成器是协程的实现，利用生成器能实现生成器函数的暂停和恢复。

好了，今天我们就聊到这里，下面我来总结下今天所讲的内容。首先，我们回顾了 Web 页面是单线程架构模型，这种模型决定了我们编写代码的形式——异步编程。基于异步编程模型写出来的代码会把一些关键的逻辑点打乱，所以这种风格的代码不符合人的线性思维方式。接下来我们试着把一些不必要的回调接口封装起来，简单封装取得了一定的效果，不过，在稍微复制点的场景下依然存在着回调地狱的问题。多层嵌套的问题；每种任务的处理结果存在两种可能性（成功或失败），那么需要在每种任务执行结束后分别处理这两种可能性。

好了，今天就介绍到这里，下面我来总结下今天的内容。首先我们回顾了宏任务，然后在宏任务的基础之上，我们分析了异步回调函数的两种形式，其中最后一种回调的方式就是通过微任务来实现的。接下来我们详细分析了浏览器是如何实现微任务的，包括微任务队列、检查点等概念。最后我们介绍了监听DOM变化技术方案的演化史，从轮询到Mutation Event再到最新使用的MutationObserver。MutationObserver方案的核心就是采用了微任务机制，有效地权衡了实时性和执行效率的问题。

好了，今天我们就讲到这里，下面我来总结下今天的内容。首先我们介绍了回调函数和系统调用栈；接下来我们站在循环系统的视角，分析了XMLHttpRequest是怎么工作的；最后又说明了由于一些安全因素的限制，在使用XMLHttpRequest的过程中会遇到跨域问题和混合内容的问题。本篇文章跨度比较大，不是单纯地讲一个问题，而是将回调类型、循环系统、网络请求和安全问题“串联”起来了。对比上一篇文章。

好了，今天我们就介绍到这里，下面我来总结下今天的内容。首先，为了支持定时器的实现，浏览器增加了延时队列。其次，由于消息队列排队和一些系统级别的限制，通过setTimeout设置的回调任务并非总是可以实时地被执行，这样就不能满足一些实时性要求较高的需求了。最后，在定时器中使用过程中，还存在一些陷阱，需要你多加注意。通过分析和讲解，你会发现函数setTimeout在时效性上面有很多先天的不足，所以对于一些时间精度要求比较高的需求，应该有针对性地采取一些其他的方案。

好了，这一节就到这里，下面我来做一个简单的总结。互联网中的数据是通过数据包来传输的，数据包在传输过程中容易丢失或出错。IP负责把数据包送达目的主机。UDP负责把数据包送达具体应用。而TCP保证了数据完整地传输，它的连接可分为三个阶段：建立连接、传输数据和断开连接。其实了解TCP协议，是为了全方位了解HTTP，包括其实际功能和局限性，之后才会更加深刻地理解为什么要推出HTTP/2，以及为什么要推出QUIC协议，也就是未来的HTTP/3。

无论你是想要设计高性能Web应用，还是要优化现有的Web应用，你都需要了解浏览器中的网络流程、页面渲染过程，JavaScript执行流程，以及Web安全理论，而这些功能是分散在浏览器的各个功能组件中的，比较多、比较散，要怎样学习才能掌握呢？通过浏览器的多进程架构的学习，你就可以把这些分散的知识点串起来，组成一张网，从而让自己能站在更高的维度去理解Web应用。因此，学习浏览器的多进程架构是很有必要的。需要说明的是，在本专栏中，所有的分析都是基于Chrome浏览器的。