Bir süredir get_theme_mod()çeşitli projelerimde kullanıyorum . Müşterilerimin kullanması için vazgeçilmez bir araç olduğunu düşündüğümden, WordPress v3.4'te Tema Özelleştirme API'sından yararlanmaya karar verdim.

Bir süre sonra, sitelerimin normalden biraz daha halsiz olduğunu fark etmeye başladım ve özellikle Customizer'ın yüklenmesi oldukça uzun sürdü. Araştırmam sırasında birçok deneme yanılma yoluyla, typeayarlarımı (yani $wp_customize->add_setting()) 'dan' theme_mode kaydederken ' den' e geçiş yapmaya karar verdim option.

Bunu yaptıktan ve tüm get_theme_mod()çağrılarımı değiştirdikten sonra, ön uçtaki ve özellikle arka uçtaki Customizer'daki ikinci kurulumun aksine ikinci kurulumu kullanarak hızda çok önemli bir artış get_option()fark ettim . WordPress çekirdeğini neden bunun için bir cevap bulmaya çalışmaktayım, ancak bu senaryoda belirli bir hangisinin ne olduğunu fark edemiyorum.

Topluluğun get_option()önemli ölçüde daha hızlı performansla ilgili sahip olabileceği her türlü anlayış get_theme_mod()çok takdir edilecektir.

Evet yanıtı, theme_mod işlevleri daha yavaş olacak, ancak önemli olmayacak ve faydalar farklılıklardan daha ağır basacaktır.

Tema modları seçenek olarak kaydedilir. Bu nedenle, theme_mod işlevleri, seçenekler işlevleri etrafındaki sarmalayıcılardır.

İlk olarak, theme_mod ayarlarının belirli bir tema adına anahtarlanmış tek bir seçenekte bir dizi olarak saklandığını anlayın. Eğer bunu yaparsam:

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

Sonra aslında veritabanında ne olsun, içinde 'aaa' => 123, 'bbb' => 456) ile serileştirilmiş bir dizi içeren theme_mods_themename adı ile tek bir seçenek satırıdır.

Şimdi, get_theme_moddaha yavaş olacak çünkü aslında ikiget_option çağrı yapıyor. İlk olarak, temanın adını alır. Sonra theme_mods_themenameseçeneği alır . İşte tam% 50 hız kaybı. Yapılan işin geri kalanı çoğunlukla filtrelerde yatar, çünkü ekstra bir filtre çağrısı vardır, ancak bu filtrede bir şey yoksa, bu biraz önemsizdir.

Sistemin alınan verileri nesne önbelleğinde sakladığına dikkat edin, bu nedenle burada birden fazla veritabanı çağrısı yapmaz. Sadece ilk kullanım bir veritabanı isabet ile sonuçlanır.

Bu set_theme_modbiraz daha yavaş olacaktır çünkü aynı iki alma seçeneği aramasını yapar, daha sonra get_optiontema adını tekrar almak için başka bir arama yapar ve sonraupdate_option şimdi değişti seçeneklerinin tamamına sahip. Bu bir veritabanı güncellemesine neden olur ve çok daha fazla veri göndermesi gerçekten de göze çarpan bir yavaşlamanın nedeni olabilir. Birkaç bayt güncelleme, daha büyük bir satırı güncellemekten daha hızlıdır. Ama genellikle fark edeceğiniz kadar değil. Çok fazla ayarın olmadığı sürece ...

Tema modu işlevleri muhtemelen genel olarak optimizasyondan kaynaklanmaktadır, ancak yine de get_option yerine bunları kullanmalısınız ve bu nedenle alt temalar.

Seçenek satırlarını doğrudan kullanmayla ilgili sorun, bunları doğrudan kullanmanız ve ayarlarınız için belirli anahtar adları kullanmanızdır.

