work.log

エンジニアの備忘録的ブログ

WordPressで利用するファイルのExpiresヘッダを見直す

投稿:2014-03-15 14:05  更新:

WordPress で運用するコンテンツを最適化するメモです。

GTmetrix を使って Page Speed と YSlow のパフォーマンス診断を行いましたので、今回から各指摘事項を潰していこうと思っています。

まずは影響が大きいと思われる下記項目から見直していきます。

  • Page Speed → Leverage browser caching
  • YSlow → Add Expires headers

スポンサーリンク

Expires ヘッダを最適化する

上記の指摘事項は何を指しているかというと、コンテンツを構成する各ファイル (css, js, 画像等) に設定される「Expires ヘッダ」を見直して、ブラウザキャッシュを有効的に使えって事のようです。

Expires ヘッダのざっくりした認識としてはこんな感じです。

Expires ヘッダはファイルの有効期限をブラウザに伝えるもので、ダウンロードしたファイルに有効期限が設定されていればブラウザはその期限までローカル内にキャッシュとして保存。

キャッシュが有効であれば、ブラウザがそのファイルへのリクエストを Web サーバに送信しなくなるので、サーバ処理の負荷、NW 帯域、レスポンスの待ち時間等を削減できる。

Web コンテンツ全般に言える最適化事項なので WordPress に限った話ではないですが、経験上、この最適化は設定が簡単な割には効果が非常に大きいと感じています。

特に、画像を沢山掲載しているコンテンツなんかだと効果が大きいです。いくら画像を最適化しても文字に比べるとバイト数はデカいですから、クライアントがダウンロードを完了するまで比較的長くコネクションを占領されてしまいがち。

忙しいサーバだと特に効果を感じれるような気がします。

今回は、Apache で mod_expires モジュールが使えるのを前提に書いていますが、WordPress の htaccess にこんな感じに追加してみました。

<IfModule mod_expires.c>

  ExpiresActive On
  ExpiresByType text/css "access plus 3 weeks"
  ExpiresByType text/javascript "access plus 3 weeks"
  ExpiresByType application/javascript "access plus 3 weeks"
  ExpiresByType application/x-javascript "access plus 3 weeks"
  ExpiresByType image/gif "access plus 6 months"
  ExpiresByType image/jpeg "access plus 6 months"
  ExpiresByType image/png "access plus 6 months"
  ExpiresByType image/vnd.microsoft.icon "access plus 6 months"

  <FilesMatch "\.(css|js|gif|jpe?g|png|ico)$">
    Header append Cache-Control "private"
  </FilesMatch>

</IfModule>

書くファイルの有効期限を設定している書式は概ね下記のような感じです。

ExpiresByType plus <期限 *2>”

*1 base

  • access (now) → 有効期限はクライアントが初めてキャッシュした時を起算
  • modification → 有効期限はファイルの最終更新時間から起算

*2 期限

years, months, weeks, days, hours, minutes, seconds

メモ: できればこの設定は Apache のコンフィグに書いた方が Apache 的には良くなるはず。

参考: Apache モジュール mod_expires

css, js ファイルは有効期限を 3 週間、各種画像ファイルは有効期限を半年にしてみました。

よくある注意点としては、上記設定を入れた後は css, js の変更に少し気を使う必要が出てきます。ファイル名 style.css でキャッシュされるとブラウザは有効期限までサーバに取りにいかないので変更が反映されない現象が起きます。

一応、解決策はあるのですがこれは次回に回すとして、早速この状態でパフォーマンス計測してみます。

work.log クローン環境の計測結果

before

wp-optimize-gtmetrix-001-02

wp-optimize-pingdom-001-02

after

wp-optimize-gtmetrix-002-02

wp-optimize-gtmetrix-002-04

こんな感じでスコアアップしました。Pingdom のスコアの伸びが半端ないです。

work.log の計測結果

つづいてこのブログ。

before

wp-optimize-gtmetrix-001-01

wp-optimize-pingdom-001-01

after

wp-optimize-gtmetrix-002-03

wp-optimize-gtmetrix-002-05

こっちはまだまだという感じですが前回よりは大分良いです。

こっちも Pingdom の伸びは良いですが Page Speed は全然駄目ですね。これはコンテンツ圧縮の絡みが大きいと思うのでこの辺りは優先的に見直す予定。

微々たる所ですが、アクセス解析とかの外部スクリプト等も含めての評価なので、その点はクローンと比べるとマイナス評価されちゃってます。外のサービスなので弄れないですしここはしょうがない。

ただ、それにしてもクローン環境とリクエスト数が違うような気がしますがとりあえず保留!

最後に、本件に関する情報が細かく書かれたページを見つけたので貼っておきます。まだ全部読めてないですがこれは必読かも。

スポンサーリンク

コメント

コメントを残す

よく読まれている記事

  • 今日
  • 週間
  • 月間