WordPress Site Hızlandırma: Core Web Vitals Nasıl İyileştirilir?

WordPress hızlandırma denince akla genellikle bir önbellek eklentisi kurup ayarlarını açmak gelir. Bu bazen işe yarar, bazen de siteyi bozar. Kalıcı sonuç için önce neyin yavaş olduğunu ölçmek, sonra sorunu doğru katmanda çözmek gerekir: sunucu, görseller, JavaScript, veritabanı ya da üçüncü taraf kodlar. Aşağıdaki başlıklar bu sırayı izliyor.

Core Web Vitals nedir, eşikler neler?

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini ölçmek için kullandığı üç metriktir. Her biri deneyimin farklı bir yüzünü ölçer: sayfanın ana içeriğinin ne kadar hızlı göründüğü, sayfanın etkileşime ne kadar çabuk yanıt verdiği ve yüklenirken içeriğin ne kadar kaydığı.

INP, Mart 2024'te FID'in (First Input Delay) yerini aldı. FID yalnız ilk etkileşimin başlama gecikmesine bakıyordu; INP ise ziyaret boyunca yapılan etkileşimlerin tamamını değerlendirir. Bu yüzden eskiden sorunsuz görünen, ama ağır JavaScript taşıyan pek çok WordPress sitesi INP ile birlikte kırmızıya düştü.

Eşikler 75. yüzdelik üzerinden değerlendirilir. Yani bir sayfanın iyi sayılması için ziyaretlerin en az yüzde 75'inde metriğin eşiğin altında kalması gerekir. Hızlı bir ofis bağlantısında sitenin iyi açılması, orta segment bir telefonda mobil veriyle giren kullanıcının deneyimini göstermez.

Saha verisi ile laboratuvar verisi arasındaki fark

Saha verisi, Chrome kullanıcılarından anonim olarak toplanan gerçek ölçümlerdir (CrUX, Chrome User Experience Report). Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üst bölümü bu veriyi gösterir; son 28 günün kayan ortalamasıdır, yani yaptığınız bir düzeltmenin yansıması haftalar sürer. Laboratuvar verisi ise Lighthouse gibi araçların sabit bir cihaz ve ağ profiliyle yaptığı tek seferlik simülasyondur. Hata ayıklamak için idealdir, ama sıralama ve gerçek deneyim açısından belirleyici olan saha verisidir. Lighthouse puanınız 95 olup saha verinizde INP başarısız olabilir; çünkü laboratuvar testi kullanıcı etkileşimi yapmaz.

Önce ölç: hangi araç ne söyler?

• PageSpeed Insights: Tek bir URL için hem saha hem laboratuvar verisini birlikte gösterir. Mobil sonuca odaklanın; LCP öğesinin hangisi olduğunu ve LCP süresinin hangi alt aşamada (sunucu yanıtı, kaynak yükleme, render) kaybedildiğini buradan görebilirsiniz.
• Search Console Core Web Vitals raporu: Sorunları tek tek URL yerine benzer sayfa grupları halinde verir. Hangi şablonun (ürün sayfası, blog yazısı, kategori) sorunlu olduğunu anlamanın en hızlı yoludur.
• Tarayıcı DevTools: Performance panelinde sayfayı kaydedip uzun görevleri, düzen kaymalarını ve etkileşim gecikmesini yaşayan kodu görebilirsiniz. Network sekmesinde ağ ve CPU kısıtlaması açarak yavaş bir telefonu taklit edin.
• Sunucu tarafı ölçüm: Query Monitor gibi bir geliştirme eklentisi, sayfa başına veritabanı sorgu sayısını, yavaş sorguları ve hangi eklentinin ne kadar süre harcadığını gösterir. Canlı sitede yalnız ölçüm süresince açık tutun.

Sunucu tarafı: her şey TTFB ile başlar

TTFB (Time to First Byte), tarayıcının sunucudan ilk baytı alma süresidir. Doğrudan bir Core Web Vitals metriği değildir, ama LCP'nin başlangıç noktasıdır: sunucu HTML'i geç gönderiyorsa, ön yüzde yapacağınız hiçbir optimizasyon o kaybı telafi etmez. WordPress her istekte PHP çalıştırıp veritabanını sorguladığı için TTFB en sık görülen darboğazdır.

