LCP Nedir? Core Web Vitals (LCP, INP, CLS) ve Nasıl İyileştirilir

LCP (Largest Contentful Paint), sayfa açılırken ekranın görünen alanındaki en büyük görselin ya da metin bloğunun ne kadar sürede çizildiğini ölçen metriktir. Google, LCP'nin 2,5 saniye veya altında olmasını "iyi" kabul eder. LCP; INP ve CLS ile birlikte Core Web Vitals adı verilen üç temel kullanıcı deneyimi metriğinden biridir ve kullanıcının "sayfa açıldı" hissini en iyi yansıtan ölçüdür.

Bu rehberde Core Web Vitals'ın ne olduğunu, üç metriğin eşiklerini, saha verisi ile laboratuvar verisi arasındaki farkı, PageSpeed Insights ve Search Console raporlarının nasıl okunacağını ve her metrik için uygulanabilir iyileştirme adımlarını anlatıyoruz. Sonunda bu metriklerin sıralamaya etkisini de abartmadan, olduğu gibi ele alıyoruz.

Core Web Vitals nedir?

Core Web Vitals, Google'ın bir web sayfasındaki gerçek kullanıcı deneyimini üç boyutta ölçmek için tanımladığı metrik setidir: yüklenme hızı, etkileşime yanıt verme ve görsel kararlılık. Her boyut tek bir metrikle temsil edilir:

• LCP (Largest Contentful Paint): Ana içerik ne kadar hızlı görünüyor?
• INP (Interaction to Next Paint): Kullanıcı tıkladığında, dokunduğunda ya da klavyeye bastığında sayfa ne kadar hızlı tepki veriyor?
• CLS (Cumulative Layout Shift): Sayfa yüklenirken ve kullanılırken içerik beklenmedik biçimde kayıyor mu?

Bu metrikler, daha geniş "sayfa deneyimi" kavramının ölçülebilir çekirdeğidir. HTTPS kullanımı, mobil uyumluluk ve rahatsız edici geçiş reklamlarından kaçınmak gibi diğer sinyallerle birlikte değerlendirilir. Teknik SEO çalışmasının genel çerçevesini merak ediyorsanız Teknik SEO Nedir? yazısı bu metriklerin nereye oturduğunu gösterir.

Eşik değerleri tablosu

Her metrik için Google üç bant tanımlar: iyi, iyileştirme gerekli ve zayıf.

Metrik	Ne ölçer	İyi	İyileştirme gerekli	Zayıf
LCP	Yüklenme	2,5 sn ve altı	2,5 - 4 sn	4 sn üzeri
INP	Etkileşim yanıtı	200 ms ve altı	200 - 500 ms	500 ms üzeri
CLS	Görsel kararlılık	0,1 ve altı	0,1 - 0,25	0,25 üzeri

LCP nedir ve neyi ölçer?

LCP, sayfanın yüklenmeye başladığı andan itibaren görünüm alanındaki (viewport) en büyük içerik öğesinin ekrana çizildiği ana kadar geçen süredir. Hangi öğenin "en büyük" sayılacağı tarayıcı tarafından belirlenir ve yükleme sırasında değişebilir; ilk önce bir başlık en büyük öğe olabilir, ardından büyük bir kapak görseli yüklenince LCP öğesi o görsele geçer.

LCP adayı olabilecek öğeler şunlardır:

• <img> öğeleri (çoğu sitede LCP öğesi budur),
• SVG içindeki <image> öğeleri,
• video öğelerinin kapak (poster) görseli,
• CSS ile url() üzerinden yüklenen arka plan görselleri,
• metin içeren blok düzeyindeki öğeler (paragraf, başlık gibi).

Pratikte e-ticaret ürün sayfalarında LCP öğesi genellikle ana ürün görseli, blog yazılarında öne çıkan görsel ya da başlık, kurumsal ana sayfalarda ise büyük "hero" alanıdır. İyileştirmeye başlamadan önce kendi sayfanızda LCP öğesinin tam olarak ne olduğunu tespit etmek ilk iştir; aksi halde yanlış görseli optimize edip hiçbir şey kazanamazsınız.

LCP süresinin dört parçası

LCP tek bir sayı gibi görünse de aslında dört ardışık aşamanın toplamıdır. Hangi aşamanın uzun sürdüğünü bilmek, doğru çözümü seçmenin anahtarıdır:

