Core Web Vitals Rehberi: LCP CLS ve INP Nasıl İyileştirilir

Bir sayfayı açtığınızda üç ayrı şey sinir bozar. İlki beklemektir: ekran boş ya da yarım durur, görmek istediğiniz görsel veya başlık geç gelir. İkincisi zıplamadır: metni okumaya başlarsınız, tam o anda üstte bir şey yüklenir ve okuduğunuz satır aşağı kayar; kötü senaryoda parmağınız butona giderken buton yer değiştirir. Üçüncüsü sessizliktir: tıklarsınız, sayfa görünüş olarak hazırdır ama hiçbir şey olmaz.

Core Web Vitals bu üç rahatsızlığı birebir karşılayan üç metriktir. Geç görme LCP'dir (Largest Contentful Paint), zıplama CLS'tir (Cumulative Layout Shift), tepkisiz tıklama INP'dir (Interaction to Next Paint). Google'ın "iyi" kabul ettiği değerler sırasıyla 2,5 saniye ve altı, 0,1 ve altı, 200 milisaniye ve altıdır. Üçü aynı sayfanın farklı arızalarını gösterdiği için biri düzelirken diğeri bozulabilir. Bu yüzden tek bir hız puanının peşinden gitmek yerine üç metriği ayrı okumak gerekir.

Üç Metrik Yan Yana

İki eşik arasında kalan aralık "iyileştirme gerekli" bandıdır. Yani LCP için 2,5 ile 4 saniye arası, CLS için 0,1 ile 0,25 arası, INP için 200 ile 500 milisaniye arası ne geçer not ne kalır nottur; sayfa çalışır ama kullanıcı farkı hisseder.

Eşik Neden Tek Bir Testten Değil Ziyaretlerin Yüzde 75'inden Okunur

Bir metriğin iyi sayılması için o sayfaya yapılan tek bir ziyaretin değil, ziyaretlerin yüzde 75'inin eşiği tutturması gerekir. Ölçüm ayrıca mobil ve masaüstü için ayrı ayrı yapılır. Bu ayrıntı az bilinir ama tartışmaların yarısını bitirir: kendi bilgisayarınızda 1,2 saniyede açılan sayfanın alan verisinde kötü görünmesi bir çelişki değildir. Sizin ölçtüğünüz tek bir ziyarettir, eşik ise ziyaretlerin dörtte üçünün deneyimidir.

Yüzde 75 tercihi iki isteğin ortasında durur. Bir yandan seçilen dilim, ziyaretlerin çoğunluğunun hedef performansı yaşadığını garanti etmelidir; bunun için yüksek dilim iyidir. Öte yandan seçilen değer aykırı örneklerden aşırı etkilenmemelidir; bunun için yüksek dilim kötüdür. Yüz ziyaretlik bir sayfada yüzde 95'lik dilim kullanılsa, ağı takılan beş ziyaret sınıflandırmayı tek başına belirleyebilirdi. Yüzde 75'te ise ziyaretlerin dörtte üçünün hedefi ya da daha iyisini yakaladığı bilinir ve tekil aksaklıkların sonucu ele geçirme ihtimali düşer.

LCP: Ana İçerik Ne Zaman Ekranda Sayılır

LCP, görüntü alanındaki en büyük içerik elemanının ekrana çizildiği anı işaretler. Aday eleman kümesi karmaşıklığı azaltmak için kasten dardır: <img> elemanları, <svg> içindeki <image> elemanları, <video> elemanları (poster görselinin yükleme anı veya ilk karenin sunum anı, hangisi önceyse), url() ile yüklenmiş arka plan görseli taşıyan elemanlar ve içinde metin düğümü bulunan blok düzeyi elemanlar. CSS gradyanı arka plan görseli sayılmaz.