• Güncel PHP sürümü: Hosting panelinizde desteklenen en güncel kararlı PHP sürümünü seçin. Eski sürümler hem yavaştır hem de güvenlik güncellemesi almaz. Geçişten önce test ortamında eklenti uyumluluğunu kontrol edin.
• OPcache: PHP dosyalarının derlenmiş halini bellekte tutar; her istekte kodun yeniden derlenmesini önler. Çoğu iyi hostingde açıktır, yine de Site Sağlığı ya da phpinfo çıktısından doğrulayın.
• Sayfa önbelleği: Oturum açmamış ziyaretçilere hazır HTML sunar ve PHP'yi tamamen devre dışı bırakır. Sunucu seviyesinde (Nginx FastCGI cache, LiteSpeed Cache, Varnish) yapılan önbellek, PHP ile çalışan eklenti önbelleğinden genellikle daha verimlidir.
• Nesne önbelleği (Redis): Tekrarlanan veritabanı sorgularının sonuçlarını bellekte saklar. Sayfa önbelleğinin işe yaramadığı durumlarda, yani yönetim paneli, üye alanları ve WooCommerce sepet/ödeme sayfaları için özellikle değerlidir.
• Hosting seçimi: Yüzlerce sitenin aynı kaynakları paylaştığı ucuz paylaşımlı paketlerde TTFB, komşu sitelerin yüküne göre dalgalanır. Hedef kitleniz Türkiye'deyse sunucu konumunu da hesaba katın.

LCP'yi iyileştirmek

WordPress sitelerinde LCP öğesi çoğunlukla hero görseli, kaydırıcının ilk slaytı ya da öne çıkan görseldir. İyileştirmenin ilk adımı PageSpeed Insights'ta LCP öğesinin tam olarak ne olduğunu görmektir.

LCP görselini tembel yüklemeyin

Lazy load, ekranın altında kalan görseller için doğrudur; ekranın üstündeki LCP görseli için ise zararlıdır, çünkü tarayıcı görseli ancak düzen hesaplandıktan sonra istemeye başlar. WordPress çekirdeği ilk görsellerde bunu otomatik olarak atlamaya çalışır, ama sayfa oluşturucular ve optimizasyon eklentileri bu davranışı sık sık geçersiz kılar. HTML kaynağında LCP görselinde loading=lazy olmadığını, bunun yerine fetchpriority=high bulunduğunu kontrol edin. Görsel CSS arka planı olarak veriliyorsa tarayıcı onu geç keşfeder; mümkünse gerçek bir img etiketine çevirin ya da bir preload bağlantısıyla önceden bildirin.

Görsel boyutu ve formatı

Mobilde 400 piksel genişliğinde görünecek bir alana 2500 piksellik bir fotoğraf göndermek en yaygın israftır. WordPress'in ürettiği srcset boyutlarının temanızda gerçekten kullanıldığını doğrulayın, görselleri WebP ya da AVIF formatında sunun ve yüklemeden önce makul bir boyuta küçültün. Kaydırıcıları hero alanından kaldırmak da çoğu zaman tek başına ciddi bir kazanç sağlar.

Render'ı engelleyen CSS, JavaScript ve fontlar

Başlıkta yüklenen her stil dosyası ve eşzamanlı script, sayfanın ilk çiziminin gecikmesine yol açar. Kullanılmayan eklenti stillerini yalnız gereken sayfalarda yükleyin, kritik olmayan scriptlere defer ekleyin. Fontlarda ise sadece kullandığınız ağırlıkları yükleyin, fontları kendi sunucunuzdan servis edin ve ana başlık fontunu preload ile önceden isteyin. Beş farklı ağırlıkta iki font ailesi, çoğu sitede görsellerden daha fazla gecikme yaratır.

CLS'yi iyileştirmek

• Görsellere boyut verin: img etiketlerinde width ve height öznitelikleri bulunmalı; tarayıcı yeri önceden ayırır. Aynı kural video, iframe ve gömülü içerikler için de geçerlidir.
• Font değişiminden kaynaklanan kaymayı azaltın: font-display: swap metni hemen gösterir ama web fontu geldiğinde satır uzunlukları değişebilir. Yedek fonta size-adjust, ascent-override gibi metrik ayarları vermek bu sıçramayı büyük ölçüde giderir.
• Geç yüklenen öğelere yer ayırın: Reklam alanları, çerez bannerları, duyuru şeritleri ve sonradan eklenen öneri kutuları içeriği aşağı iter. Bu alanlar için sabit minimum yükseklik tanımlayın ya da içeriğin üstüne binen katman olarak gösterin.
• Animasyonları transform ile yapın: top, height gibi düzen özelliklerini değiştiren animasyonlar kayma üretir; transform ve opacity üretmez.

INP'yi iyileştirmek

