Etkileşimden Sonraki Boyamaya Kadar Geçen Süre (INP)

TL;DR — INP, biri tıkladığında, dokunduğunda veya yazdığında sayfanızın ne kadar hızlı tepki verdiğini ölçer. Tarayıcı, etkileşim ile sonraki görsel güncelleme arasındaki süreyi tüm ziyaret boyunca izler ve yaklaşık olarak en kötü etkileşimi raporlar. 200 ms altı iyi, 500 ms üzeri kötüdür. Üç Core Web Vital’dan biridir ve 2024’te First Input Delay metriğinin yerini almıştır.

INP gerçekte neyi ölçer?

Bir düğmeye tıkladığınızda, menüye dokunduğunuzda veya kutuya yazdığınızda sayfanın tepki vermesini beklersiniz: menü açılır, onay kutusu işaretlenir, metin görünür. Interaction to Next Paint (INP), etkileşiminizden tarayıcının değişikliği gösteren sonraki kareyi çizmesine kadar geçen süreyi ölçer.

Önemli nokta şudur: INP yalnızca tek bir etkileşime bakmaz. Ziyaret boyunca her tıklamayı, dokunmayı ve klavye basışını izler, ardından en yavaşına yakın değeri raporlar. Her yazışınızda yarım saniye donan bir arama kutusu gibi tek bir takılma, tüm puanı düşürebilir.

Kaydırma, üzerine gelme ve yakınlaştırma hesaba katılmaz. Yalnızca tıklama, dokunma ve klavye etkileşimleri ölçülür.

Eşikler

INP milisaniye cinsinden raporlanır ve Google üç değerlendirme aralığı kullanır:

• İyi — 200 ms veya daha az
• İyileştirme gerekiyor — 200 ms üzeri, 500 ms’ye kadar
• Kötü — 500 ms üzeri

Bağlam için, 200 ms hızlıdır ama fazla pay bırakmaz. Kodunuzun tıklamaya yanıt olarak yaptığı her şey ve tarayıcının sonucu çizmesi bu süreye sığmalıdır.

Neden FID’nin yerini aldı?

Eski yanıt verebilirlik metriği First Input Delay (FID) idi. FID yalnızca sayfadaki ilk etkileşim işlenmeye başlamadan önceki gecikmeyi ölçer ve iş başladığı anda zamanlamayı durdururdu. İşin ne kadar sürdüğünü veya ekranın güncellenme süresini hesaba katmazdı.

INP bunların tümünü düzeltir. Yalnızca ilk etkileşimi değil, tüm etkileşimlerde başlangıçtan görsel güncellemeye kadar geçen tam süreyi ölçer. Google değişikliği 12 Mart 2024 tarihinde resmileştirdi; FID Eylül 2024’e kadar araçlardan tamamen kalktı.

Basitçe, INP’yi ne kötüleştirir?

Neredeyse her zaman sorun, JavaScript’in ana iş parçacığını meşgul etmesidir. Tarayıcı bu iş parçacığında aynı anda yalnızca tek şey yapabilir; bir betik parçası çalışıyorsa tıklamanız sırada bekler. Yaygın nedenler:

• Tıklama veya dokunma işleyicisinin içinde çalışan ağır işler.
• Her şeyi engelleyen büyük JavaScript “uzun görevleri”.
• Üçüncü taraf betikleri — analiz, çerez onayı bantları, sohbet bileşenleri ve etiket yöneticileri. Basit içerik sitelerinde bile en kötü suçlular arasında olabilirler.

Genel çözüm, biri etkileşim kurduğunda daha az iş yapmak ve büyük işleri küçük parçalara bölerek tarayıcının aralarına etkileşimi yerleştirebilmesini sağlamaktır.

Üç parçalı gecikme dökümünü, 75. yüzdelik hesabını, her nedeni nasıl düzelteceğinizi ve SEO boyutunu görmek için Advanced sekmesine geçin.

TL;DR — INP, yanıt verebilirliği ölçen Core Web Vital’dır. Bir ziyaret boyunca tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini izler; FID gibi yalnızca ilk girdiyi değil, 75. yüzdelikteki değeri raporlar (her 50 etkileşimde bir aykırı değer çıkarılır). Etkileşim gecikmesi = girdi gecikmesi + işleme süresi + sunum gecikmesi. Alan verilerinin 75. yüzdeliğinde 200 ms ve altı iyi, 500 ms üzeri kötüdür. INP, 12 Mart 2024’te FID’nin yerini aldı; FID Eylül 2024’te araçlardan tamamen kaldırıldı. Uzun görevleri bölerek, scheduler.yield() ile ana iş parçacığına söz vererek, olay işleyicilerinde daha az iş yaparak, DOM’u küçülterek ve üçüncü taraf betiklerini erteleyerek iyileştirin. Bu bir alan metriğidir; Total Blocking Time laboratuvar vekilidir ve ikisi her zaman aynı sonucu vermez.

INP neyi ölçer ve FID’den nasıl ayrılır?

Google’ın tanımı nettir: “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Türkçe çeviri) “INP, bir kullanıcının sayfa ziyareti boyunca gerçekleşen tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözlemleyerek sayfanın kullanıcı etkileşimlerine genel yanıt verebilirliğini değerlendiren bir Core Web Vitals metriğidir.”

