Rehber

INP nedir? Etkileşim gecikmesini düşürmenin yolları

INP neyi ölçer, mobilde neden hâlâ sorun, süre nereye gidiyor? Saha verisiyle teşhis, uzun görevleri bölme ve Safari'nin 2025 sonunda açtığı yeni ölçüm imkânı.

Fratres Editör · 11 Kasım 2026

INP (Interaction to Next Paint, etkileşimden sonraki ilk boyama), bir sayfanın tıklama, dokunma ve tuş vuruşlarına ekranı güncelleyerek ne kadar çabuk karşılık verdiğini ölçen Core Web Vitals metriğidir. Ziyaret boyunca görülen en yavaş etkileşimi raporlar. 200 milisaniye ve altı iyi sayılır. Değeri düşürmenin yolu, tarayıcının ana iş parçacığını (main thread) tıkayan JavaScript işini bölmek, ertelemek ve azaltmaktır.

INP neyi ölçer, FID'den farkı ne?

web.dev, INP'yi kullanıcının sayfada kaldığı süre boyunca yaptığı tüm tıklama, dokunma ve klavye etkileşimlerine bakan bir duyarlılık ölçüsü olarak tanımlar. Fareyle üzerine gelme, yakınlaştırma ve kaydırma hesaba girmez. Ölçülen süre, kullanıcının hareketinden tarayıcının bir sonraki kareyi çizmesine kadar geçen zamandır. Sunucudan gelen yanıtın ekrana ne zaman yansıdığı değil, ilk görsel tepkinin ne kadar geciktiği önemlidir. Sayfaya gömülü iframe içindeki etkileşimler, örneğin bir video oynatıcının düğmesi, de sayılır.

Raporlanan değer çoğu sitede ziyaretin en yavaş etkileşimidir. Çok etkileşimli sayfalarda tek bir tesadüfi aksaklık sonucu bozmasın diye her 50 etkileşimde en yüksek değer dışarıda bırakılır. Site, tüm sayfa görüntülemelerinin 75. yüzdeliğine göre puanlanır:

200 milisaniye ve altı: iyi.
200 ile 500 milisaniye arası: iyileştirme gerekir.
500 milisaniyenin üstü: kötü.

INP, 12 Mart 2024'te FID'nin (First Input Delay, ilk giriş gecikmesi) yerine Core Web Vitals'a girdi. FID yalnız ilk etkileşimin bekleme süresine bakıyordu. INP ise her etkileşimi bekleme, kodun çalışması ve ekrana çizim dahil baştan sona izler. Fark büyük, çünkü Chrome kullanım verisine göre kullanıcının sayfada geçirdiği zamanın %90'ı yükleme bittikten sonra geçiyor (web.dev).

Bir etkileşimin süresi nereye gidiyor?

web.dev'in iyileştirme kılavuzu her etkileşimi üç parçaya ayırır. Toplam gecikme bu üçünün toplamıdır. Teşhis, hangi parçanın şiştiğini bulmakla başlar.

Giriş gecikmesi (input delay): Dokunuştan olay işleyicilerin çalışmaya başlamasına kadar geçen süre. Ana iş parçacığı o sırada başka bir işle meşgulse etkileşim sırada bekler. Yükleme sırasında ayrıştırılan büyük betikler, zamanlayıcılar ve çakışan başka etkileşimler tipik nedenlerdir.
İşleme süresi (processing duration): Etkileşime bağlı kodun çalıştığı süre. Doğrulama, analitik çağrısı ve arayüz güncellemesi aynı görevde sıraya dizilirse bu parça uzar.
Sunum gecikmesi (presentation delay): Kod bittikten sonra tarayıcının stili hesaplayıp yerleşimi kurması ve kareyi boyaması için geçen süre. Büyük bir DOM ağacı ve JavaScript ile üretilen yüklü HTML burayı uzatır.

Bu parçaların arkasında çoğunlukla uzun görevler (long tasks) vardır. web.dev 50 milisaniyeyi aşan her görevi uzun sayar. Ana iş parçacığı aynı anda tek iş yapabildiği için uzun bir görev bitmeden tarayıcı kullanıcıya cevap veremez.

Web genelinde tablo ne gösteriyor?

HTTP Archive Web Almanac 2025, masaüstünde sitelerin %97'sinin, mobilde %77'sinin iyi INP aldığını raporluyor. Mobil oran 2024'te %74'tü. Masaüstünde konu büyük ölçüde çözülmüş görünüyor, asıl açık telefonda.

