- 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 的去请求头, 使用缓存
来源: http://www.jianshu.com/p/4e384a10378a