“Ziyaret boyunca tüm etkileşimler” ifadesi konunun özüdür. INP, yükleme zamanı değil, ziyaret düzeyi bir metriktir. Google’ın gerekçesi, kullanıcının sayfadaki zamanının büyük bölümünü sayfa yüklendikten sonra geçirmesidir; bu yüzden kullanım sırasındaki yanıt verebilirlik, yalnızca ilk izlenimden daha önemlidir.

First Input Delay ile karşılaştırmak farkı en açık biçimde gösterir: “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (Türkçe çeviri) “FID yalnızca sayfadaki ilk etkileşimin girdi gecikmesini ölçüyordu. INP, girdi gecikmesinden olay işleyicilerinin çalışma süresine kadar sayfadaki tüm etkileşimleri gözlemleyerek FID’yi geliştirir.” FID, tek bir etkileşimde işleyicinin başlamasından önceki beklemeyi ölçer; işleyicinin ne kadar çalıştığını ve ekranın ne zaman güncellendiğini hesaba katmazdı. INP ise her etkileşimin tam gecikmesini ölçer.

Yaygın bir yanılgıyı da düzeltelim: INP doğrudan en kötü etkileşim değildir. Tarayıcı, tek bir rastlantısal sıçrama yüzünden sayfayı cezalandırmamak için her 50 etkileşimde bir aykırı değeri çıkarır, sonra değeri sayfa görüntülemelerinin 75. yüzdeliğinde raporlar. Az etkileşimli bir ziyarette bu, en yavaş etkileşime denk gelir; yoğun bir ziyarette önce birkaç aykırı değer elenir.

Etkileşim sayılan davranışlar da sanılandan dardır. Yalnızca tıklamalar, dokunmalar ve klavye basışları ölçülür; kaydırma, üzerine gelme ve yakınlaştırma açıkça kapsam dışıdır. Tek bir hareket pointerdown, pointerup ve click gibi birkaç olayı tetikleyebilir; INP bunları üç değil tek etkileşim olarak gruplar. Grup içinde olay sürelerini toplamak yerine en uzun tek olay süresini kullanır. Hızlı bir pointerdown ile yavaş bir click, yavaş olaya göre boyutlanan tek etkileşim olarak raporlanır. Ziyarette uygun bir etkileşim yoksa INP değeri de raporlanmaz.

Etkileşim gecikmesinin üç bölümü

Her etkileşimin gecikmesi art arda gelen üç parçaya ayrılır. Her parça farklı bir çözüme işaret ettiği için bu modeli akılda tutun:

Interaction latency = Input delay + Processing duration + Presentation delay

1. Girdi gecikmesi — Genellikle ana iş parçacığı uzun bir görevi bitirmekle meşgul olduğu için olay işleyicilerinizin başlayamadığı bekleme süresi.
2. İşleme süresi — Tüm olay işleyici geri çağrılarının yürütülme süresi.
3. Sunum gecikmesi — İşleyicilerin bitişinden tarayıcının sonraki kareyi ekrana çizmesine kadar geçen süre.

web-vitals ilişkilendirme derlemesi üç parçayı da (inputDelay, processingDuration, presentationDelay) gösterir; böylece gerçek bir etkileşimde hangisinin baskın olduğunu görebilirsiniz. Web Almanac’ın 2024 verilerinde medyanda en büyük tek parça çoğu zaman sunum gecikmesidir. Ancak kötü oluşturulmuş sayfalarda en çok şişen bölüm olduğu için optimizasyon fırsatı genellikle işleme süresindedir.

Eşikler ve p75 alan verisi uyarısı

Google Search Central hedefi açıkça “an INP of less than 200 milliseconds” (Türkçe çeviri) “200 milisaniyeden düşük bir INP” olarak verir ve programı “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (Türkçe çeviri) “Site sahiplerinin Arama’da başarı için iyi Core Web Vitals değerlerine ulaşmasını önemle öneriyoruz.” diye çerçeveler. Tarayıcının 60 fps’de yaklaşık her 16,7 ms’de bir kare çizmek istediği düşünülürse 200 ms bütçesi gerçekten dardır; işleyici işiyle oluşturma işlemlerinin tamamı bu süreye sığmalıdır.

INP neden alan metriğidir? Laboratuvar verisi neden yetmez?

Birçok SEO uzmanını yanıltan nokta şudur: yeşil bir Lighthouse puanı, iyi INP anlamına gelmez. “Lighthouse INP’yi ölçemez” sözü de tek değil, üç ayrı durumla açıklanmalıdır:

