echohuangshihuxue的博客

好了，今天的内容就介绍到这里，下面我们总结下本文的主要内容：我们先回顾了数字证书的申请流程，接着我们重点介绍了浏览器是如何验证数字证书的。首先浏览器需要CA的数字证书才能验证极客时间的数字证书，接下来我们需要验证CA证书的合法性，最简单的方法是将CA证书内置在操作系统中。

本文主要的目的是让我们学会如何分析Main指标。通过页面加载过程的分析，就能掌握一套标准的分析Main指标的方法，在该方法中，我将加载过程划分为三个阶段：导航阶段；解析HTML文件阶段；生成位图阶段。在导航流程中，主要是处理响应头的数据，并执行一些老页面退出之前的清理操作。在解析HTML数据阶段，主要是解析HTML数据、解析CSS数据、执行JavaScript来生成DOM和CSSOM。

好了，本节内容就介绍到这里，下面我来总结下本文的主要内容：本节我们首先介绍了如何去配置Performance并生成报告页，然后我们将焦点放在了如何解读报告页上。之后我们介绍了报告页面主要分为三个部分，概览面板、性能面板和详情面板。我们可以通过概览面板来定位问题的时间节点，然后再使用性能面板分析该时间节点内的性能数据。不过在分析数据时，我们需要弄明白性能面板内各项数据指标的含义，要了解这些，需要了解浏览器渲染流水线、浏览器的进程架构等知识点，因此结合这些知识点，我们接下来分析了性能面板的各项指标的含义。

我们看下wiki对Web 性能的定义Web 性能描述了Web应用在浏览器上的加载和显示的速度。因此，当我们讨论Web性能时，其实就是讨论Web应用速度，关于Web应用的速度，我们需要从两个阶段来考虑：页面加载阶段；页面交互阶段。在本文中，我们会将焦点放到第一个阶段：页面加载阶段的性能，在下篇文章中，我们会来重点分析页面交互阶段的性能。好了，今天的内容就介绍到这里，下面我来总结下本文的主要内容：本文我们主要讨论如何优化加载阶段的Web应用的性能。

好了，本节的内容就介绍到这里，下面我来总结下本文的主要内容：首先我们分析了基于单消息队列会引起队头阻塞的问题，为了解决队头阻塞问题，我们引入了多个不同优级的消息队列，并将紧急的任务添加到高优先级队列，不过大多数任务需要保持其相对执行顺序，如果将用户输入的消息或者合成消息添加进多个不同优先级的队列中，那么这种任务的相对执行顺序就会被打乱，所以我们又迭代了第二个版本。

好了，本节的内容就介绍到这里，下面我来总结下本文的主要内容：首先我们使用了两种不同的方式打开两个标签页，第一种是从A标签页中通过链接打开了B标签页，第二种是分别打开A和B标签页，这两种情况下的A和B都属于同一站点。通过Chrome的任务管理器我们发现，虽然A标签页和B标签页都属于同一站点，不过通过第一种方式打开的A标签页和B标签页会共用同一个渲染进程，而通过第二种方式打开的两个标签页却分别使用了两个不同的渲染进程。

好了，今天就介绍到这里，下面我来总结下本文的主要内容。由于HTTP的明文传输特性，在传输过程中的每一个环节，数据都有可能被窃取或者篡改，这倒逼着我们需要引入加密机制。于是我们在HTTP协议栈的TCP和HTTP层之间插入了一个安全层，负责数据的加密和解密操作。我们使用对称加密实现了安全层，但是由于对称加密的密钥需要明文传输，所以我们又将对称加密改造成了非对称加密。

好了，今天的内容就介绍到这里，下面我来总结下本文的主要内容。首先我们分析了单进程浏览器在系统安全方面的不足，如果浏览器存在漏洞，那么黑客就有机会通过页面对系统发起攻击。因此在设计现代浏览器的体系架构时，就考虑到这个问题了。于是，在多进程的基础之上引入了安全沙箱，有了安全沙箱，就可以将操作系统和渲染进程进行隔离，这样即便渲染进程由于漏洞被攻击，也不会影响到操作系统的。

CSRF英文全称是Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。通常当用户打开了黑客的页面后，黑客有三种方式去实施CSRF攻击。下面我们以极客时间官网为例子，来分析这三种攻击方式都是怎么实施的。#同时支持POST和Get#接口#参数##目标用户user##目标金额number。