1. Sunucu yanıt süresi (TTFB): Tarayıcının HTML belgesinin ilk baytını alana kadar geçen süre.
2. Kaynak yükleme gecikmesi: HTML geldikten sonra tarayıcının LCP görselini indirmeye başlamasına kadar geçen bekleme.
3. Kaynak yükleme süresi: LCP görselinin kendisinin indirilmesi.
4. Öğe çizim gecikmesi: Görsel indikten sonra ekrana gerçekten çizilene kadar geçen süre (render engelleyen CSS veya JavaScript bu aşamayı uzatır).

Sık görülen hata, sorunun yalnızca görselin dosya boyutunda olduğunu varsaymaktır. Oysa birçok sitede asıl kayıp ikinci aşamadadır: tarayıcı görseli çok geç keşfeder, çünkü görsel JavaScript ile ekleniyordur ya da tembel yüklemeye (lazy-load) takılıyordur.

INP nedir? FID'in yerini neden aldı?

INP (Interaction to Next Paint), kullanıcının sayfa ile yaptığı etkileşimlere (tıklama, dokunma, tuş basma) sayfanın ne kadar sürede görsel bir yanıt verdiğini ölçer. Sayfa ziyareti boyunca gerçekleşen etkileşimler gözlemlenir ve en yavaşlarından biri (çok sayıda etkileşim olan sayfalarda aşırı uç değerler hariç tutularak) INP değeri olarak raporlanır. İyi eşik 200 milisaniyedir.

INP, Mart 2024'te FID'in (First Input Delay) yerini resmi olarak aldı. FID yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu; işleyicinin çalışma süresini ve ekranın güncellenmesini hesaba katmıyordu. Bu yüzden birçok site FID'de iyi görünürken kullanıcılar menü açarken, filtre seçerken ya da sepete eklerken belirgin takılmalar yaşıyordu. INP ise tüm ziyaret boyunca etkileşimin tamamını (giriş gecikmesi, işleme süresi ve sonraki çizim) ölçtüğü için gerçek deneyimi çok daha iyi yansıtır.

CLS nedir?

CLS (Cumulative Layout Shift), sayfadaki görünür öğelerin beklenmedik biçimde yer değiştirmesini puanlayan metriktir. Bir makaleyi okurken üstte bir reklam yüklenip metni aşağı itmesi ya da tam bir butona tıklayacakken butonun kayması tipik CLS sorunlarıdır. Değer birimsizdir; kayan alanın büyüklüğü ve kayma mesafesiyle hesaplanır. İyi eşik 0,1'dir.

Kullanıcının kendi eylemiyle (örneğin bir akordeonu açması) kısa süre içinde tetiklenen kaymalar CLS'ye sayılmaz. Sorun, kullanıcının beklemediği kaymalardır.

Saha verisi ile laboratuvar verisi farkı

Core Web Vitals'ı doğru yorumlamanın en kritik noktası, iki farklı veri türünü ayırt etmektir. Birçok ekip laboratuvar puanını düzeltmeye uğraşıp Search Console'da hiçbir değişiklik görmediğinde hayal kırıklığına uğrar; nedeni genellikle bu farktır.

	Saha verisi (field)	Laboratuvar verisi (lab)
Kaynağı	Gerçek Chrome kullanıcılarından toplanır (Chrome UX Report, CrUX)	Tek bir simüle edilmiş cihaz ve ağ koşulunda yapılan test (Lighthouse)
Zaman aralığı	Son 28 günün kayan ortalaması	Testi çalıştırdığınız an
INP ölçebilir mi?	Evet	Hayır, gerçek etkileşim olmadığı için Total Blocking Time (TBT) gibi vekil metrikler kullanılır
Ne işe yarar?	Kullanıcıların gerçekte ne yaşadığını ve Google'ın neyi değerlendirdiğini gösterir	Sorunu teşhis etmek ve değişikliği hemen test etmek için

Kural basittir: Hedefinizi saha verisine göre koyun, teşhisi laboratuvar verisiyle yapın. Laboratuvar puanı 95 olan bir sayfa, kullanıcılarınızın çoğu yavaş mobil bağlantıdaysa sahada zayıf çıkabilir. Tersi de olabilir.

75. yüzdelik ne demek?

