Core Web Vitals Nedir? LCP, INP ve CLS Eşikleri ve Düzeltme Yolları

Core Web Vitals, Google'ın bir sayfanın kullanıcı deneyimini ölçtüğü üç saha metriğidir: LCP (yükleme hızı), INP (etkileşim tepkisi) ve CLS (görsel kararlılık). Üçü de gerçek ziyaretçilerin tarayıcılarından toplanır ve her biri için "iyi" sayılan bir eşik vardır. Bir sayfanın geçtiğini söyleyebilmek için üç metriğin de eşiği aşmaması gerekir.

Metriklerin adı zaman içinde değişti. En önemli değişiklik INP'dir: Mart 2024'te FID'in (First Input Delay) yerini aldıve ölçüm çıtasını belirgin şekilde yükseltti. FID yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu; INP, sayfa boyunca yapılan etkileşimlerin tamamına bakar ve tepkinin ekrana çizilmesine kadar geçen süreyi sayar. FID'i geçen birçok sayfa INP'de kalır — bu bir hata değil, ölçümün gerçeğe yaklaşmasıdır.

Eşik, sayfa görüntülemelerinin 75. persentilinde ve saha verisi (CrUX) esas alınarakölçülür. Yani ortalamanız değil, ziyaretçilerinizin en yavaş dörtte birlik diliminin sınırı değerlendirilir. Ortalamanın 2,0 saniye olması bir şey ifade etmez; 75. persentil 4,2 saniyedeyse o sayfa LCP'de kalmıştır.

Bu, en sık yapılan hatanın da açıklaması: Lighthouse lab verisidir ve sıralamada kullanılan sayı o değildir. Lighthouse, kendi makinenizde simüle edilmiş bir cihaz ve ağ profiliyle tek bir yükleme yapar. Teşhis için mükemmeldir, karne için değil. Sıralamayla ilişkilendirilen veri, Chrome kullanıcılarından toplanan CrUX saha verisidir; gerçek cihazları, gerçek şebekeleri ve gerçek etkileşimleri içerir.

Pratik sonuç: Lighthouse'ta 100 alıp saha verisinde kalabilirsiniz. Bunun en yaygın sebebi cihaz dağılımıdır — laboratuvarda test ettiğiniz makine, ziyaretçilerinizin kullandığı orta segment Android telefondan kat kat hızlıdır. İkinci sebep ise CrUX'un 28 günlük kayan pencere üzerinden raporlaması; bugün yaptığınız düzeltmenin saha verisine tam yansıması haftalar alır. Bu iki tabloyu ayrı ayrı okumak, bir teknik SEO denetiminin ilk adımıdır.

LCP (Largest Contentful Paint), görünür alandaki en büyük içerik ögesinin ekrana çizilme anını ölçer — genellikle hero görseli, bir video posteri veya büyük bir başlık bloğu. Kullanıcının "sayfa açıldı" hissettiği ana en yakın metriktir. İyi kabul edilmesi için 2,5 saniye ve altında kalması gerekir; 4,0 saniyenin üzerindeki değerler kötü sayılır.

Tipik nedenler dört başlıkta toplanır: sunucunun ilk yanıtı geç dönmesi, render'ı bloklayan CSS ve yazı tipi dosyaları, gereğinden büyük veya yanlış formattaki görseller, ve LCP ögesinin geç keşfedilmesi (örneğin CSS arka planı olarak tanımlanmış ya da JavaScript ile sonradan eklenen bir görsel). Düzeltme sırası şudur:

• Görsel formatı ve boyutu: hero görselini WebP veya AVIF olarak servis edin ve gerçekten gösterilen boyutta üretin. 2400 piksel genişliğinde bir görseli 800 piksellik bir alanda göstermek, LCP'yi en hızlı bozan tek hatadır.
• Preload: LCP ögesini tarayıcıya erkenden bildirin. Görsel HTML içinde geç keşfediliyorsa preload ipucu, keşif anını belgenin başına çeker.
• Sunucu yanıt süresi: ilk baytın gecikmesi doğrudan LCP'ye eklenir. Sayfayı önceden üretmek, önbelleğe almak ve içeriği kullanıcıya coğrafi olarak yakın bir noktadan sunmak bu kalemi kısaltır.
• Render'ı bloklayan CSS: kritik olmayan stilleri ertelemek, kullanılmayan CSS'i temizlemek ve yazı tiplerini gecikmeden gösterecek şekilde yüklemek ilk çizim anını öne alır.
• Lazy loading'i doğru yerde kullanın: görünür alandaki LCP görseline tembel yükleme uygulamak metriği iyileştirmez, bozar. Tembel yükleme yalnızca ekranın altındaki görseller içindir.