Boyut hesabı göründüğünden ince bir konudur ve yanlış elemanı kovalamanın en sık sebebidir. Elemanın yalnızca görüntü alanı içinde kalan kısmı sayılır; taşan veya kırpılan bölüm hesaba girmez. Doğal boyutundan küçültülerek gösterilen bir görselde görünen boyut ile doğal boyuttan hangisi küçükse o alınır. Metin elemanlarında tüm metin düğümlerini kapsayan en küçük dikdörtgen ölçülür. CSS ile verilen margin, padding ve border hiçbir elemanda boyuta eklenmez.

Aday eleman ayrıca sabit değildir. Sayfa yüklenirken en büyük eleman önce bir başlık olabilir, ana görsel indiğinde aday ona geçer. Tarayıcı bu güncellemeyi kullanıcının ilk etkileşimine kadar sürdürür; o andaki son aday nihai LCP elemanı olarak raporlanır. Bu yüzden optimizasyon, hangi elemanın gerçekten LCP elemanı olduğunu tespit etmeden başlayamaz.

LCP'nin Dört Parçası ve Sağlıklı Dağılım

LCP tek bir olay değil, arka arkaya gelen dört sürenin toplamıdır: sunucunun ilk baytı göndermesi (TTFB), LCP kaynağının keşfedilmesine kadar geçen gecikme, kaynağın indirilme süresi ve indirildikten sonra ekrana çizilene kadar geçen gecikme. İki parçanın adında gecikme geçmesi tesadüf değildir; ikisi de sıfıra yaklaşması gereken ölü zamanlardır. Diğer ikisi ağ işidir ve doğaları gereği zaman alır.

Bu oranlar hedef değil teşhis aracıdır. Google bunları milisaniyeye çevirip sabit hedef haline getirmemek gerektiğini ayrıca uyarır; LCP zaten 2,5 saniyenin altındaysa parçaların oranı önemli değildir. İşe yarayan okuma şudur: sürenin büyük kısmı HTML belgesini ve LCP kaynağını indirmekle geçmelidir. Bu iki isteğin indirilmediği her aralık, kazanılabilecek zamandır.

LCP'yi Düşürmenin Uygulama Sırası

İlk soru "görsel kaç kilobayt" değil, "tarayıcı bu kaynağı ne zaman öğreniyor" olmalıdır. Tarayıcının preload tarayıcısı, HTML yanıtını okurken indirilecek kaynakları önden yakalar. LCP kaynağı bu taramada görünüyorsa indirme erken başlar; görünmüyorsa önce bir script veya stil dosyasının gelip çalışmasını beklemek zorunda kalır.

Preload tarayıcısının yakaladığı durumlar nettir: LCP elemanı bir <img>'dir ve src veya srcset değeri ilk HTML çıktısında vardır, ya da kaynak <link rel="preload"> ile bildirilmiştir. Yakalayamadığı durumlar da aynı ölçüde nettir: görsel JavaScript ile sonradan eklenmiştir, bir lazy-load kütüphanesi gerçek adresi data-src gibi bir attribute'te saklamıştır ya da eleman CSS arka plan görseli kullanmaktadır. Bu üç kalıp, "görseli küçülttüm ama LCP düşmedi" şikayetinin arkasındaki asıl sebeptir. Metin tabanlı bir LCP elemanı web fontuna bağlıysa aynı mantık font dosyası için de geçerlidir.

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

Keşif sorunu çözüldükten sonra sıra indirme süresine gelir ve buradaki kazanç bayt tarafından çıkar. Aynı görselin modern formatlarla üretilmiş sürümleri arasından tarayıcının desteklediğini sunmak, görünen kaliteyi düşürmeden dosyayı belirgin biçimde küçültür; bu tarafın ayrıntısı WebP ve AVIF format kullanımı yazısındadır. Dördüncü parça olan render gecikmesinde ise suçlu genellikle içerik değil, çizimi bekleten kaynaklardır: render engelleyen stil dosyaları ve senkron scriptler. İlk ekranı çizmek için gereken stilin ayrılıp erken teslim edilmesi bu gecikmeyi doğrudan kısaltır; yöntem için inline kritik CSS yüklemesi yazısına bakabilirsiniz.