1. Standart, etkileşimsiz Lighthouse çalıştırması hiçbir INP raporlamaz. Yalnızca sayfanın yüklenmesini gözlemler; tıklamaz, dokunmaz veya yazmaz. Bu yüzden süre tutulacak etkileşim yoktur. Lighthouse bunun yerine yükleme zamanı vekili olarak Total Blocking Time (TBT) kullanır. Google bunu “Because TBT correlates well with INP, a page with a high TBT is a reasonable indicator that there may be high INP values during load.” (Türkçe çeviri) “TBT, INP ile iyi korelasyon gösterdiğinden yüksek TBT’ye sahip bir sayfa, yükleme sırasında yüksek INP değerleri olabileceğine dair makul bir göstergedir.” diye açıklar. Buradaki kilit nokta yükleme aşamasıdır. TBT, on saniye sonra tembel yüklenen bir bileşenin bozduğu etkileşimi göstermez; vekildir, ikame veya dönüşüm formülü değildir.
2. DevTools’ta gerçek bir düğmeye tıklamak ya da laboratuvar aracında tıklama betiği çalıştırmak gibi elle veya sentetik olarak gerçekleştirilen bir etkileşim, o etkileşim için gerçek INP benzeri gecikme üretir. Belirli bir hatayı yeniden oluşturmak için yararlıdır. Yine de tek cihazdaki tek betikli yoldur; gerçek cihaz, kullanıcı, hedef ve tam ziyaret ömrü çeşitliliğini temsil edemez. Google’ın ifadesiyle sonuç “will be dependent on what interactions are performed during the measurement period” (Türkçe çeviri) “ölçüm döneminde hangi etkileşimlerin gerçekleştirildiğine bağlı olacaktır”; gerçek kullanıcı davranışı tek bir laboratuvar çalışmasının temsil edemeyeceği kadar değişkendir.
3. INP’nin kendisi alan dağılımıdır. Bu nedenle yetkili kaynak alan verisidir: PageSpeed Insights ve Search Console Core Web Vitals raporunda sunulan Chrome User Experience Report (CrUX). “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (Türkçe çeviri) “Gerçek kullanıcılar için hangi etkileşimlerin sorunlu olduğunu anlamada yararlanabileceğiniz en iyi bilgi kaynağı alan verisidir.”

Yavaş etkileşimi bulup yeniden üretmek için laboratuvarı (1 ve 2), gerçek ziyaretçi puanlarını düşürüp düşürmediğini doğrulamak için alan verisini (3) kullanın.

INP puanınız neden kötüdür?

INP sorunlarının neredeyse tamamı, kullanıcı etkileşirken ana iş parçacığının engellenmesine dayanır. Olağan şüpheliler şunlardır:

• Uzun görevler. 50 ms üzerindeki her ana iş parçacığı işi uzun görev kabul edilir; 50 ms’yi aşan bölüm “engelleme süresi” olarak adlandırılır. Görev çalışırken etkileşim işlenemez. En büyük neden budur.
• Ağır olay işleyicileri. Tıklama veya girdi işleyicisinde eşzamanlı çok iş yapmak, işleme süresini doğrudan artırır.
• Büyük DOM. Büyük DOM’ların oluşturulması daha pahalıdır; hem girdi hem sunum gecikmesini artırır.
• Üçüncü taraf betikleri. Web Almanac’a göre izin sağlayıcıları, etiket yöneticileri, analiz ve sohbet bileşenleri başlıca suçlulardır; basit içerik sitelerini bile etkilerler. Kendi oluşturmadığım bir sayfada ilk baktığım yer burasıdır.
• Yükleme sonrası JavaScript. Sayfanın çizilmiş olması yüklemenin bittiği anlamına gelmez; ilk çizimden sonra değerlendirilen betikler erken etkileşimleri engelleyebilir.

Nasıl düzeltilir?

Yaklaşık etki sırasına göre stratejiler:

1. Uzun görevleri bölün. Google’ın işleyicilere ilişkin temel önerisi “do as little work as possible in them” (Türkçe çeviri) “içlerinde mümkün olduğunca az iş yapın” şeklindedir. Büyük işi küçük görevlere ayırın; böylece tarayıcı araya kullanıcı etkileşimi alabilir. Görevler bölündüğünde “the browser can respond to higher-priority work much sooner — including user interactions.” (Türkçe çeviri) “tarayıcı, kullanıcı etkileşimleri dahil daha yüksek öncelikli işlere çok daha erken yanıt verebilir.”

2. Ana iş parçacığına söz verin. Modern ve önerilen yöntem scheduler.yield() (Chrome 129+, Firefox 142+): await scheduler.yield() kodunuzu duraklatır, tarayıcının bekleyen işleri işlemesine izin verir ve öncelikli biçimde sürdürür; başka görevler devam kodunuzun önüne geçmez. Klasik setTimeout(..., 0) alternatifi çalışır, fakat kodu görev kuyruğunun sonuna gönderir; ayrıca tarayıcılar iç içe birkaç çağrıdan sonra 5 ms alt sınır uygular. Artık kullanmamanız gereken yöntem isInputPending()’dir: Google “we no longer recommend using this API.” (Türkçe çeviri) “artık bu API’nin kullanılmasını önermiyoruz” diyor. Örnek için Scripts sekmesine bakın.

3. Olay işleyicilerinde daha az iş yapın; kritik olmayanı erteleyin. Yalnızca sonraki karenin gerektirdiği görsel güncellemeyi eşzamanlı çalıştırın. Kaydetme, yazım denetimi, analiz ve sözcük sayımı gibi diğer işleri requestAnimationFrame + setTimeout arkasına veya bir yield sonrasına taşıyın. Kullanıcı yanıtı hemen görür; kayıt işleri sonra yapılır.

4. Düzen çırpınmasını önleyin. Aynı görevde stilleri yazdıktan hemen sonra düzen özelliklerini okumak, tarayıcıyı normalde toplu yapabileceği eşzamanlı düzene zorlar. Önce okumaları, sonra yazmaları toplu gerçekleştirin.

