たいしたことではないのですが、WordPressのフォーラムを漁っていたら、Possible improvement of get_option()というスレッドにレスが一個もついていなくて可哀想に思ったので、エントリーしておきます。
たまにどっかのWordPress系エントリーで「WordPressの負荷をなくすためにこのテンプレートタグをなくせ」という記述を見ることがよくあります。
<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_url'); ?>" />
//↓上のを下に変えると負荷が減るという記事がよくある
<link rel="stylesheet" type="text/css" href="http://example.jp/wp-content/themes/example/style.css" />
要するに、「WordPressのテンプレートタグはDBにアクセスしてるから、頻繁に変わらないものはベタ書きしちゃえ」という判断ですね。
ただ、僕の認識が正しければ、この「bloginfo削るメソッド」はあんまり意味ありません。
たとえば、WordPressのテーマファイル（single.phpとか）の一番上にこんなコードを書いて、そのページにアクセスしてみてください。
var_dump($GLOBALS["wp_object_cache"]->cache["options"]); die();
これはグローバル変数$wp_object_cacheのメンバー変数を表示して、すぐにプログラムを終了させているんですが、画像でご覧いただいてもわかるように、URLとかはすでに取得されてるんですね。
get_optionやbloginfoなどの関数は、あらかじめDBから取得したこれらの値を参照し、探している値がなければDBにアクセスするという仕様になっています。
get_optionは上に触れたエントリーにも書いていますが、パラメータにautoloadが設定されているものは自動的にDBから読み込むようになっています。これはWordPress内のどのページにアクセスしても同じことです。
これを実証するのは簡単で、こんなコードを書いてみるといいでしょう。
//データベース接続オブジェクトを破棄する
global $wpdb;
$wpdb = null;
bloginfo('url'); //出力される
bloginfo('stylesheet_url'); //出力される
//データベースにクエリを発行してみる
var_dump($wpdb->get_row("SELECT * FROM {$wpdb->posts} WHERE ID = 1"));
//Fatal Errorでプログラム終了
$wpdbというのはWordPressのデータベース接続オブジェクトで、これを利用すると好きなSQL文を発行できます。まあ、ほとんどの人はSQLが好きじゃないみたいですが。
なんにせよ、データベース接続オブジェクトを破棄しても、bloginfoは動くってことですね。ちなみに$wpdb->get_varの返り値もSQLが同じ限りはキャッシュされた気がします。
それでもオブジェクトのプロパティを呼び出すオーバーヘッドが気になるというのであれば、仕方ないですが…
ベンチマークを知っていることは重要だけど…
プログラムをかじった人間なら誰しも知っているであろう、forループ問題というのがあります。
for($i = 0; $i < count($arr); $i++){
echo $arr[$i];
}
//上のより下の方がちょっと早い（はず）
for($i = 0, $l = count($arr); $i < $l; $i++){
echo $arr[$i];
}
for文は一つ目のセクションが初期化処理、二つ目のセクションがループごとに行われる処理、３つ目のセクションがループ終了後に行われる処理であるため、配列の長さを数えるのは一回目だけにした方がいいよ、というクリシェです。
こういうのは知識として知っておいた方がいいのですが、あくまで前提を知ってはじめて役に立つことだと思います。
「bloginfo削るメソッド」なんかでも、SSL対応したときメンドクサイ（WordPressはSSLのときに自動でCSSのURLをhttps://にしてくれます）とか、そういう思わぬ弊害が現れる可能性があります。じゃあ絶対パスで書けばいいのかというと、ローカルとリモートで環境整えるのが面倒だったり。なにを重視するかによって、TIPSの生かし方も変わるということですね。
結論：毒を食らわば皿まで
以上のように、WordPressというのはいろんな人が使ってわりと揉まれているアプリケーションなので、凡人が思いつくような機能はだいたい実装されていますし、実装されていないものは遠からず実装されます。「そんなこといっても僕のほしいこんな機能がマイルストーンに入っていない！」と思っても、それはそもそも必要のないものだったり、要望自体が間違っていたり、すでにプラグインが存在したりします。
optionテーブルに入っている値を一個引っこ抜くだけの関数を排除するか否かが問われるようなシステムを運営しているなら、そもそもWordPressを使うべきかとか、PHP使うべきかというところから考えた方がいいですし（Facebookはそうですよね）、テンプレートタグという名前のグローバル関数を使いまくって、それでもなおフレームワークっぽく色々よしなにしてくれるのがWordPressのいいところだと思うので、あんまり細かいところで悩まない方がいいと思います。
それよりもクソみたいなサーバを解約するとか、ゴミみたいなプラグインを外すとか、月300円のサーバにするか980円のサーバにするかで悩んでるくらいならいっそ家にあるXPパソコンを叩き割って*nix系のOSで自分を苦しめる決断をするとか、そういうことの方が生産的な気がします。
