Your SlideShare is downloading. ×
0
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
WordCamp Yokohama 2010 Komori
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

WordCamp Yokohama 2010 Komori

2,451

Published on

WordCamp Yokohama のこもりのスライド

WordCamp Yokohama のこもりのスライド

Published in: Technology, Design
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,451
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 本日はありがとうございました配信側の都合だけではなく、利用者に優しいサイト作りを

×