TTFB tarafı ise ölçek meselesidir. Sunucu yanıtı geciktiği sürece geri kalan her iyileştirme o gecikmenin üstüne biner. Uygulama katmanında önbellek, mümkün olan sayfalarda statik üretim ve içeriğin kullanıcıya yakın noktadan sunulması bu ilk parçayı kısaltan başlıca müdahalelerdir.

CLS: Sayfanın Ayağınızın Altından Kayması

CLS, sayfanın ömrü boyunca oluşan beklenmeyen layout kaymalarının en yoğun serisini ölçer. Toplam kayma miktarı değildir ve bu ayrım sonucu tamamen değiştirir. Kaymalar oturum penceresi denen gruplara ayrılır: aralarında 1 saniyeden az boşluk olan kaymalar aynı pencereye girer ve bir pencere en fazla 5 saniye sürer. Sayfanın CLS değeri, bu pencerelerin en yüksek skorlu olanının skorudur.

Pratik sonucu şudur: uzun bir sayfada dakikalarca gezinmek skoru sürekli şişirmez, ancak tek bir noktada patlayan büyük kayma serisi sayfanın notunu tek başına belirler. Yani CLS, onlarca küçük kusurun toplamı değil, en kötü anın fotoğrafıdır.

Kayma Skoru Nasıl Hesaplanır

kayma skoru = etki oranı × mesafe oranı

Etki oranı, kararsız elemanların iki kare arasında görüntü alanında etkilediği birleşik alanın oranıdır. Mesafe oranı ise herhangi bir kararsız elemanın yatayda veya dikeyde kat ettiği en büyük mesafenin, görüntü alanının büyük kenarına bölümüdür. Görüntü alanının dörtte üçünü etkileyen ve ekran yüksekliğinin dörtte biri kadar kayan bir blokta hesap 0,75 × 0,25 = 0,1875 verir. Tek bir kayma bile iyi eşiğinin yaklaşık iki katıdır. CLS'in neden birkaç büyük hatadan ibaret olduğunu bu aritmetik açıklar.

Mesafe oranı formüle sonradan eklenmiştir. Başlangıçta skor yalnızca etki oranından hesaplanıyordu ve bu, çok az kayan büyük elemanları hak etmedikleri ölçüde cezalandırıyordu.

Beklenen Kayma ile Beklenmeyen Kaymanın Sınırı

Kullanıcının kendi eylemiyle tetiklediği kaymalar cezalandırılmaz. Bir akordiyona tıklandığında altındaki içeriğin itilmesi beklenen bir davranıştır. Bu ayrım 500 milisaniyelik bir pencereyle yürür: kullanıcı girdisinden sonraki 500 ms içinde oluşan kaymalar hadRecentInput bayrağıyla işaretlenir ve hesaptan çıkarılabilir.

Pencerenin iki sert kenarı vardır ve ikisi de sık sık gözden kaçar. Birincisi, bayrak yalnızca kesikli girdilerde (dokunma, tıklama, tuş basımı) doğru olur; kaydırma, sürükleme ve iki parmakla yakınlaştırma yakın girdi sayılmaz. Dolayısıyla kullanıcı aşağı kaydırırken geç yüklenen bir içeriğin altındaki blokları itmesi doğrudan CLS'e yazılır. İkincisi, 500 ms geçtikten sonra gelen değişim artık beklenmeyen kabul edilir: tıklamadan sonra ağır bir istek dönüp DOM'u iki saniye sonra güncelliyorsa o kayma skora eklenir. Tek sayfa uygulamalarındaki geçişler tam olarak bu tuzağa düşer. Çözüm isteği hızlandırmaya çalışmak değil, tıklama anında yeri ayırmak ve yükleniyor göstergesini oraya koymaktır.

Kaymanın Gerçek Kaynakları

