better-compression

资讯栏目上线了，用户一致好评，用户量稳定的在增长。伴随着用户的增长，费用的支出也在上升，对于一直坚持“以最少的钱做最多的事”的老板，不能接受这种等比例的支出增加，要求开发找出方案减少支出。虽然对于这种观点不能完全认同，但很多情况的确可以通过技术的手段来节约支出。

由于是资讯类的站点，系统的逻辑比较简单一些，对于机器的使用没有过多的增加，倒是在带宽上增长较大。那么主要的解决方案就是在如何解决带宽的使用了。

当前系统状况分析

• 静态文件（js css）的带宽占比为10%左右，对于缓存的使用已优化，缓存优化暂无提高方式

• 资讯中使用到的图片占了带宽的30%左右，由于都是内容相关性图片，客户端的缓存意义不大

• 资讯内容是占用带宽的大部分，但由于资讯的实时性，客户端的缓存意义也不大，客户基本都只浏览一次

优化思路

• 静态文件(js css)使用gzip压缩使用更高的压缩率或者brotli压缩

• 资讯图片大部分都是管理员上传，上传时未做压缩处理，增加图片的压缩以及使用更好的webp格式

• 资讯内容与静态文件的处理采用同样的方式，提高压缩率

以前一直直接使用nginx来做数据压缩，因为每次都压缩，因此为了更高的性能，gzip level使用的是1。如果使用更高的压缩比，那么压缩时间就更长了，为了避免因为压缩而导致系统整理的性能下降，我们参考varnish的实现，实现了HTTP缓存的服务。对于可缓存的数据（静态文件、接口等），自动使用gzip与brotli生成两份压缩数据，根据浏览器的Accept-Encoding返回相应的数据。如果浏览器不支持压缩，则解压再返回（现在的浏览器都支持压缩处理，在实际中我们发现大部分都是一些没写好的爬虫等，因此我们关闭了此功能）

在客户端中有统一的图片加载处理函数，对于支持webp的客户端，在加载图片时，指定使用webp格式图片。服务器收到图片的请求，读取原图片，做转换压缩处理。图片都是非动态数据，可以在服务器端做缓存，因此图片转换的时间对于整体的性能影响不大。

对于资讯内容（接口数据），根据接口响应的Cache-Control设置，对于不可缓存或较短缓存时间数据（小于5秒），则使用较低的gzip压缩率，性能较高。对于缓存时间较长的数据，使用较高的gzip压缩率（因为资讯数据变化的较快，而且数量多，因此没有生成gzip与brotli两份数据，避免占用较多的内存）

小结

系统经过优化之后，带宽减少了30%左右，主要是图片的优化空间较大，最大的收获反而是HTTP缓存程序的使用，更多的项目直接接入了，公司的带宽减少了，老板开心了，但是工资没有涨~！