はじめに
Webサイトの運用において、サイト内のリソース参照先を変更する場面はよくあります。
今回は、サイトに埋め込まれているアクセス解析スクリプトのドメインを変更したのですが、
「ユーザのhtmlブラウザキャッシュって、残りすぎじゃない?」
とおもったので、これをメモ書きとして記録しておきます。
予想よりも長期間旧ドメインへのアクセスが継続したので、
HTMLキャッシュの影響について残しておきます。
作業内容
ある中規模Webサイトで使用していた、アクセス解析スクリプトのドメインを変更しました。
-
変更内容: スクリプト参照先のドメインを
a.example.com
からb.example.com
へ変更 -
実施内容:
- ソース内のアクセス解析スクリプトURLを新ドメインに一斉に変更
- 実施後、CDN (Cloudfront) のキャッシュを完全クリア
サーバー側での変更とCDNキャッシュのクリアを完了したため、
2~3日で旧ドメインへのアクセスは自然に消滅すると考えていました。
結論からいうと、3週間たっても微妙にアクセスがあります。
これ、理由すぐわかる人はすごいと思います。
私全然わかんなかったので、記録として残した次第です。
結果
旧ドメインへのアクセス推移
元々デイリーで、4桁前半ぐらいのアクセスのサイトです
変更前の通常アクセス数を100%とした場合の旧ドメインへのアクセス率の推移がこちら:
日付 | ユニークビジター | 対移行前比率 | 検索エンジン経由 | 直接入力 |
---|---|---|---|---|
初日 | 100 | 5.00% | - | - |
2日目 | 19 | 0.95% | 68.4% | 52.6% |
3日目 | 13 | 0.65% | 53.8% | 69.2% |
4日目 | 8 | 0.40% | 62.5% | 37.5% |
5日目 | 6 | 0.30% | 100% | - |
6日目 | 9 | 0.45% | 88.9% | 33.3% |
7日目 | 3 | 0.15% | 33.3% | 166.7% |
8日目 | 2 | 0.10% | 50% | 150% |
9日目 | 0 | - | - | - |
10日目 | 1 | 0.05% | 100% | - |
11日目 | 1 | 0.05% | 100% | - |
12日目 | 1 | 0.05% | 200% | - |
13日目 | 3 | 0.15% | 66.7% | 66.7% |
14日目 | 2 | 0.10% | 100% | 50% |
15日目 | 0 | - | - | - |
16日目 | 0 | - | - | - |
17日目 | 1 | 0.05% | 100% | - |
18日目 | 0 | - | - | - |
19日目 | 1 | 0.05% | 100% | - |
20日目 | 0 | - | - | - |
21日目 | 0 | - | - | - |
22日目 | 0 | - | - | - |
23日目 | 1 | 0.05% | - | 100% |
なお、初日は切り替え作業後(朝7時頃)のみの数字です
分析
HTMLキャッシュの影響
今回の観測結果から最も重要な発見は、HTMLのキャッシュが予想以上に長く保持されるという事実です。
<!-- 変更前のHTMLソース -->
<script src="https://a.example.com/analytics.js"></script>
<!-- 変更後のHTMLソース -->
<script src="https://b.example.com/analytics.js"></script>
重要なポイントは、サーバー側でHTMLを更新し、CDNキャッシュをクリアしても、ユーザー側のブラウザキャッシュには影響がないということです。ユーザーがキャッシュされた古いHTMLを読み込むと、そこには古いドメインへの参照が残っているため、旧ドメインへのアクセスが発生します。
リピートユーザーの影響
データからは、旧ドメインへのアクセスが主にリピートユーザーから発生していることが見えます:
- 移行後はリピートビジットが急増
- 変更翌日以降もリピートビジット数がユニークビジター数を上回る特殊な状況
これは、リピートユーザーのブラウザに保存された古いHTMLキャッシュが、新しいHTMLをダウンロードする前に自動的に旧ドメインのスクリプトを呼び出していると考えられます。
このような挙動に関する考察
正直、こんなちょろちょろとアクセスが残ってる理由は本気で理解できなかったのですが
アクセス解析しっかり洗ったところ、以下のような特徴がありました:
-
デバイス構成の特徴:
- モバイルデバイスからのアクセスが大半を占める(今の時代そりゃそうだなんですが)
- デスクトップアクセスは Mac のみ(Windows からのアクセスは皆無)
-
ユーザー行動パターンの特定:
- アクセスログ分析から、多くのユーザーが特定ページを定期的に再訪問していることが判明
ここからは推測ですが、これは
「ブラウザでタブを開いたままにして、メモ代わりにみている人が結構いる?」
のかと。
記事の内容的にもそういう記事だったんですよね。
キャッシュ長期残存の主な要因
今回の調査データから見えてきた要因はシンプルです:
-
開きっぱなしタブの存在
- 多くのユーザーは頻繁に見返すページをタブで開きっぱなしにしている
- 特にモバイルデバイスでは、バックグラウンドタブとして何週間も残存(繰り返し見てくれるのはありがたいことですが)
-
モバイルブラウザの挙動
- iOSのSafariとかバックグラウンドでタブがのこったまま
- これ再読み込みとかしてくれなさそう…
-
定期的な再訪問パターン
- タブを閉じずに定期的にチェックするユーザーはまあまあいる
- こういったユーザーがキャッシュを再利用し続ける可能性
推測ですが、これらの要因が組み合わさって
「3週間後もアクセスが続く」という現象を引き起こしていると考えられます。
まとめ
ということで、わすれがちなのですが、「開きっぱなしタブ」のユーザーは結構残りそうです。
今の時代、ユーザーは頻繁にチェックしたいページをタブで開きっぱなしにして何日も放置しています。
特にモバイルでは、バックグラウンドタブとして何週間も生き残るケースがあります。
今回のケースはアクセス解析スクリプトの変更だけなので、もうこのまま放置します。
ただこれ、なんかケースによってははまることもありそうだな、と思ったので…。
モバイルで開きっぱになったタブの、htmlキャッシュが生き残ってしまって悪さする。
なんかありそうですよね。あんま考えたくないですけど。
実運用ネタって結構スルーされがちなので残してみました。
結論としては
サーバー側でHTMLを更新してCDNキャッシュをクリアしても、HTMLキャッシュが22日後も残り続けるケースがありmした。
推測ですが、「タブを開きっぱなしにして定期的にチェックする」というユーザー行動がこの現象の主な原因と考えられます。
実務上「こういった面倒なケースも想定してキャッシュ戦略をきちんと考えないとハマることがあるかも」というところでしょうか。
モバイルユーザーが多い昨今、このあたりも頭の片隅にいれておいたほうがよさそうです。