WordPress Performansını Optimize Etmeye Yönelik Gelişmiş Kılavuz

Bugün, WordPress İnternet'in %30'undan fazlasına güç sağlıyor. Kullanımı kolay, inanılmaz derecede popüler ve yakın zamanda hiçbir yere gitmiyor.

Ancak WordPress yavaş olabilir. Peki nasıl optimize edersiniz?

WordPress'i nasıl ayarlayacağınız ve optimize edeceğiniz hakkında birçok makale var. Aslında, WordPress'in kendisi, WordPress optimizasyonu konusunda sağlam bir kılavuz sağlar.

Çoğunlukla, bu makaleler ve öğreticiler, önbellek eklentilerini kullanma, içerik dağıtım ağlarıyla (CDN'ler) entegrasyon ve istekleri en aza indirme gibi oldukça basit ancak kullanışlı kavramları kapsar. Bu ipuçları son derece etkili ve hatta gerekli olsa da, sonunda, altta yatan sorunu çözmezler: Çoğu yavaş WordPress sitesi, kötü veya verimsiz kodun bir sonucudur.

Bu nedenle, bu makale temel olarak geliştiricilere ve WordPress geliştirme şirketlerine birçok WordPress performans sorununun altında yatan nedenleri ele almalarına yardımcı olabilecek bazı yönergeler sağlamayı amaçlamaktadır.

WordPress, geliştiriciler tarafından genellikle gözden kaçırılan birçok performans odaklı özellik sunar. Bu özelliklerden yararlanmayan kodlar, gönderileri getirmek gibi en basit görevleri yavaşlatabilir. Bu makale, yavaş WordPress performansının altında yatan bazı sorunları ele alan dört olası çözümü detaylandırmaktadır.

Gönderiler Alınıyor

WordPress, veritabanından her türlü gönderiyi alma imkanı sunar. Bunu yapmanın üç temel yolu vardır:

• query_posts() işlevini kullanma: Bu çok doğrudan bir yaklaşımdır, ancak sorun, ana sorguyu geçersiz kılmasıdır, bu da rahatsızlıklara yol açabilir. Örneğin, gönderileri aldıktan sonra bir noktada (örneğin footer.php içinde) ne tür bir sayfayla uğraştığımızı belirlemek istersek bu bir sorun olabilir. Aslında, resmi belgelerde, orijinal sorguyu geri yüklemek için ek bir işlev çağırmanız gerekeceğinden, bu işlevin kullanılmasına karşı tavsiyede bulunan bir not vardır. Ayrıca, ana sorgunun değiştirilmesi sayfa yükleme sürelerini olumsuz etkiler.

• get_posts() işlevini kullanma: Bu, neredeyse query_posts( query_posts() gibi çalışır, ancak ana sorguyu değiştirmez. Öte yandan, get_posts() varsayılan olarak sorguyu suppress_filters parametresi true olarak ayarlanmış olarak true . Bu, özellikle kodumuzda sorguyla ilgili filtreler kullanırsak tutarsızlıklara yol açabilir, çünkü bir sayfada beklemediğiniz gönderiler bu işlev tarafından döndürülebilir.

• WP_Query sınıfını kullanma: Bence bu, veri tabanından gönderileri almanın en iyi yolu. Ana sorguyu değiştirmez ve diğer WordPress sorguları gibi standart şekilde yürütülür.

Ancak veritabanıyla etkileşim kurmak için hangi yöntemi kullanırsak kullanalım, dikkate almamız gereken başka şeyler var.

Sorguyu Sınırlama

Sorgumuzun kaç gönderi alması gerektiğini her zaman belirtmeliyiz.

Bunu başarmak için posts_per_page parametresini kullanıyoruz.

WordPress, bu parametre için olası bir değer olarak -1'i belirtmemize izin verir, bu durumda sistem, tanımlanan koşulları karşılayan tüm gönderileri almaya çalışacaktır.

Yanıt olarak yalnızca birkaç sonuç alacağımızdan emin olsak bile, bu iyi bir uygulama değildir.

Birincisi, yalnızca birkaç sonucu geri almaktan nadiren emin olabiliriz. Ve yapabilsek bile, sınır belirleme, veritabanı motorunun eşleşme aramak için tüm veritabanını taramasını gerektirecektir.

Tersine, sonuçları sınırlamak genellikle veritabanı motorunun verileri yalnızca kısmen taramasını sağlar, bu da daha az işlem süresi ve daha hızlı yanıt anlamına gelir.

WordPress'in varsayılan olarak yaptığı ve performansı olumsuz etkileyebilecek bir diğer şey, yapışkan gönderiler getirmeye ve sorguda kaç satır bulunduğunu hesaplamaya çalışmasıdır.

Bununla birlikte, çoğu zaman, bu bilgilere gerçekten ihtiyacımız yoktur. Bu iki parametreyi eklemek, bu özellikleri devre dışı bırakacak ve sorgumuzu hızlandıracaktır:

 $query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Gönderileri Sorgudan Hariç Tutma

Bazen belirli gönderileri sorgudan çıkarmak isteriz. WordPress, bunu başarmanın oldukça doğrudan bir yolunu sunar: post__not_in parametresini kullanmak. Örneğin:

 $posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i < count( $query->posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Ancak bu oldukça basit olsa da, dahili olarak bir alt sorgu oluşturduğu için optimal değildir. Özellikle büyük kurulumlarda bu, yavaş tepkilere neden olabilir. Bu işlemin PHP yorumlayıcısı tarafından bazı basit değişikliklerle yapılmasına izin vermek daha hızlıdır:

 $posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i < count( $query->posts ) && $i < $posts_per_page; $i++ ) { if ( ! in_array( $query->posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

Orada ne yaptım?

Temel olarak, veritabanı motorundan bazı işleri çıkardım ve onun yerine aynı şeyi yapan ancak bellekte çok daha hızlı olan PHP motoruna bıraktım.

Nasıl?

İlk önce sorgudan post__not_in parametresini kaldırdım.

Sorgu, sonuç olarak istemediğimiz bazı gönderileri bize getirebileceğinden, posts_per_page parametresini artırdım. Bu şekilde, yanıtımda bazı istenmeyen gönderiler olsa bile, orada en az $posts_per_page istenen gönderilerin olmasını sağlarım.

Ardından, gönderiler arasında döngü yaptığımda yalnızca $posts_to_exclude dizisinin içinde olmayanları işliyorum.

Karmaşık Parametrelendirmeden Kaçınmak

Tüm bu sorgulama yöntemleri, gönderileri almak için çok çeşitli olanaklar sunar: kategorilere göre, meta anahtarlara veya değerlere göre, tarihe göre, yazara göre vb.

Ve bu esneklik güçlü bir özellik olsa da, bu parametreleştirme karmaşık tablo birleştirmelerine ve pahalı veritabanı işlemlerine dönüşebileceğinden dikkatli kullanılmalıdır.

Bir sonraki bölümde, performanstan ödün vermeden benzer işlevsellik elde etmenin zarif bir yolunu özetleyeceğiz.

WordPress Seçeneklerinden En İyi Şekilde Yararlanmak

WordPress Seçenekler API'si, verileri kolayca yüklemek veya kaydetmek için bir dizi araç sağlar. WordPress'in sunduğu diğer mekanizmaların (gönderiler veya sınıflandırmalar gibi) aşırı karmaşık olduğu küçük bilgi parçalarını işlemek için kullanışlıdır.

Örneğin, bir kimlik doğrulama anahtarı veya sitemizin başlığının arka plan rengini saklamak istiyorsak, aradığımız seçenekler bunlardır.

WordPress bize yalnızca bunları işlemek için işlevler vermekle kalmaz, aynı zamanda bunu en verimli şekilde yapmamızı sağlar.

Hatta bazı seçenekler sistem başladığında doğrudan yüklenir, bu da bize daha hızlı erişim sağlar (yeni bir seçenek oluştururken, onu otomatik olarak yüklemek isteyip istemediğimizi düşünmemiz gerekir).

Örneğin, arka uçta belirtilen son dakika haberlerini gösteren bir atlıkarıncaya sahip olduğumuz bir siteyi düşünün. İlk içgüdümüz, bunun için aşağıdaki gibi bir meta anahtar kullanmak olacaktır:

 // functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

Gördüğünüz gibi, bu yaklaşım çok basittir, ancak optimal değildir. Belirli bir meta anahtara sahip bir gönderi bulmaya çalışan bir veritabanı sorgusu gerçekleştirir. Benzer bir sonuç elde etmek için bir seçenek kullanabiliriz:

 // functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

İşlevsellik bir örnekten diğerine biraz farklılık gösterir.

İlk kod parçasında, gönderinin yayınlanma tarihi açısından her zaman en son haberleri alacağız.

İkincisinde, her yeni bir son dakika haberi olarak ayarlandığında, önceki son dakika haberlerinin üzerine yazılacaktır.

Ancak, muhtemelen her seferinde bir son dakika haberi istediğimizden, bu bir sorun olmamalı.

Ve sonunda, ağır bir veritabanı sorgusunu (meta anahtarlarla WP_Query kullanarak) daha iyi ve daha performanslı bir yaklaşım olan basit ve doğrudan bir sorguya ( get_post() çağırarak) dönüştürdük.

Ayrıca küçük bir değişiklik yapabilir ve seçenekler yerine geçici olayları kullanabiliriz.

Geçici olaylar benzer şekilde çalışır ancak bir sona erme süresi belirlememize izin verir.

Örneğin, son dakika haberi için eldiven gibi uyuyor çünkü eski bir gönderiyi son dakika haberi olarak istemiyoruz ve bu son dakika haberini değiştirme veya ortadan kaldırma işini yöneticiye bırakırsak, yapmayı unutabilir. o. Bu nedenle, iki basit değişiklikle bir son kullanma tarihi ekliyoruz:

 // functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Kalıcı Önbelleğe Almayı Etkinleştir

WordPress doğal olarak bir nesne önbelleğe alma mekanizmasına sahiptir.

Örneğin seçenekler bu mekanizma kullanılarak önbelleğe alınır.

Ancak, varsayılan olarak, bu önbelleğe alma kalıcı değildir, yani yalnızca tek bir istek süresince yaşadığı anlamına gelir. Tüm veriler daha hızlı erişim için bellekte önbelleğe alınır, ancak yalnızca bu istek sırasında kullanılabilir.

Kalıcı önbelleğe almayı desteklemek, kalıcı bir önbellek eklentisinin yüklenmesini gerektirir.

Bazı tam sayfa önbellek eklentileri kalıcı bir önbellek eklentisi ile birlikte gelir (örneğin W3 Total Cache), ancak diğerleri yoktur ve ayrı olarak yüklememiz gerekir.

Önbelleğe alınmış verileri depolamak için dosyaları mı, Memcached'i mi yoksa başka bir mekanizma mı kullanacağımız, platformumuzun mimarisine bağlı olacaktır, ancak bu şaşırtıcı özellikten yararlanmalıyız.

Biri şunu sorabilir: “Bu harika bir özellikse, WordPress neden varsayılan olarak etkinleştirmiyor”?

Bunun ana nedeni, platformumuzun mimarisine bağlı olarak bazı önbellek tekniklerinin çalışıp bazılarının çalışmamasıdır.

Örneğin, sitemizi dağıtılmış sunucumuzda barındırıyorsak, harici bir önbellek sistemi kullanmalıyız (Memcached sunucusu gibi), ancak web sitemiz tek bir sunucuda bulunuyorsa, sadece dosya sistemini kullanarak biraz tasarruf edebiliriz. önbelleğe almak.

Dikkate almamız gereken bir şey önbellek süresinin dolması. Bu, kalıcı önbelleğe alma ile çalışmanın en yaygın tuzağıdır.

Bu sorunu doğru bir şekilde ele almazsak, kullanıcılarımız yaptıkları değişiklikleri göremeyeceklerinden veya değişikliklerinin uygulanmasının çok uzun sürdüğünden şikayet edeceklerdir.

Bazen kendimizi performans ve dinamizm arasında değiş tokuş yaparken bulacağız, ancak bu engellere rağmen, kalıcı önbelleğe alma, neredeyse her WordPress kurulumunun faydalanması gereken bir şeydir.

AJAXing En Hızlı Yol

Web sitemizle AJAX üzerinden iletişim kurmamız gerekirse, WordPress sunucu tarafında isteğin işlenmesi sırasında bazı soyutlamalar sunar.

Bu teknikler, arka uç araçları programlarken veya ön uçtan form gönderimleri programlanırken kullanılabilse de, kesinlikle gerekli değilse bunlardan kaçınılmalıdır.

Bunun nedeni, bu mekanizmaları kullanmak için wp-admin klasöründe bulunan bir dosyaya istek gönderme zorunluluğumuz olmasıdır. WordPress tam sayfa önbelleğe alma eklentilerinin çoğu (tümü değilse de) ne gönderi isteklerini ne de yönetici dosyalarına yapılan çağrıları önbelleğe alır.

Örneğin, kullanıcı ana sayfamızı kaydırırken dinamik olarak daha fazla gönderi yüklersek, önbelleğe alınmanın avantajlarından yararlanacak olan başka bir ön uç sayfaya doğrudan çağrı yapmak daha iyi olur.

Daha sonra sonuçları tarayıcıda JavaScript aracılığıyla ayrıştırabiliriz.

Evet, ihtiyacımız olandan daha fazla veri gönderiyoruz, ancak işlem hızı ve yanıt süresi açısından kazanıyoruz.

WordPress'in Yavaş Olduğu Düşüncesini Yok Edin

Bunlar, geliştiricilerin WordPress için kod yazarken dikkate alması gereken birkaç tavsiyedir.

Bazen, eklentimizin veya temamızın diğer eklentilerle birlikte yaşaması gerekebileceğini veya sitemizin ortak bir veritabanı ile yüzlerce veya binlerce başka siteye hizmet veren bir barındırma şirketi tarafından sunulabileceğini unutuyoruz.

Biz sadece eklentinin nasıl çalışması gerektiğine odaklanıyoruz ve bu işlevsellikle nasıl başa çıktığına veya nasıl verimli bir şekilde yapılacağına değil.

Yukarıdan, WordPress'teki düşük performansın temel nedenlerinin kötü ve verimsiz kod olduğu açıktır. Bununla birlikte, WordPress, genel platformun hızından ödün vermeden çok daha performanslı eklentiler ve temalar oluşturmamıza yardımcı olabilecek çeşitli API'leri aracılığıyla gerekli tüm işlevleri sağlar.