问题描述
问题起因就是现场需要展示一张91M的超大图片，然后需要保证加载速度。这种场景在摸鱼的时候看了一大堆，不是手到擒来？然后就踩了一堆坑。。。
服务器配置
gzip压缩
想到大静态资源下载，首先肯定是想到开启gzip压缩，但是加上gzip后，结果如下：
资源大小91.9M, 传输大小92M，可给我整不会了。
最后找到了问题原因
gzip 是无损压缩，压缩后可通过某种算法操作得到原本的数据（这个过程就是所谓的解压缩）。 tinypng 背后用的技术是有损压缩，以牺牲图片质量和色彩信息为代价，过程是不可逆的，也就是你无法通过某种算法再得到压缩前的数据。 对一个已经经过有损压缩的文件二次做无损压缩，通常不会有任何效果、甚至体积反而会增大。 这也是为啥你在电脑上把一个 mp4 视频放到压缩包里、压缩包并不会比 mp4 小的缘故。
好吧，看起来图片资源还是别走gzip压缩了。
cache-control缓存
像这种固定静态资源，直接用cache-control的max-age给它拉满。但是我在加上缓存后，用浏览器直接访问图片资源https://xx//xx.png,得到的接入如下图，还是没有缓存，这又是啥情况啊？
那这是为什么呢？
首先查看chrome的缓存说明，chrome的缓存上限是根据硬盘容量以及内存计算了，不会是90M存不下的问题
之后在request header中发现了问题：
之前还真没在意过request header中的cache-control字段。经过资料查阅可知：请求头中的cache-control也可以设置为max-age=0或者no-cache字段。会导致该资源不使用缓存。
继续查看相关资源可知：
- 打开控制台【disable cache】
- 使用post方法请求
- 浏览器刷新时的主要资源，或者使用清空缓存刷新
这三种情况，就算设置了cache-control字段，也不会走缓存，浏览器在请求头中会携带cache-control: max-age=0 / no-cache字段
我直接刷新图片进行访问，就是踩坑了第三种情况，后续将该图片嵌入到页面中，可正常走缓存访问。
总结
最后还是用CDN + 缓存的方式实现了，平时看起来很简单的东西，没想到也要踩这么多坑，还得继续努力学习呀。
