1. HOME
  2. 開発・ブログ運営
  3. WEB パフォーマンス
  4. WordPress がもっさりしてきたので、ブラウザキャッシュ(Expires ヘッダ)を設定して高速化してみた
2014年09月23日
CSS と Javascript の読み込み順序を変えてみた ...
2012年11月17日
Google の Chrome Developer Tools ...
2016年07月27日
WEB サーバーを Apache 2 コンテナから Nginx ...
2016年07月29日
AMP ページに Google Analytics のトラッキ ...
2012年12月06日
Facebook の「いいね」ボタンやコメントボックスを外した ...
2016年07月22日
WordPress が稼働する Apache2 コンテナと N ...

WordPress がもっさりしてきたので、ブラウザキャッシュ(Expires ヘッダ)を設定して高速化してみた

キャッシュ、きゃっしゅ、cache、→ これはキャッチェじゃないよ。キャッシュだよ。

というわけで、表示速度がモッサリしてきたこのブログをブラウザキャッシュを有効にすることによって表示速度の改善をしてみました。

いまさらながら、ブラウザキャッシュを設定してみました。ブラウザキャッシュとは、アクセスした WEB サイトのデータ(CSSや画像など)をブラウザ側で保持するキャッシュのこと。

ブラウザキャッシュが有効になると、ブラウザは一度アクセスした WEB サイトのデータをキャッシュとして保持し、同じサイトへのアクセスはサーバーに問い合わせることなくキャッシュからデータを読み込むことによって、表示を高速化させるという仕組み、だそうな。

ブラウザ側でキャッシュの仕組みがあるのは昔から知っていましたが、単純にアクセスした WEB サイトのデータをキャッシュして、単純に次回以降はそのキャッシュを読み込む、という訳ではないみたい。

どうやらいちいち WEB サーバーに問い合わせをして、WEB サーバーのデータがキャッシュファイルよりも新しければ、WEB サーバーからデータを取得し、そうじゃなければキャッシュファイルを読み込むとのこと。

なので、キャッシュしているとはいえイチイチ WEB サーバーに問い合わせるため通信環境やサーバー性能によっては時間が掛かる。

ってことで、expires ヘッダなるものを設定してあげると、イチイチ WEB サーバーに問い合わせをすることなく、キャッシュがあればキャッシュファイルを読み込むようにできるみたい。

WEB サーバーによっては expires ヘッダの設定が大変

このブログはレンタルサーバー(エックスサーバー )で動いている訳ですが、多くのレンタルサーバーでは WEB サーバーとして Apache が使われていることが多い。

っで、expires ヘッダは、Apache の mod_expires というエクステンションを利用すると簡単に設定できるみたいだけど、レンタルサーバーの Apache に mod_expires が組み込まれていない(有効になっていない)場合は、PHP とかでゴリゴリしなければならないので大変(っぽい)。

今まで気にしたこともなかったけど、レンタルサーバー選びでは mod_expires が使えるかどうかって結構重要かも。

自分のレンタルサーバーで mod_expires が使えるかどうかわからない場合は、とりあえず設定だけでもしちゃってください(笑)。

別に壊れたりするわけじゃないので。

設定した後、WEB サーバーへのアクセスが発生してるかどうかを確認して、アクセスが発生していたら、あぁ mod_expires が使えないんだな・・と、その時にあきらめる、と。単純に設定をミスってるだけの可能性もありますが・・。

ちなみに人気のさくらのレンタルサーバーでも、2012年7月より mod_expires が使えるようになったみたいです。

参考:遂にさくらのレンタルサーバでmod_expiresが使用可能に!さっそく試してみた | 情報科学屋さんを目指す人のメモ

もちろん、エックスサーバー でも mod_expires は使えます。

expires ヘッダを設定するファイルの対象

動的に生成される WEB サイトでは、WEB ページ(HTML)自体がキャッシュされてしまうと、その WEB ページを更新した際にもブラウザは更新前にキャッシュしたページ(HTML)を読み込んでしまうため、原則、画像ファイルや CSS、Javascript などの静的なファイルのみをキャッシュするようにするようです。

そりゃそうだ。

WordPress で構築した WEB サイト(ブログ)は PHP によって動的に生成される訳ですが、記事の修正等をしない限り毎回同じ内容で生成されるので、WEB ページ(動的に生成された HTML)自体をキャッシュしてしまっても良いかもしれません。

ただ、このブログのように「人気の記事」などをサイドバーに表示してたり、コメント欄を設けてたりする場合、WEB ページ自体をキャッシュする設定にしていると、それら変更が反映しなくなっちゃうので、やっぱり原則は画像などの静的なファイルのみをキャッシュする方が無難かも。

ただ、やってみるとわかりますが、WEB サーバーへのアクセスをスキップして、直接キャッシュファイルが読み込まれると圧倒的に速いです。天と地の差。

なので、動的に変化する部分についてもリアルタイムで変化しなければならないのか、別にタイムラグがあっても問題がない場合も多いと思うので、それらを吟味しながら極力 expires ヘッダを設定する方向で。

さっそく設定してみた

expires ヘッダを追加すべく .htaccess に以下を追加しました。

# BEGIN CACHE(Browser Cache)
<ifModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif “access plus 14 days”
ExpiresByType image/jpeg “access plus 14 days”
ExpiresByType image/png “access plus 14 days”

ExpiresByType text/html “access plus 1 seconds”
ExpiresByType text/css “access plus 60 minutes”
ExpiresByType application/x-javascript “access plus 60 minutes”

