Core Web Vitals ve Sayfa Hızı: Neden Kritik?

Core Web Vitals nedir?

Core Web Vitals, gerçek kullanıcı deneyiminin yükleme, etkileşim ve görsel kararlılık boyutlarını ölçmeye yardımcı olan üç temel web performans metriğidir. Largest Contentful Paint ana içeriğin görünme süresini, Interaction to Next Paint kullanıcı etkileşimlerine verilen yanıtı, Cumulative Layout Shift ise beklenmeyen yer değiştirmeleri değerlendirir.

Bu metrikler web sitesinin bütün kalitesini tek başına açıklamaz. Erişilebilirlik, içerik doğruluğu, güvenlik, gezinme ve işlevsellik ayrıca değerlendirilmelidir. Bununla birlikte LCP, INP ve CLS farklı sayfa türlerindeki somut performans problemlerini ortak bir dille izlemeyi sağlar.

Core Web Vitals hem SEO hem kullanıcı deneyimi bağlamında önemlidir; ancak tek amaç yeşil puan almak olmamalıdır. Kullanıcının ana içeriğe hızlı ulaşması, butona bastığında yanıt görmesi ve sayfanın dokunma sırasında yer değiştirmemesi gerçek hedeftir. Metrik iyileştirmesi bu kullanıcı problemlerinin çözümünden doğmalıdır.

Saha verisi ile laboratuvar verisi arasındaki fark nedir?

Laboratuvar verisi kontrollü cihaz ve ağ koşulunda yapılan tekil testtir. Lighthouse veya PageSpeed Insights laboratuvar bölümü, belirli anda sayfayı analiz eder ve hata nedenlerini araştırmak için ayrıntılı öneriler sunar. Kod değişikliğinin etkisini hızlı karşılaştırmak için yararlıdır.

Saha verisi, gerçek ziyaretçilerin farklı cihaz, konum, ağ ve kullanım koşullarında yaşadığı deneyimi toplar. Chrome User Experience Report ve gerçek kullanıcı izleme araçları bu tür veriler sağlayabilir. Core Web Vitals değerlendirmesi genellikle son 28 günlük dönemde kullanıcıların yüzde 75’lik dilimindeki deneyime bakar.

Laboratuvar testi iyi, saha verisi kötü olabilir. Test güçlü cihazda çalışırken gerçek kullanıcıların çoğu orta sınıf telefonda olabilir; giriş yapmış kullanıcılara farklı içerik sunulabilir veya üçüncü taraf script yalnız belirli ülkelerde yavaşlayabilir. Tersi durumda tek laboratuvar testi geçici ağ sorunuyla kötü sonuç verebilir. İki veri türü birlikte yorumlanmalıdır.

LCP nedir ve neyi ölçer?

Largest Contentful Paint, görünür alan içindeki en büyük içerik öğesinin çizilme zamanını ölçer. Bu öğe çoğu sayfada hero görseli, büyük başlık bloğu veya ana içerik görseli olabilir. LCP, kullanıcının sayfanın asıl içeriğinin geldiğini ne zaman hissettiğine dair pratik gösterge sunar.

İyi LCP optimizasyonu yalnız görsel sıkıştırmak değildir. Süre; sunucunun ilk byte cevabı, kaynağın HTML içinde ne kadar erken keşfedildiği, indirme süresi ve tarayıcının öğeyi ne zaman render edebildiği aşamalarına ayrılır. Her aşama farklı çözüm gerektirir.

LCP öğesi sayfa ve cihaz genişliğine göre değişebilir. Masaüstünde büyük görsel, telefonda metin bloğu ölçülebilir. Test araçlarında gerçek LCP öğesi incelenmeli; varsayımla optimizasyon yapılmamalıdır. Slider gibi bileşenlerde ilk görünür slaytın yükleme stratejisi ayrıca önemlidir.

LCP nasıl iyileştirilir?

