Saya telah menggunakan get_theme_mod()beberapa waktu di berbagai proyek tambang. Saya memutuskan untuk memanfaatkan API Kustomisasi Tema di WordPress v3.4 begitu tersedia karena saya merasa itu adalah alat yang sangat diperlukan oleh klien saya untuk digunakan.

Setelah beberapa waktu, saya mulai memperhatikan bahwa situs saya terasa sedikit lebih lambat dari biasanya, dan Customizer membutuhkan waktu yang cukup lama untuk memuat. Melalui banyak trial and error selama investigasi saya, saya memutuskan untuk mencoba mematikan typeketika mendaftarkan pengaturan saya (yaitu $wp_customize->add_setting()) dari theme_modke option.

Setelah saya melakukan ini dan mengganti semua get_theme_mod()panggilan saya get_option(), saya perhatikan peningkatan yang sangat signifikan dalam kecepatan menggunakan pengaturan yang terakhir sebagai lawan dari yang pertama di frontend dan terutama di Customizer di backend. Saya telah mencari di inti WordPress dalam upaya untuk mencoba dan mencari tahu jawaban mengapa ini terjadi, tetapi sepertinya tidak bisa membedakan apa yang menjadi penyebab utama dari skenario ini.

Wawasan apa pun yang mungkin dimiliki masyarakat sehubungan dengan get_option()kinerja secara signifikan lebih cepat daripada get_theme_mod()akan sangat dihargai.

Jawabannya ya, fungsi theme_mod akan lebih lambat, tetapi tidak signifikan, dan manfaatnya lebih besar daripada perbedaannya.

Mod tema disimpan sebagai opsi. Jadi, pada dasarnya, fungsi theme_mod adalah pembungkus di sekitar fungsi opsi.

Pertama, pahami bahwa pengaturan theme_mod disimpan sebagai array dalam satu opsi, dikunci dengan nama tema tertentu. Jadi, jika saya melakukan ini:

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

Lalu apa yang sebenarnya saya dapatkan di database adalah baris opsi tunggal dengan nama theme_mods_themename yang berisi array serial dengan ('aaa' => 123, 'bbb' => 456) di dalamnya.

Sekarang, get_theme_modakan lebih lambat karena itu sebenarnya membuat dua get_optionpanggilan. Pertama, ia mendapat nama temanya. Kemudian, ia mendapat theme_mods_themenameopsi. Jadi di sana itu adalah kehilangan kecepatan 50%. Sisa pekerjaan yang dilakukan sebagian besar terletak pada filter, karena ada panggilan filter tambahan, tetapi kecuali Anda memiliki sesuatu pada filter itu, ini agak tidak signifikan.

Perhatikan bahwa sistem opsi menyimpan data yang diambil dalam cache objek, jadi ini tidak membuat beberapa panggilan basis data di sini. Hanya penggunaan pertama yang menghasilkan hit database.

The set_theme_modakan agak lambat karena membuat yang sama dua get opsi panggilan mereka, maka masuk lagi get_optionpanggilan untuk mendapatkan nama tema lagi, dan kemudian melakukan update_optiondengan set lengkap pilihan sekarang berubah. Ini menyebabkan pembaruan basis data, dan fakta bahwa ia mengirimkan lebih banyak data memang dapat menjadi penyebab perlambatan yang nyata. Memperbarui beberapa byte lebih cepat daripada memperbarui baris yang lebih besar. Tapi biasanya tidak sebanyak yang Anda perhatikan. Kecuali jika Anda memiliki banyak pengaturan ...

Fungsi mod tema mungkin karena untuk optimasi secara keseluruhan, tentu saja, tetapi Anda tetap harus menggunakannya alih-alih get_option dan semacamnya karena tema anak.

Masalah dengan menggunakan baris opsi secara langsung adalah Anda menggunakannya secara langsung dan menggunakan nama-nama kunci spesifik untuk pengaturan Anda.

Jika saya memiliki tema yang disebut "AAA" dan saya membuat tema anak yang disebut "BBB" untuk digunakan di situs lain, maka tema "AAA" saya mungkin menggunakan opsi bernama "example". Ketika saya memperbarui satu situs, dan itu memperbarui opsi saya, maka opsi yang sama sekarang akan berlaku untuk tema anak saya. Bagaimana jika saya tidak ingin melakukannya? Bagaimana jika saya ingin tema anak menggunakan set pengaturan opsi yang berbeda?

