Core Web Vitals Nedir? LCP, CLS ve INP Rehberi

Hızlı bir sayfa demek kolay.

Ama kullanıcı açısından hızlılık ne demek? Çoğu zaman tüm dosyalar yüklendiğinde değil, aradığı ana içeriği gördüğünde rahatlar. Düzen kaymıyorsa, tıkladığında sayfa hemen tepki veriyorsa deneyimi olumlu bulur. Core Web Vitals tam olarak bu hissedilen kaliteyi üç ölçülebilir başlık altında toplar.

Performans konuşmasını soyutluktan çıkarıp karar verilebilir hale getirmek değerlidir. "Site biraz ağır" ya da "arayüz garip hissettiriyor" gibi cümleler ekip içinde işe yaramaz. Buna karşılık "ana içerik geç geliyor", "ekran oynuyor" ya da "etkileşimler ağır kalıyor" dediğinizde çözüm yolu daha net görünür. Yalnızca SEO için değil, ürün kalitesi için de önemlidir.

Neden üç ayrı metrik var?

Kullanıcı deneyimi tek boyutlu değil. Sayfa çabuk açılmış gibi görünür ama ana içerik geç gelirse deneyim eksik kalır. Düzen çok hızlı kurulmuş olabilir ama sonradan kayıyorsa güven hissi bozulur.

Tıklamaya bastığınızda arayüz ağır tepki veriyorsa, yükleme süresi iyi olsa bile kalite algısı düşer. Tek bir skor bütün bu farklı kırılmaları yeterince ayıramaz. LCP, CLS ve INP ayrı ayrı tanımlanır.

Her problem farklı çözüm yolu ister. İlk ekranı hızlandırmakla, yerleşimi kararlı hale getirmek ya da etkileşim gecikmesini azaltmak aynı teknik hamle değildir. Ekip hangi başlığın bozulduğunu net görürse, zamanını çok daha doğru yere harcar.

LCP neyi ölçer?

LCP, kullanıcının ilk ekranda gördüğü en büyük anlamlı içeriğin ne zaman görünür hale geldiğine bakar. Kahraman görsel, büyük başlık bloğu ya da baskın bir medya öğesi. Kullanıcı çoğu zaman bu ana içeriği gördüğünde "sayfa geldi" der. LCP yalnızca teknik bir zaman ölçüsü değil, ilk izlenimin temposudur. İyi kabul edilen eşik çoğu senaryoda 2,5 saniye ve altıdır.

LCP yüksek çıktığında tek suçlu görsel değildir.

Sunucu yanıtı geç olabilir, kritik CSS sırası bozulmuş olabilir, ilk ekranda gerekli olmayan script'ler öne alınmış olabilir ya da büyük medya yanlış önceliklendirilmiş olabilir. LCP konuşulurken yalnızca dosya boyutuna takılmak çoğu zaman eksik okumadır.

CLS neyi ölçer?

CLS, sayfa yüklendikten sonra düzenin beklenmedik biçimde oynayıp oynamadığını izler. Kullanıcı bir paragrafı okurken görsel geldiğinde içerik aşağı kayıyorsa, bir butona basmak üzereyken üstten bar açılıp her şeyi itiyorsa ya da font değişimi satırları yerinden oynatıyorsa burada CLS sorunu vardır. Küçük görünür ama kullanıcı güveni üzerinde etkisi büyüktür. İyi eşik çoğu durumda 0,1 ve altıdır.

Özellikle medya yoğun sayfalarda sorun daha görünür hale gelir. Yer ayrılmadan yüklenen görseller, geç açılan reklam alanları, sonradan eklenen duyuru bantları ve yanlış kurgulanmış bileşenler düzeni bozar. Kullanıcı bunu teknik terimle anlatmaz; fakat sayfayı özensiz bulur.

INP neyi ölçer?

INP, kullanıcının bir etkileşim sonrası ne kadar beklediğini anlamaya çalışır.

Tıklama, dokunma, sekme değiştirme, filtre uygulama, form kullanma gibi anlarda arayüzün ne kadar canlı tepki verdiği burada önemlidir. Özellikle büyük JavaScript paketleri, yoğun üçüncü taraf kodları ve yanlış önceliklendirilmiş modüller bu metriği zayıflatabilir. Bazı projelerde code splitting ve teslimat sırası INP için kritik hale gelir.