Aynı raporda iki ayrıntı yöneticiyi ilgilendirir. Birincisi, en çok ziyaret edilen 1.000 sitede mobil iyi INP oranı %63 ile genel ortalamanın altında. Rapor bunu zengin işlevlere, ağır üçüncü taraf entegrasyonlarına ve doğası gereği çok JavaScript çalıştıran e-ticaret, haber ve sosyal medya sitelerine bağlıyor. İkincisi, laboratuvarda ölçülen toplam engelleme süresi (TBT, Total Blocking Time) mobilde medyan 1.916 milisaniyeye çıktı ve bir yılda %58 arttı. Rapor, saha verisi iyileşirken laboratuvar verisinin kötüleşmesinin olası nedenleri arasında gerçek cihazların güçlenip artan kod karmaşıklığını örtmesini sayıyor.

Etkileşimi yoğun ve kalabalık sitelerde INP kendiliğinden düzelmiyor. Filtre, sepet, form ve kampanya sayfaları ayrı takip ister.

INP nasıl ölçülür?

Ölçüm üç soruya yanıt verir: Sorun var mı, hangi şablonda, hangi kodda?

Search Console, Core Web Vitals raporu: Benzer URL'leri gruplar. Yardım sayfasına göre grup INP değeri, son 28 günde sayfa isteklerinin %75'inin bu süre ya da daha kısasında yanıt aldığını gösterir. Sorunlu şablonu buradan seçersiniz.
PageSpeed Insights ve CrUX: URL veya alan adı düzeyinde saha verisi verir. Bu veri seti Chrome'un masaüstü ve Android sürümlerinden gelir. Metodoloji sayfası iOS'taki Chrome'u, WebView kullanan uygulamaları ve Edge'i kapsam dışında sayar.
Gerçek kullanıcı izleme (RUM, Real User Monitoring): Nedeni gösteren katman budur. web-vitals kütüphanesinin ilişkilendirme (attribution) sürümü yavaş etkileşimin hangi öğede yaşandığını ve üç parçanın sürelerini verir. web.dev 4. sürümden beri buna uzun animasyon karesi kayıtlarının da eklendiğini anlatır. Long Animation Frames API (LoAF) olarak bilinen bu kayıtlar, işi yapan betiğin adresini de içerir. Böylece gecikmenin kendi kodunuzdan mı bir etiketten mi geldiğini ayırırsınız. API Chrome 123'ten beri kullanılabiliyor.

Safari tarafında yeni bir imkân var. Apple, 12 Aralık 2025'te yayımlanan Safari 26.2 ile Event Timing API desteği ekledi ve bunun INP ölçümünü mümkün kıldığını yazdı. Web features explorer de özelliği bu tarihten beri tüm ana tarayıcılarda bulunan (Baseline) olarak gösteriyor. CrUX'te ise iPhone verisi yine yok. Safari kullanıcılarının INP değerini ancak kendi RUM ölçümünüzle görürsünüz.

Laboratuvar araçlarının sınırı da bilinmeli. Yalnız sayfa yüklemesini izleyen bir test kimse tıklamadığı için INP üretmez. web.dev, TBT'yi makul bir vekil sayar ama INP'nin yerini tutmadığını vurgular.

INP nasıl düşürülür?

En yavaş etkileşimi adıyla bulun. RUM verisinde INP'yi belirleyen öğeyi ve uzayan parçayı çıkarın. "Kategori sayfasındaki filtre düğmesi, işleme süresi uzun" gibi bir satır, "INP kötü" cümlesinden çok daha işe yarar.
Laboratuvarda yeniden üretin. Chrome DevTools Performans panelinde kaydı başlatıp aynı etkileşimi yapın. web.dev uzun görevleri güvenilir yakalamak için işlemci yavaşlatmayı açmayı veya düşük ya da orta sınıf bir Android cihazı bağlamayı önerir.
Olay işleyiciyi inceltin. Tıklamadan sonra yalnız ekranda görünecek değişikliği yapın. Kaydetme, sayaç güncelleme ve analitik gönderimi gibi işleri sonraki göreve bırakın. web.dev, requestAnimationFrame içinde setTimeout kullanmayı tüm tarayıcılarda çalışan bir erteleme yolu olarak gösterir.
Uzun görevleri bölün. await scheduler.yield() ana iş parçacığını kısa süre serbest bırakır ve işin devamını sıradaki diğer görevlerin önüne koyar. Web features explorer bu API'yi Chrome ve Edge 129, Firefox 142 sürümlerinde destekli, Safari'de desteksiz gösteriyor. Bu yüzden setTimeout tabanlı bir yedek yazın. web.dev her küçük işten sonra değil, genellikle 50 milisaniyelik dilimlerle bırakmayı önerir, çünkü her bırakmanın küçük bir maliyeti var.
Okuma ve yazmayı ayırın. Aynı görevde stili değiştirip hemen ardından genişlik veya yükseklik okumak, tarayıcıyı yerleşimi o anda hesaplamaya zorlar. Önce ölçün, sonra değiştirin.
DOM'u küçültün. web.dev, Lighthouse'un 800 düğümün üstünde uyarı verdiğini ve 1.400 düğümü aşırı büyük saydığını aktarır. Ekran dışındaki bölümler için CSS content-visibility özelliği çizim işini azaltır.
Üçüncü taraf betikleri tek tek sorgulayın. LoAF kayıtlarında sık görünen etiketleri listeleyin. Kullanılmayanları kaldırın, kalanların yüklenme zamanını pazarlama ekibiyle birlikte gözden geçirin.

