HiGash.Net ホームページへ戻る

Home [Blog] » 公開前にやっておきたいサイト最適化対策

公開前にやっておきたいサイト最適化対策

公開前にやっておきたいサイト最適化対策

サイトを高速化するためには、パワフルなWebサーバーやCDN(Contents Delivery Network)の導入など、サーバーやネットワークの改善も必要でしょう。
しかし、ソースコードや画像などのフロントエンドまわりを最適化するだけでもじゅうぶんにサイトは速くなります。

サーバーやネットワークにお金をかけるのは、ある程度フロントエンドを最適化してもなおサイトを高速化する必要がある場合だけでじゅうぶん。さらに言うと、そこまでのレベルの最適化が必要ならば、それは専門家に任せるべきだと思います。

というわけで今回のエントリーは、フロントエンドエンジニア(デザイナー兼マークアップエンジニア)としての僕がサイトを本番公開する前にやっている最適化対策についてまとめてみました。公開前にちょっと手を加えるだけでサイトを少しでも早く表示させられるなら、やっておいて損はないと思います。

ちなみにサイトのパフォーマンスを計測するツールとして、僕はYahoo! Inc.が公開しているFirefoxアドオン YSlow を使っています。
最近、GoogleからもYSlowと似たアドオン Page Speed が公開されましたが、ちょっと使ってみた感じだと個人的にはYSlowのほうがわかりやすくて使いやすいです。
これは単なる好みだし、慣れの問題だとも思うけど。

CSS、JavaScriptの最適化

まず CSSもJavaScriptもできる限り結合してひとつのファイルにまとめるようにすること が基本です。
もちろんコンポーネント化(機能別に分離させること)によって制作効率を高められるというメリットもあるので、すべてをひとつのファイルにまとめあげるのは現実的には難しいかもしれません。
だけど、全ページで必ず読み込まれているCSSやJavaScriptはひとつのファイルにまとめることができるはずです。そうすることでHTTPリクエストの回数を確実に減らすことができます。

Online YUI Compressor

また、JavaScriptについては Online YUI Compressor などのオンラインツールを利用するだけでギュッと圧縮することができます。ファイルサイズが小さくなればなるほど当然読み込み終わるまでに要する時間は短くなります。
気をつけなければいけないのは、著作権表示を義務づけているJavaScriptライブラリを利用している場合に圧縮ツールで著作権を削除してしまわないようにすることです。

CSSにもいくつかオンラインの最適化ツールがありますが、CSSの場合はJavaScriptに比べて修正が加わりやすいことと、CSSハックの記述部分がうまく最適化されないことがあるので僕は利用していません。
ひとつCSSを書く時に気にかけてるとしたら、 無駄にインデントやコメントを増やさないようにすること ぐらいでしょうか。これはHTMLを書く時にも言えることだけど、インデント(空白スペース)やコメントは制作の効率化を大きく犠牲にしない程度に極力無くすことを心がけたほうがよいと思います。
結局ページの表示には無駄な要素だから。

なお、YSlowではCSSはできる限りソースコードの上のほうで、逆にJavaScriptはできる限りソースコードの下のほうで読み込むよう推奨しています。
JavaScriptは <head> タグ内に書かなければいけないわけじゃないので、下のほうに書いても問題ないものは </body> の直前ぐらいに移動してしまってよいと思います。

画像の最適化

圧縮率と画質の観点から、もっとも効率のよい画像の保存形式はPNG8と言われています。なので 画像はPNG8を基本に保存していくとよい でしょう。
ただしIE6対策として透過を使いたい場合はGIFを選択したり、写真など色数の多い画像や複雑なグラデーションをきれいに表示したい場合についてはJPEG(PNG24)を選択する必要もあります。そのへんは臨機応変に。

smush.it!

PhotoshopやFireworksで画像を制作している場合、 smush.it! を利用することで余計なメタデータを削除し、画像ファイルのサイズを小さくすることができます。圧縮できるサイズは全体の3%程度ですが、特に画像を多く利用している場合はバカにできない数字なんじゃないでしょうか。

