Core Web Vitals ve INP: Uygulamalı Optimizasyon Rehberi

Core Web Vitals, bir sayfanın kullanıcı deneyimini üç ölçülebilir sinyale indirger: yükleme hızı, görsel kararlılık ve etkileşim tepkiselliği. 2024'te FID'in yerini alan INP ile birlikte bu üçlü artık gerçek kullanıcı davranışını çok daha dürüst yansıtıyor.

Üç metrik ve eşikleri

Bu eşikler, oturumların %75'inde sağlanmalıdır. Ortalama değil, yüzdelik dilim üzerinden değerlendirilir — yani kötü deneyim yaşayan azınlık göz ardı edilmez.

LCP: neredeyse her zaman aynı beş sebep

Yüzlerce denetimden sonra LCP sorunlarının büyük çoğunluğunun şu beş nedenden birine indiğini söyleyebiliriz:

1. Yavaş sunucu yanıtı (TTFB). Paylaşımlı hostingde 800 ms üzeri TTFB yaygındır. Önbellek katmanı ve PHP-FPM ayarları çoğu vakayı çözer.
2. Optimize edilmemiş hero görseli. 1,4 MB'lık bir JPEG, AVIF'e çevrildiğinde 180 KB'a düşebilir. fetchpriority="high" ekleyin ve asla hero görselini loading="lazy" yapmayın.
3. Yazı tipi engellemesi. font-display: swap kullanın, kritik yazı tipini preload edin ve varyant sayısını ikiye indirin.
4. Render engelleyen CSS/JS. Kritik CSS'i satır içine alın, gerisini ertelenmiş yükleyin.
5. İstemci taraflı render. İçerik JavaScript ile üretiliyorsa LCP zorunlu olarak gecikir. Sunucu taraflı render veya statik üretim tercih edin.

CLS: görünmez ama en kolay düzelen metrik

Düzen kayması genellikle dört kaynaktan gelir:

• Boyutsuz medya. Her <img> ve <video> etiketine width ve height yazın; CSS ile ölçeklemek sorun değil, tarayıcının en/boy oranını önceden bilmesi yeterli.
• Sonradan enjekte edilen bannerlar. Çerez bildirimi ve duyuru çubuklarını position: fixed ile akıştan çıkarın.
• Web font takası. size-adjust ve ascent-override ile yedek yazı tipini gerçek fontun metriklerine yaklaştırın.
• Reklam ve gömülü içerik. Konteynere min-height verin.

INP: yeni ve en çok yanlış anlaşılan metrik

INP, sayfa ömrü boyunca gerçekleşen tüm etkileşimlerin neredeyse en kötüsünü ölçer. Yani tek bir yavaş tıklama tüm skoru bozar. Üç bileşeni vardır: giriş gecikmesi, işleme süresi ve sunum gecikmesi.

Pratik düzeltmeler

• Uzun görevleri bölün. 50 ms'yi aşan her JavaScript görevi ana iş parçacığını kilitler. scheduler.yield() veya await new Promise(r => setTimeout(r, 0)) ile görevi parçalayın.
• Görsel geri bildirimi işten önce verin. Kullanıcı tıkladığında önce butonu "yükleniyor" durumuna alın, ağır işi bir sonraki kareye erteleyin. Algılanan gecikme dramatik biçimde düşer.
• Üçüncü taraf betikleri denetleyin. Sohbet widget'ları, ısı haritaları ve A/B test araçları INP'nin en yaygın katilidir. Her birini async yükleyin ve gerçekten gerekli olup olmadığını sorgulayın.
• Olay dinleyicilerini hafifletin. scroll ve resize dinleyicilerinde passive: true kullanın, işlemleri requestAnimationFrame içine alın.
• DOM boyutunu kontrol edin. 1.500 düğümü aşan sayfalarda stil yeniden hesaplaması pahalılaşır.

Doğru ölçüm: laboratuvar ve alan

İki veri türünü karıştırmayın. Laboratuvar verisi (Lighthouse, PageSpeed Insights skoru) sabit koşullarda simülasyondur; geliştirme sırasında hızlı geri bildirim için idealdir. Alan verisi (CrUX, Search Console Core Web Vitals raporu, kendi RUM kurulumunuz) gerçek kullanıcılardan gelir ve sıralamada kullanılan budur.

Pratik yaklaşım: geliştirirken Lighthouse'a bakın, karar verirken alan verisine bakın. Alan verisi 28 günlük hareketli pencere kullandığı için değişikliğin etkisini görmek yaklaşık dört hafta sürer — sabırlı olun ve her hafta yeni bir müdahale yapmayın.

Performans bütçesi kurun

Optimizasyon tek seferlik bir proje değil, kalıcı bir disiplindir. Basit bir bütçe yeterli:

• Toplam JavaScript: sıkıştırılmış 150 KB altı
• Toplam görsel ağırlığı: ilk ekran için 400 KB altı
• Üçüncü taraf istek sayısı: 10 altı
• LCP: 2,0 sn altı (hedefi eşiğin altında tutun ki pay kalsın)

Bu değerleri CI sürecine bağlarsanız, performans altı ay sonra sessizce bozulmaz.