SEO & Pazarlama

Core Web Vitals: LCP, INP ve CLS için Pratik Rehber

Google'ın Core Web Vitals metriklerini kesin eşikler, ölçüm komutları ve LCP, INP ile CLS optimizasyonunda sık yapılan hatalarla öğrenin.

SEO & Pazarlama

Core Web Vitals Neden Sıralamanızı Belirler

Siteniz Google'ın ilk sayfasında ve trafik alıyorsunuz, ancak dönüşüm oranınız düşük. Kullanıcılar giriyor ve birkaç saniye sonra sayfayı kapatıyor. PageSpeed Insights raporunu açıyorsunuz ve üç kırmızı metrik görüyorsunuz: LCP 4.8 saniye, INP 600 milisaniye ve CLS 0.35. Bu sayılar sadece bir uyarı değil; Google, Mart 2024'ten itibaren bu metrikleri doğrudan mobil sıralama algoritmasında uyguluyor. Yani şu anda, içerik açısından daha zayıf ama teknik olarak daha hızlı bir sayfaya sahip rakibiniz sizden daha üstte duruyor.

Core Web Vitals, ham sunucu hızını değil, gerçek kullanıcı deneyimini ölçen üç metriktir. Bu fark önemlidir. 10 Gigabit bağlantıya sahip bir NVMe sunucusu yanıtı 50 milisaniyede verebilir, ancak JavaScript tarayıcıyı kilitlerse, kullanıcı yine de boş bir sayfa görür.

LCP: En Büyük Görünür İçerik Ne Zaman Yüklenir

LCP veya Largest Contentful Paint, sayfadaki en büyük görünür öğenin (genellikle kahraman görseli, ana başlık veya video) render edildiği anı ölçer. Google'ın kabul eşiği 2.5 saniyedir. 2.5 ile 4 saniye arası iyileştirme gerektirir ve 4 saniyenin üzeri başarısız olduğunuz anlamına gelir.

Doğru ölçüm için Chrome DevTools'ta şu komutu kullanın:

npx lighthouse https://example.com --only-categories=performance --output=json --output-path=report.json

Bu komut, LCP bölümünde TTFB sürelerini, kaynak yükleme süresini ve render gecikmesini ayrı ayrı gösteren tam bir JSON raporu üretir. Gerçek kullanıcı verilerini görmek istiyorsanız, Google Search Console'daki Core Web Vitals raporuna gidin ve "mobil" filtresini etkinleştirin.

TTFB Neden Yükselir

Farsça sitelerde en sık gördüğüm neden, yavaş DNS veya yoğun paylaşımlı sunucudur. TTFB'niz 800 milisaniyenin üzerindeyse, önce DNS'i kontrol edin. Aşağıdaki komutla DNS yanıt süresini ölçebilirsiniz:

dig +stats example.com | grep "Query time"

Query time 100 milisaniyenin üzerindeyse, sorun DNS'ten kaynaklanıyor. DNS sağlamsa, sunucuyu kontrol edin. WordPress siteleri için pratik bir çözüm, sunucu düzeyinde sayfa önbelleği kullanmaktır. WP Rocket veya LiteSpeed Cache gibi eklentiler TTFB'yi 1.2 saniyeden 200 milisaniyeye düşürebilir.

Görseller; LCP'nin Sessiz Katili

Kahraman görselini WebP veya AVIF formatında sunun. Üç megabaytlık bir JPEG görseli LCP'yi 2 saniye artırabilir. ImageMagick ile dönüştürme komutu:

convert hero.jpg -quality 80 -resize 1920x1080 hero.webp

Ayrıca, tarayıcının onu diğer kaynaklardan daha erken yüklemesi için LCP görseline fetchpriority="high" özelliğini ekleyin. Bu, etkisini raporda hemen göreceğiniz tek satırlık bir değişikliktir.

İşte burada hata yapıyorlar: Birçok kişi sadece görseli sıkıştırıyor ancak aynı kahraman görseline loading="lazy" koyuyor. Sonuç? Tarayıcı, görselin viewport'a girmesini bekliyor ve sonra yüklemeye başlıyor. LCP'niz 1.5 saniye daha kötüleşiyor ve kimse nedenini anlamıyor. Basit kural: LCP görseli asla lazy olmamalıdır.

