「チューニング」タグアーカイブ

mod_pagespeed

mod_pagespeed を試してみました

コメントを残す

Google の Apache サーバ向け高速化モジュール mod_pagespeed の最初の安定版がリリースされました。

折角なので WordPress で試してみました

mod_pagespeed の設定は、デフォルトのままです。

比べてみてもらうと分かるんですが、CSS、JS、画像のファイルサイズが小さくなってます。
幾つかの画像は、すでに Yahoo! Smush.it で最適化されているので、それほど違いがありません。
しかし、Yahoo! Smush.it を適用していない以下の画像は mod_pagespeed を通したものと通していないものでは、ファイルサイズに差が出ています。

また、CSS は Minify するだけでなく、複数 CSS を結合後、小さい画像ファイルは自動でデータURIスキーマに変換してくれたりします。

これらを、特に意識することなく勝手にやってくれるのでラクチンですね。
以下、インストール方法。
続きを読む →

WordPress をとにかく速くする (WordPress Advent Calendar 2011 20日目)

2件の返信

12月25日まで毎日ブログをつないでいく WordPress Advent Calendar 2011、20日目担当 @wokamoto です。
@mypacecreator さんに引き継いでいただきました！ドキドキ。
そんな、@mypacecreator さんのエントリはこちら。
3大「WordPressに慣れていない人がやってしまいがちだけど、こっちのほうがいいのになぁ」って思うこと

去年は PHP Advent Calendar に参加して「匿名関数と無名関数 (PHP Advent Calendar 2010 16日目)」って記事を書いたんですが、今年は WordPress Advent Calendar に参加します！

そんなわけで、(一部の)みんな大好き WordPress のハイパフォーマンスチューニングの話題。
このサイト dogmap.jp で行っている施策について書きますね。
続きを読む →

WordPress Object Cache のバックエンドに Tokyo Cabinet を利用する

コメントを残す

2.5以前の WordPress には Object Cache という機能がありました。
最近の WordPress では、この機能はデフォルトでは使えない状態になっているのですが、wp-content フォルダに object-cache.php というファイルを置き、wp-config.php に "define(’ENABLE_CACHE’,true);" を追加することで、この機能が使用できるようになります。
この object-cache.php は、WordPress のコアには含まれていないので、どこからか調達してくる必要があります。
バックエンドに何を使うかにも寄りますが、ファイルや memcached に Cache 情報を持たせるモジュールが提供されています。

参考URL:

で、この object-cache.php を書いてしまえば、Memcached やファイルだけでなく、軽量データベースライブラリ Tokyo Cabinet なんかもバックエンドのDBとして利用できるのです。
ってなわけで、レンタルサーバに Tokyo Cabinet をインストールして、WordPress から利用してみましょう。
続きを読む →

Head Cleaner (仮) で、なぜ速くなるのか？

57件の返信

WordPress Plugin には、WP-Cacheや、WordPress Super Cache と言った高速化を実現するためのプラグインが多数あります。
これらのプラグインは、本来は動的に生成している WordPress のコンテンツをサーバ上にキャッシュしておいて、サーバ負荷を減らし、クライアントからのリクエストに対して、素早く返答しようというモノです。
つまりは、サーバ側の処理（バックエンド）の高速化。

Head Cleaner (仮) は、これらのプラグインとは違い、クライアント側の処理（フロントエンド）を高速化しようと言うのが狙いです。
多分、今まで無かったタイプの高速化プラグインでは無いでしょうか？
この辺のフロントエンドの高速化の解説は、以下のエントリが詳しいです。

これらで、提案されている基本的な技法は

  • クライアント側のキャッシュを活用したり、無駄な HTTP リクエストを減らして、ネットワークボトムを解消しよう
  • ページレンダリングに関連するもの(CSS)は先に読み込ませ、関係ないもの(JavaScript)は後で読み込んで、見た目の表示を速くしよう

と言うことになります。

では、 Head Cleaner (仮) の高速化技法について、当サイトのトップページを例に検証してみましょう。
続きを読む →

Head Cleaner (仮) – ここまでのまとめ

13件の返信

さて、先日から「Head Cleaner (仮)」を、夜半になると Twitter 上で公開しては修正、機能アップを繰り返してきたのですが、盛り込みたかった機能もかなり盛り込めたので、これより熟成期間に入ります。
で、熟成期間に入る前に今までの経緯をまとめておきます。
まずは、このプラグインの基本的な動作原理。

  1. WordPress のテーマテンプレート inex.php や single.php に <?php get_header(); ?> って記述があると思いますが、これが呼ばれた時に動作を開始します。
    この時は、まだ ob_start で、バッファ取得開始するだけ。
  2. header.php の <?php wp_head(); ?> が呼ばれた時点でバッファ取得を終了し、書き出された文字列を解析して整形します。

やってることは、これだけ。
まだまだ開発途上のプラグインですが、人柱になっていただいている方々、ありがとうございます m(_ _)m
不具合は色々と出てきましたが、私は元気です。

さて、では以降は今までの経緯のまとめ。
続きを読む →

Head Cleaner (仮)

84件の返信

WordPress にプラグインをガンガンと突っ込んでいくと <head> 部に、JavaScript やら CSS やらが、ドンドン追加されて、カオスなことになってしまいます。
そんな状態の自サイトを「YSlow for Firebug」で診断してみると、とても低いスコアになったりしてガックリ来るわけです。
プラグインを外したりしたくなかったりするので、チマチマと修正したりして使っていたんですが、プラグインのバージョンアップのたびに修正するのも面倒です。

