WordCamp Yokohama のこもりのスライド

1. WordPressを り高速に
よ
∼環境にあわせた表示パフォーマンスの最適化∼
WordCamp Yokohama 2010: Website Performance Optimization for WordPress

2. ち っ だけ自己紹介を…
ょ と
こもりまさあき
1972年生まれのフリーランス。
Web サイトの企画・情報設計・制作・管理をはじめ、書
籍の執筆や講師、アーティストのライブ撮影など、ジャ
ンルを問わず活動中なので肩書きはありません。
WordPressはいつから使い始めたか覚えてません。

3. 本日のアジェンダ
• 何故、サイトの表示パフォーマンスが求められるか
• Webサイトで起こっていることをおさらい
• 自サイトのチェックの仕方
• 環境に合わせたWordPressサイトの最適化手法

4. 表示パフォーマンス？

5. なぜ、表示パフォーマンスが求められるか
ブロードバンド化が進む一方、閲覧デバイスの多様化も進んでいる現代
• ブロードバンド化が進みつつあるが、
それに伴ってコンテンツは肥大化傾向にある
• 回線が速くなっても、データが大きければ、
それだけ表示に時間はかかる
• 閲覧デバイスの多様化が進み、
利用者の環境は常に最新のPCだけとは限らない

6. Google も表示までの平均を採っている
Labsでサイトパフォーマンスの平均値かチェック可能
• 直近半年間のサイトの表示パフォーマンス

7. むかし8秒、いま3秒ってホント？
決まりはないが、速くページが表示されるに超したことはない
• Alexa では、3秒が基準
• Google では、2.5秒が基準
• 必ずしもその秒数以内にする必要はないとはいえ、
利用者側からすれば、速く表示された方が嬉しい

8. データ配信の仕組みをおさらい

9. Webサーバの中で何が起こっているのか
まずは、WordPressの配信の仕組みをおさらいしておきましょう
• WordPressは、PHPとMySQLをバックエンドに
コンテンツを動的に生成して配信する仕組み
• ブラウザからのリクエストにあわせて、
それに応じたテンプレート中のPHPが実行される
• データの格納されたデータベースへ接続し、
HTMLを生成してからWebブラウザに送り返す

10. 簡単に図解するとこんな感じ
クライアントサイドとサーバサイドの関係図

11. 重く感じてしまう。その原因はいろいろ
配信環境やサイト構築の仕方がパフォーマンスに大きく影響
• チューニングされていないホスティング環境
• ホスティングの回線が貧弱（ベストエフォート型）
• プラグインを大量に使ったサイト構築をしている
• テンプレートの設計で失敗している
さまざまな条件が重なって、パフォーマンスに影響が出てしまう

12. WordPressのサイトを高速化するには

13. まずは、自サイトの現状を把握しよう
オンラインサービスや専用ツールでサイトのパフォーマンスを測定
• Pagetest（http://webpagetest.org）
• Load Impact（http://loadimpact.com/pageanalyzer.php）
• Firefoxのアドオン「YSlow! 」「Google Page Speed」
• SafariやGoogle ChromeのWebインスペクタ

14. データは順番にダウンロードされている
ウォーターフォールチャートでデータの流れを確認してみよう

15. ボトルネックを見極める
バックエンドの処理なのか？、フロントエンドの設計なのか？

16. その前に。何ができるかを考える
自サイトの環境や自身の職域次第でできる対応が変わってくる
1. サーバにソフトのインストールまで可能か？
※専用サーバ、VPS、Delegated Serverなど
2. Webサーバのモジュールが比較的自由に利用できる？
※Apacheの.htaccessなどでモジュールのオン・オフができる
3. どちらも不可能…

17. 環境にあわせて、パフォーマンスを改善
自サイトの環境に照らし合わせて、できる対策を適用していく
1. バックエンドのPHPとSQLの処理速度を改善
2. サーバの設定を変えて、配信ファイルをキャッシュ
3. Webサイトパフォーマンスの最適化手法を適用

18. 1. バックエンドの処理からチューニング
サーバにPHPアクセラレータを導入し、バックエンドの処理から高速化
• 実行済みのPHPスクリプトのデータをキャッシュする
• 代表的なPHPアクセラレータ
・APC（Alternative PHP Cache）
・eAccelerator
・xCache
・memcache

19. 2. いろいろなキャッシュを有効にする
モジュールが自由に使えれば、いろいろな方法でボトルネックの解消を試みる
• 「WP Super Cache」や「W3 Total Cache」を導入し
HTMLファイルをキャッシュして配信する
• 「DB Cache Reloaded」でクエリーをキャッシュ
• 可能ならテキストデータをgzip化して配信、
変更の少ないファイルへの有効期限の設定する
※gzip化には、PHPで直接かける方法とサーバサイドで「mod_gzip（mod_deflate）」を使う方法がある。
WP Super CacheやW3 Total Cacheでは、オプションでgzip化することができる
※有効期限の設定には、「mod_expire」や「mod_header」を利用する

20. 2. データのやりとりを減らすには
mod_expireを使って有効期限を設定し、ブラウザのキャッシュに残す
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 1 years"
ExpiresByType image/vnd.microsoft.icon "access plus 1 years"
ExpiresByType image/jpeg "access plus 1 years"
ExpiresByType image/png "access plus 1 years"
ExpiresByType image/gif "access plus 1 years"
ExpiresByType application/x-shockwave-flash "access plus 3 months"
ExpiresByType text/css "access plus 1 years"
ExpiresByType text/javascript "access plus 1 years"
ExpiresByType application/x-javascript "access plus 1 years"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

21. 3. サーバサイドが変更できない場合は…
いわゆる「Webサイトパフォーマンスの最適化手法」を適用する
• プラグインの数を減らす
• HTMLのhead要素内をクリーンにする
JavaScriptやCSSの結合、テキストのMinify化、読み込み順の修正
→ 「head cleaner」プラグインの導入
• 配信画像ファイルを見直す
CSSスプライトの採用、画像ファイルの最適化、別サーバからの配信
→ 「WP Smush.it」プラグインの導入

22. 3. サーバサイドが変更できない場合
いわゆる「Webサイトパフォーマンスの最適化手法」を適用する
• プラグインの数を減らしてHTMLの生成時間を短縮
• JavaScriptやCSSの結合とMinify化、
配信画像ファイルの最適化などを考えてみる
→ 「head cleaner」プラグインの導入
→ 「WP Smush.it」プラグインの導入
• とにもかくにもHTTPリクエストを減らすことが先決
ブラウザは1ホストあたりの同時接続数が決まっている

23. まとめると…
環境にあわせてできることから適用していく
• 自サイトの現状把握からはじめる
• バックエンドからやるなら、PHPの処理を高速化
• キャッシュできるものは、キャッシュさせてしまう
• 自由度が低ければ、HTMLの構造変更や画像最適化

24. できることからやってみましょう

25. 本日はありがとうございました
配信側の都合だけではなく、利用者に優しいサイト作りを