前端性能优化之网络篇

前端性能优化之网络篇

这是学习后的总结和记录

用户输入url到页面呈现经历了哪些过程?

• DNS域名解析
• TCP 连接
• HTTP请求
• HTTP响应
• 渲染

但从网络层面分析, 影响性能的点有哪几部分呢?
DNS 域名解析时间太长? 能够经过浏览器DNS缓存和DNS预加载解决, TCP每次都要创建三次握手,属实没有必要怎么办呢?能够经过TCP长连接,预连接等。HTTP层面的优化能够分为 减小HTTP请求说起和 减小HTTP请求次数等方面优化

网络层面优化分类

# 请求过程的优化
        - 构建工具Webpack调优
            - 生产环境: 主要提高构建速度
            - 开发环境: 主要优化打包体积
        - Gzip压缩原理
        - 前端图片的选型
    
    # 减小HTTP请求次数
        - 本地存储技术
            - 浏览器缓存
            - 离线存储技术
        - CDN缓存和回源机制

Webpack构建工具调优

Webpack优化能够从开发和生产做为切入点,在开发环境下注重构建速度的提高,不然你修改一行代码command + s保存,从新编译等待一分钟,阁谁谁都受不了。生产环境也就是直接面向用户的,主要注重打包的说起。你一个js包20多兆,能给用户卡死还费用户的流量。

• 缩小构建范围
• 解析loader单进程转换为多进程,使用 happypack插件
• 提早打包第三方库,经过 webpack模块的 DllPlugin和DllReferencePlugin 建立动态连接库
• 中间件缓存步骤,经过配置 HardsourceWebpackPlugin插件
• 分包, Webpack4.x提供 optimization.splitChunks提取公用代码
• Tree-Shaking, 删除沉淤代码
• 按需加载

以上的调优方案主要是构建工具的压缩与合并

Gzip压缩原理

开始 Gzip压缩,只须要在请求头添加一句 accept-encoding:gzip。

HTTP压缩是一种内置到网页服务器和网页客户端中以改进传输速度和带宽利用率的方式, 在使用HTTP压缩的状况下  
HTTP数据在服务器发送前就已压缩,兼容的浏览器将在下载所需的格式前宣告支持何种方法给服务器。  
不支持压缩方法的浏览器将下载未经压缩的数据。最多见的压缩方案包括 Gzip 和 Deflate。

HTTP压缩就以缩小说起为目的,对HTTP内容进行从新编码的过程。
Gzip压缩的原理是在一个文本文件中找出一些重复出现的字符串,进而替换他们,从而使文件体积变小。

图片选型

不一样的业务场景下使用合适的图片类型，从而达到在压缩图片体积实现优化的同时尽可能保证质量

时下应用较为普遍的 Web 图片格式有JPEG/JPG、PNG、SVG、Webp以及Base6四、精灵图等。

JPEG/JPG

特色: 有损压缩, 体积小, 加载快,不支持透明
应用场景: 一些网站的大图,如背景图, 轮播图和banner图等
缺点: 不支持透明,如需使用透明图则用 PNG

PNG

PNG分为 PNG-8和PNG-24。8位的PNG支持 256种颜色, 而24位的PNG支持1600万种颜色。
特色: 无损压缩, 质量高,体积大,支持透明
应用场景: 适用与更强的色彩表现力图片, 如 网站logo,网站上的一些小图标等。

SVG

特色: 文本文件, 体积小, 不失真,兼容性好
SVG和上面的 JPG和PNG比较,具备更小的体积,可压缩性更强。
SVG使用:

• 将SVG写入HTML
• 将SVG写入独立文件后引入HTML (使用居多)

Base64和精灵图

图像精灵（sprite，意为精灵），被运用于众多使用大量小图标的网页应用之上。它可取图像的一部分来使用，使得使用一个图像文件替代多个小文件成为可能。相较于一个小图标一个图像文件，单独一张图片所需的 HTTP 请求更少，对内存和带宽更加友好。

Base64对出现也是为了减小HTTP的请求数量, 从而提高网页性能。Base64是做为精灵图的补充而存在的。

特色: 文本文件、依赖编码、小图标解决方案

Base64是一种用于传输8Bit字节码的编码方式, 对小图标进行Base64进行编码,咱们能够直接将编码的结果插入到HTML文件和Css中,从而减小HTTP请求数

Base64编码工具, 能够借助于构建工具 Webpack,使用 url-loader和file-loader进行编码

module.exports = {
        // ... 
        module: {
            rules: [
                {
                    test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
                    loader: 'url-loader',
                    options: {
                      limit: 10000  // 小于 10000
                    }
                }
            ]
        }
    }

