首屏加载缓慢优化

TTFB

# 什么是 TTFB

  TTFB，Time to First Byte 的缩写，又叫首字节响应时间。指的是浏览器开始接受服务器响应数据的时间，包含 后台处理时间 + 重定向时间，是反应服务端响应熟读的重要指标。时间越短，说明服务器响应的速度越快。

#TTFB 多长算长

  TTFB 主要受服务器硬件和网络环境影响，可以查看国内一些优秀的网站，不难发现大多TTFB都在50ms以下，受网络因素波动也不超过100ms。所以，当网站大部分资源的TTFB在50ms以下，少数在50~100ms中时，说明已经达到了比较理想的状态。

静态资源 动态资源

# TTFB 过长的原因

1. 如上诉所说，TTFB受服务器及网速带宽影响，网络是最容易想到的因素之一

2. 我们知道，对于动态网页来说，服务器收到用户打开一个页面的请求时，首先要在指定位置找到该页面，然后分析该页面依赖的资源，从数据库中读取页面首次加载需要的数据，再把这些数据传入到模板中渲染，再返回给用户。由于查询数据和渲染模板需要一些时间，这个过程没有完成之前，浏览器就会处理等待接收服务器响应的状态，如果没处理好逻辑，就直接影响到响应性能。

3. 如果网页中保存了过多的cookie，这些cookie被频繁的在服务器和客户端之间传输，也会造成响应增长问题。
    

# 优化

1. 使用缓存。
     使用缓存可以降低非首次加载的大量请求，减低与服务端交互的频次

2. 网络问题
     频繁有用户出现网络问题，可以使用CDN，把页面同步到离用户比较近的CDN节点上，减少时延

3. Cookie问题
     这就是你编程功底的体现了，是否合理使用cookie，也可以转化部分cookie信息到header上，或者通过其他方式实现

---

 

白屏过长

# 原因

1. 网络时延高
2. 文件较大
3. 脚本过大阻塞渲染
4. 资源重复加载
5. cookie影响

# 解决办法

1. 网络时延高

  如上，使用CDN部署在离用户比较近的服务器节点上

2. 文件较大

  遇到文件较大的情况，有
（1）用户看到的页面不能是你的源码，现在vue项目或react项目基本都使用webpack打包，能减少一定的体积。
（2）可以开启Nginx的gzip功能。其工作原理就是：当用户请求资源时，其在服务器端进行压缩，客户端执行下载，到本地后浏览器在执行解压。用一定的性能换下载时间。但机器的执行速度和下载速度不是一个数量级。这里有一个gzip的配置案例

server {
  listen 80;
   server_name localohst;
   gzip on;  //开启gzip压缩
   gzip_min_length 1k; //最小的长度，避免压缩变大
   gzip_buffers 4 16k;    //设置缓存的单位，压缩的时候要分配的缓冲区，缓冲区以16K为单位，往缓冲区写入内容的时候超过16K的时候，那么就会按照4倍的大小创建新的缓冲区，也就是建立一个64K的存储，这样把压缩的内容倒进去
   gzip_comp_level 6;   //压缩级别1-9，比如level为1的话，压缩的比例比较低，但是效率比较高，比如100K的文件压缩之后还剩40K或者50K，但是处理的时间很短；如果level为9的话，压缩的效果最好，效率会低一点，比如还是100K的文件，压缩的会更小，甚至20K ，这样对cpu消耗会高点，一般设置中间差不多
   gzip_type text/plain application/javascript text/css application/xml;  //定义了压缩的类型，默认压缩图片，text/html的压缩无需指定，否则报错
   location / {
     root /data/apps/abc.com;
     index index.html;
   }
}

  添加了gzip压缩，如果在资源响应头里看到如下信息，则表示添加成功

 

3. 渲染被脚本阻塞

  检查你的脚本文件之间的相关性，检查是否有自执行逻辑等对页面渲染影响的因素，可以给<script>增加defer 或 async来改变脚本执行的时机

4. 资源重复下载

  如果不是必须，避免使用no-store的去请求头，使用缓存