INP: Sayfanın Kullanıcı Etkileşimine Tepkisi

INP veya Interaction to Next Paint, Mart 2024'ten itibaren FID'nin yerini aldı. Temel fark, FID'nin yalnızca ilk etkileşimi ölçmesi, ancak INP'nin sayfanın tüm ömrü boyunca en kötü etkileşimi kaydetmesidir. Yani kullanıcı üçüncü dakikada bir düğmeyle etkileşime girerse ve tarayıcı 800 milisaniye kilitli kalırsa, raporunuzda aynı sayı yer alır.

INP için kabul eşiği 200 milisaniyenin altıdır. 200 ile 500 milisaniye arası iyileştirme gerektirir ve 500'ün üzeri başarısızlıktır. Ölçmek için şu komutu kullanın:

npx @puppeteer/browsers install chrome@stable

Ardından, Puppeteer ile sayfayı açan, birkaç öğeye tıklayan ve INP'yi kaydeden bir Node.js betiği yazın. Daha basit yöntem: Chrome'a Web Vitals uzantısını kurun ve gerçek sayfayla çalışın.

INP'nin Ana Suçlusu: Ağır JavaScript

Tarayıcının ana iş parçacığında çalışan her betik INP'yi artırır. Analiz betikleri, canlı sohbet, slayt gösterileri ve karmaşık CSS animasyonlarının hepsi pay sahibidir. Teşhis için DevTools'ta Performance sekmesini açın ve bir etkileşimi kaydedin. Bir fonksiyonun 300 milisaniye sürdüğünü görürseniz, onu Web Worker ile başka bir iş parçacığına taşıyın.

Hızlı bir çözüm: Gereksiz betikleri defer ile yükleyin. Bu özellik tarayıcıya, betiği HTML'ye ulaştığı anda değil, HTML'yi tamamen ayrıştırdıktan sonra çalıştırmasını söyler. Varsayılan durumdan defer'a geçmek genellikle INP'yi %30-40 oranında iyileştirir.

Burada gerçek bir takas var: JavaScript'i tamamen kaldırmak INP'yi mükemmel yapar, ancak siteniz bir e-ticaret mağazasıysa, sepet ve filtreler JS olmadan çalışmaz. Benim seçimim: Kritik betikleri inline yapın, gerisini defer ile yükleyin ve kullanıcı etkileşiminde hiçbir rolü olmayan betikleri (sohbet robotları gibi) tamamen kaldırın. Canlı sohbet sizin için hayatiyse, onu yalnızca iletişim sayfasında etkinleştirin, tüm sayfalarda değil.

CLS: Sayfa Öğelerinin Ani Yer Değiştirmesi

CLS veya Cumulative Layout Shift, sayfanın ömrü boyunca öğelerin beklenmedik yer değiştirme miktarını ölçer. Kabul eşiği 0.1'in altıdır. 0.25'in üzeri başarısızlıktır. Bu metrik doğrudan kullanıcı güveniyle ilişkilidir; kullanıcı bir düğmeye tıkladığında ve aniden reklam banner'ı yer değiştirdiğinde, yanlış tıklama meydana gelir.

Farsça sitelerde CLS'nin en büyük nedeni, belirli boyutları olmayan görseller ve web fontlarıdır. Görseller için HTML'de her zaman genişlik ve yüksekliği belirtin:

<img src="product.jpg" width="800" height="600" alt="Ürün">

Bu, tarayıcıya görseli yüklemeden önce gerekli alanı ayırmasını söyler. Fontlar için, metnin varsayılan fontla görüntülenmesi ve web fontu yüklendikten sonra değiştirilmesi için font-display: swap kullanın. Bu basit değişiklik CLS'yi 0.3'ten 0.05'e düşürebilir.

İşte burada hata yapıyorlar: Sayfa yüklendikten sonra görünen reklam banner'ları veya slayt gösterileri. 300 piksellik bir banner 2 saniye sonra içeriğin üstünde belirirse, CLS'niz 0.25 artar. Çözüm: Banner alanını önceden boş bir div ile ayırın veya banner'ı sayfanın altına taşıyın.

Optimizasyon Sırası; Nereden Başlamalı

