私はget_theme_mod()、私のさまざまなプロジェクトでしばらくの間使用しています。WordPress v3.4のテーマカスタマイズAPIは、クライアントが使用するのに不可欠なツールであると判断し、利用可能になった時点で利用することにしました。

しばらくして、私は自分のサイトがいつもよりも少し遅くなっていることに気付き始め、特にカスタマイザーのロードにはかなり長い時間がかかりました。調査中に何度も試行錯誤を繰り返した結果、type設定を登録するときに（$wp_customize->add_setting()）からtheme_modに切り替えることにしましたoption。

これを実行し、のすべてのget_theme_mod()呼び出しを交換すると、フロントエンドの前者、特にバックエンドのカスタマイザーとは対照的に、後者のセットアップを使用すると速度が非常に大幅に向上するget_option()ことに気付きました。私はこれがなぜなのかという答えを見つけようと努力してWordPressコアを調べてきましたが、このシナリオで特定のハングアップが何であるかを見分けることはできないようです。

コミュニティが非常に高く評価されるget_option()よりもはるかに高速に実行することに関して持つ可能性のある洞察get_theme_mod()。

はい、theme_mod関数は遅くなりますが、それほど大きくはないという答えと、違いよりも利点のほうが重要です。

テーマmodはオプションとして保存されます。したがって、本質的に、theme_mod関数はオプション関数のラッパーです。

まず、theme_modの設定は、特定のテーマ名をキーとする単一のオプションの配列として保存されることを理解してください。したがって、これを行うと：

set_theme_mod('aaa',123);
set_theme_mod('bbb',456);

その後、実際にデータベースで取得するのは、（ 'aaa' => 123、 'bbb' => 456）のシリアル化された配列を含むtheme_mods_themenameという名前の単一オプション行です。

さて、get_theme_modそれは実際には二つ作っているので、遅くなりますget_option呼び出しを。まず、テーマの名前を取得します。次に、theme_mods_themenameオプションを取得します。そのため、速度が50％低下します。行われた残りの作業は主にフィルターにあり、追加のフィルターコールがありますが、そのフィルターで何かを持っている場合を除き、これは少し重要です。

オプションシステムは取得したデータをオブジェクトキャッシュに保存するため、ここでは複数のデータベース呼び出しを行っていないことに注意してください。最初に使用した場合のみ、データベースにヒットします。

set_theme_modそれはそれは別となり、これらの同じ2つのgetオプションの呼び出しを行うので、多少遅くなりますget_option再びテーマ名を取得するための呼び出しをした後、それがないupdate_option今、変更オプションのフルセットで。これによりデータベースの更新が発生し、大量のデータを送信しているという事実が実際に顕著な減速の原因になります。数バイトの更新は、大きな行の更新よりも高速です。ただし、通常は気づくほどではありません。たくさんの設定がある場合を除き...

テーマmod関数は、おそらく全体的な最適化が原因であると考えられますが、子テーマのため、get_optionなどの代わりに引き続き使用する必要があります。

オプション行を直接使用する場合の問題は、オプション行を直接使用し、設定に特定のキー名を使用することです。

「AAA」というテーマがあり、そのテーマの別のサイトで使用する「BBB」という子テーマを作成する場合、「AAA」テーマでは「example」という名前のオプションを使用できます。1つのサイトを更新し、それがオプションを更新すると、同じオプションが子テーマに適用されるようになります。そうしたくない場合はどうすればよいですか？子テーマで別のオプション設定セットを使用する場合はどうなりますか？

キーの一部として実際のテーマ名（ハードコーディングされた値ではなく）を含めることにより、テーマmodは、サイト上の各「テーマ」が独自の設定セットを使用するようにします。私は前後に切り替えることができ、設定はそれらの間で転送されず、それらは私がそれらを設定した方法のままです。よりシンプルで、より明確で、より直感的です。

また、将来のコアの変更またはプラグインによってtheme_modsの動作が変更された場合は、変更することなく自動的にその利点が得られます。ラッパーは常に遅くなりますが、それは避けられない、ラッパーの性質です。それでも、あなたはまだ機械語ではなくPHPコードを書いています。このようなラッパーを使用して、物事を簡素化し、機能を分離します。テーマは、オプションがデータベースにどのように格納されるか、または命名がどのように機能するかを知っている必要はありません。theme_mod関数は、より簡潔でシンプルなソリューションを提供します。

get_theme_modはの単なるラッパーget_optionです。理論的には抽象化の別の層であるため、動作は遅くなりますが、実際には違いは人間が気付くほど大きくないはずです。

theme_modフックにいくつかの遅いコードがフックされている場合、実際の速度の違いが発生する可能性があります。

その場合、カスタマイザーで何かが発生する可能性がありますか？私はここでOPと同じことを見ています。

切り替えたとき、私はと約30の選択肢の私のカスタマイザーのロード時間が.5sの周りに、3S周りから落ちたことを確認することができるget_optionオーバーget_theme_mod

メソッドを直接呼び出すと、2ミリ秒の違いがあります。

（https://gist.github.com/anonymous/d98a46d00d52d40e7dec）

APIを直接比較する場合、目立たないかもしれませんが、カスタマイザーでのAPIの使用方法には何かがあるはずです。

次のコードを使用して（100回の反復）時間をテストできget_optionます（入力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開発者はそれをよく知っているかもしれません） 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でパフォーマンスとクエリ数を確認できます