5. DOM boyutunu azaltın. Küçük ağaçlar daha hızlı oluşturulur. content-visibility, ekran dışındaki öğeleri tembel oluşturup yükleme veya etkileşim maliyetini azaltabilir.

6. Üçüncü taraf betiklerini denetleyip erteleyin. Gerçek sitelerde en yüksek getirili SEO düzeltmelerinden biridir. İzin, etiket ve analiz betiklerini tembel yükleyin, etkileşime bağlayın veya kritik yolun dışına taşıyın. “Hafif” bir içerik sayfası yalnızca ağır gömülü bileşen yüzünden INP’den kalabilir.

INP sıralamaları etkiler mi?

Evet. INP üç Core Web Vital’dan biridir ve Core Web Vitals, Google’ın sayfa deneyimi sinyallerinin parçasıdır. Ancak hafif bir sinyaldir: birincil sıralama faktörü değil, benzer derecede alakalı sonuçlar arasında eşitlik bozucudur. İçerik ve alaka pahasına kusursuz INP peşinde koşmayın.

İki pratik SEO noktası var. Birincisi, mobil zorlu ölçümdür. 2024 Web Almanac’ta mobil sitelerin yaklaşık %74’ü, masaüstü sitelerin yaklaşık %97’si INP’den geçti. Google mobil öncelikli dizine eklediği için önemli sayı mobildir. İkincisi, karmaşık siteler daha kötü sonuç verir: En büyük 1 000 sitenin yalnızca yaklaşık %53’ü geçti; özellik bakımından zengin sayfalar ana iş parçacığını engelleyen daha fazla JavaScript gönderir. Yoğun özellik geliştirme INP riskidir; ürün, ödeme, arama sonucu ve form sayfaları gibi etkileşimi yüksek sayfalar statik içerikten çok daha açıktadır.

INP ve FID: tam tablo

FID artık yoktur: INP’nin kullanıma sunulduğu gün Search Console’dan, Eylül 2024’e kadar da CrUX BigQuery/API’den kaldırıldı. Bir araç veya denetim hâlâ FID’ye başvuruyorsa eskidir.

INP verilerinin uyuşmamasına yol açan uç durumlar

Yaşam döngüsündeki birkaç ayrıntı, “RUM neden CrUX ile eşleşmiyor?” sorularının çoğunu açıklar:

• Etkileşim yoksa INP de yoktur. Ziyarette tıklama, dokunma veya tuş basışı olmazsa ya da yalnızca kaydırma ve üzerine gelme gibi kapsam dışı hareketler gerçekleşirse o sayfa görüntüleme için INP değeri yoktur. Bu, salt okunur içerik sayfalarında normaldir; izleme hatası değildir.
• Iframe etkileşimleri metriğe katılır, ancak kendi JavaScript’iniz iframe’in içini göremez. Reklam, bileşen veya form gibi gömülü iframe içindeki etkileşim sayfanın INP’sine katkıda bulunur. Birinci taraf RUM betiği ise tarayıcının metriği gibi çapraz kaynaklı iframe olaylarını okuyamaz. Bu nedenle üçüncü taraf gömüler bulunan sayfalarda CrUX ile aynı kaynaklı RUM meşru biçimde ayrışabilir. RUM/alan uyumsuzluğunu hata saymak yerine bu boşluğu belgeleyin.
• Geri/ileri önbelleği geri yüklemeleri INP’yi sıfırlar. Örneğin geri düğmesiyle bfcache’den getirilen sayfa yeni bir INP sayımı başlatır; sayfadan ayrılmadan önceki etkileşimler taşınmaz.
• Uzun süre açık veya arka plana alınmış sekmeler de raporlanmalıdır. Özellikle mobilde işletim sistemi sekmeyi sonlandırabildiği için sekme saatlerce açık kalıp resmen hiç boşaltılmayabilir. INP yalnızca boşaltmada değil, sayfa gizlendiğinde yakalanmalıdır. Yalnızca unload sırasında gönderen RUM kurulumları bu ziyaretlerin verisini sessizce yitirir.

Büyük resimdeki yeri

INP, yüklemeyi ölçen Largest Contentful Paint ve görsel kararlılığı ölçen Cumulative Layout Shift ile birlikte Core Web Vitals tablosunun bir parçasıdır. Alan verisini PageSpeed Insights ve Search Console raporunda kontrol edin; laboratuvarda TBT vekiliyle Lighthouse / Chrome DevTools üzerinden hata ayıklayın. Hepsinin arkasındaki veri CrUX’tan gelir.

AI özeti

Advanced sürümün kısa özeti:

• INP, yanıt verebilirlik için Core Web Vital’dır. Tüm ziyaret boyunca bütün tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözler ve değeri 75. yüzdelikte raporlar; FID gibi yalnızca ilk girdiye bakmaz.
• Gecikme = giriş gecikmesi + işleme süresi + sunum gecikmesi. Her parça farklı bir çözüme işaret eder; en büyük iyileştirme alanı çoğunlukla işleme süresidir.
• Eşikler (alan verisi, p75): iyi ≤ 200 ms, iyileştirme gerekiyor ≤ 500 ms, kötü > 500 ms.
• Yalnızca tıklamalar, dokunmalar ve klavye sayılır; kaydırma, üzerine gelme ve yakınlaştırma hariçtir. Tek hareketin birden çok olayı tek etkileşimde gruplanır.
• 12 Mart 2024’te FID’nin yerini aldı; FID Eylül 2024’te araçlardan tamamen kaldırıldı. FID yalnızca ilk etkileşimin giriş gecikmesini ölçerdi.
• Alan metriğidir ve “Lighthouse ölçemez” ifadesinin üç durumu vardır: standart etkileşimsiz Lighthouse çalıştırması INP vermez ve yükleme vekili olarak Total Blocking Time kullanır; elle yapılan laboratuvar etkileşimi gerçek tek-etkileşim gecikmesi üretir ama alan nüfusunu temsil edemez; yalnızca CrUX, PageSpeed Insights ve Search Console alan verileri belirleyicidir.
• Nedenler: uzun görevler (>50 ms), ağır olay işleyicileri, büyük DOM ve özellikle üçüncü taraf betikleri (onay, etiket yöneticisi, analiz, sohbet).
• Çözümler: uzun görevleri bölün, scheduler.yield() ile ana iş parçacığına teslim edin (setTimeout yedeği; isInputPending() artık önerilmez), işleyicilerde daha az iş yapın, layout thrashing’den kaçının, DOM’u küçültün ve üçüncü tarafları erteleyin.
• Uç durumlar: uygun etkileşim yoksa INP değeri yoktur; iframe etkileşimleri metriğe katılır ancak aynı origin RUM betiği içlerini göremez; bfcache dönüşleri INP’yi sıfırlar; uzun yaşayan veya arka plana alınan sekmeler yalnız unload’da değil hidden’da raporlamalıdır.
• SEO: hafif bir sıralama sinyalidir. Mobile-first dizine eklemede önemli olan mobil değerdir (~%74 geçiş, masaüstünde ~%97); çok etkileşimli sayfalar daha açıktır.

Resmî belgeler

Google ve Chrome ekibinden birincil kaynak belgeler.

web.dev — INP kaynakları

• Interaction to Next Paint (INP) — neyi ölçtüğü, üç parçalı gecikme dökümü, etkileşim türleri ve eşiklerin temel tanımı.
• Interaction to Next Paint’i optimize etme — işleyicilerde daha az iş, kritik olmayan işlerin ertelenmesi, layout thrashing, DOM boyutu ve content-visibility.
• Interaction to Next Paint resmen Core Web Vital oluyor — Jeremy Wagner ve Rick Viscomi’nin 12 Mart 2024 duyurusu; FID kullanım sonu takvimi.
• First Input Delay (FID) — kullanımdan kaldırılan metriğin neyi ölçtüğü ve neden değiştirildiği.
• Yeni yanıt verebilirlik metriği: görüşlerinizi bekliyoruz — FID’nin tasarım sınırları ve INP iyileştirmeleri.
• Uzun görevleri optimize etme — 50 ms uzun görev tanımı, scheduler.yield(), setTimeout yedeği ve isInputPending() yönteminin artık önerilmemesi.
• Betik değerlendirme ve uzun görevler — INP vekili olarak TBT ve betik boyutu rehberliği.
• Alanda yavaş etkileşimleri bulma — web-vitals attribution derlemesi ve Long Animation Frames (LoAF) API.

Chrome / Google Arama

• Performans özellikleri başvurusu (Chrome DevTools) — Interactions izi, Live Metrics ve 200 ms uyarısı.
• CrUX sürüm notları — FID’nin Eylül 2024’te BigQuery/API’den kaldırıldığını doğrular.
• Core Web Vitals ve Google Arama sonuçları — sayfa deneyimi sinyalinin parçası olarak INP ve ≤ 200 ms hedefi.

Kaynaktan alıntılar

Google ve Chrome ekibinden kayda geçmiş açıklamalar. Her bağlantı kaynak sayfadaki alıntılanan bölüme doğrudan gider.

INP neyi ölçer ve FID’den nasıl ayrılır?

• “INP is a Core Web Vitals metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Türkçe çeviri) “INP, kullanıcının sayfa ziyareti boyunca gerçekleşen tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözleyerek sayfanın genel yanıt verebilirliğini değerlendiren bir Core Web Vitals metriğidir.” — web.dev, Interaction to Next Paint (INP). Alıntıya git
• “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers.” (Türkçe çeviri) “FID yalnızca sayfadaki ilk etkileşimin giriş gecikmesini ölçerdi. INP, giriş gecikmesinden olay işleyicilerinin çalışma süresine kadar sayfadaki tüm etkileşimleri gözleyerek FID’yi geliştirir.” Alıntıya git
• “First Input Delay (FID) is no longer a Core Web Vital, and has been replaced by the Interaction to Next Paint (INP) metric.” (Türkçe çeviri) “First Input Delay (FID) artık Core Web Vital değildir ve yerini Interaction to Next Paint (INP) metriğine bırakmıştır.” — web.dev, First Input Delay (FID). Alıntıya git

FID → INP geçişi

• “FID will be deprecated.” (Türkçe çeviri) “FID kullanımdan kaldırılacak.” — Jeremy Wagner ve Rick Viscomi, web.dev blogu, Interaction to Next Paint resmen Core Web Vital oluyor. Alıntıya git
• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12.” (Türkçe çeviri) “INP 12 Mart’ta Core Web Vital olur olmaz FID Google Search Console’dan kaldırılacak.” Alıntıya git

Uzun görevler — temel neden

