WordPress Site Hızlandırma: Uygulamada Yapılacaklar

WordPress Site Hızlandırma: Uygulamada Yapılacaklar

Bir WordPress sitesini hızlandırmak için ilk adım ölçüm, sonra sırasıyla düzeltme yapılır: sunucu yanıt süresi ve sayfa önbelleği, sonra ağır hero resim, sonra rendering'i engelleyen CSS ve JavaScript, sonra veritabanı ve eklenti yükü. Çoğu yavaş site, bunların hepsiyle değil, sadece ikisinden veya üçünden etkilenir. PageSpeed Insights'ı en yavaş şablonunuzda çalıştırın, Largest Contentful Paint öğesini not edin ve bu listeyi, sayı yeşile dönene kadar takip edin.

Temeli Yoksa Yanlış Şeyi Hızlandırırsınız

Temel olmadan hız yapısı kaynama suyunda su boşaltmaktır. Hiçbir eklentiyi dokunmadan önce, en yavaş gerçek şablonunuzda (genellikle büyük hero görseli olan bir gönderi veya WooCommerce ürün sayfası) üç sayıyı kaydedin: Largest Contentful Paint, Interaction to Next Paint ve Time to First Byte. Mobil ayarlarında test edin, çünkü "benim makinamda hızlı" ile "müşterinin ziyaretçileri için hızlı" arasındaki fark burada ortaya çıkar.

Hedefler yayınlanmış, söylenti değil. Google'ın web.dev rehberine göre LCP 2,5 saniye veya daha az, gerçek ziyaretlerin 75. yüzdeliğinde iyi sayılır. INP 200 milisaniyenin altında kalmalı, layout shift 0,1 altında olmalı. Bu sayıları monitorunuzun yanında yapışkan kağıda yazın.

Lighthouse gibi lab araçları size tekrarlanabilir bir ölçü sağlar. Chrome User Experience Report'tan alınan alan verileri, PageSpeed Insights'ın başında gösterilir, ziyaretçilerin aslında ne elde ettiğini söyler. İkisi anlaşmazlığa düşerse, alan verisine güvenin ve lab çalıştırmasını nedeni bulmak için kullanın.

Kenar Notu: Bu iş sırası WordPress 6.5 ve sonrası için geçerli. Eski kurulumlar bunun öncesinde düzeltilecek daha çok şeye sahip.

Sunucuyu Önce Düzeltin: Hosting, PHP ve First Byte Süresi

Her ön-uç numarası ilk yanıtın üzerine oturur. HTML'in gelmesi 1,5 saniye alırsa, görüntü sıkıştırması LCP'nizi kurtarmaz. First Byte Süresi, zayıf bir ana sunucu, güncel olmayan PHP dalı veya her istek üzerine yeniden oluşturulan bir sayfayı ortaya çıkaran sayıdır.

Sırasıyla üç şeyi kontrol edin. Şu anda desteklenen bir PHP dalı çalıştırın, her sürüm son sürümden ölçülebilir şekilde istek başına daha ucuz olduğundan. Ana sunucunun ısrarlı bir nesne önbelleği sunduğunu (Redis veya Memcached) doğrulayın, çünkü seçenekler, menüler ve sorgular için tekrarlanan veritabanı okumalarını kaldırır. Ve planın kendisine bakın: yüz komşu ile paylaşılan bir sunucu trafiğin çıktığı tam anda sizi azaltacak.

Birçok istemci sitesini yönetiyorsanız, bu yönetilen hosting'in ücretini kazandığı yerdir. Hosting, önbelleğe alma ve performans hedefini bir pakette sunan bir platform, tahmin kategorisinin tamamını kaldırır. 10Web, WordPress'i Google Cloud'da barındıran ve kutudan çıktığı gibi 90+ PageSpeed puanı hedefleyen bir örnek, bağlı opsiyonları olmayan küçük bir ajans için makul varsayılandır.

Önbelleğe alma etkinleştirmeden önce daha büyük bir plan satın almak cazibesini atlatın. Önbelleğe alınmamış sayfaları sunmak için donanım yükseltmek, aynı savurgan işi daha hızlı yapmak için daha fazla ödenmektir.

Tam Sayfa Önbelleğini Açın ve Gerçekten Çalışıp Çalışmadığını Kontrol Edin

WordPress her PHP ve MySQL ile her istek üzerine her sayfayı oluşturur. Sayfa önbelleği, bitmiş HTML'i kaydeder ve bu dosyayı sunmak yerine kullanır. Blog, broşür sitesi veya portföy gibi çoğunlukla okunandan oluşan bir site için, bu tek değişiklik sıklıkla TTFB'yi saniyelerden milisaniyelerine taşır.

Tek bir sayfa önbelleğe alma katmanı seçin ve yalnızca bir tane. Host düzeyinde önbellek, önbelleğe alma eklentisi ve CDN önbelleğini, hangisinin isteği sunduğunu bilmeden istiflemek, bütün öğleden sonra bayat içeriği ayıklamakla sonuçlanır. Herhangi bir şey yüklemeden önce ana sunucunuzun zaten neyi sağladığını sorun.