Saha verisinde bir sayfanın ya da sitenin "iyi" sayılması için ortalama değer değil, 75. yüzdelik değer esas alınır. Yani ziyaretlerin en az yüzde 75'inin eşiğin altında kalması gerekir. Örneğin bir sayfada ziyaretlerin yüzde 75'inde LCP 2,3 saniyenin altındaysa LCP "iyi" kabul edilir; geri kalan yüzde 25'te 5 saniye bile sürse bu sonuç değişmez. Bu yaklaşım, hem çoğunluğun deneyimini koruyan hem de tek tük uç değerlere boğulmayan bir ölçü sağlar. Mobil ve masaüstü değerleri ayrı ayrı değerlendirilir; çoğu sitede mobil değerler daha zayıftır, bu yüzden önceliği mobile vermek mantıklıdır.

Bir de şu nokta var: saha verisi 28 günlük kayan pencereyle hesaplandığı için bugün yaptığınız bir iyileştirmenin tam etkisini raporlarda görmeniz yaklaşık dört hafta alır. İyileştirme yaptıktan iki gün sonra Search Console'a bakıp "işe yaramadı" demek erken bir hükümdür.

PageSpeed Insights nasıl okunur?

PageSpeed Insights, bir URL için hem saha hem laboratuvar verisini tek ekranda gösterir. Okuma sırası şöyle olmalıdır:

1. Mobil sekmesinden başlayın. Masaüstü genellikle daha iyi görünür ve yanıltıcı bir rahatlama yaratır.
2. Üstteki saha verisi bölümüne bakın. Burada gerçek kullanıcı deneyimi değerlendirmesi, LCP, INP ve CLS'nin 75. yüzdelik değerleri ve her birinin iyi, orta ve zayıf dağılımı yer alır. Önce bu sayfanın kendi verisi, yetersizse alan adının (origin) geneli gösterilir; hangisine baktığınızı mutlaka kontrol edin.
3. Saha verisi yoksa sayfa yeterli trafiğe sahip değildir. Bu durumda laboratuvar sonuçlarıyla ve benzer şablondaki daha çok trafik alan sayfaların verisiyle çalışırsınız.
4. Alttaki laboratuvar (Lighthouse) bölümüne inin. Performans puanı ve tanılama önerileri buradadır. Puanın kendisine değil, LCP öğesinin hangisi olduğunu gösteren tanılamaya, uzun ana iş parçacığı görevlerine ve render engelleyen kaynaklara odaklanın.

Search Console Core Web Vitals raporu nasıl okunur?

Search Console'daki Core Web Vitals raporu, sitenizin tamamını saha verisiyle özetler. Tek tek URL'leri değil, benzer davranan URL gruplarını gösterir ve her grubu en zayıf metriğine göre iyi, iyileştirme gerekli veya zayıf olarak sınıflandırır. Raporun genel kullanımı için Google Search Console Nedir? yazısına göz atabilirsiniz.

Bu raporla verimli çalışmak için şu sırayı izleyin:

1. Mobil raporu açın ve "zayıf" durumdaki sorun türlerini listeleyin (örneğin "LCP sorunu: 4 saniyeden uzun").
2. Her sorunun altındaki URL gruplarını inceleyin. Bir grup genellikle aynı şablonu paylaşan sayfalardır: tüm ürün sayfaları, tüm kategori sayfaları gibi.
3. Gruptan örnek bir URL'yi PageSpeed Insights'ta açıp laboratuvar teşhisi yapın.
4. Düzeltmeyi şablon düzeyinde uygulayın; böylece tek değişiklikle yüzlerce sayfa iyileşir.
5. Düzeltme yayına alındıktan sonra rapordaki doğrulama işlemini başlatın ve 28 günlük döngünün tamamlanmasını bekleyin.

Raporu tek başına okumak yerine organik trafik verisiyle birlikte değerlendirmek önceliklendirmeyi kolaylaştırır: zayıf durumdaki şablonlar arasında en çok gösterim ve tıklama alanlar önce ele alınmalıdır. Biz seoanalytics panelinde Search Console performans verisini sayfa bazında topladığımız için bu eşleştirmeyi yapmak, hangi teknik sorunun gerçekten trafik getiren sayfalara dokunduğunu görmeyi hızlandırıyor. Genel bir site değerlendirmesi akışı için SEO Analizi Nasıl Yapılır? yazısındaki adımlar bu çalışmayla iyi birleşir.

LCP nasıl iyileştirilir?

LCP'yi iyileştirirken yukarıdaki dört aşamayı sırayla ele almak en sistematik yoldur.

1. Sunucu yanıt süresini düşürün

HTML geç gelirse geri kalan her şey de gecikir. Sunucu yanıt süresi yüksekse şunlara bakın:

• Sayfa önbellekleme (full page cache) kullanılıyor mu? Her istekte veritabanı sorgusu çalıştıran dinamik sayfalar yavaştır.
• Bir CDN üzerinden sunuluyor musunuz? Kullanıcıya coğrafi olarak yakın bir uç sunucu, gecikmeyi belirgin biçimde azaltır.
• Gereksiz yönlendirmeler var mı? HTTP'den HTTPS'e, ardından www'ye, ardından sonda eğik çizgili adrese giden zincirler her adımda süre ekler.
• Barındırma kaynakları trafik için yeterli mi? Yoğun saatlerde yanıt süresinin uzaması kaynak yetersizliğine işarettir.

2. LCP görselini erken keşfettirin ve önceliklendirin

Tarayıcının LCP görselini mümkün olan en erken anda bulması gerekir. Bunun için görsel, sunucudan gelen HTML içinde standart bir <img> etiketi olarak bulunmalı; JavaScript ile sonradan eklenmemeli. Ardından görsele yüksek öncelik verin:

<img src="/gorseller/kapak.webp" width="1200" height="630"
     fetchpriority="high" alt="Ürün kapak görseli">

LCP görseli CSS arka planı olarak yükleniyorsa ya da başka bir nedenle HTML'de geç keşfediliyorsa, belge başına bir önceden yükleme (preload) ipucu ekleyebilirsiniz:

<link rel="preload" as="image" href="/gorseller/kapak.webp"
      fetchpriority="high">

fetchpriority="high" özelliğini yalnızca LCP görseline verin. Her görsele yüksek öncelik vermek, önceliklendirmeyi anlamsız hale getirir.

3. LCP görselinde tembel yüklemeyi kapatın

Bu, en sık rastlanan ve düzeltmesi en kolay LCP hatasıdır. loading="lazy" özelliği, ekranın altındaki görsellerin geç yüklenmesi için idealdir; ancak ekranın üstünde, ilk görünen alandaki LCP görseline uygulandığında tarayıcı görseli indirmeyi sayfa düzeni hesaplanana kadar erteler. Birçok tema ve eklenti tüm görsellere otomatik olarak tembel yükleme ekler. Kontrol edin ve ilk ekrandaki ana görselden bu özelliği kaldırın:

<!-- Yanlış: ilk ekrandaki ana görsel -->
<img src="/kapak.webp" loading="lazy" alt="...">

<!-- Doğru -->
<img src="/kapak.webp" fetchpriority="high" alt="...">

JavaScript tabanlı tembel yükleme kütüphanelerinde (gerçek adresi data-src gibi bir özellikte tutan çözümler) sorun daha da büyüktür, çünkü görsel betik çalışana kadar hiç keşfedilmez.

4. Görsel boyutunu ve formatını optimize edin

• Modern format kullanın: WebP ve AVIF, aynı görsel kalitede JPEG ve PNG'ye göre genellikle çok daha küçük dosyalar üretir.
• Doğru boyutta sunun: 400 piksel genişliğinde gösterilecek bir görsel için 3000 piksellik orijinali göndermeyin. srcset ve sizes ile cihaza uygun boyutu sunun.
• Sıkıştırmayı ayarlayın: Kalite ayarını makul bir seviyeye çekmek gözle fark edilmeyen ama ciddi boyut kazancı sağlar.
• Görseli aynı alan adından ya da önceden bağlantı kurulmuş bir CDN'den sunun: Farklı bir alan adı ek DNS ve bağlantı süresi demektir; gerekiyorsa <link rel="preconnect"> ile bağlantıyı erken kurun.

5. Render engelleyen CSS ve JavaScript'i azaltın

Görsel indikten sonra bile tarayıcı, sayfanın başındaki CSS dosyaları ve senkron çalışan betikler işlenmeden ekrana bir şey çizemez. Yapılacaklar:

• İlk ekran için gereken kritik CSS'i satır içine alın, kalanını sonra yükleyin.
• Kullanılmayan CSS'i temizleyin; tek bir sayfa için tüm sitenin stil dosyasını yüklemek yaygın bir israftır.
• Sayfanın başındaki betiklere defer veya async ekleyin. İlk görünümü oluşturmak için gerekmeyen hiçbir betik çizimi engellememelidir.
• LCP öğesi metinse, web fontlarının metnin görünmesini geciktirmediğinden emin olun.
• İçeriği istemci tarafında JavaScript ile oluşturan sitelerde, ana içeriğin sunucu tarafında oluşturulmuş HTML olarak gelmesini değerlendirin.