XSS全称是Cross Site Scripting，为了与“CSS”区分开来，故简称XSS，翻译过来就是“跨站脚本”。XSS攻击是指黑客往HTML文件中或者DOM中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。但是发展到现在，往HTML文件中注入恶意代码的方式越来越多了，所以是否跨域注入脚本已经不是唯一的注入手段了，但是XSS这个名字却一直保留至今。

要了解什么是同源策略，我们得先来看看什么是同源。如果两个URL的协议、域名和端口都相同，我们就称这两个URL同源。比如下面这两个URL，它们具有相同的协议HTTPS、相同的域名time.geekbang.org，以及相同的端口443，所以我们就说这两个URL是同源的。category=1category=0浏览器默认两个相同的源之间是可以相互访问资源和操作DOM的。两个不同的源之间若想要相互访问资源或者操作DOM，那么会有一套基础的安全策略的制约，我们把这称为同源策略。

好了，今天就介绍到这里，下面我来总结下本文的主要内容。我们首先分析了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的概念，它的主要思想是在页面和网络之间增加一个拦截器，用来缓存和拦截请求。

在谈论什么是虚拟DOM之前，我们先来看看虚拟DOM到底要解决哪些事情。将页面改变的内容应用到虚拟DOM上，而不是直接应用到DOM上。变化被应用到虚拟DOM上时，虚拟DOM并不急着去渲染页面，而仅仅是调整虚拟DOM的内部状态，这样操作虚拟DOM的代价就变得非常轻了。在虚拟DOM收集到足够的改变时，再把这些变化一次性应用到真实的DOM上。基于以上三点，我们再来看看什么是虚拟DOM。为了直观理解，你可以参考下图：虚拟DOM执行流程。

好了，今天就介绍到这里，下面我来总结下本文的主要内容。我们主要讲解了如何系统优化加载阶段和交互阶段的页面。在加载阶段，核心的优化原则是：优化关键资源的加载速度，减少关键资源的个数，降低关键资源的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在时效性上面有很多先天的不足，所以对于一些时间精度要求比较高的需求，应该有针对性地采取一些其他的方案。

好了，今天就讲到这里，下面我来总结下今天所讲的内容。如果有一些确定好的任务，可以使用一个单线程来按照顺序处理这些任务，这是第一版线程模型。要在线程执行过程中接收并处理新的任务，就需要引入循环语句和事件系统，这是第二版线程模型。如果要接收其他线程发送过来的任务，就需要引入消息队列，这是第三版线程模型。如果其他进程想要发送任务给页面主线程，那么先通过IPC把任务发送给渲染进程的IO线程，IO线程再把任务发送给页面主线程。消息队列机制并不是太灵活，为了适应效率和实时性，引入了微任务。

好了，今天就讲到这里，下面我来总结下今天的内容。首先我们介绍了编译器和解释器的区别。紧接着又详细分析了V8是如何执行一段JavaScript代码的：V8依据JavaScript代码生成AST和执行上下文，再基于AST生成字节码，然后通过解释器执行字节码，通过编译器来优化编译字节码。基于字节码和编译器，我们又介绍了JIT技术。最后我们延伸说明了下优化JavaScript性能的一些策略。

好了，今天的内容就讲到这里，下面我们来回顾下今天的内容：首先，介绍了什么是作用域链，我们把通过作用域查找变量的链条称为作用域链；作用域链是通过词法作用域来确定的，而词法作用域反映了代码的结构。其次，介绍了在块级作用域中是如何通过作用域链来查找变量的。最后，又基于作用域链和词法环境介绍了到底什么是闭包。通过展开词法作用域，我们介绍了JavaScript中的作用域链和闭包；

好了，今天就讲到这里，下面我来简单总结下今天的要点。我们介绍了JavaScript中的8种数据类型，它们可以分为两大类——原始类型和引用类型。其中，原始类型的数据是存放在栈中，引用类型的数据是存放在堆中的。堆中的数据是通过引用和变量关联起来的。也就是说，JavaScript的变量是没有数据类型的，值才有数据类型，变量可以随时持有任何类型的数据。然后我们分析了，在JavaScript中将一个原始类型的变量a赋值给b，那么a和b会相互独立、互不影响；

好了，今天就讲到这里，下面我们就来总结下今天的主要内容。首先我们介绍了不同语言的垃圾回收策略，然后又说明了栈中的数据是如何回收的，最后重点讲解了JavaScript中的垃圾回收器是如何工作的。从上面的分析你也能看出来，无论是垃圾回收的策略，还是处理全停顿的策略，往往都没有一个完美的解决方案，你需要花一些时间来做权衡，而这需要牺牲当前某几方面的指标来换取其他几个指标的提升。其实站在工程师的视角，我们经常需要在满足需求的前提下，权衡各个指标的得失，把系统设计得尽可能适应最核心的需求。

