问题：
公司我的项目在开发一项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资源，都有做缓存，是否真的有用后续再察看。