• Boyutsuz görseller ve videolar. Tarayıcı boyutu bilmediği elemana yer ayıramaz, dosya inince eleman gerçek boyutuna açılır ve altındaki her şey kayar. Her görsele width ve height vermek ya da alanı CSS ile rezerve etmek bu kaymayı tamamen ortadan kaldırır.
• Yer ayrılmamış reklamlar ve gömülü içerikler. Reklam ağları ve sosyal medya gömüleri içeriği asenkron getirir. Alan önceden ayrılmamışsa gelen kutu bütün sayfayı iter. Bu sorun CLS eşiğinin tarihinde bile iz bırakmıştır: alan verisi kaynakların yaklaşık yarısının 0,05 değerini tutturduğunu gösterdiği halde, yüksekliği yüklenmeden bilinemeyen üçüncü taraf gömüler yüzünden daha esnek olan 0,1 eşiği daha dengeli bulunmuştur.
• Web fontları. Yedek font önce gösterilip sonra web fontuyla değiştirildiğinde de (FOUT), metin web fontu gelene kadar görünmez tutulduğunda da (FOIT) kayma oluşur; metin görünmese bile yedek fontla yerleşim yapılır. font-display: optional yeniden yerleşimi engeller. Ayrıca yedek fontun doğru seçilmesi gerekir: font-family: "Marka Sans", sans-serif yazmak ile yalnızca font-family: "Marka Sans" yazmak arasında büyük fark vardır, çünkü ikincisinde tarayıcının varsayılan fontu devreye girer ve genellikle çok daha kötü bir eşleşme üretir. Metrik farkını kapatmak için size-adjust, ascent-override, descent-override ve line-gap-override tanımları kullanılır.
• Sonradan enjekte edilen bloklar. Çerez bildirimi, duyuru şeridi, kişiselleştirilmiş banner ve A/B test varyantları sayfa çizildikten sonra üste ekleniyorsa içeriği aşağı iter. Bu bileşenler ya yerleşimi bozmayan bir katmanda durmalı ya da yerleri baştan ayrılmalıdır.

<img src="/urun.avif" alt="Ürün görseli" width="1200" height="675">

.gomulu-alan {
  width: 100%;
  aspect-ratio: 16 / 9;
}

INP: Tıkladıktan Sonra Ekranın Cevap Vermesi

INP, kullanıcının ziyaret boyunca yaptığı tıklama, dokunma ve tuş basımlarının gecikmesini izler ve genel olarak en yavaş etkileşimi raporlar. Ölçülmeyenleri bilmek de en az ölçülenler kadar işe yarar: fareyle üzerine gelme, kaydırma ve yakınlaştırma INP kapsamına girmez. Kaydırma takılıyorsa sorun gerçektir ama INP bunu göstermez.

En yavaş etkileşim kuralının bir istisnası vardır. Çok etkileşim alan sayfalarda rastgele bir takılmanın bütün sayfanın notunu belirlememesi için her 50 etkileşimde bir en yüksek değer yok sayılır. Ziyaretlerin büyük çoğunluğunda 50'den az etkileşim olduğundan pratikte en kötü etkileşim raporlanır. Ardından her zamanki gibi sayfa görüntülemelerinin yüzde 75'lik dilimi alınır, yani sonuç iki kademeli olarak aykırı değerlerden arındırılır.

INP ile FID Arasındaki Fark Neyi Değiştirir

FID (First Input Delay) yalnızca ilk etkileşimin bekleme süresini ölçüyordu, üstelik o etkileşimin sadece gecikme kısmını. Yani sayfa açılırken ilk kez tıklandığında ne kadar beklendiğini gösteren bir yükleme metriğiydi. INP ise sayfadaki bütün etkileşimleri, girdi gecikmesinden event handler'ların çalışmasına ve bir sonraki karenin çizilmesine kadar bir bütün olarak izler.