Önce sunucu yanıt süresi ölçülür. Yavaş veritabanı, ağır PHP işlemi, uzak API veya eksik önbellek HTML’in geç gelmesine neden olabilir. Uygulama ve sunucu önbelleği, sorgu optimizasyonu, CDN ve uygun barındırma değerlendirilebilir. Ancak dinamik içerikte eski veri göstermemek için cache kuralları dikkatle seçilir.

LCP görseli HTML içinde doğrudan bulunmalı, kritik olmayan JavaScript sonrasında eklenmemelidir. İlk ekrandaki görsele lazy loading uygulamak indirmeyi geciktirebilir. fetchpriority, preload veya responsive image gibi araçlar yalnız gerçek ihtiyaç varsa kullanılmalı; her görseli yüksek öncelikli yapmak bant genişliği yarışını artırır.

Hero görsel optimizasyonu doğru boyut, format ve sıkıştırma gerektirir. Telefon için masaüstü boyutunda kaynak indirilmemelidir. WebP veya AVIF kullanılırken kalite ve tarayıcı desteği kontrol edilir. CSS arka plan görselleri tarayıcı tarafından HTML görselinden daha geç keşfedilebilir; kritik kullanımda tercih yeniden değerlendirilebilir.

Render engelleyen CSS ve fontlar LCP öğesinin çizilmesini geciktirebilir. Kritik stiller hızlı sunulur, kullanılmayan büyük CSS paketleri azaltılır. Yazı tipi dosyaları yalnız kullanılan karakter ve ağırlıkları içermeli; font görüntüleme stratejisi metnin görünürlüğüyle marka tutarlılığı arasında dengelenmelidir.

INP nedir ve kullanıcı etkileşimini nasıl ölçer?

Interaction to Next Paint, kullanıcının tıklama, dokunma veya klavye etkileşimlerinin büyük bölümünde sayfanın sonraki görsel yanıtı ne kadar sürede verdiğini değerlendirir. Yalnız ilk etkileşime değil, sayfa yaşam döngüsü boyunca gerçekleşen etkileşimlere bakar.

Düşük INP performansı, butona basıldığında menünün geç açılması, sepete ekleme geri bildiriminin gecikmesi veya form alanının donması şeklinde hissedilir. Kullanıcı işlemin algılanmadığını düşünüp tekrar tıklayabilir. Bu, çift gönderim veya yanlış işlem riskine yol açabilir.

INP süresi giriş gecikmesi, event handler işleme süresi ve sonraki frame’in çizilme gecikiminden oluşur. Ana iş parçacığı uzun JavaScript görevleriyle meşgulse etkileşim işlenemez. Handler ağır hesap yapıyorsa veya render çok karmaşıksa sonraki görüntü gecikir.

web.dev’in INP rehberi, metriğin sayfa boyunca etkileşim yanıtını değerlendirdiğini ve düşük INP’nin tutarlı hızlı tepki anlamına geldiğini açıklar.

INP nasıl iyileştirilir?

İlk adım uzun görevleri bulmaktır. Chrome DevTools Performance kaydı, etkileşim sırasında hangi script ve fonksiyonların ana iş parçacığını meşgul ettiğini gösterebilir. Büyük işler daha küçük parçalara bölünebilir, kullanıcıya hızlı görsel geri bildirim verildikten sonra ikincil işlem sürdürülebilir.

JavaScript performans optimizasyonu kullanılmayan kodu azaltır ve yalnız gerekli bileşenleri yükler. Bütün sayfalarda çalışan büyük bundle yerine route veya bileşen bazlı kod bölme uygulanabilir. Üçüncü taraf sohbet, reklam, analiz ve A/B test araçları da ana iş parçacığını etkileyebilir.

Event handler içinde zorunlu olmayan DOM okuma-yazma işlemleri azaltılır. Sık tetiklenen scroll veya input olayları kontrollü işlenebilir. Büyük DOM ağacı stil hesaplama ve render süresini artırabilir. Görünmeyen karmaşık bölümler gerektiğinde koşullu oluşturulabilir; ancak erişilebilirlik ve SEO etkisi değerlendirilmelidir.