• “Any task that takes longer than 50 milliseconds is a long task.” (Türkçe çeviri) “50 milisaniyeden uzun süren her görev uzun görevdir.” — web.dev, Uzun görevleri optimize etme. Alıntıya git

Alan verisi önceliklidir

• “Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users.” (Türkçe çeviri) “Gerçek kullanıcılar için hangi etkileşimlerin sorunlu olduğunu anlamada yararlanabileceğiniz en iyi bilgi kaynağı alan verisidir.” — web.dev, Alanda yavaş etkileşimleri bulma. Alıntıya git

Google Arama

• “We highly recommend site owners achieve good Core Web Vitals for success with Search.” (Türkçe çeviri) “Site sahiplerinin Arama’da başarı için iyi Core Web Vitals değerlerine ulaşmasını önemle öneriyoruz.” — Google Search Central, Core Web Vitals ve Google Arama sonuçları. Kaynak

INP düzeltme kontrol listesi

Yukarıdan aşağı ilerleyin; üstteki maddeler genellikle değeri en çok etkiler:

• Yalnız laboratuvar puanını değil, PageSpeed Insights / Search Console CWV raporundan alan INP değerini alın ve mobili ayrı kontrol edin.
• Yavaş etkileşimleri web-vitals attribution derlemesi veya Chrome DevTools Interactions iziyle belirleyin; 200 ms üzerini işaretler.
• Ana iş parçacığındaki uzun görevleri (50 ms üzeri) bulup bölün.
• Uzun döngülerde ana iş parçacığına teslim edin: scheduler.yield() ve setTimeout(..., 0) yedeği kullanın; isInputPending() kullanımını bırakın.
• Her işleyicide yalnızca çizim için kritik güncellemeyi eşzamanlı çalıştırın; kaydetme, doğrulama, yazım denetimi ve analizi rAF + setTimeout ardına erteleyin.
• Aynı görevde stil yazdıktan hemen sonra layout okumaya dayalı layout thrashing olup olmadığını kontrol edin; önce okumaları, sonra yazmaları gruplayın.
• Üçüncü taraf betiklerini denetleyin; erteleyin, tembel yükleyin veya etkileşime bağlayın. Çoğu zaman en büyük tek kazanımdır.
• DOM boyutunu küçültün; ekran dışı bölümlere content-visibility uygulayın.
• Kritik olmayan JS’yi erteleyin veya kod bölün; yükleme sonrası betikler erken etkileşimleri engellemesin.
• Yayından sonra alan verisinde yeniden ölçün; CrUX 28 günlük hareketli pencere kullandığı için puan yavaş değişir.

INP ve FID karşılaştırması — kısa başvuru

Kısa bilgiler

• Alan p75 eşikleri: İyi ≤ 200 ms · İyileştirme gerekiyor ≤ 500 ms · Kötü > 500 ms.
• Sayılanlar: tıklama, dokunma, klavye. Hariç: kaydırma, üzerine gelme, yakınlaştırma.
• Gecikme = giriş gecikmesi + işleme süresi + sunum gecikmesi.
• Uzun görev = ana iş parçacığında > 50 ms süren görev.
• Laboratuvar vekili: Total Blocking Time; yalnız yükleme sırasındaki engellemeyi yansıtır. Belirleyici kaynak alan verisidir (CrUX).
• Mobil geçiş oranı (%74), masaüstünden (%97) çok düşüktür ve önemli olan mobildir.

Ana iş parçacığına söz verin

Büyük bir listeyi oluşturmak veya tıklamayla veriyi işlemek gibi uzun süren bir döngünüz varsa, tarayıcının bekleyen kullanıcı etkileşimini işleyebilmesi için denetimi düzenli aralıklarla geri verin. Modern API scheduler.yield()’dır; desteklenmediği yerde setTimeout yedeğini kullanın.