INP (Interaction to Next Paint), kullanıcı bir şeye tıkladığında, dokunduğunda veya klavye ile etkileşime girdiğinde ekranda görünür bir tepki oluşana kadar geçen süreyi ölçer. Sayfa ömrü boyunca yapılan etkileşimlere bakar ve tek bir temsili değer raporlar. 200 ms ve altı iyi, 200-500 ms arası iyileştirilmeli, 500 ms üzeri kötüdür. Mart 2024'te FID'in yerini aldı.

Neredeyse her INP sorununun kaynağı aynıdır: meşgul ana iş parçacığı. Tarayıcı tek bir ana iş parçacığında hem JavaScript çalıştırır hem de ekranı çizer. Uzun süren bir görev devam ederken kullanıcı tıklarsa, tarayıcı o görev bitene kadar tepki veremez. Sık görülen sebepler: büyük üçüncü taraf etiketleri (analitik, chat, reklam, ısı haritası), her etkileşimde bileşen ağacının tamamını yeniden çizen arayüz kodu, ve sayfa açılışında hepsi birden çalışan başlatma betikleri.

• Uzun görevleri bölün: 50 ms'yi aşan işleri parçalara ayırın ve aralarda tarayıcıya ekranı çizme fırsatı verin. Tek bir uzun görevi ikiye bölmek çoğu zaman ölçülebilir bir INP kazancı verir.
• JavaScript bütçesi koyun: sayfaya inen betik miktarına üst sınır belirleyin ve her yeni eklentiyi bu bütçeye karşı değerlendirin. Bütçesi olmayan sitede JS boyutu tek yöne gider.
• Etkileşimi tepkiden ayırın: tıklama anında önce görsel geri bildirimi çizin (buton durumu, iskelet), ağır hesaplamayı sonraya bırakın. Kullanıcı için ölçülen şey tepkinin görünme anıdır.
• Üçüncü taraf betiklerini denetleyin: chat, reklam ve ısı haritası araçları çoğunlukla ana iş parçacığında çalışır. Gerçekten gereken sayfalarda ve gecikmeli yükleyin.
• Sunucuda render edilen içeriği tercih edin: tarayıcıda kurulması gereken bileşen sayısı azaldıkça açılıştaki ana iş parçacığı baskısı da azalır.

Son madde teknoloji seçimiyle doğrudan ilgili. Sunucu tarafında üretilen sayfalarla tarayıcıda kurulan sayfalar arasındaki farkı ve bunun hangi projelerde belirleyici olduğunu Next.js mi WordPress mi karşılaştırmasında ele aldık.

CLS (Cumulative Layout Shift), sayfa yüklenirken içeriğin beklenmedik şekilde yer değiştirmesini ölçer — okumaya başladığınız paragrafın aşağı kayması, tam basacakken yerinden oynayan buton. Birim yoktur, bir orandır: 0,1 ve altı iyi, 0,1-0,25 arası iyileştirilmeli, 0,25 üzeri kötüdür. Diğer iki metrikten farkı, doğrudan hayal kırıklığı yaratan tek metrik olmasıdır; yavaş sayfa beklenir, yerinden oynayan sayfa yanlış tıklattırır.

• Görsellerde width ve height verin: tarayıcı en-boy oranını baştan bilirse görsel inmeden önce yerini ayırır. Tek satırlık bu düzeltme, CLS sorunlarının büyük bölümünü çözer.
• Yazı tipi swap stratejisini seçin: özel yazı tipi geç yüklendiğinde metin yeniden çizilir ve satırlar kayar. Yedek yazı tipini metrik olarak eşleştirmek ve yükleme davranışını bilinçli seçmek bu kaymayı ortadan kaldırır.
• Reklam, embed ve iframe için alan ayırın: yüksekliği önceden bilinmeyen her blok, geldiğinde altındaki her şeyi iter. Minimum yükseklik tanımlayın.
• Dinamik içeriği mevcut içeriğin üstüne enjekte etmeyin: çerez bandı, duyuru çubuğu ve kampanya şeridi sayfanın başına sonradan eklendiğinde tüm düzeni aşağı kaydırır. Bu ögeleri sabit konumlandırın veya yerlerini baştan ayırın.
• Animasyonlarda düzen değiştiren özellikleri kullanmayın: yükseklik veya konum yerine transform üzerinden animasyon yapmak kayma üretmez.

Doğru araç, sorduğunuz soruya bağlıdır. Karneyi saha verisi verir, teşhisi lab verisi. İkisini karıştırmak, haftalarca yanlış şeyi optimize etmenin en kestirme yoludur.