INP nasıl iyileştirilir?

INP sorunlarının neredeyse tamamının kökü aynıdır: tarayıcının ana iş parçacığı meşgulken kullanıcı etkileşimi sırada beklemek zorunda kalır. Ana iş parçacığını kesintisiz 50 milisaniyeden uzun meşgul eden işlere "uzun görev" denir ve INP'nin baş düşmanı bunlardır.

Uzun görevleri bölün

• Büyük işlemleri küçük parçalara ayırın ve parçalar arasında ana iş parçacığını tarayıcıya geri verin. Tarayıcı destekliyorsa scheduler.yield(), desteklemiyorsa setTimeout ile ertelemek klasik yöntemdir.
• Bir etkileşimin ardından önce kullanıcıya görsel geri bildirimi gösterin (örneğin butonun durumunu değiştirin), ağır işi sonraya bırakın.
• Kaydırma ve yazma gibi sık tetiklenen olaylarda işleyicileri sınırlandırın (debounce veya throttle).

Üçüncü taraf betikleri denetleyin

Canlı destek araçları, ısı haritası ve oturum kaydı betikleri, reklam ve takip kodları, sosyal medya gömmeleri INP'yi bozan en yaygın kaynaklardır. Her biri ana iş parçacığında çalışır ve kullanıcının tıklamasıyla yarışır. Yapılacaklar:

1. Sitedeki tüm üçüncü taraf betiklerin listesini çıkarın ve her birinin hâlâ kullanılıp kullanılmadığını sorgulayın.
2. Kullanılmayanları kaldırın. Etiket yönetim sisteminde yıllar içinde biriken eski etiketler sık rastlanan bir sorundur; Google Tag Manager Nedir? yazısında etiketleri düzenli tutmanın yollarını bulabilirsiniz.
3. Gerekli olanları geciktirin: canlı destek penceresi gibi araçları sayfa yüklendikten sonra ya da kullanıcı ilk etkileşimi yaptığında başlatın.
4. Sosyal medya gömmelerini ve video oynatıcıları, kullanıcı tıklayana kadar hafif bir önizleme görseliyle değiştirin.

DOM boyutunu ve ekran güncellemelerini küçültün

Binlerce öğe içeren bir sayfada her etkileşimden sonra stil ve yerleşim hesaplaması uzun sürer. Uzun listeleri sayfalayın veya yalnızca görünen kısmı çizin, gizli menüler ve sekmeler için gereksiz öğe üretmeyin. Etkileşim sonrası tüm sayfayı yeniden çizen yapılar yerine yalnızca değişen kısmı güncelleyin.

CLS nasıl iyileştirilir?

CLS sorunlarının çoğu, tarayıcının bir öğe için ne kadar yer ayıracağını önceden bilmemesinden kaynaklanır.

Görsellere ve videolara boyut verin

Her <img> ve <video> etiketine width ve height özelliklerini yazın. Tarayıcı bu oranı kullanarak görsel gelmeden önce doğru alanı ayırır. CSS'te görseli esnek boyutlandırıyorsanız height: auto ile birlikte bu özellikler oranı korumaya devam eder. Gömülü içerikler için aspect-ratio CSS özelliği de aynı işi görür.

Reklam ve dinamik içerik alanlarını önceden ayırın

Reklam alanları, çerez bildirimleri, "size özel" öneri blokları ve sonradan yüklenen bannerlar CLS'nin klasik kaynaklarıdır. Çözüm, bu alanlar için önceden min-height ile yer ayırmaktır. Reklam gelmese bile alanın boş kalması, içeriğin aşağı itilmesinden daha iyidir. Bildirim çubuklarını içeriği iten bir blok yerine sayfanın üzerine binen sabit konumlu bir öğe olarak göstermek de kaymayı önler.

Font kaynaklı kaymaları azaltın

Web fontu yüklendiğinde yedek fonttan farklı genişlikte olduğu için metin satırları kayabilir. Önemli fontları önceden yükleyin, font-display değerini bilinçli seçin ve yedek fontun ölçülerini size-adjust gibi CSS özellikleriyle web fontuna yaklaştırın. Mümkünse font dosyalarını kendi alan adınızdan sunun.

Animasyonlarda transform kullanın