// Yield to the main thread every ~50 ms of work so the browser
// can handle a user interaction in between.
async function runJobs(jobQueue, deadline = 50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    job();

    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

// scheduler.yield() resumes with priority; setTimeout is the fallback.
function yieldToMain() {
  if ('scheduler' in window && 'yield' in scheduler) {
    return scheduler.yield();          // Chrome 129+, Firefox 142+
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Bir kaç not:

• scheduler.yield(), gelecekteki bir görevde çözülen promise döndürür ve devam koduna öncelik verir; kuyruktaki diğer görevler sürdürdüğünüz kodun önüne geçmez.
• setTimeout(..., 0) her yerde çalışır, ancak devam kodunu kuyruğun sonuna iter; tarayıcılar iç içe birkaç çağrıdan sonra yaklaşık 5 ms alt sınır uygular.
• isInputPending() kullanmayın; Google “no longer recommend[s] using this API.” (Türkçe çeviri) “artık bu API’nin kullanılmasını önermiyor.”

İşleyicide kritik olmayan işi erteleyin

Yalnızca sonraki karenin gerektirdiğini çalıştırın; kalan işi çizim sonrasına bırakın.

textBox.addEventListener('input', (event) => {
  updateTextBox(event);                  // render-critical: do it now

  requestAnimationFrame(() => {
    setTimeout(() => {
      updateWordCount(text);             // everything else: after paint
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

INP’yi ölçme ve düzeltme araçları

Alan (yetkili kaynak; Google’ın puanladığı veri)

• PageSpeed Insights — URL/kaynak için CrUX alan INP’sini mobil ve masaüstü olarak ayırır; ayrıca laboratuvar tanılama geçişi sunar.
• Search Console — Core Web Vitals raporu — URL’lerinizin alan verisine dayalı INP durumunu soruna göre gruplar.
• CrUX — Temeldeki Chrome User Experience Report veri kümesi; CrUX API / BigQuery üzerinden de sorgulanabilir.

Laboratuvar / hata ayıklama

• Chrome DevTools — Performance paneli — Interactions izi her etkileşimin girdi gecikmesini, işleme ve sunum süresini ölçer; 200 ms üzerini işaretler. Live Metrics siz tıkladıkça güncellenir.
• Lighthouse — INP’yi doğrudan ölçemez; laboratuvar vekili olarak Total Blocking Time raporlar.

Gerçek kullanıcı izleme (RUM)

• web-vitals JS kitaplığı — Değer için onINP(); attribution derlemesi (web-vitals/attribution) inputDelay, processingDuration, presentationDelay, interactionTarget seçicisi ve LoAF girdilerini gösterir. Böylece yavaş etkileşime hangi betik ve öğenin yol açtığını görürsünüz. Hangi RUM kurulumunu kullanırsanız kullanın, örnekleme oranı ve ilişkilendirme kapsamını belgeleyin. Bu bağlam olmadan verilen RUM sayısı CrUX alan p75’iyle karşılaştırılamaz; ayrıca toplu metriğin gördüğü çapraz kaynaklı iframe içini göremez (Advanced sekmesindeki uç durumlara bakın).

Araçların kendi puanları

Bu sayfada açıklanan metriğin canlı bir örneği: bilinen sayfa hızı ve izleme hizmetleri, kendi gerçek kullanıcı mobil INP verilerine göre sıralanır (Chrome UX Report alan verisi):

Genellikle amacı kaçıran INP düzeltmeleri

Yalnızca ilk etkileşimi optimize etmek

INP yalnızca ilk girdiyi değil, ziyaret boyunca etkileşimleri değerlendirir. Sayfanın yanıt verdiğine karar vermeden önce menü, arama, filtre, form ve tekrarlanan diğer denetimleri deneyin.

Total Blocking Time’ı sonuç saymak

TBT uzun ana iş parçacığı görevlerini gösterdiği için yararlı laboratuvar vekilidir, ancak alan INP’si değildir. Aday sorunları onunla bulun; gerçek etkileşimleri alan verisi veya etkileşim iziyle doğrulayın.

Tüm işi tek gecikmeli geri çağrıya taşımak

Büyük bir bloğu ertelemek yalnızca donmayı başka yere taşıyabilir. İşi küçük görevlere bölün ve tarayıcının aralarında çizim yapabilmesi için söz verin.

İşleyiciyi kısaltmak için görsel geri bildirimi kaldırmak

Yanıt göstermeden çalışan denetim yine bozuk hissedilir. Önce anlık durum değişikliğini çizin, sonra kritik olmayan takip işini erteleyin.

Üç parçalı gecikme modeliyle INP tanılama

Her yavaş etkileşimde bakılacak üç yer vardır:

1. Girdi gecikmesi: Önceki ana iş parçacığı işi sürdüğü için olay bekledi. İşleyici başlamadan önceki uzun görevleri ve üçüncü taraf JavaScript’i denetleyin.
2. İşleme süresi: Olay işleyicisi fazla iş yaptı. Eşzamanlı işi azaltın, döngüleri bölün ve sonraki karenin gerektirmediği her şeyi erteleyin.
3. Sunum gecikmesi: İşleyiciden sonra stil, düzen veya çizim fazla sürdü. DOM karmaşıklığını azaltın ve yinelenen düzen hesaplamalarını zorlamayın.

İzdeki en büyük aşamayla başlayın. Daha hızlı işleyicinin yeni sunum darboğazını gizlememesi için her değişiklikten sonra aynı etkileşimi yeniden kaydedin.

INP değişikliğinin etkileşimi iyileştirdiğini kanıtlayın

İşleyici söz verme testi

Çalıştırılacak test: Uzun işi bölmeden veya söz vermeden önce ve sonra hedef etkileşimi Performance panelinde kaydedin. Beklenen sonuç: Etkileşimin işleme aralığı küçülür ya da bir çizimle bölünür. Başarısızlık yorumu: Pahalı iş başka yerdedir veya hâlâ eşzamanlı çalışır. İzleme penceresi: Yinelenen izlerde hemen. Geri alma tetikleyicisi: Denetim sırasız güncellenir, durumunu kaybeder veya yeni girdi hataları üretir.

Sunum testi

Çalıştırılacak test: Aynı izde olay işleyicisinden sonraki stil, düzen ve çizim işlerini inceleyin. Beklenen sonuç: Daha büyük bir düzen görevi oluşmadan sonraki çizim daha erken gelir. Başarısızlık yorumu: DOM boyutu veya zorunlu düzen darboğaz olmaya devam eder. İzleme penceresi: Laboratuvar izlerinde hemen. Geri alma tetikleyicisi: Görsel yanıt eksik veya kararsız hale gelir.

Alan doğrulaması

Çalıştırılacak test: Değişen etkileşim ve şablonun yayın sonrası onINP() ilişkilendirmesini temel değerle karşılaştırın. Beklenen sonuç: p75 INP iyileşir ve hedef öğe artık yavaş olaylara baskın olmaz. Başarısızlık yorumu: Laboratuvar durumu gerçek cihazları veya yolculukları temsil etmemiştir. İzleme penceresi: Ziyaretler geldikçe RUM; 28 günlük hareketli penceresinde CrUX. Geri alma tetikleyicisi: Yayından sonra yanıt verebilirlik veya etkileşimin tamamlanması sürekli kötüleşir.

İzlenmeye değer INP metrikleri

p75’te gerçek kullanıcı INP’si

Metrik: Şablon ve cihaz sınıfına göre 75. yüzdelik INP. Size ne söyler: Tipik gerçek ziyaretlerin tüm yolculuk boyunca yanıt verip vermediğini. Nasıl alınır: CrUX, PageSpeed Insights veya web-vitals RUM. Karşılaştırma / gerçekçi aralık: 200 ms veya altı iyi, 500 ms üzeri kötüdür. Sıklık: JavaScript yayınlarından sonra izleyin; hareketli alan eğilimini aylık inceleyin.

Yavaş etkileşim oranı

Metrik: Hedefe göre gruplanmış, 200 ms üzerindeki ölçülen etkileşimlerin payı. Size ne söyler: Sayfa düzeyi p75 geçse bile hangi denetimlerin en çok görünür gecikmeyi ürettiğini. Nasıl alınır: web-vitals attribution derlemesi veya RUM’daki Event Timing verisi. Karşılaştırma / gerçekçi aralık: Her yolculuk için temel değer belirleyip yüksek hacimli sorunları azaltın. Sıklık: Uygulama benzeri şablonlarda haftalık.

Gecikme aşaması payı

Metrik: Yavaş etkileşimlerin girdi gecikmesi, işleme süresi ve sunum gecikmesi. Size ne söyler: Ana kısıtın zamanlama, işleyici kodu veya oluşturma olup olmadığını. Nasıl alınır: DevTools izleri ve INP ilişkilendirmesi. Karşılaştırma / gerçekçi aralık: Evrensel sağlıklı bir dağılım yoktur; her aşamayı kendi temeliyle ve toplam 200 ms iyi eşiğiyle karşılaştırın. Sıklık: Her odaklı performans incelemesinde.

Zaman ayırmaya değer kaynaklar

Google / Chrome (temel kaynaklar)

• Interaction to Next Paint (INP) — Buradan başlayın.
• Interaction to Next Paint’i optimize etme — Düzeltmeler.
• Uzun görevleri optimize etme — Söz verme, scheduler.yield().
• Alanda yavaş etkileşimleri bulma — LoAF + ilişkilendirme hata ayıklaması.
• INP bir Core Web Vital oluyor — 12 Mart 2024’teki başlangıç.

Veri

• Web Almanac 2024 — Performans — Gerçek dünyadaki INP geçiş oranları ve alt bölüm medyanları.

Sektörden

• INP — MDN Web Docs — Tarayıcı desteğini ve metrik tanımını Google belgeleri dışında doğrulamak için MDN başvurusu.
• Scheduler API: scheduler.yield() — MDN — Ana söz verme ilkelinin tarayıcı destek tablosu ve belirtim ayrıntıları.
• PerformanceEventTiming — MDN — INP’nin okuduğu temel tarayıcı API’si; ham olay zamanlamasını incelerken yararlıdır.
• Long Animation Frames API — Chrome Platform Status — web-vitals kitaplığındaki INP ilişkilendirmesini besleyen LoAF API’sinin tarayıcı desteği.
• INP konusu — Search Engine Land — INP güncellemeleri, test sonuçları ve FID’den INP’ye geçiş hakkında sektör haberleri.

Alıntılanmaya değer istatistikler

• Mobilde yaklaşık %74, masaüstünde yaklaşık %97 INP geçişi (2024). Mobil çok daha zordur; Google mobil öncelikli dizine eklediği için SEO açısından önemli sayı budur. Web Almanac 2024
• En büyük 1 000 sitenin yalnızca yaklaşık %53’ü INP’den geçiyor. Özellik bakımından zengin siteler ana iş parçacığını engelleyen daha fazla JavaScript gönderdiğinden en büyük siteler çoğu zaman daha kötü sonuç verir. Web Almanac 2024
• Uzun görev = > 50 ms. Ana iş parçacığında 50 ms’yi aşan her iş, tarayıcının etkileşimlere yanıt vermesini engeller; kötü INP’nin doğrudan mekanizmasıdır. web.dev — Uzun görevleri optimize etme
• Alt bölüm medyanları (2024): Sunum gecikmesi yaklaşık 36 ms ile medyandaki en büyük tek katkı olur; p75’te girdi gecikmesi ve işleme süresi yakından izler. Bu, hangi üçte bire müdahale edileceğini belirlemede yararlıdır. Web Almanac 2024

Videolar

• Google Chrome Developers (YouTube) — Chrome ekibinin Core Web Vitals ve INP açıklamaları; DevTools’ta yavaş etkileşim tanılama gösterimleri dahil. Kanal

Kendinizi sınayın: Interaction to Next Paint

Yanıt verebilirlik ve INP tanısı hakkında beş kısa soru. Her biri için yanıt seçip kontrol edin.

Değişiklik günlüğü