好了，今天就到这里，下面我们来回顾下今天的内容。首先，在使用this时，为了避坑，你要谨记以下三点：当函数作为对象的方法调用时，函数中的this就是该对象；当函数被正常调用时，在严格模式下，this值是undefined，非严格模式下this指向的是全局对象window；嵌套函数中的this不会继承外层函数的this值。最后，我们还提了一下箭头函数，因为箭头函数没有自己的执行上下文，所以箭头函数的this就是它外层函数的this。

好了，今天的内容就讲到这里，下面我来简单总结下今天的内容。由于JavaScript的变量提升存在着变量覆盖、变量污染等设计缺陷，所以ES6引入了块级作用域关键字来解决这些问题。之后我们还通过对变量环境和词法环境的介绍，分析了JavaScript引擎是如何同时支持变量提升和块级作用域的。既然聊到了作用域，那最后我们再简单聊下编程语言吧。

函数调用就是运行一个函数，具体使用方式是使用函数名称跟着一对小括号。var a = 2var b = 10return a+badd()这段代码很简单，先是创建了一个add函数，接着在代码的最下面又调用了该函数。那么下面我们就利用这段简单的代码来解释下函数调用的过程。在执行到函数add()之前，JavaScript引擎会为上面这段代码创建全局执行上下文，包含了声明的函数和变量，你可以参考下图：全局执行上下文从图中可以看出，代码中全局变量和函数都保存在全局上下文的变量环境中。

好了，今天就到这里，下面我来简单总结下今天的主要内容：JavaScript代码执行过程中，需要先做变量提升，而之所以需要实现变量提升，是因为JavaScript代码在执行之前需要先编译。在编译阶段，变量和函数会被存放到变量环境中，变量的默认值会被设置为undefined；在代码执行阶段，JavaScript引擎会从变量环境中去查找自定义的变量和函数。如果在编译阶段，存在两个相同的函数，那么最终存放在变量环境中的是最后定义的那个，这是因为后定义的会覆盖掉之前定义的。

好了，我们现在已经分析完了整个渲染流程，从HTML到DOM、样式计算、布局、图层、绘制、光栅化、合成和显示。下面我用一张图来总结下这整个渲染流程：完整的渲染流水线示意图结合上图，一个完整的渲染流程大致可总结为如下：渲染进程将HTML内容转换为能够读懂的DOM树结构。渲染引擎将CSS样式表转化为浏览器可以理解的styleSheets，计算出DOM节点的样式。创建布局树，并计算元素的布局信息。对布局树进行分层，并生成分层树。为每个图层生成绘制列表，并将其提交到合成线程。

好了，今天正文就到这里，我画了下面这张比较完整的渲染流水线，你可以结合这张图来回顾下今天的内容。渲染流水线图从图中可以看出，本节内容我们介绍了渲染流程的前三个阶段：DOM生成、样式计算和布局。要点可大致总结为如下：浏览器不能直接理解HTML数据，所以第一步需要将其转换为浏览器能够理解的DOM树结构；生成DOM树后，还需要根据CSS样式表，来计算出DOM树所有节点的样式；最后计算DOM元素的布局信息，使其都保存在布局树中。

好了，今天就到这里，下面我来简单总结下这篇文章的要点：服务器可以根据响应头来控制浏览器的行为，如跳转、网络数据类型判断。Chrome默认采用每个标签对应一个渲染进程，但是如果两个页面属于同一站点，那这两个标签会使用同一个渲染进程。浏览器的导航过程涵盖了从用户发起请求到提交文档给渲染进程的中间所有阶段。导航流程很重要，它是网络加载流程和渲染流程之间的一座桥梁，如果你理解了导航流程，那么你就能完整串起来整个页面显示流程，这对于你理解浏览器的工作原理起到了点睛的作用。

本篇文章的内容比较多、比较碎，但是非常重要，所以我先来总结下今天的主要内容。为了便于你理解，我画了下面这张详细的“HTTP请求示意图”，用来展现浏览器中的HTTP请求所经历的各个阶段。HTTP请求流程示意图从图中可以看到，浏览器中的HTTP请求从发起到结束一共经历了如下八个阶段：构建请求、查找缓存、准备IP和端口、等待TCP队列、建立TCP连接、发起HTTP请求、服务器处理请求、服务器返回请求和断开连接。