Sunucuya bağlı etkileşimlerde optimistic UI her zaman doğru değildir. Riskli işlem tamamlanmadan başarılı gösterilmemelidir. Bunun yerine yüklenme durumu ve iptal veya tekrar deneme seçeneği sunulabilir. Arka uç gecikmesi, ağ ve ön yüz tepkisi ayrı ölçülür.

CLS nedir ve sayfa neden yer değiştirir?

Cumulative Layout Shift, kullanıcı etkileşimi dışında gerçekleşen beklenmeyen düzen kaymalarının toplam etkisini ölçer. Kullanıcı bir bağlantıya dokunmak üzereyken üstte görsel yüklenip butonu aşağı itiyorsa yanlış öğeye basabilir. Bu yalnız rahatsızlık değil, işlem hatası riskidir.

CLS sorunu çoğunlukla boyutu belirtilmemiş görsel ve iframe, sonradan eklenen reklam veya banner, geç yüklenen font ve dinamik içerikten kaynaklanır. İçerik için önceden yeterli alan ayrılmazsa tarayıcı kaynak geldiğinde sayfayı yeniden düzenler.

Kullanıcının tıklamasıyla açılan accordion veya menü gibi beklenen hareketler belirli koşullarda CLS hesabına farklı yansıyabilir. Ancak animasyonun akıcı ve bağlama uygun olması yine önemlidir. Metrik düşük diye rahatsız edici geçiş göz ardı edilmemelidir.

CLS nasıl iyileştirilir?

Görsel ve video öğelerinde width-height veya aspect-ratio kullanmak tarayıcının alanı önceden ayırmasını sağlar. Responsive tasarımda oran korunurken genişlik esneyebilir. Reklam, harita ve üçüncü taraf embed için minimum alan ayrılabilir; içerik gelmediğinde boşluğun nasıl davranacağı planlanır.

Sayfanın üst kısmına sonradan kampanya veya çerez bandı eklemek mevcut içeriği aşağı itebilir. Bandın ilk HTML’de alanı ayrılabilir veya içeriğin üzerine kontrollü katman olarak yerleştirilebilir. Sabit öğeler mobilde ekranı kapatmamalıdır.

Web font CLS sorunu için fallback font metrikleri, preload ve font-display stratejisi değerlendirilebilir. Çok sayıda font ağırlığı yüklemek gecikmeyi artırır. Marka fontu gelene kadar kullanılan sistem fontunun ölçüsü çok farklıysa başlıklar ve paragraflar kayabilir.

Dinamik listede yeni öğe yukarı ekleniyorsa kullanıcının okuma konumu korunmalıdır. Sonsuz kaydırma, canlı skor veya sohbet uygulamalarında içerik ekleme davranışı özellikle test edilir.

Core Web Vitals eşikleri nasıl yorumlanır?

Core Web Vitals sonuçları iyi, iyileştirme gerekli ve zayıf gruplarına ayrılır. Genel hedef LCP için 2,5 saniye veya altı, INP için 200 milisaniye veya altı, CLS için 0,1 veya altıdır. Değerlendirme genellikle sayfa ziyaretlerinin yüzde 75’lik diliminde yapılır.

Bu eşikleri mutlak ürün hedefi sanmamak gerekir. Kullanıcı için daha hızlı her zaman daha iyidir; yalnız sınırı geçmek çalışmayı bitirmez. Bunun tersine birkaç milisaniyelik fark uğruna önemli içerik veya erişilebilirlik kaldırılmamalıdır. Web performans bütçesi, işlev ve deneyimle dengeli hedefler belirler.

web.dev’in Core Web Vitals eşikleri açıklaması, LCP, INP ve CLS’nin gerçek kullanıcı deneyiminin farklı yönlerini değerlendirdiğini ve hedeflerin nasıl belirlendiğini açıklar.

PageSpeed Insights puanı nasıl yorumlanmalıdır?

PageSpeed Insights üst bölümde varsa saha verisini, alt bölümde Lighthouse laboratuvar testini gösterebilir. Performans puanı laboratuvar metriklerinin ağırlıklı sonucudur ve test koşuluna göre değişebilir. Tek çalıştırmadaki 100 puan gerçek bütün kullanıcıların kusursuz deneyim yaşadığını göstermez.

