Client-side caching

[shimoju]

クライアント側のキャッシュ設定（Cache-Controlヘッダで主に静的コンテンツのキャッシュ）

• http://nginx.org/en/docs/http/ngx_http_headers_module.html
• http://httpd.apache.org/docs/2.4/mod/mod_expires.html
• https://developers.google.com/speed/docs/insights/LeverageBrowserCaching?hl=ja
• https://github.com/h5bp/server-configs-nginx/blob/master/h5bp/location/expires.conf

[shimoju]

Railsのasset pipelineのように、

• あるディレクトリ以下は全て静的ファイルで、
• ハッシュ付加などでファイルが変更されたらファイル名も変わる（=一度作ったファイルは変更されない）ことが保証されている場合

なら、このように設定できる

# For Apache:

# The Expires* directives requires the Apache module
# `mod_expires` to be enabled.
<Location /assets/>
  # Use of ETag is discouraged when Last-Modified is present
  Header unset ETag
  FileETag None
  # RFC says only cache for 1 year
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
</Location>

# For NGINX:

location ~ ^/assets/ {
  expires 1y;
  add_header Cache-Control public;

  add_header ETag "";
  break;
}

http://guides.rubyonrails.org/asset_pipeline.html

[shimoju]

WordPressにはasset用のディレクトリはないし、CSS・JSには?ver=xのクエリがつくものの必ずついているわけではないので、1年キャッシュさせるのは怖い

• ファイルの拡張子を見てキャッシュヘッダを送信
• キャッシュ期間は1ヶ月または1週間

が良いのでは

[shimoju]

https://github.com/shimoju/wordpress-heroku/commit/102e91f2005b82529cc6577fb5fe6b3b91d66db0

• ファイルの拡張子を見てキャッシュヘッダを送信
• CSS/JS、画像などのメディア、Webフォントの3種類設定できるように
• キャッシュ期間は全部とりあえず1ヶ月

ApacheだとHeader appendできちんと既存のヘッダに追加されて、

Cache-Control: max-age=2592000, public

となるが、nginxでは既存のヘッダに追加はできないみたいで二重になる

Cache-Control: max-age=2592000
Cache-Control: public

[shimoju]

https://github.com/shimoju/wordpress-heroku/commit/3b33198fdafaa3546471d1bd66995f0fc8f0c529

ヘッダ重複問題に対処するため、Expiresを使わずCache-Controlのみで設定するようにした 設定値がわかりにくくなるが、頻繁には変更しないので許容範囲内かなと

Cache-Control: public, max-age=2592000

それと同時にETagを無効にした

https://github.com/shimoju/wordpress-heroku/commit/3111d049e866d89dc4706f8f900710714f001482

[shimoju]

これで想定通り動いているのでclose

[shimoju]

と思ったらNginxでは

There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level. http://nginx.org/en/docs/http/ngx_http_headers_module.html

とあり、何らかのadd_headerディレクティブがある場合は前のレベルからヘッダが継承されなくなるらしい

8 でadd_header X-Content-Type-Options "nosniff";を追加したが、location内にadd_headerを書いているのでX-Content-Type-OptionsなどがCSS・JSや画像に適用されなくなってしまった

[shimoju]

location内でヘッダを再度定義してもいいが、DRY的に嫌 expiresを使うとこの挙動にはならないようなので、expiresを使うように戻して、Cache-Control: publicは付与しないようにした https://github.com/shimoju/wordpress-heroku/commit/427c0d94cf862efd36fff611c9b2736f8bd92cfd

Googleによると、publicはなくてもよいとのこと

“public” と “private” レスポンスが “public” として指定されている場合は、レスポンスに関連付けられた HTTP 認証があり、さらにレスポンスのステータス コードが通常キャッシュ可能になっていない場合でも、そのレスポンスはキャッシュに格納できます。ほとんどの場合、明示的なキャッシュ情報（”max-age” など）で レスポンスがキャッシュ可能であることが指定されているので、”public” は必要ありません。 https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=ja