ExpiresByType application/xhtml+xml “access plus 30 minutes”
ExpiresByType application/xml “access plus 30 minutes”
ExpiresByType application/rss+xml “access plus 30 minutes”
</ifModule> # END CACHE

この設定だと、画像ファイル(gif、jpeg、pne)はアクセスされてから14日間、css ファイルは 1時間、Javascript も 1時間キャッシュされます。(WEB サーバーへのアクセスが無くなります)

さらに、rss などは アクセスされてから 30分間キャッシュされます。

css とか Javascript を 1時間キャッシュするなら、rss とかも最低 1時間キャッシュしちゃえば良いような気もしますが、とりあえずこんな感じで。

また、HTML ファイル(PHP も含む)については、

ExpiresByType text/html “access plus 1 seconds”

と、1秒だけキャッシュするような設定になっているけど、何故こうするのか良く分からない。

多くのサンプルがこうなってたから真似してみた。

ちゃんと expires ヘッダが追加されているかどうかを確認してみる

設定が終わったら、ちゃんとexpires ヘッダが追加されているかどうかを Chrome Developer Tools で確認してみます。

  1. Chrome Developer Tools を起動して、Network を開きます。



  2. ブラウザで自分のブログにアクセスします。そうすると、設定した対象のファイルがキャッシュされたはず。

    そして、ブラウザでリンクをクリックします(リロードはNG)。サイドバーに使っている画像など、1回目にアクセスしたページと同じファイルで表示されていて、かつ .htaccess でキャッシュ対象として設定したファイル(gif, jpeg など)は、WEB サーバーからではなくて、キャッシュから読み込まれているはず。

    Chrome Developer Tools にずらずらーっと表示された中で、キャッシュ対象のファイルの Size が (from cache)となっていれば成功です。


なんか、ちょっとうれしい。

もうちょっと詳しく確認してみる

キャッシュから読み込まれていることは確認できたけど、ちゃんと指定した通りの期間、キャッシュが有効になっているかどうかを確認してみます。

  1. 左側からキャッシュ対象のファイルをクリックすると、右側に HTTP Response Header が表示されます。(下までスクロールしてください。)

    下の画像のように数行しか表示されない場合は、一度元の画面に戻って別のファイルを選択し直してください。



    Response Header とは、対象ファイル(この場合は png ファイル)が WEB サーバーから送られてくるときに、WEB サーバーから一緒に送られる情報です。

    っで、Response Header が表示されたらその中に、

    Cache-Control:max-age=1209600
    Expires:Wed, 05 Dec 2012 02:48:01 GMT

    があることを確認します。これは png ファイルの Response Header の内容ですが、上記 .htaccess で設定したとおり、Cache-Control の max-age が、1,209,600秒(14 days)になっています。

    Expires は、表示されている日時までキャッシュが有効ですよ、という意味。ちゃんと約2週間後になってます。

    当然、.htaccess でキャッシュ有効期間を再設定すれば、Cache-Control などの値は変わりますので、.htaccess を修正した場合は、Response Header を確認してちゃんと意図通りの設定が反映されているか確認すると安心。

    なんかプロっぽくなってきた(笑)。

    実際の効果

    サイトの作り方(画像ファイルなどの量)にもよりますが、このブログでは ページの読み込み速度が 0.5秒~0.8秒ほど早くなりました。

    たった、0.5~0.8秒かよ、と思うかもしれませんが、0.5秒の差は大きいです。体感できるレベル。モッサリ感も多少無くなった。

    ページの表示速度(読み込み速度)の確認方法については Google の Chrome Developer Tools で サイトの表示速度を計測してみた をご覧ください。

    キャッシュ管理の難しさ

    キャッシュっていうのは仕組みは単純だけどそれを管理するのは大変。なんでもかんでもキャッシュすれば表示は速くなるけどページごとに人気記事ランキングの順序が変わっちゃったり、CSS をいじったりすると、修正が反映されているページと修正が反映されていないページに分かれちゃったり。

    また、キャッシュといっても今回のブラウザキャッシュ以外にも、PHP の処理過程をキャッシュしたり、データーベース接続の内容をキャッシュしたりと、キャッシュが出てくる場面は多い。

    WEB ページの表示速度を高める上で、いかにキャッシュを効果的に利用するか?というのはとても重要なことだと思いますが、それぞれのキャッシュの挙動を理解していないと、とにかくハマル。

    泣きたいくらいにはまります。

    なので、何が、どのタイミングで、どんな条件の時には、いつまで、キャッシュされるのかなどを常に意識(理解)しながら、キャッシュの管理ができるようになれば良いなぁと。

    まとめ

    今回は、.htaccess でブラウザキャッシュの設定を対象ファイルやキャッシュの有効期間を指定しつつ設定してみたわけですが、WordPress のプラグインでチェックボックスにチェックを入れるだけでブラウザキャッシュを有効にできたりするものも沢山あります。

    なんだけど、このようなプラグインはキャッシュの挙動を理解している人にはお手軽な存在だったりもするけど、私のような初心者はひとつづつ、キャッシュの挙動を理解、確認しながら進めていった方が、結局その方が楽ちんだったよね、となるんじゃないかと。

    いずれにしても、WEB ページの表示速度とキャッシュは切っても切り離せない関係にあるので、キャッシュの挙動を理解しておいて損は無いと思います。

    なんかブログがモッサリしてきたなぁ、という人は是非チャレンジしてみてください。

    でわでわ。







「WordPress がもっさりしてきたので、ブラウザキャッシュ(Expires ヘッダ)を設定して高速化してみた」に頂いたコメント & トラックバック

この記事にコメントする





Copyright © 2012 - 2014 MacBook Air とWordPressでこうなった All rights reserved
Powered by WordPress.