Pratik sonucu keskindir: yükleme performansını iyileştirmek FID'i kurtarabiliyordu, INP'yi kurtarmaz. Kullanıcının üçüncü dakikada açtığı filtre menüsü, yazarken takılan arama kutusu ve sepete eklerken donan buton artık ölçümün içindedir. INP çalışması bir sayfa yükleme optimizasyonu değil, çalışma zamanı JavaScript optimizasyonudur.

INP'nin Üç Fazı ve Her Fazın Kendi Çözümü

Bir etkileşim üç parçaya ayrılır. Hangisinin uzadığını bilmeden yapılan müdahale genellikle yanlış yere gider.

1. Girdi gecikmesi: kullanıcı etkileşimi başlattığı andan event callback'lerinin çalışmaya başladığı ana kadar geçen süre. Uzunsa ana thread meşguldür ve suçlu 50 milisaniyeyi aşan uzun görevlerdir. Çözüm işi bölmek ve ana thread'e sık sık kontrol devretmektir.
2. İşleme süresi: event callback'lerinin baştan sona çalışma süresi. Uzunsa handler çok iş yapıyordur. Callback içindeki işi azaltmak, ağır hesabı ertelemek ya da parçalara ayırmak doğrudan buraya yazar.
3. Sunum gecikmesi: callback bittikten sonra tarayıcının sonucu içeren bir sonraki kareyi çizmesine kadar geçen süre. Uzunsa maliyet render tarafındadır: geniş DOM ağaçları, zincirleme stil hesapları ve okuma ile yazmayı birbirine karıştıran DOM erişimleri.

Uzun işi gelişigüzel bölmek bile hiç bölmemekten iyidir. Ancak daha isabetli yöntem, arayüzü güncelleyen callback'in hemen ardından kontrolü devretmektir; böylece çizim işi sıranın sonunu beklemek yerine erkenden çalışır ve kullanıcı tepkiyi görür.

Hydration: Framework Sitelerinde İki Metriğin Kesiştiği Nokta

Sunucuda üretilmiş HTML tarayıcıya ulaştığında sayfa görünür hale gelir ama henüz canlı değildir. JavaScript paketi inip çalışana ve framework elemanlara olay dinleyicilerini bağlayana kadar geçen aralıkta sayfa görünür ama tıklanamaz durumdadır. Kullanıcı bu aralıkta butona basar ve hiçbir şey olmaz. Bu deneyimin metrik karşılığı INP'nin girdi gecikmesi fazıdır, çünkü hydration geniş bileşen ağaçlarında ana thread'i uzun süre meşgul eden tek bir görev olarak çalışabilir.

LCP tarafında durum koşulludur ve karışıklık genellikle buradan çıkar. LCP elemanı sunucudan gelen HTML'in içindeyse tarayıcı onu JavaScript'i beklemeden çizer, dolayısıyla hydration LCP'yi doğrudan geciktirmez. Gecikmenin LCP'ye yazdığı iki durum vardır: LCP elemanı istemci tarafı JavaScript onu üretene ya da görünür kılana kadar ekranda yoksa (bu süre eleman render gecikmesi olarak ölçülür), bir de hydration uyuşmazlığı oluşup framework sunucudan gelen işaretlemeyi güvenilmez sayarak o ağacı istemcide baştan üretiyorsa.

Uyuşmazlığın kaynakları birkaç tekrar eden kalıptan ibarettir: sunucu ile istemcinin farklı saat dilimine göre biçimlendirdiği tarihler, her çalıştırmada değişen rastgele değerler ve sunucuda karşılığı olmayan tarayıcı API'lerine göre yapılan koşullu render. Ortak çözüm bu değerleri ilk render'a hiç sokmamak, istemci tarafında yüklendikten sonra yerleştirmektir. Mimari tarafta yön ise bellidir: hydration'ı bölünebilir hale getirmek, etkileşimli alanları birbirinden bağımsız adalar gibi izole etmek ve sunucuda kalabilecek bileşenleri istemciye hiç göndermemek. Üçünün de amacı aynıdır, istemciye inen ve çalışması gereken JavaScript miktarını azaltmak.