Sonra önbelleğin çalışıp çalışmadığını doğrulayın. Tarayıcının ağ panelini açın, halka açık bir sayfayı iki kez yeniden yükleyin ve yanıt başlıklarını okuyun. Çoğu önbellek bir hit veya miss duyurur ve çoğu bir yaş değeri ekler. Sadece miss görüyorsanız, önbelleğiniz bir çerez, sorgu dizesi veya oturum açmış durum tarafından atlanır ve "optimizasyon" dekor.

Mağazalar ekstra dikkat gerektirir. Sepet, ödeme ve hesap sayfaları hiçbir zaman önbelleğe alınmamalı ve WooCommerce siteleri genellikle bu hariçtutmaları bilen bir önbellek eklentisine bağlıdır. Hariçtutmaları yanlış anlarsanız müşteriler birbirlerinin sepetlerini görürler, bu yavaş sayfadan daha kötü bir sorun.

Hero Resmi Küçültün, LCP'nin Geleneksel Suçlusu

Çoğu yavaş WordPress sayfasında, LCP öğesi bir görüntüdür: bir hero, öne çıkan görüntü veya tam genişlikli bir afiş. Bu görüntü ağırlığını en yaygın tek başarısızlık nedenini yapar. Bir kameradan doğrudan aktarılan ve 1200 piksellik bir sütunda gösterilen 4000 piksellik geniş JPEG, düzenin kullanabileceğinden birkaç kat daha fazla bayt gönderir.

Görüntü boru hattını sırasıyla çalışın:

• Düzenin gerçekten görüntülediği en büyük boyuta, tasarımcının dışa aktardığı boyuta değil, yeniden boyutlandırın.

• WebP veya AVIF sunun, her ikisi de WordPress çekirdeği birkaç yayın için işledi.

• Tek geniş dosyayı sabit kod yapmak yerine, çekirdeğin yanıt veren srcset varyantlarını oluşturmasına izin verin.

• Hero'yu tembel yüklemeyin. Çekirdek WordPress 6.3'ten beri ilk içerik görüntüsünde tembel yüklemeyi atladı ve ona fetchpriority="high" ekledi, bu nedenle temanız veya eklentiniz bunu geri alıp almadığını kontrol edin.

• Her görüntüye açık genişlik ve yükseklik verin, böylece tarayıcı alan ayırır ve layout shift sıfır yakınında kalır.

Katlanma altında, tembel yüklemek doğru ve bedavadır. Katlanmanın üstünde, kendi kendine uygulanan gecikmedir ve "her şeyi tembel yükle" eklentisi yükledikten sonra en sık göz atan hatadır.

E-ticaret için ağırlık sıklıkla ürün fotoğrafyasından gelir. Kaynak adresinde tutarlı, sağ boyutlu görseller üretmek, yüzlerce büyükçe dosyayı sonradan sıkıştırmaktan daha ucuz ve Klayn gibi yapay zeka ürün fotoğrafyası platformu bir ürün fotoğrafını sahneler kümesine çevirir, bu nedenle herhangi bir şey medya kütüphanesine ulaşmadan önce boyutları planlayabilirsiniz.

Rendering'i Engelleyen CSS ve JavaScript'i Kaynaktan Kesin

Sunucu ve hero sıralandıktan sonra, bir sonraki gecikme tarayıcının boyamadan önce indirmesi ve çalıştırması gerektiği şeydir. Başlıktaki her stil sayfası rendering'i engeller. Her eşzamanlı script ayrıştırmayı engeller. Sayfa oluşturucular ve çok amaçlı temalar, her özellik için, kullanıp kullanmadığını bilmeden stil ve betikler gönderdikleri için geleneksel suçlular.

Blok temalar yapısal avantaj sağlar. Çekirdek, blok sayfada göründüğünde sadece o blok için stilleri yükler, bu nedenle düz bir gönderi Query Loop veya Gallery'nin maliyetini karşılamaz. Bu, yalın Full Site Editing temasının çok başta bir başlangıç yapması nedenidir. Klasik sayfa oluşturucuları farkı kapatabilir, ancak yalnızca kullanmadığınız modülleri devre dışı bırakırsanız.

Divi adil bir test örneğidir. Divi 5, daha modern bir mimarı üzerinde yeniden inşa edilmiş ve yüzlerce modül gönderir, bu tam da neden performans ayarları, dinamik CSS ve kritik CSS gibi, teslim ettiğiniz her sitede dikkatli bir inceleme hak eder.

Pratik adımlar, risk sırasında:

• Kritik olmayan JavaScript'i erteleyin ve üçüncü taraf betikleri (sohbet widget, analitik, etiket yöneticileri) mümkün olduğunca etkileşimden sonra yükleyin.

• Katlanmanın üstündeki içerik için kritik CSS'i satır içine alın ve geri kalanını eşzamanlı olarak yükleyin, önbellek aracınız desteklerse.