Metrikler birbirini etkiler mi?

Evet, hem olumlu hem olumsuz etkiler vardır.

İlk ekrandaki büyük görseli doğru önceliklendirmek LCP'yi iyileştirir; aynı görsele boyut tanımlamak CLS'yi de toparlayabilir. Gereksiz script yükünü azaltmak hem ilk boyamayı rahatlatır hem etkileşim gecikmesini düşürebilir. Buna karşılık her şeyi lazy load yapmak LCP'yi bozabilir. Aşırı preload kullanımı ağ rekabeti yaratabilir. Her değişikliği bütün deneyim üzerinden düşünmek gerekir.

İyi performans çalışması tam da burada olgunlaşır. Ekip tek bir metriği takıntı haline getirmek yerine, hangi müdahalenin diğer metriklere ne yapacağını tartmaya başlar. Performansın gerçek anlamda ürün kalitesine dönüşmesi buradan gelir.

Sayfa tipine göre öncelik değişir mi?

Evet. İçerik odaklı bir blog yazısında ilk ekran medyası ve başlık öne çıkıyorsa LCP daha baskın olabilir. Filtreli ürün listelemesinde kullanıcı etkileşimi yoğun olduğu için INP daha görünür hale gelebilir.

Reklam alanları, gömülü medya ve duyuru bantları olan ekranlarda ise CLS daha kırılgan olur. Her sayfaya tek tip performans reçetesi uygulamak verimli değildir. Önce sayfanın işlevi anlaşılmalıdır.

Kullanıcı bu sayfaya ne yapmak için geliyor? Okumak mı, seçmek mi, hızlıca bir şey karşılaştırmak mı, form doldurmak mı? Sorunun cevabı hangi metriğe önce bakmanız gerektiğini belirler. Performans ölçümü ürün bağlamından koparsa rapor doğru görünür ama karar yanlış çıkabilir.

İyileştirme sırası nasıl kurulmalı?

1. Önce kullanıcı açısından bozulmuş sinyali bulun.
2. Sonra sinyali büyüten teknik katmanları ayırın.
3. Yüksek etkili değişiklikleri tek tek uygulayın.
4. Sonucu hem laboratuvar hem gerçek kullanım verisiyle yeniden okuyun.
5. İşe yarayan kalıbı benzer sayfalara yayın.

Küçük ekipler için özellikle değerlidir. Her şeyi aynı anda çözmeye çalışmak odağı dağıtır. Oysa önce en görünür kırılmayı toparlamak hem kullanıcı tarafında fark yaratır hem ekip motivasyonunu artırır.

En sık yapılan yanlışlar

Tek metriği başarı ölçüsü sanmak

Örneğin yalnızca LCP'yi düzeltip siteyi başarılı saymak, etkileşim gecikmesini görünmez kılabilir. Aynı şekilde yalnızca etkileşim hızına bakıp ilk ekranı ihmal etmek de yanlıştır.

Performansı sadece geliştirici sorunu görmek

Oysa tasarım kararları, medya kullanımı, içerik yoğunluğu ve üçüncü taraf servis seçimi de metrikleri doğrudan etkiler. İyi sonuç için ortak sahiplik gerekir.

Her sayfaya aynı çözümü kopyalamak

Bir ürün detay sayfasında işe yarayan karar, editoryal içerikte aynı sonucu üretmeyebilir. Sayfa amacı her zaman yeniden düşünülmelidir.

Ekip içinde nasıl kullanılmalı?

Performansı daha anlamlı başlıklara ayırabilmek, ekibin neyin gerçekten bozulduğunu görmesini kolaylaştırır.

Hangi sırayla düzeltilmeli? Neden bozuldu? Cevaplar daha açık hale gelir. Kazanç sadece daha iyi skor değil; ürün davranışının olgunlaşmasıdır.

Sahiplik nasıl dağıtılmalı?

Core Web Vitals yalnızca ön yüz geliştiricisinin meselesi gibi görülürse ilerleme yavaşlar. LCP çoğu zaman medya kullanımına, CLS tasarım kararlarına, INP ise ürün akışına ve script mimarisine temas eder.