INP, tarayıcının ana iş parçacığının ne kadar meşgul olduğuyla ilgilidir. Kullanıcı bir menüye dokunduğunda ana iş parçacığı başka bir script'i çalıştırmakla meşgulse, yanıt gecikir. WordPress'te bu yükün başlıca kaynakları şunlardır:

• Sayfa oluşturucular: Görsel düzenleyicilerin çoğu, sayfada kullanılmayan bileşenler için bile kütüphane ve iç içe geçmiş derin bir DOM yapısı üretir. Büyük DOM, her etkileşimde yeniden hesaplama maliyetini artırır.
• Üçüncü taraf scriptler: Canlı sohbet widget'ları, reklam ve analitik pikselleri, ısı haritası araçları ve sosyal medya gömmeleri ana iş parçacığında ciddi süre harcar. Her birinin gerçekten kullanılıp kullanılmadığını sorgulayın; sohbet widget'ını kullanıcı düğmeye tıklayınca yüklemek gibi çözümler işe yarar.
• Uzun görevler: 50 milisaniyeyi aşan her JavaScript görevi uzun görev sayılır. Özel kod yazıyorsanız ağır işleri parçalara bölün ve aralarda tarayıcıya çizim fırsatı verin; etkileşime verilecek görsel yanıtı önce, ağır hesaplamayı sonra çalıştırın.

Eklenti yükü ve tema seçimi

Sorun eklenti sayısından çok eklentilerin ne yaptığıdır. Tek bir kötü yazılmış eklenti, on iyi yazılmış eklentiden daha fazla yavaşlatabilir. Her eklenti için şu soruları sorun: Her sayfada script ve stil yüklüyor mu? Her istekte harici bir sunucuya bağlanıyor mu? Aynı işi yapan ikinci bir eklenti var mı? Tema tarafında ise çok amaçlı, yüzlerce demo ve seçenekle gelen temalar yerine yalnız ihtiyacınız olanı yükleyen hafif bir tema ya da siteye özel geliştirilmiş bir tema uzun vadede daha az bakım ve daha iyi performans demektir. Hangi yolun sizin için doğru olduğunu değerlendirmek isterseniz WordPress geliştirme hizmetimiz sayfasına göz atabilirsiniz.

Veritabanı bakımı

• Autoload seçenekleri: wp_options tablosunda autoload olarak işaretlenen kayıtlar her sayfa isteğinde belleğe yüklenir. Kaldırılmış eklentilerin bıraktığı büyük kayıtlar bu yükü şişirir. Site Sağlığı ekranı autoload yükü fazla büyüdüğünde uyarı verir; artık kullanılmayan kayıtları temizleyin.
• Revizyonlar: Her kaydetmede yeni bir revizyon oluşur. wp-config.php içinde define( 'WP_POST_REVISIONS', 5 ); gibi bir sınır koymak tablonun sınırsız büyümesini önler.
• Süresi dolmuş transient'ler: Geçici önbellek kayıtları kalıcı nesne önbelleği yoksa veritabanında tutulur ve zamanla birikebilir. Nesne önbelleği (Redis) kullanmak bu sorunu da büyük ölçüde çözer.

CDN kullanımı

CDN, statik dosyaları (görsel, CSS, JS, font) kullanıcıya coğrafi olarak yakın sunuculardan dağıtır. Ziyaretçileriniz farklı şehir ya da ülkelerdeyse gecikmeyi belirgin biçimde düşürür. Bazı CDN'ler HTML önbelleklemeyi de destekler; bu durumda oturum açmış kullanıcıların, sepet ve hesap sayfalarının önbellek dışında tutulduğundan emin olun. Tek bir şehre hizmet veren bir sitede CDN'in etkisi daha sınırlıdır, ama güvenlik ve trafik dalgalanmalarına karşı yine de fayda sağlar.

WooCommerce sitelerine özel noktalar

• Dinamik sayfalar önbelleklenmemeli: Sepet, ödeme ve hesabım sayfaları kişiye özeldir. Bunları önbelleğe almak, bir müşterinin başka birinin sepetini görmesine kadar varan hatalara yol açar. Bu sayfaların hızını sayfa önbelleği değil, nesne önbelleği ve sunucu kaynakları belirler.
• Sepet fragments isteği: Sepet sayısını güncelleyen AJAX isteği, önbelleklenmiş sayfalarda bile her ziyarette sunucuya yük bindirebilir. WooCommerce'in yeni sürümleri bu script'i her sayfada varsayılan olarak yüklemiyor, ancak bazı temalar ve mini sepet bileşenleri onu yeniden devreye alıyor. Network sekmesinde wc-ajax=get_refreshed_fragments isteğini arayın.
• Ürün ve kategori görselleri: Kategori sayfalarında onlarca ürün görseli aynı anda yüklenir; doğru thumbnail boyutlarının kullanıldığından emin olun.
• Filtreleme eklentileri: Büyük kataloglarda katmanlı filtreler ağır sorgular üretir. Query Monitor ile sorgu sürelerini ölçün.