また、HTTPリクエストを減らすという意味ではCSS Spriteが有効です。背景画像はできる限り1枚絵にして読み込む画像の枚数を減らしましょう。 CSS Sprite Generator という便利なオンラインツールも公開されているので活用してみるのもよいでしょう。
ただ、最近CSS Spriteの使い過ぎはメモリを消費しやすいという記事を読みました。極端に大きな画像を使用している場合ということらしいですが、どの画像を1枚にまとめるかは少し考えたほうがよいかもしれない。

gzip圧縮

サーバーでHTML・CSS・JavaScriptなどを圧縮して転送し、ブラウザ側で解凍することでファイルの転送量を大幅に減らすことができます。これはApacheの設定ファイル(httpd.conf)を弄る必要があるので、基本的には共有のレンタルサーバーでは利用できないと思います(.htaccessに設定を記述することで利用できる場合もあるかもしれないけど)。

専用サーバーでサイトを運用している場合はまずhttpd.confにmod_deflateモジュールを読み込む設定をします。# でコメントアウトされている場合はコメントアウトを外すだけでOKです。


LoadModule deflate_module modules/mod_deflate.so

続いて下記のような記述をhttpd.confに追加します。一応、古いブラウザでgzip圧縮に対応していないものに対しては圧縮を行わないようにしています。


<IfModule deflate_module>
  <Directory "/var/www/"> « 設定を有効にしたいディレクトリを指定
    AddOutputFilter DEFLATE text/html text/css text/javascript text/xml »
    text/plain
    SetOutputFilter DEFLATE
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico|zip|gz)$ »
    no-gzip dont-vary
    Header append Vary User-Agent env=!dont-vary
  </Directory>
</IfModule>

気をつけなければいけないのは、サーバー側でファイルの圧縮という処理を行うため、当然サーバーには少なからず負荷がかかるという点です。

Expiresヘッダ

変更の少ない画像やCSS、JavaScriptなどをユーザーにキャッシュさせるためにExpiresヘッダを設定します。一度キャッシュされたデータは設定した期間はユーザー側で保持されるので、その間余分なHTTPリクエストを減らすことができます。

gzip圧縮のときと同様に、まずはhttpd.confでexpires_moduleを読み込む設定をします。


LoadModule expires_module modules/mod_expires.so

続いて下記のような記述をhttpd.confに追加します。下記はアクセス後3日間データをキャッシュするように設定した例です(image/x-iconは1年間キャッシュ)。


<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 3 days"
  ExpiresByType application/x-javascript "access plus 3 days"
  ExpiresByType image/jpeg "access plus 3 days"
  ExpiresByType image/png "access plus 3 days"
  ExpiresByType image/gif "access plus 3 days"
  ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

ExpiresByType image/x-iconでfaviconをキャッシュできると思ったんだけど、YSlowの結果を見る限りキャッシュされてないみたい。この設定方法って間違ってるんでしょうか。。。

ユーザーにキャッシュさせたファイルを更新してしまい、強制リロードさせたい場合は素直にファイル名を変えるか、ファイル名の末尾に「?=090628」のようなパラメータを設定すればOKです。

ちなみに共有のレンタルサーバーを利用している場合でも、.htaccessに設定を記述することでExpiresヘッダを有効にできるかもしれません。
当ブログは.htaccessに下記のような記述をすることでExpiresヘッダが有効になっています。


<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|ico|css|js)$">
    ExpiresActive on
    ExpiresDefault "access plus 7 days"
  </filesmatch>
</ifmodule>

ETag

ETag(Entity Tag)とは画像やCSS、JavaScriptなどをキャッシュする際に、ファイルの更新日時やサイズなどの情報を付与する任意の文字列のこと。
ブラウザやサーバーはETagによってユーザーにキャッシュされたデータとサーバー上のデータの相違を見比べているそうです。ETagが一致していればファイルが更新されていないと判断して、キャッシュを使うようにするということかな。

YSlowではETagを適切に設定することもサイト最適化の条件とされているので、 Improve your web site performance – tips & tricks to get a good YSlow rating – Robert’s talk という記事を参考に.htaccessに下記のようにETagを設定してやります。


FileETag MTime Size

ちなみに複数のWebサーバーでサイトを運用している場合は、ETagは利用しないほうがよいそうです。
なぜならETagはサーバーごとに生成されるので、同じファイルであっても違うサーバーにリクエストされれば違うETagが付いてしまうから。ETagを付ける意味が無くなってしまうわけですね。
ETagを除去するには、次のように記述します。