PageSpeed puanı yerine hangi metrik ve kaynakların problemi oluşturduğuna bakılmalıdır. “Kullanılmayan JavaScript” önerisinde dosyanın hangi özelliğe ait olduğu, gerçekten kaldırılıp kaldırılamayacağı incelenir. “Görselleri optimize edin” uyarısı içerik yönetim sürecinde tekrar oluşmaması için kalıcı medya kuralına dönüşmelidir.

Testler benzer koşullarda birkaç kez çalıştırılabilir. Cache sıcaklığı, sunucu yükü ve ağ değişkenliği sonucu etkiler. Kritik sayfa türleri ayrı test edilir: ana sayfa, hizmet detayı, blog, kategori, ürün ve ödeme aynı ağırlığa sahip değildir.

Sunucu yanıt süresi nasıl iyileştirilir?

Tarayıcı HTML’i almadan ana içeriği işlemeye başlayamaz. Yavaş sunucu yanıtı bütün yükleme zincirini geciktirir. Uygulama kodu, veritabanı sorguları, dış API çağrıları, disk, ağ ve sunucu kapasitesi ölçülmelidir.

TTFB optimizasyonu için tam sayfa veya parça önbelleği, OPcache, sorgu indeksleri, bağlantı havuzu ve CDN değerlendirilebilir. Her istekte uzak servisten veri beklemek sayfayı kırılgan hâle getirir. Uygun veri belirli süre önbelleğe alınabilir veya arka planda güncellenebilir.

Sunucu kapasitesi trafik tepe noktalarına göre izlenir. CPU, bellek, disk I/O, veritabanı bağlantısı ve hata oranı birlikte değerlendirilir. Hızlı barındırma kötü kodu tamamen çözmez; iyi kod da yetersiz kaynakta sınırına ulaşır.

Görseller Core Web Vitals değerlerini nasıl etkiler?

Görseller LCP öğesi olabilir, dosya boyutuyla yüklemeyi uzatabilir ve boyut belirtilmezse CLS oluşturabilir. Bu nedenle dosya formatı, çözünürlük, responsive kaynak, sıkıştırma, öncelik ve yerleşim birlikte planlanır.

Responsive image yapısında tarayıcı farklı genişlikteki dosyalar arasından uygun olanı seçer. Liste kartı için küçük, detay görünümü için daha büyük kaynak sunulabilir. Yüksek yoğunluklu ekranlar hesaba katılır; ancak telefonun görüntüleme alanından çok daha büyük dosya indirilmez.

Lazy loading ekranın altındaki görseller için faydalıdır. İlk ekrandaki LCP görselini geciktirebilir, bu nedenle koşulsuz uygulanmamalıdır. Ana görsel HTML içinde erken keşfedilebilir olmalı. CSS arka planı olarak verilen kritik görseller daha geç indirilebilir.

İçerik ekibi yeni görsel yüklediğinde optimizasyonun bozulmaması için yönetim panelinde otomatik boyutlandırma ve format üretimi uygulanabilir. Performans tek seferlik değil, içerik sürecinin parçası olmalıdır.

Web fontları performansı nasıl etkiler?

Her yazı tipi ailesi ve ağırlığı ayrı dosya indirilmesine neden olabilir. Latin dışında kullanılmayan karakter setleri ve gereksiz ağırlıklar toplam boyutu artırır. Değişken font tek dosyada farklı ağırlıkları sunabilir; fakat her projede otomatik olarak daha küçük olmayabilir.

Font optimizasyonu için kullanılan karakter alt kümeleri, format, cache ve preload stratejisi düzenlenir. Yalnız ilk ekranda gerçekten gerekli font önceliklendirilebilir. Her fontu preload etmek diğer kritik kaynaklarla yarışır.

font-display metnin font gelene kadar görünürlüğünü belirler. Fallback font ile marka fontu arasındaki metrik farkı CLS oluşturabilir. CSS font metric override özellikleri ve benzer fallback seçimi kaymayı azaltabilir. Metnin uzun süre görünmez kalması kullanıcı deneyimini zedeler.

