一 前言
文本（js，css等）是H5页面的重要组成部分，其大小影响着页面的加载时间和流量。通常，前端工程师会对发起http请求的资源进行压缩，缩短请求的响应时间。文本的压缩是在web服务器实现的，容易被开发者忽略，从而错过了进一步优化H5页面性能测机会。本文将简要介绍判断H5页面的文本压缩的方式常用压缩方法来协助进一步提升H5页面性能。
二 Accept-Encoding和Content-Encoding
Web服务器对文本的压缩是通过编码实现的，因此，我们需要关注HTTP协议中请求头（Request header）和响应头（Response header）的编码字段。HTTP 1.1头文件的定义表示，Accept-Encoding和Content-Encoding是显示文本资源是接受编码压缩和服务端实现压缩的关键头字段。
它的工作原理是这样：浏览器发送请求时，通过Accept-Encoding带上自己支持的内容编码格式列表；服务端从中挑选一种方式用来对正文进行编码，并通过Content-Encoding响应头指明选定的格式；浏览器拿到响应正文后，依据Content-Encoding进行解压。
Accept-Encoding和Content-Encoding可以不必要成对出现。如果Request header没有Accept-Encoding字段，表示浏览器默认可以接受任何一种编码形式。当然，服务端也可以返回未压缩的正文，但这种情况不允许返回Content-Encoding。如下图：
因此，判断Response header里是否存在Content-Encoding字段就能检测出文本是否在服务端被压缩。
三 Vary: Accept-Encoding
事实上，客户端和服务端之间并非都是直接访问的，可能存在一个或多个中间实体（如缓存服务器），如下图。缓存资源的Response header可能不存在Content-Encoding字段。那么如何判断客户端的响应里是包含了压缩的资源，Response header里的Vary: Accept-Encoding标头解决了这一问题。
Vary:Accept-Encoding告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。浏览器会更根据支持的压缩模式选择合适的缓存资源进行解码。
由于缓存服务器等中间实体存在差异性，判断H5页面文本资源的压缩优先以无缓存连接时Content-Encoding字段的返回为准。
四 常见的压缩方式
HTTP1.1服务端常见的无损压缩数据格式有gzip，zlib，compress等。因此，Content-Encoding的值包含下述几类：
gzip表明实体采用GNU zip编码
compress表明实体采用Unix的文件压缩程序，一般是chrome专用的
deflate表明实体是用zlib的格式压缩的
identity表明没有对实体进行编码。当没有Content-Encoding
header时，就默认为这种情况。
其中，Gzip的是如何压缩的效率是最高的，也是服务端文本压缩最常用的方式。它的工作原理是Gzip压缩是在一个文本文件中找出类似的字符串，并临时替换他们，使整个文件变小。这种形式的压缩对Web来说非常适合，因为HTML和CSS文件通常包含大量的重复的字符串，例如空格，标签。
HTTP压缩对纯文本可以压缩至原内容的40%,从而节省了60%的数据传输。
五 实例
以顺德农商直销银行的运营活动页为例，上图中，sdc9.js文件的请求头有可压缩字段，但响应头却没有Content-Encoding字段，表示该文件并未被服务端压缩。通过yslow（一款文本压缩工具）显示，该脚本通过gzip的方式压缩后大小能从原来的20.2KB降低至6.5KB，压缩了近70%的大小。试想一下，如果页面中的文本请求都能经过压缩优化，页面的加载速度和损耗流量都能被较好的优化。
当然，并不是所有文本都适合压缩。没有显著调整资源大小的压缩是无实际作用的，毕竟压缩的过程还涉及CPU，内存等其它性能问题。
上图中，wtid.js文件的响应头重Content-Encoding表示该脚本通过gzip压缩，压缩后的大小从原来的0.08KB升高至0.1KB。上文提及，gzip的压缩方式是对文本中重复的字符串进行调整，猜测该文件中重复的标签不多，所以压缩无效果。可能还引入服务端一些定义字段，从而体积变大。因此，减少不必要的压缩也是一种优化性能的手段。
六 总结
本文通过简述H5页面文本压缩判断方式，高效的gzip压缩方式及实例分析了压缩对于优化页面性能的重要性。通过调研，已找到实现压缩判断的方式，并将其作为H5 TEST的二期新需求加入开发队列中。关于H5页面性能优化的调研仍在继续，欢迎各位小伙伴提供宝贵意见。
