⚠️ Nginx Http缓存的必要性!启发式缓存有什么弊端?
- 简介
- 启发式缓存引发的问题
- nginx缓存配置
简介
我们在使用React或者Vue开发项目中会使用hash、chunkhash、contenthash来给静态资源文件进行命名。这带来的好处便是当我们部署完项目后,用户刷新页面后会重新获取html资源,html资源中的js或者css文件由于文件名发生变化会重新发起请求来获取新的资源。当然我们有时候为了项目优化,我们还会对一些页面模块进行分包进行懒加载,有时候还会把一些模块通过webpack魔法注释chunkName
拆到一个包中。
http
缓存种类:我目前总结了三类,分别为强缓存、协商缓存、启发式缓存
这篇文章介绍了强缓存和协商缓存 http缓存
那么如果响应头中没有配置强缓存和协商缓存,浏览器会触发启发式缓存。
启发式缓存的缓存有效期计算公式为 (date - last-modified ) * 10%。取响应头中 date 与 last-modified 值之差的百分之十作为缓存时间。启发式缓存比较容易忽略,不了解启发式缓存可能会因为这种默认的缓存方式而掉入坑里,但一旦你了解了浏览器启发式缓存的机制,很多问题都可以得到解决。
启发式缓存引发的问题
通常项目上线后会部署到Nginx服务器。假如我们并没有配置任何响应头来缓存静态资源。那么是会带来一些问题的。
前面已经说了在没有配置任何http缓存的情况,浏览器会触发启发式缓存的。那么好,比如我们的项目经过第一次打包生成了几个文件main-123abc.js、vender-345abc.js、main-789abc.css、chunk1-123abc.js、chunk1-123abc.css、chunk2-456abc.js、chunk2-456abc.css
。当用户访问页面后,会触发启发式缓存的,而用户并没有关闭页面。 这里的文件名hash我只是举例。
第二天我们在项目里更新了某个chunk内的代码,比如chunk1的代码,那么经过构建工具打包又会重新生成一些文件。他们是main-123abc.js、vender-345abc.js、main-789abc.css、chunk1-321abc.js、chunk1-321abc.css、chunk2-456abc.js、chunk2-456abc.css
。文件名从 chunk1-123abc
变成了chunk1-321abc
,文件hash会变化,这一切都很正常。就这样我们进行了第二次部署。
但此时问题来了(这个问题是建立在二次部署后,老页面并没有刷新),用户访问我们第一次部署的页面并且有了启发式缓存。但是这个缓存是有时效性的,他是会过期的,过期后浏览器会再次请求过期的那个文件。假如用户访问了chun1的页面,但是我们已经进行了第二次部署,你觉得会找到chunk1-123abc.js和chunk1-123abc.css
吗?肯定找不到的,那么用户就会看到白屏或者样式丢失。 当然用户刷新页面后就会正常。
此时http强缓存和协商缓存的就能解决这个问题。因为我们的静态js、css文件经过了强缓存,用户即便是不关闭页面,访问的依然是缓存。就不会出现白屏或者样式丢失的问题。
nginx缓存配置
map $request_filename $cache_control {
default "";
~*\.(htm|html)$ "no-store";
~*.* "max-age=31536000"; # 1年的秒数
}
server {
listen 80;
server_name localhost;
location / {
alias /opt/dist/;
try_files $uri /index.html;
add_header Cache-Control $cache_control;
}
}