Lab araçları INP'yi ölçemez: Event Timing API'nin gerçekte ne bildirdiği

Boşluk, metriğin tasarlandığı gibi çalışmasıdır

dev.to'da bir yazı, Core Web Vitals raporlamasında sürekli karşımıza çıkan bir kafa karışıklığını ele alıyor: Core Web Vitals'ın üç metriğinden biri olan Interaction to Next Paint (INP), lab testlerinde boş dönerken diğer tüm metrikler normal değerler bildiriyor.

Yazar bir Core Web Vitals denetleyicisi çalıştırıyor ve 29 Eylül 2026'da kendi sitesi whattofixfirst.com'a, kısıtlanmış 4G üzerinde simüle edilmiş orta seviye bir telefonla yönlendirdi. Largest Contentful Paint, Cumulative Layout Shift, Time to First Byte, First Contentful Paint ve Total Blocking Time tümü değer döndürdü ve Lighthouse sayfaya 100 üzerinden 89 puan verdi. Yalnızca INP "ölçülmedi" olarak göründü.

Yazıya göre bu, Lighthouse'ın ya da herhangi bir lab aracındaki bir hata değil. Google'ın dokümantasyonu, ziyaretçi hiç tıklamaz, dokunmaz veya tuşa basmazsa, yalnızca kaydırma veya üzerine gelme yaparsa ya da sayfa etkileşim için betiklenmemiş bir bot ya da headless browser tarafından yüklenirse INP oluşmayacağını belirtiyor. Her lab koşusu bu son duruma uyar: Lighthouse sayfaya dokunmadan yükler, dolayısıyla gözlemlenecek bir etkileşim gecikmesi yoktur. INP'nin tanıdığı tek girdi türleri fare tıklamaları, dokunmatik ekran dokunuşları ve tuş basışlarıdır.

TBT bir vekildir, yerine geçmez

Standart öneri, Total Blocking Time'a bakmaktır. Google TBT'yi olası bir vekil olarak çerçeveler ama açıkça bir yerine geçen olarak konumlandırmaz ve eşik değerleri bunun nedenini açıklar. INP, sahada sayfa yüklemelerinin 75. yüzdeliğinde değerlendirilir; 200 ms ve altı iyi, 200 ms ile 500 ms arası geliştirilmeli, 500 ms üzeri kötüdür. TBT yalnızca sayfa yüklenmesi sırasında ana iş parçacığını engellemeyi ölçer. Bir sayfa TBT'de iyi puan alabilir ama ziyaretçi ilk kez bir menü açtığında takılabilir. Yazarın kendi çalıştırmasında TBT rahat bir şekilde 78 ms idi ve bu, biri arama kutusuna yazdığında ne olacağı hakkında neredeyse hiçbir şey söylemiyor.

Saha verisi bu boşluğu kapatabilirdi, ama denetleyici Google'ın bu origin için yeterli gerçek ziyaretçi verisi olmadığını bildirdi; yazı bunun küçük siteler için normal durum olduğunu not ediyor. Lab'da boş, sahada boş.

Naif bir Event Timing gözlemcisi neden hiçbir şey kaydetmez

Sayıyı kendiniz toplamak için Event Timing API'sini bir PerformanceObserver ile kullanırsınız. Yazı, çalışan bir gözlemcinin duyarlı bir sayfada yine de hiçbir şey yazdırmamasının üç nedenini ortaya koyuyor; hepsi 19 Mart 2026 tarihli W3C Working Draft'a yazılmış durumda:

• Varsayılan süre eşiği 104 ms'dir. Spec bunu, 100 ms'den büyük 8'in ilk katı olduğu için seçmiştir; dolayısıyla API varsayılan olarak yalnızca yavaş etkileşimleri yüzeye çıkarır. Her şeyin 90 ms içinde yanıt verdiği bir sayfa, bozuk bir gözlemciden ayırt edilemeyecek şekilde boş bir günlük üretir.
• Süreler 8 ms'nin katlarına yuvarlanır; spec bu ayrıntı düzeyinin 120Hz ekranlarda bile zamanlamanın hassas kalmasını sağladığını söyler. 5 ms farklı olan iki etkileşimi karşılaştırmak, gürültüyü karşılaştırmaktır.
• Eşik düşürülebilir ama asla 16 ms'nin altına inemez. Spec, 120Hz bir ekranda tek bir kareyi atlayan bir yanıtın en az 16 ms sürdüğü gerekçesiyle, daha hızlı herhangi bir şeyin kaydedilmeye değer olmadığını belirtir.

Bir istisna var: first-input girdileri eşikten bağımsız olarak bildirilir ve tamponlanır. Yazıda alıntılanan Google rehberi, tutarlı şekilde hızlı sayfaların da değer üretebilmesi için event ile birlikte first-input'un gözlemlenmesi yönündedir. Yazıdaki düzeltilmiş toplayıcı, durationThreshold'u 16'ya ayarlıyor ve yalnızca interactionId taşıyan girdileri tutuyor.

El yapımı toplama Google'ın sayılarından nerede ayrışır

Bu düzeltme yapılsa bile, özel bir toplayıcı Google'ın kaydettiği şeylerden belgelenmiş dört şekilde ayrışır:

• INP, sayfadaki tüm etkileşimlerin yaklaşık 98. yüzdeliğidir ve unload anında hesaplanır; basitçe en kötüsü değildir. Belgelenmiş kestirme yol, bellekte yalnızca en kötü on etkileşimi tutmaktır.
• Back/forward cache'den geri yüklenen bir sayfa INP'yi sıfırlar, çünkü kullanıcı bunu ayrı bir ziyaret olarak deneyimler. Geri yükleme boyunca biriktirmeye devam eden bir toplayıcı, kimsenin gerçekte yaşamadığı bir sayı bildirir.
• Arka plana alınmış sekmeler mobilde çoğu zaman unload callback'lerini hiç çalıştırmaz; bu yüzden önerilen çözüm visibilitychange üzerinde raporlamak ve nihai değeri sunucu tarafında hesaplamaktır.
• API, iframe'lerin içinden event girdilerini yüzeye çıkarmaz ama metrik bunları sayar; ziyaretçi gömülü bir videoda oynat'a tıkladığında bir frame sınırının aşıldığını asla bilmez. Alt frame'ler girdilerini parent'a göndermek zorundadır ve bu, CrUX verisiyle uyuşmazlığın bilinen bir kaynağıdır.

Yazarın vardığı sonuça göre bu liste, çoğu site için pratik cevabın el yapımı bir toplayıcı değil, web-vitals kütüphanesinin onINP yardımcı işlevi olduğunun nedenidir.

Neden önemli

INP için lab ile saha arasındaki boşluk tanımsaldır, bir araç kusuru değil. Yalnızca Lighthouse koşularından optimize eden ekipler duyarlılık konusunda hiç sinyal alamaz ve CrUX verisi olmayan küçük siteler iki yönde de kör olabilir. En az bunun kadar önemlisi, boş bir Event Timing günlüğü genellikle sayfanın hızlı olduğu anlamına gelir, gözlemcinin bozuk olduğu değil; yuvarlama ve eşik kuralları ise küçük süre farklarının anlamsız olduğu anlamına gelir. Gerçek sayıya ihtiyaç duyan herkes onu gerçek ziyaretçilerden toplamak zorundadır ve bunu doğru yapmak; yüzdelikleri, bfcache geri yüklemelerini, arka plan sekmelerini ve iframe'leri ele almak demektir ki bu da tam olarak web-vitals kütüphanesinin çoktan yapmış olduğu iştir.