Mod tema, dengan memasukkan nama tema aktual (dan bukan nilai yang dikodekan) sebagai bagian dari kunci memastikan bahwa setiap "tema" di situs menggunakan set pengaturannya sendiri. Saya dapat beralih bolak-balik dan pengaturan tidak mentransfer di antara mereka, mereka tetap bagaimana saya mengaturnya. Lebih sederhana, lebih jelas, lebih intuitif.

Dan jika beberapa perubahan inti atau plugin di masa depan memodifikasi cara kerja theme_mods, maka Anda akan secara otomatis mendapatkan manfaatnya tanpa perubahan apa pun. Pembungkus akan selalu lebih lambat, itu tidak bisa dihindari, itu adalah sifat pembungkus. Meskipun demikian, Anda masih menulis kode PHP, bukan bahasa mesin. Kami menggunakan pembungkus seperti ini untuk menyederhanakan hal-hal dan memisahkan fungsi. Tema seharusnya tidak perlu tahu, atau peduli, bagaimana pilihan mereka disimpan dalam database, atau bagaimana penamaan itu bekerja. Fungsi theme_mod memberikan solusi sederhana yang lebih bersih.

get_theme_modhanyalah pembungkus di sekitar get_option. Secara teori karena ini adalah lapisan abstraksi lain, ia akan bekerja lebih lambat, tetapi dalam praktiknya perbedaannya tidak cukup besar untuk diperhatikan oleh manusia.

Perbedaan kecepatan yang sebenarnya dapat disebabkan jika Anda memiliki beberapa kode lambat yang dikaitkan pada kait theme_mod.

Mungkinkah ada sesuatu yang terjadi di Customizer? Saya melihat hal yang sama dengan OP di sini.

Saya dapat mengonfirmasi bahwa dengan sekitar 30 opsi, waktu pemuatan Customizer saya turun dari sekitar 3s, menjadi sekitar .5s saat beralih ke get_optionselesaiget_theme_mod

Memanggil metode secara langsung saya melihat perbedaan 2ms.

( https://gist.github.com/anonymous/d98a46d00d52d40e7dec )

Ini mungkin tidak terlihat ketika Anda membandingkan API secara langsung, tetapi harus ada sesuatu dengan bagaimana mereka digunakan di Customizer.

Anda dapat MENGUJI WAKTU dari get_option(100 iterasi) menggunakan kode ini (dimasukkan functions.phpatau di suatu tempat):

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;
}   

Pikiran lain

Saya tidak tahu, jika itu membuat perbedaan (mungkin pengembang Wordpress tahu lebih baik), tapi saya pikir, bahwa jika sebuah situs web memiliki lalu lintas yang TINGGI, dan pada setiap halaman memuat, perlu mendapatkan ratusan opsi, lalu bagaimana jika saya akan bergabung banyak pilihan menjadi satu get_option? seperti ini:

update_option('my_extra_optss',  array(
      'myNAME' => 'George',
      'myAGE'  => 43 ));

kemudian :

$x = get_option('my_extra_optss');
$x['myNAME'];
$x['myAGE'];
................

apakah ini akan membuat situs sedikit lebih cepat?

TL; DR: Jika Anda seorang pengembang tema, Anda harus menggunakan get_theme_mod

Jawaban lengkap:

Jika Anda memiliki 100 panggilan get_option, dibutuhkan 100 kueri ke basis data Anda.

Jika Anda memiliki 100 panggilan get_theme_mod, hanya dibutuhkan 1 permintaan ke basis data Anda.

Mengapa? Karena semua mod tema disimpan dalam satu baris basis data dan akan dipanggil hanya satu, sementara setiap opsi adalah satu baris dan 100 panggilan get_option akan menghasilkan 100 permintaan basis data dan tentu saja, ini memperlambat situs Anda.

Jika tema Anda memiliki banyak opsi, gunakan get_theme_mod akan mengurangi secara signifikan nomor permintaan Anda ke basis data.

Anda dapat memeriksa kinerja dan jumlah permintaan dengan Plugin Monitor Permintaan