WordCamp Yokohama 2010 Komori
-
Upload
masaaki-komori -
Category
Technology
-
view
2.440 -
download
6
description
Transcript of WordCamp Yokohama 2010 Komori
~環境にあわせた表示パフォーマンスの最適化~
WordPressをより高速に
WordCamp Yokohama 2010: Website Performance Optimization for WordPress
ちょっとだけ自己紹介を…
こもりまさあき
1972年生まれのフリーランス。Web サイトの企画・情報設計・制作・管理をはじめ、書籍の執筆や講師、アーティストのライブ撮影など、ジャンルを問わず活動中なので肩書きはありません。
WordPressはいつから使い始めたか覚えてません。
本日のアジェンダ
• 何故、サイトの表示パフォーマンスが求められるか• Webサイトで起こっていることをおさらい• 自サイトのチェックの仕方• 環境に合わせたWordPressサイトの最適化手法
表示パフォーマンス?
ブロードバンド化が進む一方、閲覧デバイスの多様化も進んでいる現代
なぜ、表示パフォーマンスが求められるか
• ブロードバンド化が進みつつあるが、それに伴ってコンテンツは肥大化傾向にある
• 回線が速くなっても、データが大きければ、それだけ表示に時間はかかる
• 閲覧デバイスの多様化が進み、利用者の環境は常に最新のPCだけとは限らない
Labsでサイトパフォーマンスの平均値かチェック可能
Google も表示までの平均を採っている
• 直近半年間のサイトの表示パフォーマンス
決まりはないが、速くページが表示されるに超したことはない
むかし8秒、いま3秒ってホント?
• Alexa では、3秒が基準• Google では、2.5秒が基準• 必ずしもその秒数以内にする必要はないとはいえ、利用者側からすれば、速く表示された方が嬉しい
データ配信の仕組みをおさらい
まずは、WordPressの配信の仕組みをおさらいしておきましょう
Webサーバの中で何が起こっているのか
• WordPressは、PHPとMySQLをバックエンドにコンテンツを動的に生成して配信する仕組み
• ブラウザからのリクエストにあわせて、それに応じたテンプレート中のPHPが実行される
• データの格納されたデータベースへ接続し、HTMLを生成してからWebブラウザに送り返す
クライアントサイドとサーバサイドの関係図
簡単に図解するとこんな感じ
配信環境やサイト構築の仕方がパフォーマンスに大きく影響
重く感じてしまう。その原因はいろいろ
• チューニングされていないホスティング環境• ホスティングの回線が貧弱(ベストエフォート型)• プラグインを大量に使ったサイト構築をしている• テンプレートの設計で失敗している
さまざまな条件が重なって、パフォーマンスに影響が出てしまう
WordPressのサイトを高速化するには
オンラインサービスや専用ツールでサイトのパフォーマンスを測定
まずは、自サイトの現状を把握しよう
• Pagetest(http://webpagetest.org)• Load Impact(http://loadimpact.com/pageanalyzer.php) • Firefoxのアドオン「YSlow! 」「Google Page Speed」• SafariやGoogle ChromeのWebインスペクタ
ウォーターフォールチャートでデータの流れを確認してみよう
データは順番にダウンロードされている
バックエンドの処理なのか?、フロントエンドの設計なのか?
ボトルネックを見極める
自サイトの環境や自身の職域次第でできる対応が変わってくる
その前に。何ができるかを考える
1. サーバにソフトのインストールまで可能か?※専用サーバ、VPS、Delegated Serverなど
2. Webサーバのモジュールが比較的自由に利用できる?※Apacheの.htaccessなどでモジュールのオン・オフができる
3. どちらも不可能…
自サイトの環境に照らし合わせて、できる対策を適用していく
環境にあわせて、パフォーマンスを改善
1. バックエンドのPHPとSQLの処理速度を改善
2.サーバの設定を変えて、配信ファイルをキャッシュ
3. Webサイトパフォーマンスの最適化手法を適用
サーバにPHPアクセラレータを導入し、バックエンドの処理から高速化
1. バックエンドの処理からチューニング
• 実行済みのPHPスクリプトのデータをキャッシュする
• 代表的なPHPアクセラレータ・APC(Alternative PHP Cache)・eAccelerator・xCache・memcache
モジュールが自由に使えれば、いろいろな方法でボトルネックの解消を試みる
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」を利用する
mod_expireを使って有効期限を設定し、ブラウザのキャッシュに残す
2. データのやりとりを減らすには
<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>
いわゆる「Webサイトパフォーマンスの最適化手法」を適用する
3. サーバサイドが変更できない場合は…
• プラグインの数を減らす
• HTMLのhead要素内をクリーンにするJavaScriptやCSSの結合、テキストのMinify化、読み込み順の修正→ 「head cleaner」プラグインの導入
• 配信画像ファイルを見直すCSSスプライトの採用、画像ファイルの最適化、別サーバからの配信→ 「WP Smush.it」プラグインの導入
いわゆる「Webサイトパフォーマンスの最適化手法」を適用する
3. サーバサイドが変更できない場合
• プラグインの数を減らしてHTMLの生成時間を短縮
• JavaScriptやCSSの結合とMinify化、配信画像ファイルの最適化などを考えてみる→ 「head cleaner」プラグインの導入→ 「WP Smush.it」プラグインの導入
• とにもかくにもHTTPリクエストを減らすことが先決ブラウザは1ホストあたりの同時接続数が決まっている
環境にあわせてできることから適用していく
まとめると…
• 自サイトの現状把握からはじめる
• バックエンドからやるなら、PHPの処理を高速化
• キャッシュできるものは、キャッシュさせてしまう
• 自由度が低ければ、HTMLの構造変更や画像最適化
できることからやってみましょう
配信側の都合だけではなく、利用者に優しいサイト作りを
本日はありがとうございました