WordPress Site Hızlandırma: Core Web Vitals İçin Adım Adım Rehber

WordPress sitenizin yavaş açıldığını biliyorsanız ama nereden başlayacağınızı bilmiyorsanız, doğru yerdesiniz. Hız, hem Google'ın sayfa deneyimi sinyallerinin hem de ziyaretçi sabrının ölçüsüdür. Bu rehberde Core Web Vitals'ı nasıl ölçeceğinizi ve WordPress'te en çok fark yaratan düzeltmeleri öncelik sırasıyla anlatıyoruz.

Core Web Vitals nedir? Üç metrik, üç eşik

Core Web Vitals, gerçek kullanıcı deneyimini ölçen üç metriktir. Google'ın iyi kabul ettiği eşikler şöyledir:

• LCP (Largest Contentful Paint): Sayfanın en büyük içeriğinin görünme süresi. İyi eşik 2,5 saniye ve altıdır.
• INP (Interaction to Next Paint): Tıklama ve dokunmalara yanıt verme hızı. İyi eşik 200 milisaniye ve altıdır. INP, eski FID metriğinin yerini almıştır.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken içeriğin kayması. İyi eşik 0,1 ve altıdır.

Metriklerin tanımları ve güncel eşikler için web.dev Core Web Vitals sayfasına bakabilirsiniz. Ölçümler sayfa yüklemelerinin büyük çoğunluğunda (yüzde 75'lik dilimde) bu eşiklere ulaşmalıdır.

Google, sayfa deneyimini tek bir sinyal olarak değil, çok sayıda sinyalin parçası olarak ele alır. Dolayısıyla Core Web Vitals'ı iyileştirmek içerik kalitesinin yerine geçmez; ama iki sayfa benzer değerdeyse deneyim farkı belirleyici olabilir. Asıl kazanç genellikle dolaylıdır: hızlı sayfada ziyaretçi daha az vazgeçer, form doldurur, ürünü sepete ekler. Bu yüzden hızı yalnızca SEO değil, gelir meselesi olarak ele almak gerekir.

Önce ölçün: laboratuvar mı, gerçek kullanıcı mı?

PageSpeed Insights iki tür veri gösterir. Laboratuvar verisi tek bir simüle test sonucudur; gerçek kullanıcı verisi ise Chrome kullanıcılarından toplanır ve Search Console'daki Core Web Vitals raporunda da görünür. Sıralamada gerçek kullanıcı verisi önemlidir, düzeltmeleri denemek için ise laboratuvar verisi kullanışlıdır. Ölçümü mobil için yapın; Türkiye'de trafiğin büyük kısmı mobilden geldiği için asıl hedef orası olmalı. Skoru 100'e çıkarmaya çalışmak yerine kırmızı ve turuncu metrikleri yeşile getirmeye odaklanın.

Ölçümde sık yapılan bir hata, yalnızca ana sayfayı test etmektir. Şablon bazında düşünün: ana sayfa, blog yazısı, hizmet sayfası, ürün sayfası ve iletişim sayfası genellikle farklı sorunlar taşır. Search Console benzer sayfaları gruplayarak hangi şablonların sorunlu olduğunu gösterir; düzeltmeyi tek tek sayfalara değil şablona yapın, böylece tek müdahale yüzlerce sayfayı iyileştirir. Düzeltme sonrasında gerçek kullanıcı verisinin güncellenmesi yaklaşık dört hafta sürebilir; bu sürede laboratuvar verisini kullanın.

Sunucu ve hosting: her şeyin temeli

Sunucu yanıt süresi (TTFB) yüksekse, tüm optimizasyonlar bunun üstüne eklenir. Şunları kontrol edin:

• Güncel bir PHP sürümü ve OPcache kullanımı
• Hedef kitleniz Türkiye ise Türkiye'ye veya Avrupa'ya yakın veri merkezi ve CDN
• Sayfa önbelleği (sunucu seviyesinde ya da güvenilir bir önbellek eklentisiyle)
• Dinamik sitelerde Redis veya Memcached gibi object cache
• Paylaşımlı hostingte sınırlı CPU ve bellek; yoğun sitelerde VPS veya yönetilen WordPress hostingi

Hosting seçerken yalnızca fiyata değil, TTFB'ye ve yük altındaki davranışa bakın. Aynı eklentilerle farklı sunucularda ölçüm yapıp karşılaştırmak, sorunun sunucuda mı kodda mı olduğunu hemen ortaya çıkarır. Bir CDN statik dosyaları kullanıcıya yaklaştırır; ancak yanlış yapılandırılmış önbellek kuralları giriş yapmış kullanıcıya yanlış içerik göstermek gibi sorunlar çıkarabilir, bu yüzden dinamik sayfalar için kuralları dikkatle tanımlayın. Hedef kitle Türkiye ise sunucunun Türkiye'de ya da Avrupa'da olması çoğu zaman yeterli gecikmeyi sağlar.

Üç metrik için pratik düzeltmeler

LCP: görseller ve ilk ekran

WordPress sitelerinde LCP elemanı çoğunlukla ana sayfadaki büyük görsel veya slider'dır. Bu görseli doğru boyutta sunun, WebP veya AVIF gibi modern biçimlere çevirin ve ilk ekrandaki görselde lazy load'u kapatın; bu görsele öncelik vermek (fetchpriority) yükleme sırasını iyileştirir. Aşağıdaki görsellerde ise lazy load kullanın. Ağır slider eklentileri ve video arka planlar LCP'nin en sık nedenlerindendir; mümkünse tek bir statik görsele geçin. LCP'yi derinlemesine optimize etmek için web.dev LCP optimizasyon rehberini önerebiliriz.

INP: JavaScript yükünü azaltın

INP düşükse ana iş parçacığı meşgul demektir. WordPress'te suçlular genellikle şunlardır: kullanılmayan eklentilerin her sayfada yüklediği script'ler, chat widget'ları, takip pikselleri, etiket yöneticisi içinde birikmiş etiketler ve ağır sayfa oluşturucu animasyonları. Her üçüncü taraf script'in karşılığını sorgulayın; gerekmiyorsa kaldırın, gerekiyorsa ertelenerek yüklenmesini sağlayın. Eklentileri sayfa bazında devre dışı bırakma imkanı sunan araçlar işe yarar, ama daha temiz çözüm baştan az eklentiyle kurmaktır.

Gerçek kullanıcı verisinde INP kötü ise sorunlu etkileşimi bulmak için Chrome DevTools'taki Performance panelinden uzun görevleri (long tasks) inceleyin. Menü açılışı, filtreleme ve form gönderimi gibi etkileşimlerde ana iş parçacığını bloke eden kodu bulun; çoğu zaman suçlu, bir eklentinin tıklamada çalışan ağır script'idir. web.dev INP optimizasyon rehberi adım adım yöntemleri anlatır. Çerez onay araçları da INP ve CLS üzerinde etkilidir; KVKK uyumu için gerekli olsa da hafif ve sayfa düzenini kaydırmayan bir çözüm seçin.

CLS: boyutları ve yer tutucuları belirleyin

Kayma çoğunlukla boyutu belirtilmemiş görsellerden, geç yüklenen reklam ve gömülü içeriklerden ve web fontunun değişmesinden doğar. Çözümü basittir: görsel ve iframe'lere genişlik ve yükseklik verin, çerez bannerı gibi sonradan beliren öğeler için yer ayırın, fontları kendi sunucunuzdan sunup font-display kullanın ve yalnızca gerçekten kullandığınız ağırlıkları yükleyin.

Font kaynaklı kaymada, yedek fontun ölçülerini web fontuna yaklaştırmak (size-adjust gibi CSS özellikleri) görünür kaymayı azaltır. Animasyonlarda yerleşimi tetikleyen özellikler (genişlik, yükseklik, üst boşluk) yerine transform ve opacity kullanın. Hangi elemanın kaymaya neden olduğunu Chrome DevTools'taki Performance panelinden ve PageSpeed Insights'tan görebilirsiniz. İyileştirme için web.dev CLS rehberi iyi bir kaynaktır.

Tema, sayfa oluşturucu ve eklenti disiplini

Her eklenti ek CSS, JS ve sorgu demektir. Kullanmadığınız eklentileri silin (devre dışı bırakmak yetmez), aynı işi yapan eklentileri tek çatıda toplayın ve ağır çok amaçlı temalar yerine hafif bir tema tercih edin. WooCommerce gibi dinamik sitelerde ek optimizasyonlar gerekir; bunları WooCommerce hız ve dönüşüm rehberimizde ele aldık. Hız sorunları bazen WordPress'in kendi yapısından kaynaklanır; o noktada Next.js ile WordPress karşılaştırmamız alternatifleri tartmanıza yardımcı olur.

Eklentileri değerlendirirken şu soruyu sorun: bu eklenti hangi sayfalarda ne kadar kod yüklüyor? Tarayıcı geliştirici araçlarının Network sekmesi ve Query Monitor eklentisi bu soruyu hızlıca cevaplar. Slider, form, harita ve popup eklentileri bu açıdan en pahalı olanlardır; çoğu işi birkaç satır özel kodla ya da daha hafif bir alternatifle çözebilirsiniz. Yeni bir eklenti kurmadan önce ölçüm yapın, kurduktan sonra tekrar ölçün; hız bütçesi böyle korunur.

Hız bir kez yapılıp bırakılan iş değil

Yeni eklenti, yeni kampanya script'i veya yeni bir banner skorunuzu tekrar bozabilir. Search Console'da Core Web Vitals raporunu aylık takip edin. Ölçüm, düzeltme ve izlemeyi hızlı ve SEO uyumlu mimariyle birleştiren web tasarım ve SEO hizmetlerimiz hakkında bilgi alabilirsiniz.

Paylaş:XLinkedInWhatsApp