get_option（）とget_theme_mod（）：なぜ遅いのでしょうか。
私は私のさまざまなプロジェクトでしばらくget_theme_mod()を使っています。私はそれが私のクライアントが使用するのに不可欠なツールであると感じたので、私はそれが利用可能になればWordPress v3.4のテーマカスタマイズAPIを利用することにしました。
しばらくして、私のサイトはいつもより少し遅くなっていることに気づき始めました、そして、特にカスタマイザはロードするのにかなり長い時間がかかりました。私の調査の間に多くの試行錯誤を経て、私は設定（すなわち$wp_customize->add_setting()）をtheme_modからtypeに登録するときにoptionを切り替えることを試みることにしました。
これを実行してget_theme_mod()へのget_option()呼び出しをすべて入れ替えたところ、前者のフロントエンド、特にカスタマイザーの設定とは対照的に、後者の設定を使用して非常に重要な速度が向上しました。バックエンド私はWordPressのコアを調べて、これがなぜなのかという答えを見つけようとしていますが、このシナリオで特定のハングアップが何であるかを見分けることはできません。
get_option()がget_theme_mod()よりも著しく速いパフォーマンスに関してコミュニティが持っているかもしれないどんな洞察も大いに感謝されるでしょう。
そうです、その答えは、theme_mod関数は遅くなりますが、それほど大きくはなく、その利点は違いを上回ります。
テーマ改造はオプションとして保存されます。したがって、本質的には、theme_mod関数はoptions関数のラッパーです。
まず、theme_mod設定は、特定のテーマ名に合わせて、単一のオプションに配列として格納されていることを理解してください。だから、私はこれをすれば：
set_theme_mod('aaa',123);
set_theme_mod('bbb',456);
それで私が実際にデータベースに入れるのは、その中に（ 'aaa' => 123、 'bbb' => 456）がある直列化された配列を含むtheme_mods_themenameという名前の単一のオプション行です。
get_theme_modは実際には2つのget_option呼び出しを行うので遅くなります。まず、テーマの名前を取得します。それから、それはtheme_mods_themenameオプションを取得します。だからまさにそこに50％のスピードロスがあります。残りの作業は、追加のフィルタ呼び出しがあるという点で、主にフィルタにありますが、そのフィルタに何かがない限り、これはあまり意味がありません。
オプションシステムは取得したデータをオブジェクトキャッシュに保存するので、ここで複数のデータベース呼び出しを行うことはありません。最初の使用のみでデータベースがヒットします。
set_theme_modは、同じ2つのget options呼び出しを行い、次にテーマ名をもう一度取得するために別のget_option呼び出しを行い、次に変更されたオプションのフルセットを使用してupdate_optionを行うため、やや遅くなります。これはデータベースの更新を引き起こします、そしてそれがより多くのデータを送っているという事実は確かに顕著な減速の原因になり得ます。数バイトを更新する方が大きな行を更新するよりも速くなります。しかし、あなたが気づくほどではありません、通常。たくさんの設定が揃っていない限り….
テーマのmod関数は、おそらく全体的に最適化されているはずですが、それでもやはりget_optionなどの代わりにそれらを使用する必要があります。それは、子テーマのためです。
オプション行を直接使用することの問題点は、オプション行を直接使用し、設定に特定のキー名を使用していることです。
私が "AAA"というテーマを持っていて、それに "BBB"という子テーマを別のサイトで使用するようにした場合、私の "AAA"テーマは "example"というオプションを使用するでしょう。あるサイトを更新したときに自分のオプションが更新されると、同じオプションが自分の子テーマにも適用されます。そうしたくなかった場合はどうしたらいいですか？子テーマに別のオプション設定を使用させたい場合はどうすればよいですか？
テーマの変更は、キーの一部として実際のテーマ名（ハードコードされた値ではない）を含めることで、サイト上の各 "テーマ"がそれぞれ独自の設定を使用するようにします。私は前後に切り替えることができ、設定はそれらの間で転送されず、それらは私が設定した方法のままです。より単純で、より明白で、より直感的です。
そして、将来のコアの変更やプラグインがtheme_modsの動作方法を変更しても、何も変更しなくても自動的にその利点が得られます。ラッパーは常に遅くなるでしょう、それは避けられない、それはラッパーの性質です。それにもかかわらず、あなたはまだ機械語ではなくPHPコードを書いています。物事を簡素化し、機能を分離するために、このようなラッパーを使用します。テーマは、それらのオプションがデータベースにどのように格納されているか、または命名がどのように機能するかを知っている、または気にする必要はありません。 theme_mod関数は、よりクリーンなより簡単な解決策を提供します。
get_theme_modはget_optionの単なるラッパーです。理論的には抽象化の別の層であるため、動作は遅くなりますが、実際には違いは人間に気づかれるほど大きくなるべきではありません。
Theme_modフックに遅いコードがフックされていると、実際の速度差が生じる可能性があります。
あなたは このコードを使ってget_optionのTEST THE TIME （100回の繰り返し）（functions.phpまたはどこかに置く）：
add_action('wp','My_Test');
function My_Test(){
var_dump(microtime(true));
for ($i=1; $i<100; $i++) { get_option('blogdescription'); }
var_dump(microtime(true));
for ($i=1; $i<100; $i++) { get_theme_mod('blogdescription'); }
var_dump(microtime(true));
exit;
}
もう一つの考え
違いが出ても（Wordpressの開発者はそれをよく知っているかもしれませんが）、私は知りませんが、Webサイトのトラフィックが多い場合、およびページを読み込むたびに何百ものオプションを取得する必要があると思います。 1つのget_optionに多くのオプションがありますか？このような：
update_option('my_extra_optss', array(
'myNAME' => 'George',
'myAGE' => 43 ));
その後：
$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................
これはサイトを少し速くするでしょうか？
TL; DR：テーマ開発者の場合、get_theme_modを使用する必要があります
完全な答え：
100個のget_option呼び出しがある場合、データベースへのクエリは100回かかります。
100個のget_theme_mod呼び出しがある場合、データベースへのクエリは1つだけです。
どうして？すべてのテーマmodは単一のデータベース行に格納され、1つだけ呼び出されるため、各オプションは行であり、100のget_option呼び出しは100のデータベースクエリを実行し、もちろんサイトの速度が低下します。
テーマに多くのオプションがある場合、get_theme_modを使用すると、データベースへのクエリ数が大幅に削減されます。
Query Monitor Plugin でパフォーマンスとクエリ数を確認できます
それでは、カスタマイザで何か問題があるのでしょうか。私はここでOPと同じものを見ています。
get_optionよりget_theme_modに切り替えると、カスタマイザのロード時間が約3秒から約0.5秒に約30オプション短縮されたことを確認できます。
メソッドを直接呼び出すと、2msの違いがあります。
（ https://Gist.github.com/anonymous/d98a46d00d52d40e7dec ）
APIを直接比較してもそれほど目立たないかもしれませんが、カスタマイザでAPIがどのように利用されているかについては何かがあるはずです。