知识体系： 从一道面试题说起

在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题：

从输入 URL 到页面加载完成，发生了什么？ 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作。

我们将这个过程切分为如下的过程片段：

• DNS 解析
• TCP 连接
• HTTP 请求抛出
• 服务端处理请求，HTTP 响应返回
• 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户

大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。

从原理到实践：各个击破

我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。

具体来说，DNS 解析花时间，能不能尽量减少解析次数或者把解析前置？能——浏览器 DNS 缓存和 DNS prefetch。TCP 每次的三次握手都急死人，有没有解决方案？有——长连接、预连接、接入 SPDY 协议。如果说这两个过程的优化往往需要我们和团队的服务端工程师协作完成，前端单方面可以做的努力有限，那么 HTTP 请求呢？——在减少请求次数和减小请求体积方面，我们应该是专家！再者，服务器越远，一次请求就越慢，那部署时就把静态资源放在离我们更近的 CDN 上是不是就能更快一些？

以上提到的都是网络层面的性能优化。再往下走就是浏览器端的性能优化——这部分涉及资源加载优化、服务端渲染、浏览器缓存机制的利用、DOM 树的构建、网页排版和渲染过程、回流与重绘的考量、DOM 操作的合理规避等等——这正是前端工程师可以真正一展拳脚的地方。学习这些知识，不仅可以帮助我们从根本上提升页面性能，更能够大大加深个人对浏览器底层原理、运行机制的理解，一举两得！

我们整个的知识图谱，用思维导图展示如下

我们将从网络层面和渲染层面两个大的维度来逐个点亮前端性能优化的技能树。

在各种网站上经常能看到PWA（渐进式web应用）的概念，每次都是大致的过一遍，基本概念是知道的，具体是怎么实现的还没看过，最近正好有时间去研究。

PWA为什么值得关注？

移动web的优势（SEO，即时性 ，可查找能力，可链接 ，低阻力）为它带来了很多流量，但是它的缺点平均加载时间也会导致损失很多的用户，并且移动网站无法进行推送通知。 而以上问题的解决方案就是渐进式Web App（PWA）

什么是PWA？

PWA结合了最好的Web应用和最好的原生应用的用户体验。
实现pwa技术点：

• Service Workers 开启服务线程，拦截网络请求
• Cache 用于离线缓存
• manifest.json web 应用清单，添加程序到主屏幕
• Push Notification 推送通知

什么是Web Worker？为什么引入？

简单点说，Web Worker就是一个运行在后台的JavaScript线程，不会影响页面的响应。

我们知道，JavaScript是单线程的脚本语言，即同一时刻只能做一件事情，否则会带来极其复杂的同步问题。比如JavaScript同时有两个线程，一个线程负责给某个DOM节点添加内容，另一个线程删除这个节点，这时，浏览器要以哪个线程为主呢？

k线颜色:传递阴阳涨跌信号

k线实体大小:传递内在动力信号

注：空方——持有方卖方 多方——买方

在网络中，网站的IP地址很难让人去记住，一般都是使用域名去访问，因此就有了DNS服务器，根据IP查询域名的地址簿。
每台计算器上都有相应的DNS客户端，也称作DNS解析器。通过DNS查询IP地址的操作称为域名解析，DNS解析器实际上是一段代码，包含在了操作系统的Socket库中，Socket是C语言实现的调用网络功能的库。

DNS解析流程

浏览器调用解析器时，切换到了解析器的上下文执行环境切，也就是Socket中的一段代码 gethostbyname ,这段代码会生成发送给DNS服务器的查询消息，与浏览器生成http请求的过程类似，然后将消息发送给DNS服务器。发送这个过程并不是解析器来执行的，而是委托给了操作系统内部的协议栈去做处理，协议栈通过网卡将消息发送给DNS服务器。