Yavaş açılan bir sayfa, kullanıcı henüz içeriği okumadan bekletir; geç tepki veren düğme de işlemi yarıda bıraktırabilir. Bu yüzden hız çalışması hem ziyaretçi deneyimi hem teknik SEO için önemlidir. Yine de tek bir PageSpeed puanı sıralama garantisi değildir. Google, sayfa deneyimini birçok sinyal arasında değerlendirir; arama niyetini karşılamayan bir içeriği yalnızca hızlandırmak başarılı bir içerik hâline getirmez. Bu rehberde Core Web Vitals değerlerini nasıl okuyacağınızı, gerçek kullanıcı verisiyle laboratuvar testini nasıl ayıracağınızı ve WordPress’te hangi değişikliği hangi ölçümle doğrulayacağınızı anlatıyoruz.
Sayfa hızı SEO’yu hangi yoldan etkiler?
Google’ın sayfa deneyimi belgeleri, gerçek kullanıcı deneyimini ölçen Core Web Vitals değerlerinde iyi sonuçları önerir. Yüklenme, etkileşim ve görsel kararlılık kötü olduğunda kullanıcı aradığı bilgiye ulaşmakta zorlanır. Bunun arama performansındaki etkisi ise sorguya, rakip sayfalara, içerik kalitesine ve diğer sinyallere bağlıdır. “Skor 100 olursa ilk sıraya çıkarım” ya da “bir eklenti kurunca SEO biter” gibi kesin vaatler doğru değildir. Hız çalışmasını başlık, içerik, taranabilirlik ve kullanılabilirlik incelemesinin parçası olarak yürütün.
Ayrıca performans sorunu yalnızca açılış anında görülmeyebilir. Ana sayfa hızlıyken makale şablonundaki büyük kapak, ürün sayfasındaki varyasyon betiği veya ödeme adımındaki üçüncü taraf hizmet yavaş olabilir. Bu yüzden tek URL’deki laboratuvar raporunu tüm siteye genellemeyin. Şablonlara ve mobil kullanıcıların en çok ziyaret ettiği sayfalara göre bir ölçüm listesi çıkarın.
Core Web Vitals: LCP, INP ve CLS nedir?
LCP (Largest Contentful Paint), ilk görünür alandaki en büyük içerik öğesinin ne zaman gösterildiğini ölçer. Bu öğe çoğu zaman büyük kapak görseli veya metin bloğudur. İyi deneyim için hedef, ziyaretlerin en az yüzde 75’inde 2,5 saniye veya daha düşük LCP’dir. Yüksek LCP yalnızca büyük görselden kaynaklanmaz; yavaş sunucu yanıtı, geç keşfedilen kaynak, engelleyici CSS ve uzun JavaScript işleri de gecikmeye katkıda bulunur.
INP (Interaction to Next Paint), kullanıcı tıklama, dokunma veya klavye etkileşimi yaptığında sayfanın buna görünür yanıt verebilmesini ölçer. İyi eşik 200 milisaniye veya daha düşüktür. Sayfa ilk bakışta açılmış görünse bile menü geç açılıyor, arama alanı takılıyor veya sepet düğmesi tepkisiz kalıyorsa INP zayıf olabilir. Bu nedenle yalnızca ilk yükleme saniyesini iyileştirmek yeterli değildir.
CLS (Cumulative Layout Shift), beklenmedik yerleşim kaymalarını toplar. İyi eşik 0,1 veya daha düşüktür. Görsele boyut ayrılmaması, geç gelen reklam alanı veya font değişimi kullanıcının okumakta olduğu satırı kaydırabilir. Bir kullanıcı düğmeye basacakken düğmenin yer değiştirmesi doğrudan kullanılabilirlik sorunudur. Planlı kullanıcı etkileşimi sonucu oluşan bazı kaymalar metrikte farklı değerlendirilir; teşhiste gerçek kaynağı görmek gerekir.
Bu eşikler sayfanın her tekil ziyarette kusursuz olması anlamına gelmez. Değerlendirme çoğu araçta ziyaretlerin 75. yüzdelik dilimindeki deneyime bakar; mobil ve masaüstü ayrı ele alınır. Google’ın resmî Core Web Vitals belgesindeki güncel değerleri izleyin. Eski rehberlerde FID görürseniz güncel temel etkileşim metriğinin INP olduğunu unutmayın.
PageSpeed Insights raporunu doğru okuyun
PageSpeed Insights (PSI) bir URL için iki ayrı bakış sunar. Saha verisi, Chrome User Experience Report kapsamında gerçek kullanıcıların deneyimini özetler. Laboratuvar verisi ise Lighthouse’ın kontrollü koşullardaki testidir; teknik nedenleri araştırmak için kullanılır. Saha bölümündeki değerler önceki 28 günlük dönemden gelir. Bugün yaptığınız düzeltmenin ertesi dakika saha değerinde görünmemesi normaldir. Laboratuvar skoru ise test koşullarına ve sayfa durumuna göre hemen değişebilir.
Bazı düşük trafikli URL’lerde yeterli gerçek kullanıcı verisi olmayabilir. PSI bu durumda origin düzeyindeki veriyi gösterebilir veya saha verisi sunmayabilir. Origin sonucu tek makaleye aitmiş gibi yorumlamayın. Bir mobil laboratuvar testindeki kırmızı skor da tüm kullanıcıların aynı deneyimi yaşadığını kanıtlamaz. Raporun hangi URL, cihaz ve veri kaynağı için üretildiğini önce not edin. Aynı sayfanın masaüstü iyi, mobil kötü olması mümkündür.
Search Console ile sorunlu sayfa gruplarını bulun
Search Console’daki Core Web Vitals raporu, gerçek kullanıcı sinyallerine göre benzer sorunları olan URL gruplarını görmeye yardımcı olur. İlk iş, mobil rapordaki zayıf ve iyileştirme gereken gruplara bakmak; ardından hangi şablonların ortak olduğunu saptamaktır. Aynı WordPress makale şablonunu paylaşan onlarca URL’de benzer LCP sorunu varsa tek tek her yazının metnini değiştirmek yerine kapak yükleme biçimi, tema ve önbellek katmanını inceleyin. Tekil sayfa istisnalarını da atlamayın.
Rapordaki durum etiketini teknik kök neden sanmayın. “Zayıf LCP” yalnızca sonuçtur. Etkilenen bir URL’yi PSI ve Chrome DevTools ile açıp LCP öğesini, ağ zaman çizelgesini ve engelleyen kaynakları kontrol edin. Değişiklik yaptıktan sonra laboratuvar testinde iyileşme görmek ilk kanıttır; gerçek kullanıcı raporunun yeni verilerle değişmesi zaman alır. Search Console’da doğrulama başlatmak da ölçüm yerine geçmez. Kullanıcı deneyimini zaman içinde izleyin.
Önce neyi ölçmeli? Pratik başlangıç planı
- URL örnekleri seçin: Ana sayfa, makale, kategori, ürün ve ödeme gibi farklı şablonlar için gerçek adresleri listeleyin.
- Mobil ve masaüstünü ayırın: Trafiğinizin cihaz dağılımına bakın; mobil sorunu masaüstü puanıyla gizlemeyin.
- Saha verisini kaydedin: LCP, INP, CLS değerlerini ve veri kaynağının URL mi origin mi olduğunu not edin.
- Laboratuvar raporunu açın: LCP öğesi, ağ isteği sırası, toplam betik işi, engelleyici kaynaklar ve görsel boyutlarına bakın.
- Bir hipotez seçin: “Kapak geç keşfediliyor” veya “menü betiği uzun iş yapıyor” gibi ölçülebilir bir neden yazın.
- Tek değişiklik yapıp test edin: Aynı URL ve benzer koşullarda önceki ve sonraki sonucu karşılaştırın.
Testleri kaydederken tarih, cihaz, kullanılan tema/eklenti sürümü ve önbellek durumunu da yazın. Farklı sayfalar ya da farklı koşullar arasında tek sayı karşılaştırması yanıltıcıdır. SEO tarafında organik trafiği ve dizin durumunu izlemek yararlıdır; fakat sıralama değişimini yalnızca hız değişikliğine bağlamak için yeterli kanıt sayılmaz. Rekabet, içerik ve arama sonuçları aynı dönemde değişebilir.
LCP neden yüksek? Dört parçalı teşhis
LCP sorununu dört parçaya ayırın: sunucu yanıtı, kaynağın tarayıcı tarafından keşfedilmesi, kaynağın indirilmesi ve öğenin ekranda çizilmesi. İlk yanıt (TTFB) uzunsa hosting yükü, veritabanı sorguları, önbellek ve yönlendirme zinciri adaydır. Sunucu hızlıysa ama kapak dosyası geç isteniyorsa görsel başlangıç HTML’sinde yok, JavaScript ile sonradan ekleniyor ya da temanın lazy load kuralı ilk ekran görseline yanlış uygulanıyor olabilir.
Görsel zamanında istenip çok geç bitiyorsa aktarım boyutunu, uygun genişlikte srcset seçeneklerini, modern formatları ve CDN konumunu değerlendirin. İndirme bittiği hâlde öğe geç çiziliyorsa engelleyici stil dosyaları, uzun ana iş parçacığı görevleri veya görüntüyü gizleyen efektler incelenmelidir. Her aşamaya aynı “görseli sıkıştır” çözümü uygulanmaz. LCP öğesi metin bloğuysa font yükleme ve render gecikmesi ön plana çıkabilir.
İlk ekran görselini doğru önceliklendirin
Makale kapağı LCP öğesiyse onu ekran altı görseller gibi gecikmeli yüklemeyin. Tarayıcının görseli HTML’de erken bulmasını sağlayın ve uygun boyutlu dosya sunun. fetchpriority="high" gibi öncelik ipuçları bazı durumlarda yararlı olabilir; tüm görsellere aynı yüksek önceliği vermek bant genişliği yarışını artırabilir. Preload da yalnızca gerçekten kritik ve doğru dosya için kullanılmalıdır. Responsive varyantlarla uyuşmayan yanlış preload gereksiz ikinci indirmeye neden olabilir.
Ekran altındaki yazı içi görseller ise lazy load için uygundur; bu rehberdeki iki gövde görseli de bu amaçla gecikmeli yüklenir. Görsellerin genişlik ve yükseklik bilgisini HTML’de koruyun ki tarayıcı yer ayırsın ve CLS oluşmasın. Daha ayrıntılı alt metin, format ve responsive görsel örnekleri için görsel SEO rehberine bakabilirsiniz.
INP kötü olduğunda etkileşimi inceleyin
INP tek bir butonun ilk tıklanma süresi değildir; kullanıcı etkileşimlerinin görünür yanıt kalitesini özetler. Menü, arama, filtre, varyasyon seçimi ve sepet gibi gerçek görevleri mobil cihazda deneyin. Chrome DevTools Performance kaydında uzun JavaScript görevleri, yoğun DOM güncellemesi ve render gecikmesini inceleyin. Büyük bir üçüncü taraf analitik betiği, ağır tema efekti veya aynı tıklamada gereksiz çok işlem yapan kod sorun yaratabilir.
Çözüm olarak kullanılmayan JavaScript’i kaldırın, uzun işleri daha küçük parçalara bölün ve etkileşime en yakın işi önce yapın. Gereksiz üçüncü taraf etiketlerini sayfanın kritik yolundan çıkarın. Fakat “defer” veya “delay” ayarını tüm betiklere körlemesine uygulamayın: menü, arama, çerez tercihi ya da ödeme akışı bozulabilir. Her değişiklik sonrası gerçek kullanıcı görevlerini test edin. Hız puanı artarken satın alma düğmesi çalışmıyorsa optimizasyon başarısızdır.
CLS kaynağını bulup yer ayırın
CLS için önce hangi öğenin kaydığını görün. Boyutsuz görseller, iframe’ler, reklam alanları, sonradan gelen öneri kutuları ve değişen font metrikleri yaygın adaylardır. Görsel ve video kapsayıcılarına genişlik/yükseklik veya CSS aspect-ratio tanımlayarak yüklenmeden önce yer ayırın. Reklam alanı için makul sabit alan veya bilinen minimum yükseklik kullanın. Sonradan eklenecek banner’ı mevcut metnin üstüne itmek yerine akışta önceden ayrılmış bölgeye yerleştirin.
Web fontu yüklendiğinde satır uzunluğu değişiyorsa font-display ve uygun yedek font ayarlarını birlikte inceleyin. Tek başına font dosyasını küçültmek her kaymayı çözmez; metrik uyumu önemlidir. Tema tasarımını bozmadan önce Chrome DevTools ile kaymanın hangi öğeden başladığını kanıtlayın. Kullanıcının isteyerek açtığı akordeonun içerik kaydırması ile kendi kendine beliren reklamın kayması aynı kullanıcı problemi değildir.
Sunucu, önbellek ve CDN kararı
Yavaş TTFB gördüğünüzde önce hosting kaynakları, PHP işçileri, veritabanı sorguları ve uygulama günlüklerini inceleyin. Anonim ziyaretçiye sunulan statik sayfa önbelleği yükü azaltabilir; fakat oturum açmış kullanıcı, sepet ve kişiye özel sayfalar yanlışlıkla önbelleğe alınmamalıdır. CDN, uzaktaki kullanıcıya statik dosyaları daha yakın noktadan sunabilir. Ancak yanlış cache kuralı veya aynı içeriğin farklı varyantlarını karıştırmak işlevsel hata üretir.
Bir eklentinin varlığı tek başına siteyi yavaşlatmaz; etkin kodun istekte yaptığı iş önemlidir. Eklentileri silmekten önce sorgu süresini ve ağ isteğini ölçün. Birden fazla önbellek katmanı varsa hangisinin neyi sakladığını belgeleyin. Temizlik sonrası görsel, stil ve HTML sürümleri uyuşmuyorsa kullanıcı bozuk sayfa görebilir. Önce test ortamında deneyip ardından canlıda küçük bir URL örnekleminde doğrulayın. WordPress’e özel uygulama örnekleri için LiteSpeed Cache ayarları yazısına göz atabilirsiniz; ayarların hosting altyapısına göre değişeceğini unutmayın.
WordPress’te uygulanabilir iyileştirme sırası
- Hangi şablonun ve cihazın sorunlu olduğunu saha verisinde belirleyin.
- İlgili URL’nin HTML, görsel, CSS ve JavaScript isteklerini ayrı inceleyin.
- LCP görselinin gerçek boyutunu ve erken keşfedilip keşfedilmediğini kontrol edin.
- Sayfa önbelleği, sunucu yanıtı ve gereksiz yönlendirme zincirini ölçün.
- INP için menü, arama ve form görevlerini profil kaydıyla test edin.
- CLS için görsel, reklam ve font alanlarının önceden ayrıldığını doğrulayın.
- Değişiklikten sonra işlevsel regresyon testi ve yeni laboratuvar ölçümü yapın.
Bu sıra her sitede aynı önceliği üretmez. Bazı sayfalarda asıl sorun büyük kapak, bazılarında çerez yöneticisinin JavaScript işidir. Hedef, tüm Lighthouse önerilerini mekanik olarak uygulamak değil, kullanıcının en çok yaşadığı sorunu kalıcı olarak azaltmaktır. Tek bir teknik değişiklik, ilgili bütün şablonlarda yan etki yaratabileceği için örnek URL’leri farklı kategorilerden seçin.
Örnek teşhis: makale kapağı geç görünüyorsa
Varsayalım mobil makale sayfasında LCP 4 saniyeyi aşıyor. PSI raporunda LCP öğesi kapak görseli; TTFB kabul edilebilir; fakat görsel isteği HTML’den uzun süre sonra başlıyor. İlk hipotez, temanın kapağa gecikmeli yükleme uygulaması veya görseli JavaScript ile eklemesidir. Önce HTML’de gerçek src/srcset bulunduğunu ve ilk ekran görselinin lazy olmadığını kontrol edin. Sonra aynı URL’de yeni laboratuvar testini yapın. LCP düzelirken alt görsellerin gereksiz erken yüklenmediğini de doğrulayın.
Başka bir örnekte LCP görseli hemen isteniyor ama yüklenme uzun sürüyor. Burada gereksiz 3000 piksel genişlikte dosya, format ve ağ koşulları incelenir. Uygun responsive varyant, doğru sıkıştırma ve önbellek başlıkları yardımcı olabilir. “Daha küçük dosya” tek çözüm değildir: aşırı sıkıştırma görsel kalitesini bozabilir ve kullanıcı için asıl içerik değeri düşebilir. En iyi karar gerçek ekran boyutları ve algılanan kaliteyle verilir.
Örnek teşhis: mobil menü geç açılıyorsa
Sayfa ilk görünümde hızlı ama mobil menü düğmesine basınca gecikiyorsa LCP odaklı değişiklikler sorunu çözmez. Performans kaydında tıklama anındaki uzun görevleri bulun. Tema betiği büyük bir DOM listesini yeniden oluşturuyor olabilir; üçüncü taraf kod da ana iş parçacığını meşgul edebilir. Önce en uzun işi izole edin, ardından ilgili kodun işlem hacmini azaltın veya kritik olmayan parçayı sonraya bırakın. Sonucu menü açılma deneyimiyle ve mümkünse gerçek kullanıcı INP verisiyle izleyin.
Değişikliği nasıl kanıtlarsınız?
Önce başlangıç tablosu tutun: URL, şablon, cihaz, saha verisi, laboratuvar bulgusu ve beklenen düzeltme. Tek değişiklik yapın; ilgili önbellekleri uygun biçimde temizleyin. Aynı URL’de benzer koşullarda tekrar test edin. Laboratuvar sonucu hemen ipucu verir, fakat 28 günlük saha penceresi nedeniyle gerçek kullanıcı eğilimi daha yavaş değişir. Bir günün anlık skoru yerine yeterli ziyaret içeren dönemleri karşılaştırın.
Başarı ölçütünü yalnızca LCP, INP ve CLS ile sınırlandırmayın. Menü, arama, form, sepet ve ödeme çalışmalı; metin ve görseller doğru görünmeli. Erişilebilirlik ve içerik kalitesi de korunmalıdır. Test sırasında bir sorun ortaya çıkarsa son teknik değişikliği geri alıp kök nedeni yeniden inceleyin. İyileşmenin hangi şablonlara yayıldığını da kontrol edin; tüm siteyi etkileyen tema ayarı bir sayfada iyi, başka sayfada kötü sonuç verebilir.
Sık sorulan sorular
PageSpeed puanı doğrudan sıralama faktörü müdür?
Lighthouse’ın 0–100 laboratuvar performans skoru ile Google’ın sıralama sistemi aynı şey değildir. Core Web Vitals ve sayfa deneyimi sinyalleri önemlidir, fakat iyi skor üst sırayı garanti etmez. İçeriğin sorguya uygunluğu ve diğer arama sinyalleri birlikte değerlendirilir. Önce kullanıcı sorununu çözün; puanı değişimin tek amacı yapmayın.
Mobil ve masaüstü sonuçları neden farklı?
Ekran boyutu, ağ, cihaz işlem gücü, ilk ekranda görünen öğe ve kullanıcı etkileşimleri farklıdır. Ayrıca saha verisi iki cihaz sınıfından ayrı toplanır. Masaüstü iyi çıktığında mobil raporu kapatmayın. Trafiğin büyük kısmı mobilden geliyorsa o deneyimi önceliklendirin.
Hız eklentisi kurmak yeterli mi?
Önbellek ve dosya optimizasyonu sağlayan eklentiler yardımcı olabilir; fakat yavaş sorguyu, ağır tema bileşenini veya yanlış boyuttaki kapak görselini her zaman çözmez. Ayarların sepet, oturum ve kişiselleştirilmiş içerikle uyumunu test edin. Eklenti sayısından çok ölçülen etkiye bakın.
Gerçek kullanıcı verisi yoksa ne yapmalı?
PSI’da URL düzeyinde yeterli CrUX verisi olmayabilir. Origin verisini bağlam olarak okuyun; Lighthouse ve DevTools ile teknik sorunu araştırın. Kendi RUM ölçümünüz varsa gerçek ziyaretçi dağılımını izleyebilirsiniz. Saha verisinin yokluğu sayfanın hızlı veya yavaş olduğuna dair tek başına kanıt değildir.
Sonuç ve resmî kaynaklar
Sayfa hızını SEO için çalışırken önce gerçek ziyaretçinin ne yaşadığını sorun. LCP, INP ve CLS farklı sorunları gösterir; her biri için ayrı teknik teşhis gerekir. PSI saha verisi eğilimi, laboratuvar testi olası nedeni, Search Console ise etkilenen URL gruplarını bulmaya yardımcı olur. İyileştirmeyi ölçüm, tek değişiklik, işlev testi ve yeniden izleme döngüsü olarak yürütün.