CSS ve JavaScript performansı nasıl optimize edilir?

CSS tarayıcının render için ihtiyaç duyduğu kaynaktır. Büyük ve kullanılmayan stil dosyaları indirme ve işleme süresini artırır. Kritik CSS, kod bölme ve kullanılmayan kuralları azaltma yöntemleri projeye göre uygulanabilir. Çok agresif araçlar dinamik sınıfları yanlışlıkla kaldırabileceği için test gerekir.

JavaScript optimizasyonu dosya küçültmenin ötesindedir. Kullanılmayan kütüphane ve özellikler kaldırılır, modüller gerektiğinde yüklenir, uzun görevler bölünür. defer ile HTML parse süreci engellenmeden script çalıştırılabilir. Ancak yükleme sırası ve bağımlılıklar doğrulanmalıdır.

DOM boyutu ve karmaşık CSS seçicileri stil hesaplama süresini artırabilir. Sık animasyonlarda layout tetikleyen özellikler yerine transform ve opacity tercih edilebilir. Animasyonlar prefers-reduced-motion tercihini desteklemelidir.

Üçüncü taraf script, ekip kontrolü dışındaki kod ve ağ çağrılarını getirir. Her aracın iş değeri, veri gizliliği ve performans maliyeti düzenli sorgulanmalıdır. Aynı işi yapan birden fazla analiz veya sohbet aracı kaldırılabilir.

Cache ve CDN site hızını nasıl destekler?

Tarayıcı cache, tekrar ziyaretlerde değişmeyen CSS, JavaScript, font ve görselleri yeniden indirme ihtiyacını azaltır. Dosya adında içerik hash’i kullanılırsa uzun cache süresi verilebilir; dosya değiştiğinde yeni ad oluşur. HTML ve dinamik API yanıtları için daha dikkatli politika gerekir.

CDN kullanımı statik kaynakları kullanıcıya yakın noktadan sunabilir ve ana sunucunun yükünü azaltabilir. CDN yanlış yapılandırılırsa eski içerik, bozuk cache veya ek gecikme oluşturabilir. Purge ve varyasyon kuralları belirlenmelidir.

Uygulama cache’i pahalı sorgu ve hesaplamaları azaltır. Cache invalidation en zor konulardan biridir; veri değiştiğinde hangi anahtarın temizleneceği açık olmalıdır. Fiyat, stok, yetki ve kişisel içerik için yanlış cache ciddi sorun oluşturur.

Üçüncü taraf kodlar nasıl kontrol edilir?

Analiz, reklam, sohbet, harita, video ve sosyal medya widget’ları kullanıcı deneyimine değer katabilir; ancak her biri ek DNS, bağlantı, JavaScript ve ana iş parçacığı yükü getirir. Kodun ne zaman ve hangi sayfalarda gerektiği incelenmelidir.

Third-party script performansı için koşullu yükleme, kullanıcı etkileşimi sonrasında başlatma veya daha hafif embed ön izleme kullanılabilir. Video oynatıcı sayfa açılışında tam kaynak yüklemek yerine poster ve tıklamayla başlatılabilir. Harita yalnız iletişim sayfasında gerekliyse bütün sayfalara eklenmemelidir.

Tag manager içinde zamanla biriken eski etiketler düzenli temizlenir. Bir aracın panelden kapatılması kodun sayfadan kalktığı anlamına gelmeyebilir. Ağ ve performance kayıtlarıyla gerçek yük kontrol edilir.

Performans bütçesi nedir?

Performans bütçesi; JavaScript, görsel, font ve toplam sayfa ağırlığı veya LCP, INP, CLS gibi metrikler için kabul edilen sınırları belirler. Yeni özellik bu sınırı aşıyorsa optimizasyon veya farklı çözüm gerekir. Böylece performans yalnız yayın öncesi hatırlanan bir konu olmaz.

Web performans bütçesi gerçek hedef kitle ve sayfa türüne göre hazırlanır. Ana sayfa ile uygulama paneli aynı kaynak dağılımına sahip olmayabilir. Bütçe ulaşılmaz kadar katı veya etkisiz kadar geniş olmamalıdır. CI sürecinde otomatik kontrol yapılabilir.

