Mart 2024’te Google, First Input Delay (FID) metriğini Core Web Vitals’tan çıkararak yerine Interaction to Next Paint (INP) metriğini koydu; CrUX Haziran 2025 raporuna göre dünya çapındaki sitelerin yalnızca %64.2’si 200 ms iyi INP eşiğini geçebiliyor ve mobil cihazlarda bu oran %58’e düşüyor.
Core Web Vitals 2026 ve INP Geçişinin Pazar Etkisi
Core Web Vitals, 2020 yılında üç metrikle başlamış; 2024 Mart’ında FID metriğinin yerini Interaction to Next Paint almıştır. web.dev üzerinde yayımlanan resmi rehbere göre INP, sayfa yüklendikten sonraki tüm etkileşimleri ölçer ve 200 ms altı “iyi”, 200-500 ms arası “iyileştirme gerektirir”, 500 ms üzeri “zayıf” olarak sınıflandırılır. Chrome User Experience Report (CrUX) Haziran 2025 dökümünde mobil INP medyanı 246 ms; desktop medyanı 132 ms ölçülmüştür. Largest Contentful Paint (LCP) için 2.5 saniye altı eşiği geçen sitelerin oranı 2025’te %71.4 seviyesindeyken Cumulative Layout Shift (CLS) için 0.1 altı oran %78.9’a yükselmiş, INP en zorlu metrik konumuna oturmuştur. HTTP Archive 2025 verilerine göre ortalama JavaScript payload mobil cihazda 502 KB; bu rakam 2021’e göre %38 büyümüş ve INP problemlerinin birincil nedeni olarak öne çıkmıştır. Google Search Central, Mayıs 2021’den itibaren Core Web Vitals’ı sıralama sinyali olarak değerlendiriyor; SISTRIX 2024 analizine göre tüm vitaller yeşil olan siteler organik trafikte rakiplerine kıyasla ortalama %18.6 avantaj sağlıyor.
INP Optimizasyonunun Teknik Boyutu
INP, kullanıcı her tıkladığında, dokunduğunda veya tuşa bastığında girişten bir sonraki çerçeveye kadar geçen tüm süreyi kapsar. Bu süre üç parçaya bölünür: input delay (ana iş parçacığı meşgul olduğu için girişin işlenmeye başlaması için bekleme süresi), processing time (event handler’ların çalıştığı süre) ve presentation delay (sonucun ekrana boyanması). Google’ın INP debug rehberi, p75 INP problemli sayfalarda input delay’in ortalama 87 ms, processing time’ın 142 ms ve presentation delay’in 64 ms olduğunu raporluyor. Long Tasks API ile 50 ms üzeri ana iş parçacığı blokajları yakalanmalı; Long Animation Frames (LoAF) API, 2024 sonunda Chrome 123 ile stabil hale geldi ve hangi script’in INP’yi tetiklediğini script attribution ile gösterebiliyor.
| Metrik | İyi eşik | İyileştirme gerektirir | Zayıf | 2025 p75 mobil medyan |
|---|---|---|---|---|
| LCP | ≤2.5 sn | 2.5-4.0 sn | >4.0 sn | 2.31 sn |
| INP | ≤200 ms | 200-500 ms | >500 ms | 246 ms |
| CLS | ≤0.1 | 0.1-0.25 | >0.25 | 0.08 |
| FCP | ≤1.8 sn | 1.8-3.0 sn | >3.0 sn | 1.62 sn |
| TTFB | ≤800 ms | 800-1800 ms | >1800 ms | 720 ms |
Lab ve Field Veri Karşılaştırması
Performans optimizasyonu için lab tools (Lighthouse, WebPageTest, PageSpeed Insights) ile field data (CrUX, RUM) arasındaki fark kritiktir. Lighthouse INP’yi doğrudan ölçmez; Total Blocking Time (TBT) yaklaşık vekildir ve gerçek kullanıcı verisiyle 0.83 korelasyon gösterir (Google web.dev verisi). CrUX, son 28 günün p75 ölçümlerini Chrome kullanıcılarından toplar; sayfa başına minimum 100 ziyaretçi şartı sağlanmadıkça veri görünmez. Yapay Zeka destekli analiz için Developer Experience metrikleri rehberimizde RUM ile DX ilişkisini ele alıyoruz.
- Lighthouse: Throttled 4G simülasyonu, tek seferlik run, INP tahminini TBT üzerinden yapar.
- CrUX: 28 günlük p75 alan verisi, public BigQuery dataset, ay sonunda yenilenir.
- web-vitals.js: 12 KB resmi RUM kütüphanesi, INP/LCP/CLS attribution build ile birlikte 24 KB.
- SpeedCurve, Calibre, DebugBear: Sentetik + RUM birleşik, kurumsal SLA dashboard’ları.
- PageSpeed Insights: Lab + CrUX birleşik rapor, hem geliştirici hem ürün ekibi için tek pencere.
LCP Optimizasyonu Implementation Pattern’ı
LCP elementi, viewport içindeki en büyük resim, video poster, background image veya text node’dur. Google’ın 2024 LCP optimization rehberi, p75 LCP’si zayıf sayfalarda time-to-first-byte (TTFB)’nin ortalama %38, resource load delay’in %19, resource load duration’ın %29 ve element render delay’in %14 paya sahip olduğunu gösteriyor. Pratik müdahaleler: hero image için fetchpriority="high", ile kritik kaynakları beklemeden indirme, AVIF/WebP formatı ile %50-70 boyut tasarrufu, Cloudflare Early Hints ile 103 status kodu üzerinden başlık öncesi push (Cloudflare 2024 raporuna göre ortalama 220 ms LCP iyileşmesi). Server-side rendering (SSR) veya statik üretim (SSG), CSR’a göre LCP’yi ortalama 1.4 saniye düşürüyor. Next.js 14 App Router ile streaming SSR, hero block’unun ilk byte ile birlikte gönderilmesini sağlayarak LCP’yi tipik olarak 800-1200 ms aralığına çekiyor.
INP Operasyon, İzleme ve Bütçeleme
INP regresyonlarını yakalamak için performans bütçesi (performance budget) ve sürekli izleme şart. SpeedCurve verisine göre INP regresyonu yaşayan ekiplerin %63’ünde performance budget tanımsız. Önerilen pratikte build zamanı bundle-size limitleri (örneğin route başına initial JS <180 KB) ve runtime metrik eşikleri (p75 INP <200 ms) ayrı tutulur; herhangi biri aşıldığında PR otomatik bloklanır. Web-vitals.js v4 ile INP attribution, hangi event target, hangi script ve hangi DOM update’inin gecikmeye neden olduğunu raporluyor. Bu attribution verisi BigQuery’ye aktarılırsa “en pahalı 10 event handler” listesi otomatik üretilebilir.
| Optimizasyon | Tipik LCP etkisi | Tipik INP etkisi | Uygulama maliyeti | Kaynak |
|---|---|---|---|---|
| fetchpriority=”high” hero | −320 ms | ±0 | 1 satır HTML | web.dev/fetch-priority |
| AVIF + responsive srcset | −480 ms | ±0 | Build pipeline ekleme | HTTP Archive |
| Code splitting + lazy import | −180 ms | −72 ms | 1-2 sprint | Next.js docs |
| scheduler.yield() ile task bölme | ±0 | −118 ms | Hot path refactor | web.dev/optimize-inp |
| Server-side rendering | −1.4 sn | −45 ms | Mimari değişikliği | Vercel benchmark |
| CDN edge cache + Early Hints | −220 ms | ±0 | CDN config | Cloudflare 2024 |
Sektörel Use Case’ler ve CLS Tuzakları
E-ticarette ürün listesi sayfalarındaki en yaygın CLS kaynağı, lazy-loaded ürün kartlarının yer ayrımı (aspect-ratio CSS) olmadan render edilmesidir. Shopify 2024 verisine göre yer ayrımı eklenen mağazalarda CLS p75 ortalama 0.18’den 0.06’ya düşmüş; aynı dönemde sepete ekleme oranı %3.2 artmıştır. Haber siteleri için INP’nin en büyük tüketicisi reklam SDK’ları; Google Publisher Tag (GPT) v4 ve Prebid 9 ile lazy load + intersection observer pattern’ı ortalama 140 ms INP tasarrufu sağlıyor. SaaS dashboard’larında ise React 18 useDeferredValue ve Concurrent Features, ağır liste güncellemelerinde INP’yi yarıdan fazla düşürüyor.
Kurumsal Core Web Vitals Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Lab vs field uçurumu: Lighthouse 95 puan ama CrUX p75 INP 380 ms; ekipler lab metriğine inanıp field’ı gözden kaçırıyor.
- Üçüncü taraf script kontrolsüzlüğü: Tag Manager üzerinden eklenen 14-20 script, INP’nin %60’ını tüketiyor; sahipsiz kalıyor.
- Performans bütçesi yokluğu: PR review’larında bundle size kontrolü manuel, geliştirici unutuyor; haftalar içinde 200 KB regresyon birikiyor.
- Tasarım sisteminde aspect-ratio eksik: Component library’de görsel placeholder’ı yer ayırmıyor, CLS sürekli tetikleniyor.
- React re-render fırtınası: Context API yanlış kullanımıyla tek state değişikliği 80+ component’i yeniden çiziyor, INP tavan yapıyor.
- RUM verisi toplanmıyor: Web-vitals.js prod’a yüklenmemiş; ekip CrUX’ın 28 günlük gecikmesiyle körlemesine optimize ediyor.
Sonuç
Core Web Vitals 2026’da yalnızca SEO sinyali değil; doğrudan dönüşüm, terk oranı ve marka algısı metriği. INP’nin getirdiği eşik, JavaScript-ağır SPA mimarilerini yeniden değerlendirmeye zorluyor. Yapılması gereken net: web-vitals.js’i bugün prod’a alın, p75 INP’yi BigQuery’ye akıtın, performance budget’ı CI’ya bağlayın ve Long Animation Frames API ile attribution’ı debug iş akışınızın parçası yapın. web.dev INP rehberi, CrUX dokümantasyonu ve Google Search Central başlangıç için yeterli; ama gerçek kazancı, alan verisiyle yapılan her sprintlik iteratif optimizasyon getiriyor. Yorumlarınızı bekliyorum.
Sıkça Sorulan Sorular
INP, FID’den neden daha zor?
FID yalnızca ilk etkileşimin gecikmesini ölçerdi; INP sayfa ömrü boyunca tüm etkileşimlerin p98’ini raporlar. CrUX Haziran 2025’e göre FID’de iyi eşiği geçen site oranı %92 iken INP’de bu oran %64.2; INP, sayfa kullandıkça biriken JavaScript yükünü ve uzun task’ları gerçekçi yansıtıyor.
Lighthouse 100 alıyorum ama CrUX kırmızı, neden?
Lighthouse, tek seferlik throttled 4G simülasyonudur; CrUX ise gerçek Chrome kullanıcılarının 28 günlük p75 ölçümlerinin toplamıdır. Cihaz çeşitliliği, ağ koşulları ve uzun oturumlar Lighthouse’da görünmez. Web-vitals.js ile RUM toplamadığınız sürece CrUX’un gerisinde kalırsınız.
LCP için hangi tek müdahale en yüksek etkiyi getirir?
Hero görsele fetchpriority="high" eklemek ve AVIF formatına geçmek, Google 2024 case study’lerinde p75 LCP’yi tipik olarak 500-800 ms düşürüyor. Cloudflare Early Hints (103 status) eklenirse ek 220 ms kazanım geliyor.
CLS için animasyonlar problem mi?
Yalnızca transform ve opacity ile yapılan animasyonlar CLS’yi tetiklemez; çünkü compositor thread’te çalışır. top, left, height, width ile yapılan animasyonlar layout shift sayılır ve CLS’ye yansır. user-initiated etkileşim sonrası 500 ms içindeki kaymalar muaftır.
Web-vitals.js kütüphanesi performansa olumsuz etki yapar mı?
v4 gzipped 1.6 KB; attribution build dahil 5.2 KB. Long Tasks API ve PerformanceObserver kullandığı için ana iş parçacığını bloklamaz. Google 2024 benchmark’ına göre INP’ye etkisi 1 ms’in altında; kazandığı veri yüzünden eklememek tipik bir hatadır.
Ömer ÖNAL
Mayıs 18, 2026Core Web Vitals’ı sadece SEO metriği gibi gören müşterilerime şunu söylüyorum: INP, kullanıcı sinirlenme eşiğinin teknik karşılığıdır. Danışmanlık projelerimde RUM verisini gerçek kullanıcıdan toplamayan ekipler, Lighthouse’da yeşil görüp CrUX’ta kırmızı kalıyor. Önerim: ilk gün web-vitals.js’i prod’a koyun, p75 INP’yi BigQuery’ye akıtın, sonra optimize edin. Ömer ÖNAL