Browser Cache - High Performance Web 2015

# Cache

関連エントリを訳しながら読んだ、だいぶ雑なメモ。

## 復習

- cache-control
 - no-cache: キャッシュに変更が無いか ETag でサーバに確認する
 - no-stroe: 一切キャッシュしない
 - public: キャッシュが可能である(普通つけない)
 - private: セッションごとなどで違うので、中間キャッシュできない(クライアントは良い)
 - max-age: キャッシュを再利用できる最大時間

- If-Modified-Since
 - If-Non-Match があればそっち優先
 - Last-Modefied を入れる

- Etag
 - リソースのタグ
 - hash 値
 - 更新されたかがわかる

- If-Non-Match
 - Etag を入れて送る
 - validation して 403

- Expires
 - Cache-Control 非対応クライアント向けの古いヘッダ
 - Cache-Control があったらこっちは無視

- Pragma
 - HTTP/1.0 互換の為にある
 - no-cache 以外指定しない


## Yahoo

[performance research part2: Browser cache Usage - Exporsed](http://yuiblog.com/blog/2007/01/04/performance-research-part-2/)


2007 年の調査
browser は80% をfetch につかっているので、そこを減らすのには効果がある。

full cache
empty cache

empty な理由
- first visit
- キャッシュが消えた
- ブラウザが設定により消した
- スーパーリロード

### どのくらいキャッシュが使われているか

1. 新しい画像をリクエストしたユニークユーザ数
2. 新しい画像の PV

画像に Expires と Last-Modified に古い値を付けるように設定
毎回必ずリクエストを投げるようになる。(戻るボタンは別)


Last-Modified を conditional GET してくるので
304 Not Modified を返す

- 200: キャッシュはなかった
- 304: キャッシュがあった

割合を調べる

- 少なくとも一つは 200 だったユーザ/ユーザ全体 (ユーザごと)
- 200 レスポンスの数 / 200 + 304 レスポンス

初日こそみんなキャッシュが無いので empty cache 率が高いが、だんだん下がっていく。
しかし、ある一定値で止まった。

- ユーザの 40-60% が empty cache
- PV の 20% が empty cache

-----

[Web performance: Cache efficiency exercise](https://code.facebook.com/posts/964122680272229/web-performance-cache-efficiency-exercise/)

2015/4/14 の記事
yahoo の調査が 8 年前なので Facebook がやり直した。

# Facebook

Cache-Control
Etag
Expires
Pragma
Last-Modified

を送るが、 IE はバグがあるので

Cache-Control
Pragma

だけ。


1. ヘッダが無ければ 200 と画像を送り、 L-M と ETag を保存
2. I-N-M, I-M-S があれば 304 で L-M は I-M-S を送り返す

これを FB のサーチのところに置いた。

## 結果

25% 近くがキャッシュミスしてた

ブラウザ別にみると Chrome/Opera は高い。 IE は低い。
Firefox は v31 で 80% くらいだが、 v32 で直近のレスポンスヘッダを再利用するようになったらしいので、
ログが正しく取れないので外した。


モバイルではキャッシュヒットは 6~8 割の間。

ユーザ別にみると 44.6% が empty cache だった。
2007 年とそんなに変わってない。

## 追加

どのくらいキャッシュは残っているのか？
I-M-S から現在時間を引いて47h 50% が 47h 
yahoo の調査が 8 年前なのでやり直す。

p50 で 50% が 47h
p75 で 25% が 260h

平均、 47h モバイルが 12h くらい。

## 結論

2007 年よりはよくなってる
80% だったのが 84% くらいにあっぷ

42% の人が 47h はキャッシュを使える

原因は単純に最近のサイトがでかい、 1M 級のものがある。
ブラウザを圧迫してる。

FB がしょっちゅうリリースしていると、キャッシュに影響するかと危惧したが、
特に問題はなさそうということがわかった。




# 2012 Chrome17

disk cache の詳細
http://dev.chromium.org/developers/design-documents/network-stack/disk-cache

多分デフォルト値はこれ(80MB * 4 = 320MB)
https://code.google.com/p/chromium/codesearch#chromium/src/net/disk_cache/blockfile/backend_impl_v3.cc&l=757

v3 じゃない古いバージョンはこれっぽい(240MB)
https://code.google.com/p/chromium/codesearch#chromium/src/net/disk_cache/blockfile/backend_impl.cc&l=50

320という数字は、ベンチを回して決めた。
これ以上大きくしても向上は取るに足らないし、むしろ lookup が遅くなり始める。

とにかく、大半(60%)のユーザは 320MB で、 25~30% のユーザは 190MB だけキャッシュ領域がある。

windows の chrome では
25% が  4h
50% が 20h
75% が 48h
でキャッシュを使い切る。


アクティブな browsing をしてると
25% が  1h
50% が  4h
75% が 10h

あっという間だ。

すぐに cache が埋まるということが、サーバの cache hit が思ったほど上がらないことを裏付けている。

他にも ricardo 曰く

- 7% が週一回は settings でキャッシュをクリアしている
- 19% が週一回は fatal cache corruption が起こってる

明示的だけじゃなく、何らかの理由でキャッシュが消えている。


Firefox では 60%
Chrome では 70%
くらいが full cache になっていない。


chrome でキャッシュはどう使われているか？

一度キャッシュがいっぱいになったら、キャッシュヒット率は中央が 45% のほぼ正規分布に則っている。
10% 以下のコンテンツが 7KB 以下
80% が 7KB ~ 48KB
99% が 110KB 以下

lookup についてはメトリクスが色々あるが、たいていは 0-1ms で速いが、
遅いのもままある。

いずれにせよ改善の余地がある。



# TODO

IE の場合 http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-explorer-9-network-performance-improvements.aspx