そんな折、「WordPress Head Cleaner」というプラグインを見かけました。
これは、ひょっとして <head> 部を自動でキレイにしてくれるのか？と期待してダウンロードしてみたんですが、ソースを見てガッカリ。
ついカッとなって、こんなプラグインを作ってしまいました。

ダウンロード

Head Cleaner@WordPress Plugins
または
Head Cleaner (最適化＆高速化)@JSeries

[2/24 6:00 追記] コメント蘭での、ゆりこさんからの指摘により、 Safari では拡張子が .gz の css, JavaScript を認識できないことが判明。
多分 「.gz」の Content-Type が 「text/javascript」 or 「text/css」 になっていないからだと思われます。
Ver.0.3.2 以降で、Safari に対しては gzip 圧縮されたファイルを転送しないように修正しました。
なお IE, Firefox, Opera, Chrome では、問題無いようです。

[2/25 8:00 追記]Ver. 0.4.0 から CSS もすべて結合することができるようになりました。
# ただし、デフォルトでは OFF になっています。
CSS 内の画像ファイル等への相対パスはすべて絶対パスに置き換えます。
制限事項としては、media 属性を気にせずにすべて結合し、media="screen" にしてしまうため、想定外の表示になる可能性もあります。
この辺は、後々修正します。

[2/26 12:30 追記]Ver. 0.5.x から、CSS と JavaScript をそれぞれ CSSTidy、jsmin-php で圧縮できるオプションを付けました。
また、コメント欄でのゆりこさんからの指摘により、ユーザエージェントに「AppleWebKit」を含むブラウザ（ただし chrome は除く）からのリクエストがあった場合は .gz ファイルを転送しないように修正しました。
あと、簡単な注意書きを書いた「readme_ja.txt」を同梱したので、読んでやってください。

[3/4 18:30 追記]正式版のリリース準備版を公開しました。
今まで、php ファイルを直接修正していた各種設定は、管理画面の「設定」＞「Head Cleaner」から行えます。
また、競合が報告されているプラグインと、その対処法について「readme_ja.txt」に書いてあります。
そちらも、ご一読ください。

[3/5 23:00 追記]正式版リリースしました。
続きを読む →

WordPress サイトのパフォーマンスチューニング (4)

2件の返信

さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。
DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。

しかも、ご丁寧にも APC、XCache、eAccelerator などのPHP用の各種キャッシュモジュールが使える場合は、それ用のモノも用意してあります。
これらを利用すれば、オブジェクトキャッシュ情報をファイルに書き出すのではなく、PHP用の各種キャッシュモジュールが管理する変数キャッシュ領域にセットしてくれます。
SAKURA では PHP が CGIモードで動作しているため、PHP用の各種キャッシュモジュールがイマイチ使えないので、File-Based Extension… を導入してみました。
続きを読む →

WordPress サイトのパフォーマンスチューニング (3) – 冥府魔道変 –

4件の返信

さて、前回の続き。
すっかり query 数を減らすことに執着してしまった男が、冥府魔道に迷い込んでしまったお話。

他に減らせるコストは無いか？キャッシュできる情報は無いか？しばし黙考。
そうだ！オブジェクトキャッシュでキャッシュされているデータを取っておいて、次に呼び出された時にロードすれば
良いじゃないか？
と言うわけで、wp-settings.php を読んでいると、以下の記述を発見。

if ( file_exists(WP_CONTENT_DIR . '/object-cache.php') )
	require_once (WP_CONTENT_DIR . '/object-cache.php');
else
	require_once (ABSPATH . WPINC . '/cache.php');

おぉ！cache.php を改良して wp-content 直下に object-cache.php と言う名前で置いておけば良いのか。
これなら WordPress のコアコードに手をつけないでイケる。
バージョンアップ時も安心だ。

….これが冥府魔道の入り口だとは、その時は気づきませんでした。
続きを読む →

WordPress サイトのパフォーマンスチューニング (2)

9件の返信

さて、昨日の続きです。

さて、さらにゴニョゴニョして、現在は

  • トップページ　69 queries. → 34 queries.
  • シングルページ　35 queries. → 23 queries.

になりました。
ゴニョゴニョの詳細は、また次回。

と言っておりましたので、そのゴニョゴニョの部分の説明。

一言で言えば、「投稿の付属情報のキャッシュをWebサーバにファイルとして持つ」プラグインを作りました。
まだまだ改良の余地は有りますが、とりあえず現状の状態で結構満足の行く仕上がりになってます。

このプラグインを稼動させ、キャッシュが作成された後の query数がこちら。

  • トップページ　42 queries. → 34 queries.
  • シングルページ　35 queries. → 23 queries.

確実に減ってますねぇ。いい感じです。
続きを読む →

WordPress サイトのパフォーマンスチューニング (1)

3件の返信

過去にも何度かパフォーマンスチューニングを施してきたウチのサイトですが、まだまだトップページの表示が遅い。

ひょっとすると query 数が多いんじゃないか？とは思っていたのだが、あらためて他の WordPress で作成されたサイトと比較してみると、ウチのサイトは明らかに query 数が多い。
SAKURA のレンタルサーバでは、 MySQL サーバと Apache サーバが別のサーバなので、query 数が多いのは、パフォーマンス的に不利だ。
（参照：WordPressの不要なプラグインを外してチューニングする記事のメモ (blog@browncat.org)）

これは、なんとかせねばだ。と言うことで、プラグインを止めたり改良したり、結果をキャッシュに持ったりしてみました。
続きを読む →