TTFB
# 什么是 TTFB
TTFB，Time to First Byte 的缩写，又叫首字节响应时间。指的是浏览器开始接受服务器响应数据的时间，包含 后台处理时间 + 重定向时间，是反应服务端响应熟读的重要指标。时间越短，说明服务器响应的速度越快。
#TTFB 多长算长
TTFB 主要受服务器硬件和网络环境影响，可以查看国内一些优秀的网站，不难发现大多TTFB都在50ms以下，受网络因素波动也不超过100ms。所以，当网站大部分资源的TTFB在50ms以下，少数在50~100ms中时，说明已经达到了比较理想的状态。
# TTFB 过长的原因
如上诉所说，TTFB受服务器及网速带宽影响，网络是最容易想到的因素之一
我们知道，对于动态网页来说，服务器收到用户打开一个页面的请求时，首先要在指定位置找到该页面，然后分析该页面依赖的资源，从数据库中读取页面首次加载需要的数据，再把这些数据传入到模板中渲染，再返回给用户。由于查询数据和渲染模板需要一些时间，这个过程没有完成之前，浏览器就会处理等待接收服务器响应的状态，如果没处理好逻辑，就直接影响到响应性能。
如果网页中保存了过多的cookie，这些cookie被频繁的在服务器和客户端之间传输，也会造成响应增长问题。
# 优化
使用缓存。
使用缓存可以降低非首次加载的大量请求，减低与服务端交互的频次网络问题
频繁有用户出现网络问题，可以使用CDN，把页面同步到离用户比较近的CDN节点上，减少时延Cookie问题
这就是你编程功底的体现了，是否合理使用cookie，也可以转化部分cookie信息到header上，或者通过其他方式实现
白屏过长
# 原因
- 网络时延高
- 文件较大
- 脚本过大阻塞渲染
- 资源重复加载
- 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的去请求头，使用缓存