"AAA" adlı bir temam varsa ve başka bir sitede kullanmak için "BBB" adlı bir alt tema oluşturursam, "AAA" temam "örnek" adlı bir seçenek kullanabilir. Bir siteyi güncellediğimde ve benim seçeneğimi güncellediğimde, aynı seçenek artık alt temam için geçerli olacak. Ya bunu yapmak istemezsem? Alt temanın farklı bir dizi seçenek ayarı kullanmasını istersem ne olur?

Tema modları, anahtarın bir parçası olarak gerçek tema adını (ve sabit kodlu bir değer değil) ekleyerek, sitedeki her "temanın" kendi ayar kümesini kullanmasını sağlar. İleri geri gidebilirim ve ayarlar aralarında aktarılmaz, ayarladığım şekilde kalırlar. Daha basit, daha açık, daha sezgisel.

Ve gelecekteki bir çekirdek değişiklik veya eklenti, theme_mods'un çalışma şeklini değiştirirse, herhangi bir değişiklik yapmadan bunun avantajlarından otomatik olarak yararlanacaksınız. Sarmalayıcılar her zaman daha yavaş olacaktır, bu kaçınılmazdır, sargıların doğasıdır. Bununla birlikte, hala makine dili değil, PHP kodu yazıyorsunuz. İşleri kolaylaştırmak ve işlevselliği ayırmak için böyle sarmalayıcılar kullanıyoruz. Temaların, seçeneklerinin veritabanında nasıl depolandığını veya adlandırma işleminin nasıl çalıştığını bilmesine veya bunlara dikkat etmesine gerek yoktur. Theme_mod işlevleri daha temiz ve basit bir çözüm sunar.

get_theme_mod sadece bir sarıcı get_option . Teoride, bir soyutlama katmanı olduğu için daha yavaş çalışacaktır, ancak pratikte fark, bir insan tarafından fark edilebilecek kadar büyük olmamalıdır.

Theme_mod kancalarına takılmış yavaş bir kod varsa, gerçek hız farklılıklarına neden olabilir.

O zaman Customizer'da bir şey olabilir mi? Burada OP ile aynı şeyi görüyorum.

Yaklaşık 30 seçenekle, Özelleştirici yükleme süremin 3s'den yaklaşık 5s'ye düştüğünü doğrulayabilirim. get_option overget_theme_mod

Yöntemleri doğrudan çağırarak 2 ms fark görüyorum.

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

API'leri doğrudan karşılaştırdığınızda fark edilmeyebilir, ancak Customizer'da nasıl kullanıldıklarına dair bir şey olmalıdır.

Sen edebilirsiniz TIME TEST ait get_optionbu kodu (koymak kullanarak (100 tekrarlamalar) functions.phpya da bir yere):

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

Başka Düşünceler

Bilmiyorum, bir fark yaratırsa (belki Wordpress geliştiricileri daha iyi bilir), ancak bir web sitesinin YÜKSEK trafiği varsa ve her sayfa yükünde yüzlerce seçenek alması gerektiğini düşündüm. bir seçenek birçok get_option? bunun gibi:

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

sonra :

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

bu bir siteyi biraz daha hızlı hale getirecek mi?

TL; DR: Bir tema geliştiricisiyseniz get_theme_mod kullanmalısınız

Tam cevap:

100 get_option çağrınız varsa, veritabanınız için 100 sorgu gerekir.

100 get_theme_mod çağrınız varsa, veritabanınız için yalnızca 1 sorgu gerekir.

Neden? Tüm tema modları tek bir veritabanı satırında saklandığından ve yalnızca bir tane olarak adlandırılacağından, her seçenek bir satır ve 100 get_option çağrısı 100 veritabanı sorgusuyla sonuçlanır ve elbette sitenizi yavaşlatır.

Temanızda birçok seçenek varsa, get_theme_mod kullanmak sorgu numaranızı veritabanına önemli ölçüde azaltır.

Query Monitor Eklentisi ile performans ve sorgu sayısını kontrol edebilirsiniz