İçerik ekibine görsel boyutu ve video kullanım kuralları verilir. Pazarlama ekibi yeni takip kodunun maliyetini bilir. Tasarım ekibi animasyon ve font kararlarını bütçeyle birlikte değerlendirir. Performans bütün ekiplerin ortak sorumluluğu olur.

Core Web Vitals SEO sıralamasını nasıl etkiler?

Core Web Vitals sayfa deneyimi sinyallerinin bir bölümüdür. İyi değerler tek başına yüksek sıralama garantisi vermez; kötü içerik hızlı diye faydalı içeriğin önüne geçmez. Benzer alaka ve kalite koşullarında daha iyi deneyim avantaj sağlayabilir. SEO stratejisi yalnız performans puanına indirgenmemelidir.

Core Web Vitals SEO çalışması içerik ve dönüşüm hedefini koruyarak yapılmalıdır. Ana metni veya gerekli özelliği kaldırarak puan yükseltmek yanlış optimizasyondur. Daha verimli kod, medya ve yükleme stratejisiyle aynı işlev daha hızlı sunulmalıdır.

Google’ın people-first içerik yaklaşımı, kullanıcıya tatmin edici bütünsel deneyim sunmayı önerir. Teknik metrikler bu deneyimin araçlarından biridir.

Core Web Vitals iyileştirme planı nasıl hazırlanır?

Önce Search Console ve saha verisinden sorun yaşayan URL grupları belirlenir. Aynı şablonu kullanan sayfalar bir arada incelenir. Laboratuvar testi ve Performance kaydıyla darboğazın sunucu, görsel, CSS, JavaScript, font veya üçüncü taraf kaynağı olup olmadığı araştırılır.

Sorunlar kullanıcı etkisi ve geliştirme maliyetine göre önceliklendirilir. Site genelindeki ana JavaScript bundle iyileştirmesi, tek düşük trafikli sayfadaki küçük görselden daha değerli olabilir. Her değişiklik için beklenen metrik ve doğrulama yöntemi belirlenir.

Performans optimizasyonu test ortamında uygulanır, regresyon kontrolleri yapılır ve sonra kontrollü yayınlanır. Laboratuvar etkisi hemen görülebilir; saha verisinin yenilenmesi zaman alır. Değişiklik tarihi kaydedilir ve gerçek kullanıcı dağılımı izlenir.

Sitenizin teknik performansını değerlendirmek için Teknik SEO ve Site Hızlandırma hizmetimizi inceleyebilir veya Uyan Yazılım İletişim sayfasından bize ulaşabilirsiniz.

Core Web Vitals kontrol listesi

• Saha ve laboratuvar verisi ayrı ayrı incelendi mi?
• Her sayfa türünde gerçek LCP öğesi tespit edildi mi?
• Sunucu yanıtı, ana görsel ve render engelleyen kaynaklar ölçüldü mü?
• İlk ekran görseline yanlışlıkla lazy loading uygulanıyor mu?
• Uzun JavaScript görevleri ve yavaş event handler’lar belirlendi mi?
• Üçüncü taraf scriptlerin INP ve toplam yük üzerindeki maliyeti biliniyor mu?
• Görsel, video ve iframe alanları önceden ayrılmış mı?
• Font değişimi ve sonradan eklenen banner CLS oluşturuyor mu?
• Responsive görseller ekrana uygun boyutta sunuluyor mu?
• Cache, CDN ve dosya sürümleme kuralları doğru mu?
• Performans bütçesi yeni özellik ve içeriklerde korunuyor mu?
• Gerçek kullanıcı verisi yayın sonrasında izleniyor mu?

Core Web Vitals optimizasyonu tek seferlik bir puan çalışması değil, tasarım, yazılım, içerik ve operasyon ekiplerinin ortak kalite sürecidir. Kalıcı iyileştirme, metriği gizlemek yerine sorunun teknik nedenini çözmekle mümkündür.