以上代码配置小于10000字节的图片都将为Base64编码。

Webp

WebP是Google开发的一种无损压缩图像格式。 它支持有损压缩和无损压缩,能够说它集成了 JPG、PNG等优势。 惟一缺点就是兼容性很差。

浏览器缓存技术

缓存能够减小网络 IO 消耗，提升访问速度。浏览器缓存是一种操做简单、效果显著的前端性能优化手段。

经过网络获取内容既速度缓慢又开销巨大。较大的响应须要在客户端与服务器之间进行屡次往返通讯，这会延迟浏览器得到和处理内容的时间，还会增长访问者的流量费用。所以，缓存并重复利用以前获取的资源的能力成为性能优化的一个关键方面。

按照获取资源时请求的优先级排序:

• Memory Cache(内存缓存)
• Service Worker Cache(服务工做缓存)
• HTTP Cache(HTTP缓存)
• Push Cache(推高速缓存)

HTTP Cache 浏览器缓存

HTTP缓存能够分为 强缓存 和 协商缓存

强缓存

强缓存是利用 HTTP头部的 Expires和 Cache-Control两个字段来控制的。当请求再次发送时,浏览器会根据其中的 Expires和Cache-Control来判断是否命中强缓存,若是命中则直接返回缓存中的资源,不会和服务器发生通信。

强缓存的标记: form dist cache

Expires和Cache-Control有什么关系呢?

Cache-Control是 Expires的替代品。以前都是使用 Expires,在响应头中返回 Expires强缓存字段值。类型以下:

expires: Wed, 11 Sep 2019 16:12:18 GMT
Expires是一个时间戳,当咱们再次向服务器发送请求,浏览器会先对比 expires时间戳和客户端时间，若是小于客户端时间,说明缓存没有过时,直接去缓存中取资源。

可是 Expires有一个缺陷, 对比依赖客户端时间。若是服务器和客户端时间不一致,咱们手动修改客户端时间,那么 expires是没法达到咱们的预期。

HTTP1.1 新增了 Cache-Control来替代 Expires。它和Expires的做用相同, Expires能作的事情它均可以作, Expires不能作的事情它还能够作。

Cache-Control字段以下
cache-control: max-age=31536000

Cache-Control是经过 max-age来控制缓存资源的有效期, 它并非时间戳,而是一个时间长度。表示该资源在多少秒内是有效的。

Cache-Control比Expires更加准确, 它的优先级更高。当 Cache-Contorl和Expires同时存在时,会优先使用 Cache-Control。

no-cache 绕开了浏览器: 当咱们为资源设置了 no-cache时,每一次发送的请求都不会去询问浏览器的缓存状况, 而是直接去服务端确认该资源是否过时。

no-store表示不使用任何缓存,也不会去服务端确认资源是否过时,只容许你向服务端发送请求,并下载完整的响应

协商缓存

协商缓存依赖于客户端与服务端的通信。
客户端会向服务端询问缓存的相关信息,进而判断是从新发送请求,下载完整的资源。仍是从本地获取缓存的资源。

若是服务端资源不曾改动(last-Modified),资源会被重定向到浏览器缓存,这种状况下网络请求的状态码为 304

协商缓存的字段: Last-Modified 和 Etag

Last-Modified是一个时间戳, 第一次请求时会随着响应头返回。
Last-Modified: Fri, 27 Oct 2017 06:35:57 GMT

当咱们再次请求时, 请求头会携带一个 If-Modified-Since资源,其对应的时间戳就是 Last-Modified返回的时间戳。
If-Modified-Since: Fri, 27 Oct 2017 06:35:57 GMT
当服务端拿到请求中的 If-Modified-Since, 会对比该时间戳和资源在服务器上最后修改的时间是否一只,从而判断资源是否改动。若是发生了变化就返回一个完整的响应内容, 而且更新响应头(respones headers)中的 Last-Modified为最新值。 不然就返回304响应, 且响应头不会携带 Last-Modified字段。

Last-Modified字段存在一些缺点, 有时服务器没法感知文件是否发生变化。为了解决这以问题, Etag来弥补 Last-Modified的不足。

Etag是服务器为每一个资源生成的惟一的 标示字符串, 生成的方式是根据文件的内容进行编码的,当文件内容改变时,Etag的值也会发生变化,反之依然。因此Etag能够精确的感知文件的变更。

Etag和Last-Modified同样,首次请求时,响应头里获取一个最初的标示字符串。以下:
ETag: W/"2a3b-1602480f459"

当下一次的请求时, 请求头中会携带相同的、名为 if-None-Match的字符串和服务器的标示对比。更精确的判断文件是否改动。

If-None-Match: W/"2a3b-1602480f459"