Alan Verisi ve Laboratuvar Verisi: Hangi Araç Neyi Söyler

Core Web Vitals değerlendirmesi alan verisine dayanır. Alan verisi, gerçek Chrome kullanıcılarının ziyaretlerinden toplanan anonim ölçümdür ve Chrome User Experience Report (CrUX) veri setinde birikir. Search Console'un Core Web Vitals raporu doğrudan bu veri setinden beslenir; PageSpeed Insights ise aynı sayfanın hem alan hem laboratuvar verisini yan yana gösterir.

Laboratuvar verisi kontrollü tek bir yüklemedir: belirli bir cihaz profili, belirli bir ağ senaryosu, çoğunlukla boş önbellek. İki verinin çelişmesi arıza değil, tanımların sonucudur. Başlıca ayrışma nedenleri şunlardır:

• Önbellek durumu. Laboratuvar testi genelde soğuk önbellekle açar, gerçek ziyaretçilerin bir kısmı kaynakları hazır bulur. Tekrar eden ziyaretçisi çok olan siteler alanda laboratuvardan daha hızlı görünebilir.
• Ölçüm penceresi. Laboratuvar aracı çoğunlukla ilk yüklemeyi ölçer, alan verisi ise CLS'i sayfanın tüm ömrü boyunca izler. Yüklemeden sonra oluşan kaymalar yalnızca alan verisinde görünür.
• Görünürlük farkı. Iframe içinde oluşan kaymalar Web API'leriyle ölçülemez ama kullanıcı onları görür ve CrUX bunları içerir. Kendi kurduğunuz gerçek kullanıcı ölçümü bu nedenle CrUX'tan sapabilir.
• Cihaz ve bağlantı dağılımı. Alan verisi ziyaretçi kitlenizin gerçek cihaz karışımını taşır, laboratuvar testi tek bir profili temsil eder.

Bir sayfanın alan verisinde hiç görünmemesinin de kuralı vardır. CrUX'a girebilmek için sayfanın herkese açık biçimde keşfedilebilir olması gerekir ve bu, arama motorlarının indekslenebilirlik ölçütüyle aynıdır. Yönlendirmeler sonrasında 200 dışında bir durum kodu dönen, X-Robots-Tag: noindex başlığıyla ya da noindex meta etiketiyle sunulan sayfalar bu koşulu sağlamaz. Rapor tarafındaki okuma disiplini için Search Console veri takibi rehberi işi kolaylaştırır.

Core Web Vitals'ın Sıralamadaki Yeri

Google, iyi Core Web Vitals değerlerine ulaşmayı Search'te başarı için açıkça tavsiye eder ve bunun, diğer sayfa deneyimi unsurlarıyla birlikte, çekirdek sıralama sistemlerinin ödüllendirmeye çalıştığı şeyle örtüştüğünü söyler. Aynı dokümantasyon bir noktayı da kapatır: tek bir sayfa deneyimi sinyali yoktur, çekirdek sıralama sistemleri sayfa deneyimiyle örtüşen çeşitli sinyallere bakar.

Bu iki ifadenin arası, hem abartının hem küçümsemenin dışında kalır. LCP'yi 2,5 saniyenin altına çekmek, konusu alakasız bir sorguda sayfayı öne taşımaz; performans içeriğin yerine geçmez. Öte yandan kullanıcıyı bekleten, altından kayan ve tıklamaya cevap vermeyen bir sayfa, sayfa deneyimi unsurlarının tamamında kaybeder ve bu kayıp ölçülebilir bir durumdur. Pratikte Core Web Vitals bir kaldıraçtan çok zemindir: sağlamlaştırıldığında içerik ve otorite tarafındaki çalışmanın önündeki engel kalkar, tek başına ise bir şey inşa etmez.

Teşhisten Düzeltmeye Öncelik Akışı

