共计 1168 个字符，预计需要花费 3 分钟才能阅读完成。
问题：
公司我的项目在开发一项 3D 全景性能时，须要用到 threejs 这个框架进行 3D 渲染，个别 3D 文件的大小都在 40M 以上，这次咱们渲染的文件在 44M 左右，下载所破费的工夫是 80s。
以前的解决办法：
急躁劝告产品经理，这是失常景象，这么大文件必定要这么多秒，别急啊，又不是加载不进去，你看，这不是加载进去了吗？
当初的解决办法：
文件这么大，是否能够压缩后再传输？这里就引出 nginx gzip 的概念，gzip 分为两种压缩模式：
1、实时压缩，通过耗费 cpu 来实时压缩文件并返回给浏览器，该形式下响应头中 Etag 属性会有’W\’的字样，开启形式在 nginx.conf 中增加 gzip on 等属性即可。
2、动态文件压缩，这种形式须要提前将文件压缩成.gz 文件，nginx 在加载文件时会优先应用.gz 文件，而不是实时压缩中的自行压缩形式，开启形式在 nginx.conf 中增加 gzip_static on 等属性，这里 nginx 中不自带 gzip_static 模块，须要编译并增加，此外须要在 vue 我的项目打包过程中配置 gzip ->bingo 胜利
具体的具体参数设置详见 vue 我的项目开启 gzip 压缩和部署 vue 我的项目开启 Gzip 压缩和性能优化 – guopengju – 博客园
成果：44Msize 的 ifc 文件被压缩成 8M，加载工夫从 80 秒，降为 12 秒
此外，js、css、json 等动态资源文件都失去了加载晋升
Respect！
未来的解决办法：
请大家把更好的办法留在评论区！！！
衍生 proxy_cache 缓存
出发点：在做完下面 gzip 压缩后，大文件的传输问题根本得以解决，于是想进一步提高加载速度，动态资源在首次加载后，会产生 memory cache 和 disk cache 两种缓存，然而这类缓存都属于客户端缓存，换句话说，当另外一个用户拜访网站时，他也是须要从新再加载一遍，针对此类问题，思考🤔🤔是否能够有服务端缓存，于是有了 proxy_cache 的想法：
用法很简略，各类博客都有说到：https://blog.csdn.net/qq_3172…
本人感觉重要的点：
1、proxy_cache 的设置须要在 proxy_pass 的前提下，要不然有效
2、add_header Nginx-Cache $upstream_cache_status; 原来响应头中缓存是否中的属性是能够自定义。
3、这种缓存我分为两种状况：
（1）对后端响应的数据做缓存，能够将申请到的后果缓存下来，效果显著，然而弊病是针对实时性要求高的接口做缓存，在事实中不可取，还是得就地取材吧。
（2）动态资源做缓存（不能间接增加 proxy_cache, 须要做一层代理转发）：教程 https://www.jb51.net/article/…
成果不显著，然而通过剖析他人的 CDN 资源，都有做缓存，是否真的有用后续再察看。