Etag在感知文件的变更比Last-Modified更精确,因此Etag的优先级更高。Etag和Last-Modified同时存在,以 Etag为准。

MemoryCache(内存缓存)

MemoryCache，是指存在内存中的缓存。从优先级上来讲，它是浏览器最早尝试去命中的一种缓存。从效率上来讲，它是响应速度最快的一种缓存。

内存缓存是快的,也是短命的。它和渲染进程生死相依。当进程结束后,内存缓存的数据也将不复存在。
内存缓存资源存放的位置具备必定的随机性。

Service Worker Cache(服务工做缓存)

Service Worker 是一种独立于主线程以外的 Javascript 线程。它脱离于浏览器窗体，所以没法直接访问 DOM。这样独立的个性使得 Service Worker 的“我的行为”没法干扰页面的性能，这个“幕后工做者”能够帮咱们实现离线缓存、消息推送和网络代理等功能。咱们借助 Service worker 实现的离线缓存就称为 Service Worker Cache。

Service Worker 的生命周期包括 install、active、working 三个阶段。一旦 Service Worker 被 install，它将始终存在，只会在 active 与 working 之间切换，除非咱们主动终止它。这是它能够用来实现离线存储的重要先决条件。

Push Cache

Push Cache 是指 HTTP2 在 server push 阶段存在的缓存。这块的知识比较新，应用也还处于萌芽阶段。

存储技术

HTTP Cookie（也叫Web Cookie或浏览器Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。一般，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登陆状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

因为Cookie的大小有限,根据不一样的浏览器大小各不相同。最大能存储 5kb。通常多应用于:

• 会话状态管理（如用户登陆状态、购物车、游戏分数或其它须要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

若是让Cookie存储一些大量的数据显然是不合理的,由于Cookie每次都会携带在请求头部发送给服务器,因此也会形成HTTP请求头过大。

HTML5 Web Storage

Web Storage是HTML5为了解决客户端存储而诞生的。容许你在一个特定的域中设置、检索和删除数据和存储类型。

Web Storage分为:

sessionStorage: 给每个给定的源,维持一个独立的存储区域,该存储区域在页面回话期间可用,也就是当浏览器关闭了,这个保存的数据也随之销毁。

const data = [1,2,3]
sessionStorage.setItem('arr', data) // 存储 arr为键名, data是要存储的数据
let getData = sessionStorage.getItem('arr') // 根据键名去对应的数据
console.log(typeof getData)  // string  // 取出的是字符串类型

当关闭浏览器再从新开启这个页面, 存储的数据会不复存在,由于它是 会话存储。

localStorage: 和 sessionStorage同样, 只不过它是持久化存储,除非你手动删除存储的数据,不然关闭浏览器后数据仍然存在。

const data = [1,2,3]
localStorage.setItem('arr', data) // 存储 arr为键名, data是要存储的数据
let getData = localStorage.getItem('arr') // 根据键名去对应的数据
console.log(typeof getData)  // string  // 取出的是字符串类型
localStorage.removeItem('arr') // 根据指定的键名清楚缓存

当你存储完数据以后, 关闭浏览器再打开数据仍是存在的。由于它是 持久存储

localStorage和sessionStorage存储的数据都不会被请求头所携带, 而Cookie是每次都会被请求头携带

CDN的缓存和回源机制

CDN(内容分发网络) 是将源站内容分发至最接近用户的节点, 使用户可就近取得所需的内容,提升用户访问的响应的速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题。

CND是如何工做的:

假设个人根服务器在杭州, 同时北京、上海、成都、山东都有个人机房。 此时身在山东的你向我请求资源,在网络带宽小、用户访问量大的状况下,杭州的根服务器不能给用户很是快的响应速度。那么我能够把这些资源复制一份放到距离用户最近的机房呀。当你请求资源时,山东这台服务器低头一看,这个资源我存了,何况离得这么近响应速度那是杠杠的。若是山东这台服务器没有存你要的资源,它就会向杭州的根服务器要资源。此刻, 山东的这台服务器就扮演着 CND的角色。

CDN的两个核心点就是 缓存和回源。缓存就至关于把根服务器的资源复制一份放到山东的机房中。而回源就是 山东机房发现没有你要的资源,它就向根服务器或者上级服务器去要资源。

根服务器也就是业务服务器,须要对业务进行大量的计算。而CDN服务器能够理解为一个 仓库,只负责存放和转运一些东西,特别是静态的资源。如 js、css、image等。

---

总结

前端性能优化网络篇咱们分别从HTTP请求优化和 减小HTTP请求次数入手。实践了 webpack调优、Gzip压缩、前端图片选型、浏览器缓存、本地存储、CDN的缓存等几方面入手。