Öğeleri top, left, height gibi yerleşimi etkileyen özelliklerle hareket ettirmek kaymaya yol açar. Animasyonlar için transform kullanın; bu özellik diğer öğelerin yerini değiştirmez.

Core Web Vitals kontrol listesi

• Search Console Core Web Vitals raporunda mobil tarafta zayıf URL grupları listelendi mi?
• Her şablonda LCP öğesi tespit edildi mi?
• LCP görseli HTML içinde standart bir etiket olarak geliyor mu?
• LCP görselinde loading="lazy" kaldırıldı ve fetchpriority="high" eklendi mi?
• Görseller WebP veya AVIF formatında ve doğru boyutta mı?
• Sunucu yanıt süresi önbellek ve CDN ile düşürüldü mü?
• Render engelleyen CSS ve betikler azaltıldı mı?
• Kullanılmayan üçüncü taraf betikler kaldırıldı, kalanlar geciktirildi mi?
• Tüm görsel ve videolarda width ve height var mı?
• Reklam ve dinamik alanlar için yer ayrıldı mı?
• Düzeltme sonrası Search Console'da doğrulama başlatıldı ve 28 gün sonra sonuç kontrol edildi mi?

Core Web Vitals sıralamayı etkiler mi?

Evet, ama sınırlı ölçüde. Google, sıralama sistemlerinin iyi sayfa deneyimini ödüllendirdiğini ve Core Web Vitals'ın bu değerlendirmede kullanıldığını açıkça belirtir. Aynı zamanda içeriğin alaka düzeyinin ve kalitesinin çok daha belirleyici olduğunu da vurgular. Yani zayıf içerikli ama çok hızlı bir sayfa, aranan soruyu en iyi yanıtlayan ama biraz yavaş bir sayfayı geride bırakmaz.

Core Web Vitals'ın etkisi en çok, içerik kalitesi birbirine yakın sayfaların yarıştığı durumlarda hissedilir. Bunun yanında doğrudan sıralama dışı etkileri de vardır: hızlı ve kararlı sayfalar kullanıcıların daha uzun kalmasını, daha az geri dönmesini ve daha çok dönüşüm yapmasını kolaylaştırır. Bu etkiyi kendi verinizde görmek için iyileştirme öncesi ve sonrası etkileşim ve dönüşüm metriklerini kıyaslayabilirsiniz; Google Analytics Nedir? GA4 yazısı bu karşılaştırmayı kurmanıza yardımcı olur.

Doğru öncelik sırası şudur: önce arama niyetine uyan, kaliteli içerik; sonra taranabilirlik ve indekslenebilirlik; ardından Core Web Vitals. Ama "zayıf" bandındaki metrikleri görmezden gelmek de hatadır; özellikle mobilde zayıf LCP veya INP, hem kullanıcıyı hem de rekabet avantajını kaybettirir.

Sık sorulan sorular

LCP için iyi değer kaç saniyedir?

Google'ın eşiğine göre LCP 2,5 saniye veya altındaysa iyi, 2,5 ile 4 saniye arasındaysa iyileştirme gerekli, 4 saniyenin üzerindeyse zayıftır. Değerlendirme, ziyaretlerin 75. yüzdeliği üzerinden ve mobil ile masaüstü için ayrı yapılır.

PageSpeed puanım yüksek ama Search Console neden zayıf gösteriyor?

PageSpeed Insights'taki performans puanı laboratuvar testinden gelir, Search Console ise gerçek kullanıcıların son 28 günlük saha verisini gösterir. Kullanıcılarınızın cihazları ve bağlantıları test ortamından daha yavaşsa ya da sorun etkileşim sırasında ortaya çıkıyorsa (INP gibi) iki sonuç farklı olur. Hedef olarak saha verisini esas alın.

FID artık kullanılmıyor mu?

FID, Mart 2024'te Core Web Vitals setinden çıkarıldı ve yerini INP aldı. INP, yalnızca ilk etkileşimin gecikmesini değil, ziyaret boyunca etkileşimlerin tamamını ve ekranın güncellenmesini ölçtüğü için daha kapsamlıdır.

İyileştirme yaptım, sonucu ne zaman görürüm?

Laboratuvar testinde etkiyi hemen görebilirsiniz. Saha verisi ise 28 günlük kayan pencereyle hesaplandığı için Search Console ve PageSpeed Insights'taki gerçek kullanıcı verisinin tamamen güncellenmesi yaklaşık dört hafta sürer. Doğrulama işlemini başlattıktan sonra bu süreyi beklemek gerekir.