Yayına alınan her değişiklikten sonra bu tabloyu ikiye ayırarak okuyun: lab verisi düzeldi mi (değişiklik işe yaradı mı), saha verisi düzeldi mi (gerçek kullanıcılara yansıdı mı). İkincisi haftalar sürer; aradaki boşlukta panik yapıp yeni değişiklikler yığmak, hangi müdahalenin işe yaradığını ölçülemez hale getirir. Sürekli takip için bakım ve destek paketlerimizde saha verisi izleme ve regresyon uyarısı standarttır.

Doğrudan cevap: Core Web Vitals bir sıralama sinyalidir, ancak içerik uygunluğunun yerine geçmez. Kötü bir sayfayı iyi metriklerle üst sıraya taşıyamazsınız; iyi bir sayfayı kötü metriklerle geride tutabilirsiniz. Etkisi özellikle rakiplerin içerik kalitesinin birbirine yakın olduğu sorgularda belirginleşir — orada eşiği geçen sayfa farkı açar.

Sıralamadan bağımsız olarak, metriklerin ticari karşılığı doğrudandır: yavaş açılan bir ürün sayfası sepete eklemeden terk edilir, yerinden oynayan bir form yanlış tıklama üretir. Bu yüzden Core Web Vitals'ı bir SEO ödevi olarak değil, dönüşüm işi olarak ele almak daha doğru sonuç verir. Aynı mantık AI arama motorları için de geçerlidir: sunucuda render edilen, hızlı ve kararlı bir sayfa hem ziyaretçi hem tarayıcı için okunabilirdir; ayrıntısı GEO yazımızda.

Ve dürüst olalım: hiçbir ajans sıralama garantisi veremez. Garanti edilebilecek şey kontrol edilebilen kısımdır — ölçülebilir metrikler, geçerli işaretleme ve indekslenebilir bir mimari.

Sıralama şu: önce ölçün, sonra en çok trafik alan şablonu düzeltin, en son ayrıntıya inin. Sayfa sayısı yüzlerse tek tek URL peşinden koşmak kaybettirir; Core Web Vitals sorunları neredeyse her zaman şablon düzeyindedir ve bir şablonu düzeltmek yüzlerce sayfayı birden düzeltir.

• Search Console'daki Core Web Vitals raporunu açın ve kalan URL gruplarını şablonlarına göre ayırın (ürün, kategori, blog, ana sayfa).
• En çok görüntülenen şablonu seçin ve o şablondan temsili bir URL'i PageSpeed Insights ile inceleyin — saha ve lab verisini yan yana okuyun.
• Önce LCP'ye bakın: en hızlı kazanç genellikle hero görselinin formatında ve boyutundadır.
• Sonra CLS'yi kapatın: görsel boyutları ve ayrılmış alanlar düşük maliyetli, kalıcı düzeltmelerdir.
• En sona INP'yi bırakın: en çok mühendislik gerektiren metrik budur, çünkü çözümü çoğu zaman JavaScript mimarisine dokunmayı gerektirir.
• Değişikliği yayına alın ve saha verisinin güncellenmesi için bekleyin. Teknik düzeltmelerin Search Console'da ölçülebilir hale gelmesi tipik olarak 2-6 hafta sürer.

Yeni bir proje planlıyorsanız bu işi sonradan yapmak yerine baştan kurmak her zaman daha ucuzdur; hem kurumsal web sitesi hem e-ticaret projelerimizde Core Web Vitals kurulumu teslim kapsamının içindedir. Mevcut bir siteyi ölçtürmek isterseniz iletişim sayfasından adresi iletmeniz yeterli.

• Core Web Vitals üç saha metriğidir: LCP yükleme hızını, INP etkileşim tepkisini, CLS görsel kararlılığı ölçer.
• Eşikler: LCP iyi 2,5 sn ve altı, kötü 4,0 sn üzeri. INP iyi 200 ms ve altı, kötü 500 ms üzeri. CLS iyi 0,1 ve altı, kötü 0,25 üzeri.
• Ölçüm, sayfa görüntülemelerinin 75. persentilinde ve saha verisi (CrUX) üzerinden yapılır. Lighthouse lab verisidir ve sıralamada kullanılan sayı o değildir.
• INP, Mart 2024'te FID'in yerini aldı; FID'i geçen birçok sayfa INP'de kalır çünkü tüm etkileşimler ve tepkinin çizilme anı ölçülür.
• En hızlı kazanç sırası: LCP için görsel formatı ve boyutu, CLS için görsellerde width/height, INP için uzun görevleri bölmek ve JavaScript bütçesi koymak.
• Sorunlar şablon düzeyindedir; tek tek URL yerine en çok trafik alan şablonu düzeltin. Teknik düzeltmelerin saha verisine yansıması tipik olarak 2-6 hafta sürer.

Tüm yazılar blog dizininde. Hizmet karşılıkları için hizmetler, paket bedelleri için fiyatlandırma sayfalarına bakabilirsiniz.