1. Alan verisiyle başlayın. Hangi metriğin yüzde 75'lik dilimde eşiği kaçırdığını Search Console raporundan veya PageSpeed Insights'ın alan verisi bölümünden okuyun. Laboratuvar puanı bu aşamada karar vermez, yalnızca ipucu verir.
2. Mobil ile masaüstünü ayırın. Eşikler ikisi için ayrı değerlendirilir ve arıza çoğu zaman yalnızca birinde çıkar. Düşük donanımlı telefonlarda aynı JavaScript çok daha pahalıya mal olur.
3. Tek URL'yi değil şablonu bulun. Aynı şablondan üretilen sayfalar aynı hatayı taşır. Ürün detay şablonundaki boyutsuz bir görsel binlerce URL'de aynı kaymayı üretir, dolayısıyla düzeltme de tek seferde binlerce URL'yi kurtarır.
4. Nedeni laboratuvarda yeniden üretin. LCP'de hangi elemanın seçildiğini ve dört parçanın dağılımını, CLS'te hangi elemanın kaydığını, INP'de hangi etkileşimin ve hangi fazın uzadığını tespit edin. Bu aşamayı atlayan ekipler genellikle doğru metriğe yanlış müdahaleyi yapar.
5. Düzeltmeyi nedene göre seçin. Aynı metriğin farklı nedenleri farklı müdahale ister: keşif gecikmesi erken bildirimle, indirme süresi format ve boyutla, render gecikmesi kritik stilin ayrılmasıyla, sunucu gecikmesi önbellek ve statik üretimle çözülür.
6. Ölçümün gecikmesini hesaba katın. Alan verisi geçmiş ziyaretlerin birikimidir, bu yüzden düzeltme yayına alındıktan sonra raporun tamamen yenilenmesi haftalar sürer. Search Console'daki doğrulama takibi de 28 günlük bir izleme penceresi çalıştırır ve sorunun o pencere boyunca hiçbir URL'de görünmemesini bekler.

Bu akışı tek sayfada değil site genelinde tekrarlanabilir hale getirmek için sayfa şablonlarının teknik envanterini çıkarmak gerekir; site içi SEO analizi çalışması bu envanteri ve müdahale sırasını birlikte kurar.

Sık Sorulan Sorular

Lighthouse performans puanı 100 ise Core Web Vitals da iyi midir?

Zorunlu olarak değil. Lighthouse laboratuvar ölçümü yapar ve varsayılan denetiminde sayfayı bir kez yükler. INP gerçekçi etkileşimler simüle edilmeden ölçülemez, CLS'in yüklemeden sonra oluşan kısmı da bu denetimde görünmez. Yüksek puan sayfanın laboratuvar koşullarında iyi davrandığını gösterir; sınıflandırma yine gerçek ziyaretlerden gelen alan verisiyle yapılır.

Search Console'da Core Web Vitals verisi görünmüyorsa sebebi nedir?

İki tipik sebep vardır. Sayfa CrUX'un uygunluk koşulunu sağlamıyordur (yönlendirme sonrasında 200 dışında durum kodu, noindex başlığı veya meta etiketi), ya da o sayfaya anlamlı bir sınıflandırma üretecek kadar gerçek ziyaret ulaşmamıştır. İkinci durumda site genelindeki köken verisi ve kendi kurduğunuz gerçek kullanıcı ölçümü boşluğu doldurur.

Mobil ve masaüstü ayrı mı değerlendirilir?

Evet. Eşikler mobil ve masaüstü için ayrı ayrı, yüzde 75'lik dilimde okunur ve Search Console raporu iki cihaz tipini ayrı ekranlarda gösterir. Masaüstünde iyi görünen bir sayfanın mobilde kötü çıkması yaygın bir tablodur, çünkü aynı JavaScript ve aynı görsel yükü zayıf donanımda ve dalgalı bağlantıda çok daha ağır bir bedel üretir.