• Yazı türlerini kendi barındırın, alt kümeyi yapın ve yazı türü yüklenirken metin görünür olacak şekilde font-display: swap kullanın.

• Her sayfada, bir sayfada kullanılan bir özellik için büyük bir betik yükleyen herhangi bir eklentiyi kaldırın veya değiştirin.

• Her değişiklikten sonra test edin. Agresif JavaScript erteleme, bozuk bir menü veya ölü bir ödeme düğmesinin numarası bir nedenidir.

Eklenti Yığınını Budayın ve Veritabanının Nefes Almasına İzin Verin

Eklenti sayısı zayıf bir metrik. Önemli olan her eklenti ön-uç üzerinde yükleyen ve her istek üzerinde yaptığı şeydir. Ağır bir sorgusu olan kötü yazılmış bir eklenti, iyi davranışlı otuzdan daha fazlasına mal olabilir. Sorgu Monitor'ü sahnelik kopyasında kullanın, yavaş sorguları, onları tetikleyen eklentiyi ve her birinin sıraladığı betikleri görmek için.

Sonra seçenekler tablosuna bakın. Yıllar önce kaldırılan eklentiler genellikle arkada, otoyükleme için işaretlenen satırlar bırakır, bu, WordPress her istek üzerinde onları belleğe okuduğu anlamına gelir. Site Health, otoyüklenen seçenekler yaklaşık 800 KB'ye ulaştığında bayrak taşmaya başlar. Bu uyarıyı görürseniz, en büyük satırları denetleyin ve artık çalıştırmadığınız eklentilerden kalıntıları temizleyin.

Yazı revizyon, süresi dolan geçici veriler ve yetim meta veriler zamanla ağırlık ekler, ancak bunu başlık düzeltmesi yerine bakım olarak alın. Yedekleme yapın, temizliği sahnelik üzerinde çalıştırın ve tekrar ölçün. Kazanç genellikle küçük bir sitede mütevazı ve yıllar siparişi ve oturumları olan bir mağazada önemli.

CDN ve Spekulatif Yüklemede Son Çalışma

İçerik teslim ağı statik dosyaları ve sıklıkla önbelleğe alınmış HTML'yi de ziyaretçiye yakın bir konumdan sunar. Körfez ve Kuzey Afrika'dan okunması gibi bölgeler arasında dağılmış bir kitle için, kaynak sunucusu Avrupa'da oturmasıyken kaydedilen gecikme kozmetik değil. Mesafe bir maliyettir ve CDN en ucuz yol kısaltmaktır.

WordPress 6.8 hiçbir şey malı olmayan bir şey ekledi: spekulatif yüklemesi. Ziyaretçi tıklamaya başladığında bir sayfayı ön almak için Speculation Rules API kullanır, böylece sonraki navigasyon neredeyse anlık hissettiriyor. Çekirdek ekip, daha önceki eklenti sürümü kullanan siteler, WordPress 6.8 spekulatif yükleme geliştirici notunda açıklandığı gibi, ortanca LCP geçiş oranını yaklaşık yüzde 1,9 geliştirdi. Site başına küçüktür ve hiçbir yapılandırma ile gelir.

Çekirdek, güzel permalinkli siteler üzerinde oturum açmamış ziyaretçiler için etkinleştirir. Eklenti düz GET isteğinde durumu değiştiren eylem URL'lerini kullanırsa, tıklama wp_speculation_rules_href_exclude_paths filtresini kullanarak bu yolları karşılaştırın, ayarı daha istekli yapmadan önce. Sepetlerinizi ve analitiklerinizi kontrol ettikten sonra varsayılan kalana kadar kalın.

Tuş Çekmek Nerede Durmalısınız ve Önce Hangi Düzeltmeyi Çalıştırmalısınız

Daha fazla WordPress ayarı ayarlandığından daha fazla maliyete vardır. Küçük bir dükkan tuş çeken caching hariçtutmaları, eklenti çatışmaları ve hosting yükseltmelerle her ay savaşırsa, dürüst soru, yığının işi uyup uymadığıdır. WiziShop gibi barındırılan bir platform hız bakımından başkasının işi olduğu bir mağaza için esnekliği değiştirir ve bakım saatlerine karşı fiyatı görmek değerlidir.

İçerik siteleri, ajanslar ve RTL projeleri için WordPress doğru araç kalır ve yukarıdaki her şey yapılmaya değer kalır. Nokta, her istemcinin hattın hangi tarafında oturduğunu bilmektir.

Bugün en yavaş şablonunuzda temeli çalıştırın. TTFB 800 milisaniyenin üzerindeyse, hosting, PHP ve önbelleğe almadan başlayın. TTFB sağlıklı ancak LCP başarısız olursa, şelalesi açın ve hero görüntüsünü bulun. Her ikisi de geçerse ve etkileşim yavaşsa, JavaScript ve eklenti yığınına bakın. Sizin en kötü sayfanız bu üçten hangisinde başarısız oluyor?