如何搭建高性能网站哪一些事

在开发中经常会遇到网站的性能平静下来，打开慢的情况。我们平常开发中怎么一步一步排查这些问题并 解决问题呢

在快节奏的时代中，慢是个不容忍受的事情。

一、 为什么会‘慢’呢？

慢的情况是多种多样的，比如：

• 用户体验敢差，感觉“慢”
• javascript执行慢。
• 接口响应慢。
• 资源加载慢。
• 浏览器渲染慢。
  。。。

我们只能要求自己，所以用户手机网速慢是不存在的～。

二、 排查手段

我们直接进入则会难过i天

我们将从几个方面着手讲一下排查问题的手段

2.1 技术上的选择

在前端日常开发中，技术上的选择是非常重要的。为什么要讲这个呢？因为现象频发。

前端工程化严重的当下，轻量化的框架慢慢被遗忘掉了。并不是所有的业务场景都适合使用工程化框架，react/vue 并不轻量。

复杂的框架是为了解决复杂的业务

如果研发h5宣发、PC展示等场景简单的业务时候，javascript原生 配合一些轻量化插件更适合。

多页面应用也并不都是缺点。根据业务不同而选择不一样的技术是非常重要的，是每个前端都应该反思的事情。

这方面是导致卡顿的关键问题。

2.2 NetWrok

我们的老朋友NetWrok想必前端同学都很熟悉。我们先来看一下network面板

从面板上我们可以看出一些信息：

• 请求资源size
• 请求资源时长
• 请求资源数量
• 接口响应时长
• 接口发起数量
• 接口报文size
• 接口响应状态
• 瀑布图

瀑布图是什么呢？

瀑布图就是上方图片后面的waterfall纵列

瀑布图是一个级联图, 展示了浏览器如何加载资源并渲染成网页. 图中的每一行都是一次单独的浏览器请求. 这个图越长, 说明加载网页过程中所发的请求越多. 每一行的宽度, 代表浏览器发出请求并下载该资源的过程中所耗费的时间。它的侧重点在于分析网路链路

瀑布图颜色说明：

• DNS Lookup [深绿色] - 在浏览器和服务器进行通信之前, 必须经过DNS查询, 将域名转换成IP地址. 在这个阶段, 你可以处理的东西很少. 但幸运的是, 并非所有的请求都需要经过这一阶段.

• Initial Connection [橙色] - 在浏览器发送请求之前, 必须建立TCP连接. 这个过程仅仅发生在瀑布图中的开头几行, 否则这就是个性能问题(后边细说).

• SSL/TLS Negotiation [紫色] - 如果你的页面是通过SSL/TLS这类安全协议加载资源, 这段时间就是浏览器建立安全连接的过程. 目前Google将HTTPS作为其 搜索排名因素 之一, SSL/TLS 协商的使用变得越来越普遍了.

• Time To First Byte (TTFB) [绿色] - TTFB 是浏览器请求发送到服务器的时间+服务器处理请求时间+响应报文的第一字节到达浏览器的时间. 我们用这个指标来判断你的web服务器是否性能不够, 或者说你是否需要使用CDN.

• Downloading (蓝色) - 这是浏览器用来下载资源所用的时间. 这段时间越长, 说明资源越大. 理想情况下, 你可以通过控制资源的大小来控制这段时间的长度.

那么除了瀑布图的长度外，我们如何才能判断一个瀑布图的状态是健康的呢？

• 首先, 减少所有资源的加载时间. 亦即减小瀑布图的宽度. 瀑布图越窄, 网站的访问速度越快.

• 其次, 减少请求数量 也就是降低瀑布图的高度. 瀑布图越矮越好.

• 最后, 通过优化资源请求顺序来加快渲染时间. 从图上看, 就是将绿色的"开始渲染"线向左移. 这条线向左移动的越远越好.

这样，我们就可以从network的角度去排查“慢”的问题。

2.3 webpack-bundle-analyzer

项目构建后生成的bundle包是压缩后的。webpack-bundle-analyzer是一款包分析工具。

我们先来看一下它能带来的效果。如下图：

从上图来看，我们的bundle包被解析的一览无余。其中模块面积占的越大说明在bundle包中size越大。就值得注意了，重点优化一下。

它能够排查出来的信息有

• 显示包中所有打入的模块
• 显示模块size 及 gzip后的size
  排查包中的模块情形是非常有必要的，通过webpack-bundle-analyzer来排查出一些无用的模块，过大的模块。然后进行优化。以减少我们的bundle包size，减少加载时长。

安装

# NPM
npm install --save-dev webpack-bundle-analyzer
# Yarn
yarn add -D webpack-bundle-analyzer

使用(as a Webpack-Plugin)

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
  
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}

然后构建包完毕后会自动弹出一个窗口展示上图信息。

2.4 Performance

chrome自带的performance模块。先附上一个官网文档传送门：Performance

可以检测很多方面的数据，多数情况的性能排查上用的比较多。如果想要深入了解的同学建议去看一下官方文档。

接下来我们来说一下在performance面板中如何排差“慢”的问题，它给我们提供了哪些信息呢。先附上一张performance的面板图片。

从上图中可以分析出一些指标

• FCP/LCP 时间是否过长？
• 请求并发情况 是否并发频繁？
• 请求发起顺序 请求发起顺序是否不对？
• avascript执行情况 javascript执行是否过慢？
  这些指标就是我们需要重点关注的，当然performance的功能并不止于此。

先记住如何获取到这些指标，后面来一一进行解析优化。

2.5 抓包

有一些业务状况是没有上述的一些调试工具该怎么办呢？我们可以利用抓包工具进行对页面信息对抓取，上述我们通过chrome工具排查出来的指标，也可以通过抓包工具进行抓取。

这里我推荐一款抓包工具charles。使用教程网上很多，自行搜索即可

(原文地址](https://www.cnblogs.com/xiaoXuZhi/p/xyh_20201014.html)