FileETag None

WordPressの高速化について

WordPressで作ったサイトを高速化するために、一般的によく知られているのは WordPress Super Cache のようなページをキャッシュするプラグインですね。
でも、こういったプラグインを使うとPHPでブラウザを振り分けるなどの処理をできなかったり、ちょっとページを更新しただけでキャッシュを消さなきゃいけなかったり、他のプラグインとバッティングしたり。。。不便な側面も多いと感じるので僕は使ってません。

File-Based Object Cache Extension

手軽にできるWordPressの高速化対策としては、 File-Based Object Cache Extension の導入があります。
これはWordPressの変数をキャッシュしてしまおうというプラグインです。共有のレンタルサーバーなどでMySQLが重たい場合は効果が期待できるかも。

File-Based Extension to the WordPress Object Cache — The NeoSmart Files からFile-Based Object Cache Extensionをダウンロードし、wp-content(pluginsフォルダではありません!)ディレクトリ内に解凍。
さらにwp-content内にcacheというディレクトリを作ってパーミッションを777に。

最後にwp-config.phpに下記の一行を書き加えてキャッシュを有効にすれば動くはずです。


define(’ENABLE_CACHE’, true);

プラグインはWordPress 2.5用となっていますが、2.7でも動いています。しかし、ご利用は自己責任でお願いします。

PHPアクセラレータの導入

これは共有のレンタルサーバーではなく、専用サーバーでサイトを運用している人向けです。
PHPの処理を速くすれば当然WordPressも速くなります。 PHPアクセラレータには eAcceleratorAPCXCache などがあります。

僕は先日初めてXCacheを使ってみました。XCache導入の方法は bluegold.me に詳しいのでそちらに譲りますがひとつだけ。
XCacheの管理画面にはデフォルトでベーシック認証がかかっていますが、もともとベーシック認証がかかっているフォルダにXCacheの管理画面用フォルダを入れると認証がうまく動かないようです。
その場合はXCacheの認証はOFFにしてしまうとよいと思います。もちろん、もともとのベーシック認証はかけたままで。


xcache.admin.enable_auth = Off

MySQLのクエリキャッシュ

その他に、MySQLのクエリキャッシュなんかもWordPress高速化に効果がありそうです。
専用サーバーでサイトを運用している方は試してみるとよいと思います。

以上、フロントエンドまわりのサイト最適化対策についてでした。

僕の場合、正直言ってトラフィックの多さに悩まされるようなサイトの構築経験は少ないのですが、こういう対策は後手後手にまわるよりは、あらかじめできることをやっておいたほうがよいのではないかと思います。
どの対策もひとつひとつは劇的な効果があるわけじゃないですが、塵も積もれば。。。ってやつです。何事も小さな努力の積み重ねが大事ですね。

あ。ちなみにこのサイトはあんまり最適化されてないですね。。。まあ、プライベートワークだし。という言い訳をしておきます。すいません。

本エントリーとは無関係ですが、6月29日に発売される雑誌『web creators』8月号(エムディエヌコーポレーション)の巻頭特集に記事を6本ほど書かせてもらいました。特集内容は不況下の少ない予算と時間でも、クオリティの高いWebサイトを作るために必要なノウハウについてです。
今は不況下だから特にだけど、不況でなくともクオリティに妥協せず作業をいかに効率よくこなすかというのは、制作の仕事をしている人間の永遠の課題だと思います。制作コスト削減も小さなことからコツコツやっていくことが大事という意味ではサイト最適化と一緒かもしれません。
ご興味のある方はぜひご覧いただければ。

Share & Bookmark
このエントリをFacebookでシェアする
このエントリをTwitterでつぶやく
このエントリをはてなブックマークに追加
Delicious
livedoorクリップ
Yahoo!ブックマーク
Buzzurl

コメント/トラックバック

1 件のコメント/トラックバックをいただきました。ありがとうございます!!

ぜひこのエントリーに対するコメントをお聞かせください。

以下のURLでトラックバックも受付けています。

http://higash.net/20090628/optimization.html/trackback/

Preview

トラックバック
http://higash.net/20090628/optimization.html/trackback/

Page Top