Bütçeniz kısıtlıysa, önce CLS'yi düzeltin. Neden? Çünkü en basit ve en hızlı iyileştirmedir. Görsellere boyut eklemek ve font-display ayarlamak genellikle bir günde yapılır ve anında etki gösterir. Ardından LCP'yi hedefleyin; çünkü genellikle tek bir ana sorunu vardır (ağır görsel veya yüksek TTFB). INP'yi en sona bırakın; çünkü daha derin bir JavaScript analizi gerektirir.

Sürekli izleme için ücretsiz araçlar kullanın. ServerNet'in SEO ve webmaster araçları, PageSpeed Insights ve Core Web Vitals raporlarını içerir. Siteniz paylaşımlı hosting'deyse ve TTFB 500 milisaniyenin altına inmiyorsa, özel veya bulut sunucuya geçme zamanı gelmiştir. Bu bir maliyettir, ancak geliriniz Google sıralamasına bağlıysa, mantıklı bir yatırımdır.

Önemli bir not: Core Web Vitals'i genel hız testi araçlarıyla karıştırmayın. GTmetrix ve Pingdom gibi araçlar ham hızı gösterir, ancak Google'ın metrikleri kullanıcı deneyimini ölçer. Bir site mükemmel TTFB'ye sahip olabilir ancak ağır kahraman görseli nedeniyle zayıf LCP'ye sahip olabilir. Her zaman Google Search Console ve PageSpeed Insights verilerine güvenin, genel araçlara değil.

Sık Sorulan Sorular

Core Web Vitals doğrudan Google sıralamasını etkiler mi?

Evet, Mart 2024'ten itibaren bu metrikler mobil sıralama sinyallerinin bir parçasıdır. Ancak önemli bir not: Bu, yüzlerce sinyalden yalnızca biridir. Mükemmel içerik ve güçlü bağlantılara sahip bir site, zayıf Core Web Vitals ile bile iyi sıralanabilir, ancak iki site içerik açısından eşitse, bu metrikleri geçen site daha üstte yer alır.

INP neden FID'nin yerini aldı?

FID yalnızca kullanıcının ilk etkileşimini ölçüyordu ve kullanıcı önce sayfayı kaydırıp sonra tıklarsa iyi bir sayı gösteriyordu. INP, sayfanın tüm ömrü boyunca en kötü etkileşimi kaydeder, bu nedenle gerçek kullanıcı deneyiminin daha doğru bir resmini sunar. Bu değişiklik Mart 2024'te uygulandı.

Core Web Vitals masaüstünde de uygulanır mı?

Evet, Google bu metrikleri mobil ve masaüstü için ayrı ayrı raporlar. Ancak öncelik mobildedir çünkü Google trafiğinin çoğu mobil cihazlardan gelir. Kısıtlı bütçeniz varsa, önce mobil'i optimize edin, sonra masaüstünü.

Core Web Vitals iyileştirmesinin sıralamada görünmesi ne kadar sürer?

Google, değişiklikleri uyguladıktan sonra genellikle 2 ila 4 hafta içinde yeni verileri toplar ve indeksler. Değişiklikleri bugün uygularsanız, Search Console raporunda yaklaşık 28 gün sonra sonucu görürsünüz. Sabırlı olun ve raporu her hafta kontrol edin.

Optimizasyon yolculuğuna profesyonelce devam etmek istiyorsanız, ServerNet'in SEO hizmetleri, Core Web Vitals'in tam teknik analizini ve düzeltmelerin uygulanmasını içerir. Ancak herhangi bir işlem yapmadan önce, bugün bir şey yapın: Sitenizin PageSpeed Insights raporunu açın ve LCP, INP ile CLS olmak üzere üç sayıyı not edin. Bir ay sonra aynı sayıları karşılaştırın. Gerçekten ilerleme kaydedip kaydetmediğinizi anlamanın tek yolu budur.

ServerNet Destek

ServerNet mühendislik ve yayın ekibi — altyapı, ağ ve web barındırma uzmanları.

SEO Hizmetleri
Paylaş:

Yorumlar 0

Henüz yorum yok — ilk siz olun!

Yorum bırakın

İlgili hizmet

SEO Hizmetleri

SEO bir maliyet değil, bir yatırımdır. Teknik SEO, içerik stratejisi ve ilkeli bağlantı kurma ile ServerNet, Google sıralamanızı yükseltir ve gerçek, kalıcı organik trafik oluşturur.