全链路的性能优化整合·

前言：

前面的过程中，我们零零散散地提到了性能优化做的事情，恰巧内网最近一篇文章写的不错，仔细学习了下作者的微信公众号文章。但我不打算把他的文本简单copy一遍，因为自己最近刚刚做过相关的事，所以，更多的想结合自己的理解和其他资料学习总结一下

在介绍知识之前，我们需要交代一下背景。如果现在给你一个现成的项目要求做性能优化，你会怎么下手呢？这种感觉就好像，你要去体检，那么知道你哪里好，哪儿不好，不好需要吃什么药呢？开始之前，需要明确几点：

  • 如何评价页面的性能好坏呢？

    当然不是直觉，必须有数据指标支撑，这就需要一些工具的帮助

  • 随后，问题就来了，如何使用各种性能相关工具？

    这个过程中，肯定会涉及到很多指标，我们需要读懂指标的含义，针对其对应的表现优化，要有针对性的理解指标，就要需要浏览器的基本知识了。

  • 页面是从哪里来的？又是怎么在浏览器上渲染出来的？

以上抛出的3个问题基本回答了：

  1. 浏览器的网络请求环节发生了什么？
  2. 页面渲染环节发生了什么？
  3. 两个环节的我们如何下手优化？

完整过程·

图片

一、网络通信环节·

阶段0：用户输入·

我们在搜索栏目巴拉巴拉输入…一个url，并回车后。浏览器小伙会暗中判断输入的url是不是正确的：

  • 那什么是正确的url呢？

    那肯定要看标准的呀，安排：https://mynightwish.top/posts/URL_URI.html

  • 不标准是不是就搜不到了？

    wrong，浏览器会用默认的搜索引擎将该关键字拼接成url

阶段1：【Process Unload Event】、【Redirect】·

浏览器会将现有页面卸载掉并重定向到用户新输入的url页面；

此时浏览器会准备一个渲染进程用于渲染即将到来的页面，和一个网络进程用于发送网络请求。

阶段2：Service Worker·

即图中：【Service Worker Init】与【Service Worker Fecth Event 】步骤

如果当前页面注册了Service Worker那么它可以拦截当前网站所有的请求，进行判断是否需要向远程发送网络请求。

如果不需要发送网络请求，则取本地文件。如果需要则进行下一步。

阶段3：网络请求·

包含了图中黄色的：【HTTP Cache】、【DNS】、【TCP】、【Request】、【Response】步骤

OSI网络七层模型：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

在实际应用中物理层、数据链路层被统称为物理层，会话层、表示层、应用层被统称为应用层，所以实际使用时通常分为4个层级

【物理层】>【网络层(IP)】>【传输层(TCP/UDP)】>【应用层(HTTP)】

刚刚阶段1：说浏览器会重定向到输入的url页面：

  • 它怎么知道这个url对应哪个页面呢？它又怎么拿到该页面对应的资源呢？

浏览器小伙会拿着url通过网络进程进行如下步骤：

  1. 根据url查询本地是否已经有强制缓存，如果有则判断缓存是否过期，如果没过期则直接返回缓存内容，也就是图1中【HTTP Cache】步骤

    这里涉及到了强缓存、协商缓存的概念，需要补课的小伙伴，猛戳：

    https://mynightwish.top/posts/588825314.html

  2. 如果没有强制缓存或缓存已过期，则将该请求加入队列，排队准备发送网络请求，也就是图2中【正在排队】，然后进入DNS解析阶段，也就是图1中【DNS】以及图2中的【DNS查找】，DNS根据域名解析出对应的IP地址。(DNS基于UDP)。

    关于DNS解析，猛戳：https://mynightwish.top/posts/2124882507.html

    说的俗一点：就是浏览器不认识这个url了，或者这个url已经变心了，浏览器需要重新去寻找该url对应的真正地址：ip地址，才能找到这个真实的资源，建立连接，才能正常的再一次一起happy工作~

  3. 然后使用IP寻址找到对方，然后根据IP地址+端口号创建一个TCP连接(三次握手)，也就是图1中【TCP】以及图2中的【初始连接】创建完成后利用TCP连接来传输数据。(TCP会将数据拆分为多个数据包，进行有序传输，如果丢包会重发，TCP的特点是可靠、有序)

    关于TCP的传输，猛戳：https://mynightwish.top/posts/2124882507.html

    终于找到伙计了，咱们打个招呼，握个手吧~

  4. 判断当前协议是否为https，如果为https，则进行SSL协商，将数据进行加密，如果为http协议则不进行加密(明文传输)，也就是图2中的【SSL】。

    关于为什么需要HTTPS、它为啥安全呢、怎么加密的呢？请再次戳我这儿：

    https://mynightwish.top/posts/HTTPS.html

    一会我要跟伙计说话，可不能被别人偷听了，我该咋让你安全知道我说了啥呢？

  5. 开始发送http请求(请求行/请求头/请求体)，也就是图1中【Request】以及图2中的【已发送请求】。HTTP协议有多个版本，目前使用最多的版本为HTTP/1.1，HTTP/1.1发送完成后默认不会断开。keep-alive 默认打开，为了下次传输数据时复用上次创建的连接。每个域名最多同时建立6个TCP连接，所以同一时间最多发生6个请求。

    哎呀，废了半天劲，终于找到你了，手也握了，接下来我要跟你讨论一个惊天秘密，hhhh…

    可供我们选择的通讯方式太多了：

    • BB机、老年机、智能机

    关于HTTP的版本升级路线，如果你想了解，仍然戳我：

    https://mynightwish.top/posts/2716721158.html

  6. 服务器收到数据后解析HTTP请求(请求行/请求头/请求体)，处理完成后生成状态码和HTTP响应(响应行/响应头/响应体)后返回给客户端，也就是图2的【等待中】在做的事情。

    服务器端，收到你的请求后，要回应你啊。那么如何表示它的回应内容呢？都说男生很难读懂女朋友的心情，但服务器会很贴心的给你一个响应报文，他把自己关于回应的都写在这里啦，是不是更简单~

    • 关于请求报文、响应报文，安排：https://mynightwish.top/posts/2716721158.html
    • 关于状态码，猛戳我：https://mynightwish.top/posts/2716721158.html

    服务端可以响应并返回给客户端很多种类型的资源，这里主要介绍html类型

    • 目前前端处理服务端响应html请求主要分为SSR服务端渲染与CSR客户端渲染：

      CSR就是返回一个空的HTML模版，然后浏览器加载js后通过js动态渲染页面。

      SSR是服务端在接受到请求时事先在服务端渲染好html返回给客户端后，客户端再进行客户端激活。

    • 在打开一个站点的首屏页的完整链路中，使用SSR服务端渲染时的速度要远大于CSR客户端渲染，并且SSR对SEO友好。所以对于首屏加载速度比较敏感或者需要优化SEO的站点来说，使用SSR是更好的选择。比如我们的Next.js

    这里又出现了服务端渲染、客户端渲染的概念，手拉手跟我一起学习下吧：

    https://mynightwish.top/posts/CSR_SSR.html

  7. 客户端接收到HTTP响应后根据状态码进行对应的处理，如果状态码为304则直接代表协商缓存生效，直接取本地的缓存文件。如果不是则下载内容。也就是图1中【Response】以及图2中的【下载内容】步骤。

    这里又涉及到了协商缓存的概念，点俺：

    https://mynightwish.top/posts/588825314.html

二、页面渲染·

…待续