Core Web Vitals: LCP, INP ve CLS
Core Web Vitals, Google'ın kullanıcı deneyimini ölçmek için tanımladığı üç saha metriğidir: yükleme (LCP), etkileşim (INP) ve görsel kararlılık (CLS). Bu rehber üçünün tanımını, yayımlanmış eşik değerlerini, saha ile laboratuvar verisi farkını ve düzeltme sırasını kaynaklarıyla birlikte veriyor.
Core Web Vitals kısaca nedir, eşikler kaç?
Core Web Vitals üç saha metriğidir: LCP yüklemeyi, INP etkileşimi, CLS görsel kararlılığı ölçer. Google'ın iyi eşikleri: LCP 2,5 sn ve altı, INP 200 ms ve altı, CLS 0,1 ve altı. Eşik, gerçek kullanıcı verisinin 75'inci yüzdeliğinde değerlendirilir. Laboratuvar ölçümü yön gösterir; karar saha verisiyle verilir.
Bu sayfa bir satış materyali değil, referans metnidir. Sayfadaki her sayısal iddianın kaynağı ve erişim tarihi satırın altında yazılıdır; kaynağı olmayan sayı bu sitede yayımlanmaz. Bu çalışmanın hizmet karşılığı için Core Web Vitals ve hız optimizasyonu sayfasına bakabilirsiniz.
Core Web Vitals nedir?
Core Web Vitals, Google'ın bir sayfanın kullanıcı deneyimini ölçmek için tanımladığı üç saha metriğidir: LCP yükleme hızını, INP etkileşim tepkiselliğini, CLS görsel kararlılığı ölçer. Değerler sentetik testten değil, gerçek Chrome kullanıcılarının ziyaretlerinden toplanır ve sayfa görüntülemelerinin 75'inci yüzdeliğinde değerlendirilir. Üçü birden iyi aralıkta olmayan bir sayfa değerlendirmeyi geçemez.
Metriklerin “temel” (core) olması, ölçülen tek şeyin bunlar olduğu anlamına gelmez. TTFB (ilk bayta kadar geçen süre), FCP (ilk içerik boyaması) ve TBT (toplam engellenme süresi) tanı metrikleridir: kendileri eşik taşımaz, ama üç temel metriğin neden bozuk olduğunu açıklarlar. Pratikte çalışma temel metrikle ölçülür, tanı metrikleriyle yürütülür.
Üç metriğin tanımı
LCP — en büyük içerik boyaması
LCP, görünür alandaki en büyük metin bloğunun veya görselin ekrana çizildiği anı, sayfa yüklenmeye başladığı andan itibaren ölçer. Kullanıcının “sayfa açıldı” dediği ana en yakın ölçümdür.
Neden önemli: kurumsal sitelerde LCP ögesi genellikle ürün görseli veya başlık bloğudur. İki saniyede boş kalan bir katalog sayfası, tedarikçi değerlendirmesi başlamadan terk edilir.
INP — sonraki boyamayla etkileşim
INP, ziyaret boyunca gerçekleşen tıklama, dokunma ve tuş etkileşimlerinin gecikmesini ölçer; genellikle en yavaş etkileşim raporlanır. Süre, etkileşim anından ekranın bir sonraki güncellemesine kadar geçen tüm zamanı kapsar.
Neden önemli: form gönderme, filtre uygulama ve sepete ekleme gibi hunideki eylemler bu metriğin içindedir. Yavaş tepki, kullanıcıya sayfanın çalışmadığını düşündürür ve ikinci kez tıklattırır.
CLS — birikimli düzen kayması
CLS, sayfa ögelerinin kullanıcı bir şey yapmadan yer değiştirmesiyle oluşan görsel kararsızlığı ölçer. Birimsiz bir puandır; ziyaret boyunca ölçülen en yoğun kayma penceresi esas alınır.
Neden önemli: kayan bir düğme yanlış tıklamaya yol açar. Teklif formunda bu, doldurulmuş bir formun kaybı demektir ve analitikte terk olarak görünür, hata olarak değil.
Yayımlanmış eşik değerleri
| Metrik | Ne ölçer | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| LCP | Yükleme | 2,5 sn ve altı | 2,5–4,0 sn | 4,0 sn üzeri |
| INP | Etkileşim | 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 |
Kaynak: Google web.dev — Web Vitals (yeni sekmede açılır) · Erişim: 29.07.2026
LCP nedir ve neden yavaşlar?
LCP, görünür alandaki en büyük içerik ögesinin ekrana çizilme anıdır ve iyi kabul edilen eşiği 2,5 saniyedir. Yavaşlamanın nedeni çoğu zaman görselin boyutu değil, keşfedilme zamanıdır: tarayıcı o görselden ancak CSS veya JavaScript çalıştıktan sonra haberdar oluyorsa, indirme geç başlar ve süre buradan uzar.
LCP süresi dört alt bileşene ayrılır. Hangi bileşenin baskın olduğunu bilmeden yapılan iyileştirme tahmindir:
| Bileşen | Ne olur | Tipik çözüm |
|---|---|---|
| Sunucu yanıt süresi (TTFB) | Belgeye ait ilk bayt gelene kadar geçen süre | Önbellek, kenar sunucu, sorgu ve şablon maliyetinin düşürülmesi |
| Kaynağın keşfedilme gecikmesi | Tarayıcı LCP kaynağını HTML'de göremez, sonradan öğrenir | Kaynağı HTML'e taşımak, preload ve fetchpriority kullanmak |
| Kaynağın indirilme süresi | Dosyanın kendisi ağdan uzun sürede iner | Modern format, doğru boyut, sıkıştırma, gereksiz varyantların kaldırılması |
| Ögenin çizilme gecikmesi | Kaynak indi ama ana iş parçacığı meşgul olduğu için çizilmedi | Render'ı bloklayan CSS ve JavaScript'in ayıklanması, kritik CSS |
Kaynak: Google web.dev — Optimize LCP (yeni sekmede açılır) · Erişim: 29.07.2026
Kurumsal sitelerde en sık gördüğümüz üç kalıp şudur: LCP görselinin CSS arka planı olarak tanımlanması, kaydırıcı bileşeninin ilk karesinin JavaScript ile üretilmesi ve fold üstündeki başlığın web fontu inene kadar görünmez kalması. Üçünde de dosya boyutu makul, süre uzundur. Bu sitede hero bölümünde görsel bulunmaması tesadüf değil, bu üç kalıba karşı alınmış bir tasarım kararıdır: LCP ögesi metindir.
INP nedir, FID'den farkı nedir?
INP, ziyaret boyunca yapılan tüm tıklama, dokunma ve tuş etkileşimlerinin tepki süresini ölçer ve genellikle en yavaş olanı raporlar; iyi eşiği 200 milisaniyedir. FID yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu, işin tamamlanmasını değil. INP 12 Mart 2024'te FID'in yerine Core Web Vitals metriği oldu.
| Ölçüt | FID (emekli) | INP (güncel) |
|---|---|---|
| Kapsanan etkileşim | Yalnızca ilk etkileşim | Ziyaret boyunca tüm etkileşimler |
| Ölçülen süre | Etkileşimin işlenmeye başlama gecikmesi | Etkileşimden bir sonraki ekran güncellemesine kadar geçen sürenin tamamı |
| İyi eşiği | 100 ms ve altı | 200 ms ve altı |
| Pratikteki sonucu | Çoğu sitede iyi görünüyordu; sorunu gizliyordu | Filtre, form ve sepet gibi ağır etkileşimleri görünür kılar |
Kaynak: Google web.dev — INP resmen Core Web Vital oldu (yeni sekmede açılır) ve Chrome, FID desteğini sonlandırıyor (yeni sekmede açılır) · Erişim: 29.07.2026
Geçiş takvimi de kaynaklıdır: FID 12 Mart 2024'te Search Console'dan kaldırıldı, diğer Google araçlarında ise 9 Eylül 2024'e kadar süren bir geçiş dönemi tanındı. Bugün hâlâ FID üzerinden raporlama yapan bir panel görüyorsanız, o panel iki yıldır emekli olmuş bir metriği gösteriyor demektir.
INP'yi bozan şey genellikle tek bir hata değil, birikmedir: etiket yöneticisiyle eklenen izleme betikleri, sohbet bileşeni, kampanya sayacı ve filtre bileşeni aynı ana iş parçacığını paylaşır. Her biri tek başına ölçüldüğünde masum görünür; birlikte çalıştıklarında 500 milisaniyeyi aşarlar.
CLS nedir ve nasıl sıfırlanır?
CLS, kullanıcı bir şey yapmadan sayfa ögelerinin yer değiştirmesiyle oluşan görsel kararsızlığın birimsiz puanıdır; iyi eşiği 0,1'dir. Sıfırlanması ölçümle değil, alan rezervasyonuyla olur: her görsele boyut vermek, gömülü içerik için yer ayırmak ve yedek font metriklerini gerçek fontla eşitlemek kaymayı oluşmadan engeller.
CLS'nin dört klasik kaynağı vardır: boyut niteliği verilmemiş görseller, alan ayrılmamış reklam ve gömülü içerik alanları, sayfa yüklendikten sonra mevcut içeriğin üstüne enjekte edilen duyuru ve çerez şeritleri, son olarak da yedek fonttan web fontuna geçişte satır yüksekliğinin değişmesi. Dördü de yayın öncesi kontrol edilebilir; hiçbiri kullanıcı verisi beklemeyi gerektirmez.
Ölçümün iki inceliği vardır. Birincisi, CLS ilk ekranla sınırlı değildir; kullanıcı kaydırdıkça oluşan kaymalar da sayılır. İkincisi, puan toplam değil, ziyaret içindeki en yoğun kayma penceresidir. Bu yüzden yalnızca ilk ekranı düzelten bir çalışma saha verisinde beklenen iyileşmeyi vermez.
Kaynak: Google web.dev — Cumulative Layout Shift (yeni sekmede açılır) · Erişim: 29.07.2026
Saha verisi ile laboratuvar verisi neden farklı çıkar?
Laboratuvar verisi tek cihaz, sabit şebeke ve tek yükleme ile üretilen sentetik bir ölçümdür; tekrarlanabilir olduğu için hata ayıklamaya uygundur. Saha verisi gerçek kullanıcıların cihaz, şebeke ve önbellek çeşitliliğini taşır ve 28 günlük yuvarlanan bir ortalama olarak yayımlanır. Bu yüzden karar saha verisiyle verilir.
| Ölçüt | Saha verisi (CrUX, gerçek kullanıcı izleme) | Laboratuvar verisi (Lighthouse, DevTools) |
|---|---|---|
| Kaynak | Uygun ayarlara sahip gerçek Chrome kullanıcıları | Tek cihaz, emüle edilmiş şebeke ve işlemci |
| Zaman penceresi | 28 günlük yuvarlanan ortalama | Tek çalıştırma, anlık |
| INP ölçülebilir mi | Evet, gerçek etkileşimlerden | Hayır; yerine TBT gibi tanı metrikleri kullanılır |
| Ne için kullanılır | Durum tespiti, önceliklendirme, kabul kararı | Kök neden analizi, düzeltme sırasında hızlı geri bildirim |
| Sonuç ne zaman görünür | Yayın sonrası, veri penceresi dolunca | Aynı dakika |
Kaynak: Chrome for Developers — CrUX API (yeni sekmede açılır) · Erişim: 29.07.2026
Bu farkın pratik sonucu şudur: yayın günü alınan “100 puan” ekran görüntüsü bir kanıt değildir. Saha verisi birikmeden düzeldi denemez, çünkü ölçüm penceresi düzeltmeden önceki günleri de içerir. Takvime bu bekleme süresi baştan yazılmazsa, çalışmanın sonucu tartışmalı hale gelir.
Hangi ölçüm aracı ne için kullanılır?
Durumu saha araçları belirler, nedeni laboratuvar araçları açıklar. Chrome kullanıcı deneyimi raporu ve gerçek kullanıcı izlemesi gerçek durumu verir; Search Console aynı veriyi URL grupları halinde önceliklendirir; PageSpeed Insights ikisini yan yana koyar; Lighthouse ve DevTools performans paneli kök nedeni bulur. Tek araçla yürütülen çalışma eksik kalır.
| Araç | Veri türü | Ne için kullanılır |
|---|---|---|
| Chrome kullanıcı deneyimi raporu (CrUX) | Saha | Gerçek durumun tespiti; kaynak ve URL bazında 28 günlük dağılım |
| Gerçek kullanıcı izleme (kendi kurduğunuz) | Saha | Şablon, cihaz, ülke ve sürüm kırılımı; CrUX'ta görünmeyen sayfalar |
| Search Console — Core Web Vitals raporu | Saha | URL gruplarını benzer sayfa kalıplarına göre önceliklendirme |
| PageSpeed Insights | Saha + laboratuvar | Tek adreste iki veri türünü yan yana okuma |
| Lighthouse | Laboratuvar | Yayın öncesi kontrol, düzeltme sonrası hızlı doğrulama |
| Chrome DevTools performans paneli | Laboratuvar | Uzun görevler, kritik kaynak zinciri ve kayma kaynaklarının tespiti |
Sıralama şudur: saha verisinde sorunu görün, laboratuvarda nedenini bulun, düzeltin, laboratuvarda doğrulayın, sahada teyit edin. Bu döngü tersine çevrildiğinde — yani laboratuvar skorunu yükseltip orada durulduğunda — sayfa araçta iyi, kullanıcıda kötü kalır.
Hız iş sonucunu nasıl etkiler?
Hızın iş sonucuna etkisi için geçerli tek bir formül yoktur; sektör, huni ve cihaz karışımı sonucu değiştirir. Elimizde olan, tek tek şirketlerin kendi siteleri için yayımladığı ölçümlerdir. Aşağıdaki dört bulgunun tamamı kaynaklıdır ve çoğu A/B testiyle üretilmiştir; hiçbiri sizin sayfanıza doğrudan uygulanamaz.
Vodafone, LCP değerini %31 iyileştirdiğinde ölçtüğü toplam satış artışı. Aynı testte ziyaretten talebe dönüşme oranı %15, ziyaretten sepete dönüşme oranı %11 arttı.
Kaynak: Google web.dev — Vodafone vaka çalışması (yeni sekmede açılır) · Erişim: 29.07.2026
Rakuten 24'ün Core Web Vitals odaklı optimizasyon sonrası ölçtüğü ziyaretçi başına gelir artışı. Aynı çalışmada dönüşüm oranı %33,13, ortalama sipariş değeri %15,20 arttı.
Kaynak: Google web.dev — Rakuten 24 vaka çalışması (yeni sekmede açılır) · Erişim: 29.07.2026
Yahoo! JAPAN News, CLS değerini yaklaşık 0,2'den 0'a indirdiğinde ölçtüğü oturum başına sayfa görüntüleme artışı. Oturum süresi %13,3 uzadı, hemen çıkma oranı 1,72 puan geriledi.
Kaynak: Google web.dev — Yahoo! JAPAN News vaka çalışması (yeni sekmede açılır) · Erişim: 29.07.2026
Mobil sitede 0,1 saniyelik hızlanmanın perakende dönüşümüne etkisi; aynı çalışmada ortalama sipariş değeri %9,2 arttı. Deloitte tarafından 37 Avrupa ve Amerika markasının 30 milyondan fazla oturumu üzerinde yürütüldü.
Kaynak: Google web.dev — Milliseconds make millions (Deloitte) (yeni sekmede açılır) · Erişim: 29.07.2026
Bu sayılar sizin sayfanız için ne söyler?
Kesin bir tahmin vermezler. Söyledikleri şudur: dört bağımsız ölçümün dördü de aynı yöne bakıyor ve etkinin büyüklüğü hunide kullanıcının karara en yakın olduğu sayfalarda artıyor. Bu yüzden çalışmayı ana sayfadan değil, teklif formundan, ürün detayından ve kategori listesinden başlatıyoruz.
Sıralama tarafında ise abartılı bir vaat yapmıyoruz. Google, sayfa deneyimi sinyallerinin sıralama sistemlerinde kullanıldığını, ancak iyi bir deneyimin alakasız içeriği öne çıkarmadığını belirtiyor. Pratikte hız, alaka düzeyi benzer sayfalar arasında ayrıştırıcıdır. Bizim taahhüdümüz sıralama değil, ölçülebilir metrik hedefidir.
Kendi sitemizin ölçülmüş değerlerini de aynı kuralla yayımlıyoruz: araç adı, ölçüm profili ve ölçüm tarihiyle birlikte, Kanıt sayfasında. Ölçülemeyen hiçbir satır bu sitede yayımlanmaz.
LCP, INP ve CLS hangi sırayla düzeltilir?
Sıra ölçümle başlar, tahminle değil. Önce saha verisinden şablon bazlı dağılım çıkarılır; sonra en çok trafik alan üç şablon seçilir. LCP kök nedeni dört alt bileşene ayrılır, CLS kaynağında kapatılır, INP için uzun görevler bölünür, üçüncü taraf betikler envantere alınır ve bütçe yayın hattına bağlanır.
-
01
Sahadan başlayın, laboratuvardan değil
Önce gerçek kullanıcı verisini toplayın: CrUX ve mümkünse kendi kurduğunuz gerçek kullanıcı izlemesi. Tek bir skor değil, sayfa şablonu ve cihaz türü bazında dağılım çıkarın. Laboratuvar ölçümü bu dağılımı açıklamak için kullanılır, onun yerine geçmez.
-
02
Sayfayı değil şablonu seçin
Kurumsal sitelerde sorun tek sayfada değil şablondadır. En çok trafik alan ve dönüşüme en yakın üç şablonu seçin: ürün veya hizmet detayı, kategori listesi, form sayfası. Bir şablondaki düzeltme yüzlerce sayfayı birlikte taşır; tek sayfada yapılan düzeltme ise ölçülemeyecek kadar küçük kalır.
-
03
LCP ögesini bulun ve dörde ayırın
Önce hangi ögenin LCP ögesi olduğunu tespit edin; çoğu tahmin burada yanlış çıkar. Sonra süreyi dört parçaya ayırın: sunucu yanıt süresi, keşfedilme gecikmesi, indirilme süresi ve çizilme gecikmesi. En büyük parça hangisiyse çalışma oradan başlar.
-
04
CLS'yi kaynağında kapatın
Kaymayı sonradan düzeltmeye çalışmayın, oluşmasını engelleyin: her görsel ve videoya genişlik ve yükseklik veya en boy oranı verin, reklam ve gömülü içerik için alanı önceden ayırın, yedek font metriklerini gerçek font metriklerine göre ayarlayın. CLS, kullanıcı verisi beklemeden yayın öncesi kapatılabilen tek metriktir.
-
05
INP için uzun görevleri bölün
Ana iş parçacığını 50 milisaniyeden uzun süre meşgul eden görevleri ölçün ve bölün. Olay işleyicilerinde ağır iş yapmayın; görsel geri bildirimi bekletmeyin, hesaplamayı erteleyin. INP yalnızca gerçek etkileşimle oluştuğu için laboratuvarda TBT gibi tanı metrikleriyle çalışılır, doğrulama sahada yapılır.
-
06
Üçüncü taraf betikleri envantere alın
Etiket yöneticisi, sohbet aracı, ısı haritası ve reklam betiklerini tek tek listeleyin. Her birinin ana iş parçacığında geçirdiği süreyi ölçün, sahibini ve iş gerekçesini yazın. Gerekçesi olmayan betik kaldırılır, gerekli olan ertelenir veya kullanıcı onayı sonrasına alınır. Bu adım genellikle en büyük INP kazancını verir.
-
07
Bütçeyi yayın hattına bağlayın
Sayfanın aşamayacağı sayısal sınırları yazın ve yayın öncesi otomatik kontrole bağlayın: bütçeyi aşan değişiklik yayına çıkmaz. Ardından saha verisini periyodik izleyin. Bu adım atlanırsa kazanım birkaç sürüm içinde geri alınır; performans kendiliğinden kalıcı olmaz.
Performans bütçesi nasıl kurulur?
Performans bütçesi, bir sayfanın aşamayacağı sayısal sınırlar kümesidir ve üç türü vardır: metrik sınırı, kaynak ağırlığı sınırı ve istek sayısı sınırı. Bütçe bir belge değil, yayın hattında çalışan otomatik bir kontroldür. Sınırı aşan değişiklik yayına çıkmaz; bu mekanizma kurulmazsa optimizasyon birkaç sürüm içinde geri alınır.
Aşağıdaki tablo bu sitenin yayın hattında uygulanan bütçesidir. Örnek olsun diye yazılmadı: derleme adımı bu sınırları her yayında kontrol eder ve aşıldığında derlemeyi durdurur.
| Kalem | Sınır | Sınır türü |
|---|---|---|
| LCP (mobil) | < 1,8 sn | Metrik |
| CLS | < 0,05 | Metrik |
| INP | < 200 ms | Metrik |
| Satır içi kritik CSS | ≤ 9 KB gzip | Kaynak ağırlığı |
| Toplam CSS | ≤ 30 KB gzip | Kaynak ağırlığı |
| Toplam JavaScript | ≤ 12 KB gzip | Kaynak ağırlığı |
| Web fontu | 2 dosya · ≤ 60 KB | Kaynak ağırlığı |
| Fold üstü görsel | 0 | İstek sayısı |
| Üçüncü taraf istek (onay öncesi) | 0 | İstek sayısı |
Bütçe yazarken üç kural işe yarar: sınırı bugünkü değerin biraz altına koyun (ulaşılamayan bütçe yok sayılır), her sınıra bir ölçüm aracı yazın, ve sınırı aşan değişikliğin ne olacağını baştan kararlaştırın. Uygulamanın hizmet karşılığı: Core Web Vitals ve hız optimizasyonu.
En sık yapılan yedi hata nedir?
En sık yapılan hata, laboratuvar skorunu saha verisi sanmaktır. Onu ortalamaya bakmak, LCP ögesini yanlış tespit etmek, CLS'yi yalnızca ilk ekranda ölçmek, INP'yi laboratuvarda aramak, her şeyi görsel sıkıştırmayla çözmeye çalışmak ve bütçesiz optimizasyon yapmak izler. Yedisinin ortak noktası ölçüm hatasıdır, kod hatası değil.
- Laboratuvar skorunu saha verisi sanmak. Yayın günü alınan yüksek Lighthouse puanı sayfanın gerçek kullanıcı deneyimini göstermez; kararı saha verisi verir.
- Ortalamaya bakmak. Eşikler 75'inci yüzdelikte değerlendirilir. Ortalama iyi görünürken kullanıcıların dörtte biri zayıf aralıkta olabilir; kayıp tam orada gerçekleşir.
- LCP ögesini yanlış tespit etmek. Çoğu ekip hero görselini varsayar; ölçüm sık sık başlık bloğunu veya kaydırıcının ikinci karesini gösterir. Yanlış ögeye yapılan iyileştirme sonucu değiştirmez.
- CLS'yi yalnızca ilk ekranda ölçmek. Kayma kullanıcı kaydırdıkça da oluşur ve puan ziyaretteki en yoğun pencereden gelir. İlk ekranı düzeltmek çoğu zaman yeterli olmaz.
- INP'yi laboratuvarda aramak. INP yalnızca gerçek etkileşimle oluşur. Laboratuvarda TBT gibi tanı metrikleriyle çalışılır; “laboratuvarda INP yok, demek ki sorun yok” sonucu yanlıştır.
- Her şeyi görsel sıkıştırmayla çözmeye çalışmak. Görselleri küçültmek çoğu kurumsal sitede LCP'nin en küçük bileşenine dokunur; asıl süre sunucu yanıtında ve kaynağın geç keşfedilmesindedir.
- Bütçesiz optimizasyon yapmak. Yayın hattına bağlanmamış bir iyileştirme, eklenen ilk etiket veya bileşenle geri alınır. Kalıcılık disiplinle değil mekanizmayla sağlanır.
Yayın öncesi 18 maddelik kontrol listesi
Bu on sekiz madde, bir sayfanın Core Web Vitals açısından yayına hazır sayılması için kontrol edilmesi gerekenlerdir: altısı LCP, dördü CLS, dördü INP, dördü ölçüm ve bütçe disiplini içindir. Listenin sonundaki kutudan tamamını kopyalayıp kendi yayın kontrol dokümanınıza ekleyebilirsiniz.
LCP · 6 madde
- Her ana şablon için LCP ögesi tespit edildi ve yazılı olarak kayıt altına alındı.
- LCP kaynağı HTML'de keşfedilebilir durumda; CSS arka planı veya JavaScript ile sonradan enjekte edilmiyor.
- LCP görseli
fetchpriority="high"ile işaretlendi veloading="lazy"ile işaretlenmedi. - Render'ı bloklayan CSS ve JavaScript ayıklandı; fold üstü için gereken CSS satır içine alındı.
- Sunucu yanıt süresi ölçüldü, önbellek politikası yazıldı ve doğrulandı.
- Web fontları kendi sunucumuzda barındırılıyor, ön yüklemesi yapıldı ve
font-displaystratejisi belirlendi.
CLS · 4 madde
- Tüm görsel ve video ögelerinde genişlik ve yükseklik veya en boy oranı tanımlı.
- Reklam, harita ve gömülü içerik alanları için yer önceden rezerve edildi.
- Yedek font metrikleri gerçek font metriklerine göre ayarlandı; font değişimi kayma üretmiyor.
- Sayfa yüklendikten sonra mevcut içeriğin üstüne itilen duyuru, şerit veya banner yok.
INP · 4 madde
- 50 milisaniyeden uzun görevler ölçüldü ve bölündü.
- Olay işleyicileri ağır iş yapmıyor; hesaplama bir sonraki boyamadan sonraya erteleniyor.
- Üçüncü taraf betiklerin her biri envanterde; sahibi, gerekçesi ve ana iş parçacığı maliyeti yazılı.
- Kullanıcı etkileşimine görsel geri bildirim, ağır iş tamamlanmadan veriliyor.
Ölçüm ve bütçe · 4 madde
- Ölçüm hem saha hem laboratuvar verisiyle yapılıyor; kabul kararı saha verisine göre veriliyor.
- Değerler 75'inci yüzdelikte, mobil ve masaüstü ayrı ayrı okunuyor.
- Performans bütçesi yazılı ve yayın hattında otomatik kontrol ediliyor.
- Yayın sonrası saha verisi periyodik izleniyor; sapma bir sahibine raporlanıyor.
CORE WEB VITALS · YAYIN ÖNCESİ KONTROL LİSTESİ (18) # LCP - [ ] 01 LCP ögesi her şablon için tespit edildi ve yazıldı - [ ] 02 LCP kaynağı HTML'de keşfedilebilir - [ ] 03 fetchpriority="high" verildi, loading="lazy" verilmedi - [ ] 04 Render'ı bloklayan CSS/JS ayıklandı, kritik CSS satır içi - [ ] 05 Sunucu yanıt süresi ölçüldü, önbellek politikası yazıldı - [ ] 06 Fontlar self-host, preload ve font-display stratejisi tanımlı # CLS - [ ] 07 Tüm görsel/videoda width+height veya aspect-ratio var - [ ] 08 Reklam, harita ve gömülü içerik için alan rezerve edildi - [ ] 09 Yedek font metrikleri gerçek fontla eşitlendi - [ ] 10 Yüklemeden sonra içeriği iten duyuru/şerit yok # INP - [ ] 11 50 ms üzeri uzun görevler ölçüldü ve bölündü - [ ] 12 Olay işleyicileri ağır iş yapmıyor, hesaplama erteleniyor - [ ] 13 Üçüncü taraf betik envanteri: sahip, gerekçe, maliyet - [ ] 14 Etkileşime görsel geri bildirim ağır iş beklemeden veriliyor # ÖLÇÜM VE BÜTÇE - [ ] 15 Saha + laboratuvar birlikte; karar saha verisine göre - [ ] 16 Değerler 75'inci yüzdelikte, mobil ve masaüstü ayrı - [ ] 17 Performans bütçesi yazılı ve yayın hattında otomatik - [ ] 18 Yayın sonrası saha verisi izleniyor, sapma raporlanıyor
Bu rehberde geçen terimler ne anlama geliyor?
Rehberde on üç teknik terim geçiyor. Her birinin kısa ve tek başına anlaşılır tanımı dijital görünürlük sözlüğümüzde, kendi ankoruyla birlikte duruyor. Aşağıdaki liste tanımların özetini verir; tam tanım, ilgili terimler ve kullanım örnekleri için sözlük girişlerine gidebilirsiniz.
- Core Web Vitals — LCP, INP ve CLS'den oluşan üç saha metriğinin ortak adı.
- LCP — görünür alandaki en büyük içerik ögesinin çizilme anı.
- INP — etkileşimden bir sonraki ekran güncellemesine kadar geçen süre.
- FID — INP'nin yerini aldığı, ilk etkileşim gecikmesini ölçen emekli metrik.
- CLS — kullanıcı kaynaklı olmayan düzen kaymalarının birimsiz puanı.
- TTFB — ilk bayta kadar geçen süre; LCP'nin ilk alt bileşeni.
- TBT — laboratuvarda ana iş parçacığının toplam engellenme süresi.
- CrUX — Chrome kullanıcı deneyimi raporu; 28 günlük yuvarlanan saha verisi.
- Saha verisi — gerçek kullanıcı ziyaretlerinden toplanan ölçüm.
- Laboratuvar verisi — sabit koşullarda üretilen sentetik ölçüm.
- Lighthouse — laboratuvar ölçümü üreten açık kaynaklı denetim aracı.
- Performans bütçesi — sayfanın aşamayacağı sayısal sınırlar kümesi.
- Kritik render yolu — ilk boyama için zorunlu kaynakların oluşturduğu zincir.
Devamı: dijital görünürlük sözlüğü · Arama görünürlüğünün diğer iki ekseni: AEO nedir ve GEO nedir · Makine okunabilirliği: Schema.org ve JSON-LD rehberi.
Core Web Vitals hakkında sık sorulan sorular
Altı soru, doğrudan cevaplar. Sayısal iddiaların kaynağı ve erişim tarihi cevabın içinde yazılıdır.
Core Web Vitals nedir?
Core Web Vitals, Google'ın bir sayfanın kullanıcı deneyimini ölçmek için tanımladığı üç saha metriğinin ortak adıdır. LCP yükleme hızını, INP etkileşim tepkiselliğini, CLS görsel kararlılığı ölçer. Veriler sentetik testten değil, uygun ayarlara sahip gerçek Chrome kullanıcılarının ziyaretlerinden toplanır ve sayfa görüntülemelerinin 75'inci yüzdeliğinde değerlendirilir. Üç metrikten biri eşiğin dışındaysa sayfa değerlendirmeyi geçmez.
İyi LCP, INP ve CLS değerleri kaç?
Google'ın yayımladığı eşiklere göre iyi aralık şudur: LCP 2,5 saniye ve altı, INP 200 milisaniye ve altı, CLS 0,1 ve altı. İyileştirilmeli aralığı sırasıyla 2,5–4,0 saniye, 200–500 milisaniye ve 0,1–0,25'tir; bu değerlerin üzeri zayıf sayılır. Eşikler mobil ve masaüstü için ayrı ayrı, sayfa görüntülemelerinin 75'inci yüzdeliğinde okunur. Kaynak: Google web.dev, erişim 29 Temmuz 2026.
INP ile FID arasındaki fark nedir?
FID yalnızca ilk etkileşimin gecikmesini ölçerdi ve tarayıcının cevap verme süresini kapsamıyordu; bu yüzden çoğu sitede iyi görünüyordu. INP ise ziyaret boyunca gerçekleşen tüm tıklama, dokunma ve tuş etkileşimlerini ölçer ve etkileşimden bir sonraki ekran güncellemesine kadar geçen sürenin tamamını hesaba katar. INP 12 Mart 2024'te FID'in yerine Core Web Vitals metriği oldu; FID aynı gün Search Console'dan kaldırıldı ve diğer Google araçlarında 9 Eylül 2024'e kadar süren bir geçiş dönemiyle emekliye ayrıldı.
Saha verisi ile laboratuvar verisi neden farklıdır?
Laboratuvar verisi tek cihaz, sabit şebeke ve tek yükleme ile sentetik olarak üretilir; tekrarlanabilir olduğu için hata ayıklamaya uygundur. Saha verisi gerçek kullanıcıların cihaz, şebeke, önbellek ve etkileşim çeşitliliğini taşır. Chrome kullanıcı deneyimi raporu bu veriyi 28 günlük yuvarlanan bir ortalama olarak yayımlar. INP yalnızca gerçek etkileşimle oluştuğu için laboratuvarda tam karşılığı yoktur. Karar saha verisiyle verilir, laboratuvar verisi nedeni açıklar.
Hangi ölçüm aracı ne için kullanılır?
Chrome kullanıcı deneyimi raporu ve gerçek kullanıcı izlemesi saha verisi verir; durumu bunlar belirler. Search Console'un Core Web Vitals raporu aynı saha verisini URL grupları halinde gösterir, önceliklendirme için kullanılır. PageSpeed Insights tek adreste saha ve laboratuvar verisini yan yana koyar. Lighthouse ve Chrome DevTools performans paneli laboratuvar verisi üretir; kök neden analizi ve düzeltme doğrulaması için kullanılır. Tek araçla yürütülen bir çalışma eksik kalır.
Performans bütçesi nasıl kurulur?
Performans bütçesi, bir sayfanın aşamayacağı sayısal sınırlar kümesidir. Üç tür sınır yazılır: metrik sınırı (örneğin mobil LCP 1,8 saniye, CLS 0,05), kaynak sınırı (ilk yüklemede gönderilen JavaScript ve CSS ağırlığı, font sayısı) ve istek sınırı (onay öncesi üçüncü taraf istek sayısı). Bütçe bir belge değil, yayın hattında çalışan otomatik bir kontroldür: sınırı aşan değişiklik yayına çıkmaz. Bütçesiz optimizasyon birkaç sürüm içinde geri alınır.
Mevcut dijital varlığınızın ölçülmüş durumunu 5 iş günü içinde görün.
Denetim ücretsizdir ve karşılığında bir çalışma zorunluluğu doğurmaz. Raporda beş eksenin bulguları madde madde yer alır: AEO cevaplanabilirliği, yapay zekâ tarayıcı erişimi, Core Web Vitals laboratuvar ölçümü, yapılandırılmış veri geçerliliği ve otomatik erişilebilirlik taraması.
Kurumsal ölçekte, çok lokasyonlu veya çok dilli yapılarla çalışıyoruz. Tek seferlik küçük işler kapsamımız dışında; bu durumda daha küçük ölçekli stüdyolara yönlendiriyoruz.