İyileştirme işe değer mi?

Sıralama beklentisini ölçülü tutun. Google sayfa deneyimini sıralamada kullanır ama tek başına belirleyici saymaz. Bu dengeyi Core Web Vitals yazımızda ele aldık. Daha güçlü gerekçe kullanıcı davranışıdır. web.dev, geç tepki veren bir akordeon menünün kullanıcıyı tekrar tekrar tıklamaya ittiğini ve menünün beklenmedik biçimde açılıp kapandığını örnek verir.

Google'ın yayımladığı iki vaka bu ilişkiyi rakamla anlatıyor. İkisi de şirketlerin kendi aktardığı, kontrol grubu içermeyen ve sayfaları 2023'te güncellenmiş sonuçlar:

Hindistan'daki otobüs bileti sitesi redBus, arama sayfasında tarih değiştirme etkileşimini düzelterek o sayfanın INP'sini %72 iyileştirdi ve satışlarda yaklaşık %7 artış bildirdi.
The Economic Times, konu sayfalarında TBT'yi 3.260 milisaniyeden 120 milisaniyeye indirdi. INP 1.000 milisaniyenin üzerinden 257 milisaniyeye geriledi. Aynı sayfalarda hemen çıkma oranında %50 düşüş, sayfa görüntülemede %43 artış raporlandı. Ekip aynı dönemde Next.js'e de geçti, bu yüzden etkiyi tek bir değişikliğe bağlamak mümkün değil.

İstemci tarafında çok HTML üreten sitelerde konu performansla sınırlı kalmaz. Tarama ve görüntüleme tarafını JavaScript SEO yazımızda ayrıca ele alıyoruz.

Sık yapılan hatalar

Lighthouse puanını yeterli saymak. Yükleme testi etkileşim içermez. Almanac verisinde saha ve laboratuvar sonuçları ters yönlere gidebiliyor.
Yalnız geliştiricinin bilgisayarında denemek. Güçlü işlemcide görünmeyen uzun görev, orta sınıf bir telefonda INP'yi belirler.
Görsel tepkiyi işin sonuna bırakmak. Ağır bir işlem varsa önce düğmenin basıldığını gösterin. INP ilk boyamayı ölçer, işin tamamlanmasını değil.
forEach içinde await scheduler.yield() kullanmak. web.dev, Array.prototype.forEach döngüsünün her adımı beklemediğini hatırlatır. Her adımı bekleyen for...of döngüsünü kullanın.
Etiketi ölçmeden yayına almak. Etiket yöneticisine eklenen her betik ana iş parçacığında yer kaplar. Büyük kampanyalardan sonra INP'yi ayrıca kontrol edin.
iPhone kullanıcısını CrUX'te aramak. Bu veri orada yok. Safari payınız yüksekse RUM kurulumu şarttır.

Yarın ilk iş: En yavaş üç etkileşimi yazın

Search Console'da mobil Core Web Vitals raporunu açın ve INP sorunu olan URL gruplarını not edin. Her gruptan bir sayfayı Chrome DevTools'ta işlemci yavaşlatma açıkken yükleyin. Filtreleme, menü açma, sepete ekleme veya form gönderme gibi üç temel etkileşimi kaydedin ve her birinde en uzun parçayı (giriş gecikmesi, işleme, sunum) yanına yazın. Saha ölçümünüz yoksa web-vitals ilişkilendirme sürümünü kurmayı geliştirici ekibinin bu haftaki ilk işi yapın. Bu üç satırlık liste, bir teknik SEO çalışmasının da en somut başlangıç noktasıdır.