移动端index.html被缓存问题

在移动端,我们为了解决带宽限制或者网络缓慢等问题,常常会使用http协议缓存静态文件(http缓存简介),从而减少网络请求,加快首屏加载时间。缓存虽然给我们带来了性能上的优化,但是也会带来一些问题,如最常见的问题就是:系统升级后文件未更新,需要手动进行刷新。要解决这个问题,要分以下几种情况:

1、传统的多页面应用

我们一般使用时间戳或者版本号等标记html、css、js等文件,例如:原有的html文件为:index.html?v=1598443151546,系统升级后以时间戳为标志的html文件为:index.html?v=1599463092282,这样用户访问新的页面时,浏览器会返回新的文件。可以使用构建工具gulp、grunt等的对应的插件对静态文件进行自动化处理。

2、基于webpack单入口的单/多页面应用

现在流行的react、vue等框架都使用了虚拟DOM(virtual DOM)技术,html文件主要的作用是提供一个可以绑定的dom容器节点,所有的业务逻辑都在对应的编译后的js文件里面。所以单/多页面应用的html文件是利用html-webpack-plugin创建出来的,然后引入其他的js、css等文件。
webpack编译后的文件缓存策略和其hash有关,webpack有各种hash值,包括每次项目构建hash,不同入口的chunkhash、文件的内容contenthash,这么多hash,它们有什么区别呢?

  1. hash
    hash是跟整个webpack构建项目相关的,每次项目构建hash对应的值都是不同的,即使项目文件没有做“任何修改”。其实运行webpack打包都是有修改的,因为每次webpack打包编译都会注入webpack的运行时代码,导致整个项目有变化,所以每次hash值都会变化的。
  2. chunkhash
    chunkhash根据不同的入口文件(Entry)进行依赖文件解析、构建对应的chunk,生成对应的哈希值。在生产环境里把一些公共库和程序入口文件区分开,单独打包构建,接着我们采用chunkhash的方式生成哈希值,那么只要我们不改动公共库的代码,就可以保证其哈希值不会受影响。并且webpack4中支持了异步import功能,固chunkhash也作用于此,如下:
    image

    我们将各个模块的hash值 (除主干文件) 改为chunkhash,然后重新build一下,可得下图:
    image

    我们可以清晰地看见每个chunk模块的hash是不一样的了。
    但是这样又有一个问题,因为我们是将样式作为模块import到JavaScript文件中的,所以它们的chunkhash是一致的,如test1.js和test1.css:
    image

    这样就会有个问题,只要对应css或则js改变,与其关联的文件hash值也会改变,但其内容并没有改变呢,所以没有达到缓存意义。固contenthash的用途随之而来。
  3. contenthash
    contenthash是针对文件内容级别的,只有你自己模块的内容变了,那么hash值才改变,所以我们可以通过contenthash解决上诉问题。如下:
    image

2.1 js、css、图片等静态文件

由于webpack的特性,很容易配置好相关参数,使每次修改过js、css等文件后,引用的文件名称都会改变(例如上面的利用chunkhash设置文件名),浏览器请求对应的文件时都会重新获取,而不使用缓存。

2.2 html静态文件

因为html文件是通过html-webpack-plugin生成的,默认为index.html,一般情况下每次编译生成的文件名不会改变。所以有可能会出现,系统更新后,用户访问的index.html文件是缓存中保存的上次的文件,需要用户手动去刷新。
解决办法:
1、一般设置了静态文件的缓存,都会设置文件的协商缓存。所以每次请求下载文件时,都会返回一个http响应Last-Modified:文件修改时间1。用户访问文件会在http请求头带上If-Modify-Since:文件修改时间1,当后台发现文件在修改时间1之后都没有修改,会返回304,告诉客户端从缓存里面获取文件;当系统更新后,文件修改时间变为修改时间2,此时用户访问文件会在http请求头带上If-Modify-Since:文件修改时间1,后台会返回200,并且返回最新的文件,所以设置了协议缓存后,返回的html都是最新的文件。
2、按照协商缓存原则,设置了协议缓存后,不会出现修改后文件获取不到问题,但是由于移动端的客户端比较繁杂,内核不同,封装的方法千奇百怪,所有也可能会出现设置协商缓存后,更新文件后,还是获取缓存的文件问题。这时候可以尝试用强缓存去解决这个问题,在nginx配置,访问html文件时,强制不缓存:

  • 设置所有的html文件强制不缓存:
 location ~ .*.(htm|html)?$ {
   add_header Cache-Control "no-store, no-cache";
}

  • 设置某个目录下的html文件强制不缓存:
 location /user {       
        if ($request_filename ~* .*\.(?:htm|html)$)
        {
            add_header Cache-Control "no-store, no-cache";
            add_header Pragma no-cache;
            add_header Expires 0;
        }
    }

参考目录:

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,332评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,508评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,812评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,607评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,728评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,919评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,071评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,802评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,256评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,576评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,712评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,389评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,032评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,798评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,026评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,473评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,606评论 2 350