Mağaza tarafında hız, dönüşümü doğrudan etkileyen bir konu olduğu için altyapı kararlarını en baştan doğru vermek önemlidir; bu konuda e-ticaret hizmetimiz kapsamında destek veriyoruz.

Sık yapılan hatalar

• Optimizasyon eklentisinin tüm seçeneklerini aynı anda açmak: CSS birleştirme, kullanılmayan CSS'i kaldırma, JS geciktirme ve tembel yükleme aynı anda açıldığında bir şeyler bozulursa hangisinin sebep olduğunu bulmak zorlaşır. Seçenekleri tek tek açın ve her adımdan sonra test edin.
• JavaScript geciktirmenin etkileşimi bozması: Tüm scriptleri ilk kullanıcı hareketine kadar geciktirmek laboratuvar puanını yükseltir, ama menü, sepete ekle düğmesi ya da form ilk dokunuşta çalışmayabilir. Üstelik ilk etkileşimde bütün scriptler birden çalıştığı için INP kötüleşebilir.
• Birden fazla önbellek katmanını çakıştırmak: Hosting önbelleği, eklenti önbelleği ve CDN önbelleği birbirinden habersiz çalışırsa güncellenen içerik görünmez ya da temizleme işlemleri tutarsızlaşır.
• Yalnız Lighthouse puanını hedeflemek: Puan bir teşhis aracıdır. Hedef, Search Console'daki saha verisinin iyiye dönmesidir.
• Güvenlik ile hızı ayrı düşünmek: Zararlı kod bulaşmış siteler de yavaşlar. Beklenmedik bir yavaşlamada WordPress güvenlik açıkları ve korunma yöntemleri yazımızdaki belirtileri de kontrol edin.

Adım adım hızlandırma planı

1. Canlı sitenin tam yedeğini alın ve değişiklikleri denemek için bir test ortamı hazırlayın.
2. Search Console Core Web Vitals raporundan sorunlu sayfa gruplarını belirleyin; her gruptan bir temsilci URL seçin.
3. Bu URL'leri PageSpeed Insights ile mobilde ölçün; LCP öğesini, TTFB'yi ve başarısız metrikleri not edin.
4. PHP sürümünü güncelleyin, OPcache'in açık olduğunu doğrulayın ve sunucu seviyesinde sayfa önbelleğini etkinleştirin.
5. Dinamik içerik ya da WooCommerce varsa Redis nesne önbelleğini kurun.
6. LCP görselini düzeltin: lazy load'u kaldırın, fetchpriority=high ekleyin, boyutunu küçültüp WebP/AVIF'e çevirin.
7. Fontları sadeleştirin, kritik olmayan scriptleri defer edin, kullanılmayan eklenti stillerini sayfa bazında kapatın.
8. Görsellere ve reklam/banner alanlarına sabit boyut vererek CLS kaynaklarını giderin.
9. Üçüncü taraf scriptleri ve eklentileri tek tek gözden geçirin; gereksiz olanları kaldırın, gerekli olanları geç yükleyin.
10. Veritabanını temizleyin: autoload yükünü, revizyonları ve süresi dolmuş transient'leri kontrol edin.
11. Gerekiyorsa CDN ekleyin; oturum açmış kullanıcılar ve dinamik sayfalar için önbellek kurallarını doğrulayın.
12. Her değişiklikten sonra laboratuvar ölçümünü tekrarlayın; saha verisinin güncellenmesi için birkaç hafta bekleyip Search Console'dan düzeltmeyi doğrulayın.

Hız, arama görünürlüğünün tek başına belirleyicisi değildir; içerik, teknik yapı ve kullanıcı deneyimiyle birlikte değerlendirilir. Bu bütünü merak ediyorsanız SEO uyumlu web sitesi nedir yazımızı okuyabilir, teknik SEO ve performans çalışmaları için SEO hizmetimizi inceleyebilirsiniz. Ankara'daki ekibimizle mevcut WordPress sitenizin ölçümünü birlikte yapıp önceliklendirilmiş bir iyileştirme planı çıkarabiliriz.

Yazan: ArGetia ekibi · Ankara, Türkiye