Sağlıklı model, her metriğin tek sahibi olması değil; sorumluluk alanlarının birlikte görünür hale gelmesidir. İçerik ekibi ilk ekran medyasının ağırlığını bilmeli, tasarım ekibi sonradan açılan bileşenlerin düzen etkisini hesaba katmalı, geliştirici de teslimat sırasını buna göre kurmalıdır.

Ortak sahiplik kurulduğunda performans tartışması teknik bir ek iş olmaktan çıkar. Ürünün parçası haline gelir. Yapılan iyileştirmeler daha kalıcı olur; yalnızca sonradan eklenen yama değil, başlangıçta verilen kararlara da yansır.

Hedef koyarken hangi denge korunmalı?

Sayısal hedef koymak faydalıdır ama bağlamdan koparsa baskı üretir.

Her sayfanın aynı hızda aynı eşiğe ulaşmasını beklemek gerçekçi değildir. Bazı sayfalar medya yoğun, bazıları etkileşim yoğun, bazıları ise doğası gereği daha karmaşık olabilir. Hedefler sayfa tipine göre okunmalı ve gelişme yönü de başarı kabul edilmelidir. Sadece "iyi" bölgesine geçmek değil, kullanıcıyı rahatsız eden asıl kırılmaları azaltmak da önemli ilerlemedir.

Dengeyi kuran ekipler, metrikleri cezalandırma aracı olarak kullanmaz. Onları yön duygusu oluşturan bir çerçeve gibi görür. Ürün tarafında gerçekten işe yaraması da buna bağlıdır.

Asıl fayda nedir?

Performans konuşmasını soyutluktan çıkarmasıdır. "Site biraz ağır" gibi genel cümleler yerine "ana içerik geç geliyor", "yerleşim kayıyor", "etkileşim gecikiyor" gibi net başlıklar üretir.

Netlik, ekip içinde çözüme giden yolu kısaltır. Hangi probleme neden hangi değişiklik yapıldığını anlatmak kolaylaşır.

Kazanılan şey yalnızca daha iyi rapor değildir. Daha doğru öncelik, daha tutarlı ürün kararı ve daha açıklanabilir teknik yön ortaya çıkar.

Pratik değerlendirme

Bir sayfada önce hangi metriğe bakacağınıza karar veremiyorsanız kullanıcıya ilk soruyu sorun: burada en çok ne rahatsız ediyor?

Geç gelen ana içerik mi, oynayan düzen mi, ağır etkileşim mi? Basit yaklaşım, teknik tartışmayı ürün tarafıyla aynı çizgiye getirir.

Core Web Vitals yalnızca performans raporu olmaktan çıkar. Ürünün ilk bakış, ilk okuma ve ilk tepki kalitesini izleyen ortak sözlüğe dönüşür. Sözlük kurulduğunda ekip içi kararlar çok daha hızlı netleşir.

Çerçevenin değeri, ekibi daha çok rapor okumaya zorlaması değil; daha az dağınık karar aldırmasıdır. İyi performans kültürü çoğu zaman buradan doğar.

Performansı tek cümlede değil, doğru başlıklar altında konuşabilmek ekip olgunluğu yaratır. Olgunluk kurulduğunda yapılan işin etkisi daha net, önceliği daha berrak ve sonucu daha ölçülebilir hale gelir.

Bir ekip Core Web Vitals metriklerini düzenli izlemeye başladığında zamanla şunu fark eder: performans işi sonradan yapılan yamalardan çok, baştan verilen kararlarla ilgilidir.

İlk ekran medyası, geç açılan bileşenler, ağır etkileşimler ve teslimat sırası daha proje aşamasında düşünülürse, düzeltme ihtiyacı da azalır. Core Web Vitals yalnızca ölçüm sistemi değil, daha dikkatli ürün inşa etme biçimidir.

Kazanılan şey sadece daha iyi rapor değildir; ekip içinde daha net sorular sorulmasıdır. Hangi öğe neden önce gelmeli, neden sabit kalmalı, neden hızlı tepki vermeli gibi sorular çoğaldıkça kalite doğal olarak yükselir.

Devam etmek isterseniz önce LCP, ardından CLS ve ilk ekranı tutan katmanlar için render engelleyen kaynaklar yazılarına geçebilirsiniz.