INP Nedir? Etkileşim Gecikmesini Ölçme ve İyileştirme

Bir düğmeye dokunuyorsunuz, ekran bir an hiçbir şey olmamış gibi bekliyor, sonra yanıt geliyor. Kullanıcı bu kısa duraksamayı "site takıldı" diye yaşar. INP (Interaction to Next Paint, "sonraki boyamaya etkileşim") tam olarak bu duraksamayı ölçen Core Web Vitals metriğidir. Kısa cevap: INP, bir ziyaret boyunca yapılan tıklama, dokunma ve klavye etkileşimlerinin gecikmesini izler ve çoğu sitede en kötü etkileşimi tek bir değer olarak raporlar. 200 milisaniye ve altı iyi, 500 milisaniyenin üstü zayıf sayılır.

Bu rehber SEO uzmanı, geliştirici ve ürün sahibi için hazırlandı. Önce INP'nin neyi ölçtüğünü ve neyi ölçmediğini netleştirir, sonra yavaş etkileşimi alan verisinde bulmanın yolunu gösterir. Ardından yanıt süresini üç aşamaya bölen modeli kullanarak uzun görevleri, olay işleyicilerini, yeniden çizim maliyetini ve üçüncü taraf betikleri sırayla ele alır. Sonda sorunları etki ve çabaya göre sıralayan bir öncelik listesi bulacaksınız. Yazı genel bilgi içindir; sitenizin gerçek darboğazı yalnızca kendi ölçümünüzle ortaya çıkar ve hiçbir düzeltme belirli bir sıralama sonucu garanti etmez.

INP Neyi Ölçer ve Eşikler Nelerdir

INP'yi doğru iyileştirmek için önce neyi saydığını bilmek gerekir. Metrik, sayfanın tepki verme hızını kullanıcı etkileşimleri üzerinden değerlendirir ve bunu tarayıcının Event Timing API'sine dayanarak hesaplar. web.dev'in INP makalesi (yeni sekmede açılır) bu tanımı ve eşikleri veren birincil kaynaktır.

Hangi etkileşimler sayılır

Etkileşim, tek bir mantıksal kullanıcı hareketi sırasında çalışan olay işleyicilerinin bütünüdür. Dokunma için pointerdown, pointerup ve click olayları aynı etkileşimin parçasıdır; klavyede keydown, keypress ve keyup birlikte düşünülür. Ölçüme giren hareketler fare tıklaması, dokunmatik ekran dokunuşu ve tuş basımıdır. Kaydırma, üzerine gelme (hover) ve yakınlaştırma ölçülmez. Bu hareketlerin içinde tıklama, dokunma veya tuş basımı varsa o kısım yine de ölçülebilir.

Bunun pratik sonucu şudur: Hiç tıklanmayan, yalnızca kaydırılan bir haber sayfasında INP değeri hiç oluşmayabilir. Botlar ve betiklenmiş etkileşimi olmayan başsız tarayıcılar da değer üretmez. Raporda INP görmemek tek başına "sorun yok" demek değildir; kimi zaman yalnızca ölçülecek etkileşim yoktur.

Değer nasıl hesaplanır

Sayfanın INP değeri kullanıcı sayfadan ayrılırken hesaplanır. Çoğu sitede ziyaret boyunca görülen en yüksek gecikmeli etkileşim raporlanır. Çok sayıda etkileşim yaşanan sayfalarda her 50 etkileşim için en yüksek olan bir tanesi yok sayılır, böylece tek seferlik bir aksama bütün değeri belirlemez. Ardından sayfa görüntülemeleri arasında 75. yüzdelik değer alınır ve mobil ile masaüstü ayrı değerlendirilir.

Gecikme, kullanıcının girdisinin başladığı andan ekranda sonucu gösteren bir sonraki karenin boyandığı ana kadar geçen süredir. Yani yalnızca kodunuzun çalışma süresi değil, tarayıcının sonucu ekrana yansıtması da dahildir.

Eşikler

FID'den farkı ve iki sınır durumu

INP, First Input Delay (FID) metriğinin yerini aldı. FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyordu ve ağırlıklı olarak yükleme sırasındaki tepkiyi gösteriyordu. INP ise zamanlamasına bakmadan tüm etkileşimleri, giriş gecikmesinden işlemeye ve sunuma kadar kapsar. Eski FID alışkanlığıyla "yalnızca ilk tıklamaya bakmak" bu yüzden artık yetersizdir.

İki sınır durumunu bilmek raporu yanlış yorumlamayı önler. Birincisi, sayfa geri/ileri önbelleğinden (bfcache) geri yüklenirse INP sıfırlanır, çünkü kullanıcı bunu yeni bir ziyaret olarak yaşar. İkincisi, iframe içindeki etkileşimler üst sayfanın deneyimini etkiler ve sayfa düzeyinde sayılır; ancak Event Timing API iframe kayıtlarını doğrudan üst sayfaya vermez, alt çerçevenin kayıtları üst çerçeveye iletilmelidir. Bu yüzden yerleşik ödeme formu, harita ya da reklam çerçevesi gibi bileşenler INP'yi etkiliyor olabilir ve ana sayfanın kodunda hiçbir kusur görünmeyebilir.

Alan Verisi ile Laboratuvarı Birleştirme

INP davranışa bağlı bir metriktir: Kullanıcı neye ne zaman tıkladığına göre değişir. Bu yüzden önce alan verisiyle sorunun var olup olmadığını, sonra laboratuvarda sebebini aramak gerekir. Alan ve laboratuvar ayrımının genel çerçevesi için CrUX alan verisi ve laboratuvar verisi farkı yazısına bakabilirsiniz; burada yalnızca INP'ye özgü kısmı ele alıyoruz.

Hangi sayfada, hangi etkileşimde

PageSpeed Insights gerçek kullanıcı (CrUX) verisini gösterir, ama web.dev'in anlatımına göre bu veri çoğunlukla hangi etkileşimin yavaş olduğu bağlamını içermez. Hangi öğenin, tıklama mı dokunma mı klavye mi olduğunun, sayfa yüklenirken mi sonra mı yaşandığının cevabı için gerçek kullanıcı izleme (RUM) çözümü gerekir. Kendi RUM'unuzu kuruyorsanız web-vitals kütüphanesinin attribution sürümü bu bağlamı üretir.

web.dev'in alanda yavaş etkileşimleri bulma (yeni sekmede açılır) sayfasına göre attribution nesnesi şu alanları verir: etkileşimi üreten öğenin CSS seçicisi (interactionTarget), girdi türü (interactionType) ve üç aşamanın süreleri (inputDelay, processingDuration, presentationDelay). Ayrıca etkileşimle ilişkili Long Animation Frame kayıtlarını (longAnimationFrameEntries) da içerir. Bu kayıtlardaki betik girdileri hangi betiğin, hangi fonksiyonun ve hangi çağırıcı türünün (örneğin olay dinleyicisi, zamanlayıcı ya da modül betiği) işi uzattığını gösterir.

Laboratuvarda yeniden üretme

RUM verisi "nerede" sorusunu cevaplar, laboratuvar "neden" sorusunu. web.dev yavaş etkileşimleri laboratuvarda bulmak için yaygın kullanıcı akışlarını izlemenizi ve her adımda etkileşim denemenizi önerir. Özellikle sayfa yüklenirken etkileşime girmek önemlidir, çünkü ana iş parçacığı genellikle en yoğun o sırada çalışır. Tek bir "yüklendi, sonra ölç" denemesi bu yüzden yanıltıcı olur.

Ölçüm kayıtlarını okurken şu soruları sırayla sorun: Gecikmenin hangi aşaması uzun? Aynı etkileşim yükleme sırasında mı yoksa sonrasında mı yavaş? Aynı davranış yalnızca mobilde mi görülüyor? Bu üç cevap, aşağıdaki bölümlerde hangi yoldan gideceğinizi belirler.

Long Animation Frame kayıtlarını okumak

Attribution verisi tek başına bir süre listesi değildir; her aşamanın nedenini okumanıza izin verir. web.dev'in anlattığı okuma düzeni şöyledir. İşleme süresi uzunsa son Long Animation Frame kaydındaki betikleri süreye göre sıralayıp en uzun olanı alırsınız. Giriş gecikmesi uzunsa ilk kayda bakarsınız: çağırıcı türü classic-script ya da module-script ise yükleme sırasındaki betik değerlendirmesi, user-callback ise zamanlayıcı ya da requestAnimationFrame işi, event-listener ise daha önceki bir girdinin hâlâ işlenmesi, promise türleri ise etkileşim sırasında sonuçlanan eşzamansız iş anlamına gelir. Sunum gecikmesi uzunsa renderStart ile styleAndLayoutStart değerlerini karşılaştırarak requestAnimationFrame işini, startTime ile duration değerlerinden de stil ve yerleşim süresini kabaca kestirirsiniz.

Bu okuma düzeninin değeri şudur: "JavaScript yavaş" gibi belirsiz bir hükümden, "şu dosyadaki şu fonksiyon, şu etkileşimde, şu aşamayı uzatıyor" cümlesine geçersiniz. Böyle bir cümle kuramıyorsanız henüz düzeltmeye hazır değilsiniz demektir.

Örnek senaryo: filtre düğmesi

Örnek senaryo olarak bir ilan listeleme sayfasını düşünelim. Kullanıcı "filtrele" düğmesine dokunuyor ve liste yenilenene kadar düğme basılmış görünmüyor. RUM kaydı etkileşimin dokunma olduğunu, hedefin filtre düğmesi olduğunu ve süreyi işleme aşamasının uzattığını gösteriyor. Bu durumda giriş gecikmesini düşürmek için bir şey yapmak boşa çabadır; çözüm, olay işleyicisinin içindeki işi bölmek ve düğmenin görsel durumunu önce güncellemektir. Aşamayı baştan ayırmak, yanlış yere zaman harcamayı engeller.

Uzun Görevler ve Ana İş Parçacığı

Tarayıcının ana iş parçacığı aynı anda tek iş yürütebilir. Betik çalıştırma, stil hesaplama, yerleşim ve olay işleyicileri sırayla bu iş parçacığını kullanır. O meşgulken kullanıcının dokunuşu kuyrukta bekler.

50 milisaniye kuralı

web.dev'in uzun görevleri optimize etme (yeni sekmede açılır) sayfası, 50 milisaniyeden uzun süren her görevi uzun görev olarak tanımlar. Görevin toplam süresinden 50 ms çıkarıldığında kalan kısım engelleme süresidir. JavaScript tamamlanana kadar çalışma modeline sahiptir: Bir görev ne kadar uzun sürerse sürsün bitene kadar ana iş parçacığını bırakmaz. Tek bir tıklama işleyicisi birden çok fonksiyon çağırıp uzun bir görev oluşturursa, görünür geri bildirim gecikir ve INP kötüleşir.

Giriş gecikmesinin kaynakları

Giriş gecikmesi, kullanıcının girdisi ile olay işleyicilerinin başlaması arasındaki süredir. web.dev bu sürenin nedenleri arasında betiklerin yüklenmesi, ayrıştırılması ve derlenmesi gibi ana iş parçacığı işlerini, fetch yanıtlarının işlenmesini, zamanlayıcı fonksiyonlarını ve peş peşe yapılan etkileşimlerin çakışmasını sayar. Betik değerlendirme (ayrıştırma, derleme, çalıştırma) yükleme sırasında uzun görevler yaratabilir. Dolayısıyla sayfa açılırken hemen bir menüye ya da sepet düğmesine basan kullanıcı, henüz bitmemiş bir betik yükünün arkasında bekleyebilir.

İşi bölmek: setTimeout ve scheduler.yield

Uzun işi küçük görevlere bölmek, tarayıcıya aralarda kullanıcı girdisine yanıt verme fırsatı tanır. Sayfa iki yöntemi anlatır.

• setTimeout(fn, 0): Geri çağırmayı yeni bir göreve taşır. Dezavantajları vardır: Beş iç içe çağrıdan sonra tarayıcılar her ek çağrıya en az 5 ms gecikme uygular ve ertelenen görev kuyruğun sonuna gider, yani bekleyen diğer görevler önce çalışır.
• scheduler.yield(): await ile duraklatıp yeni bir görevde devam etmeyi sağlar. Devam eden iş öncelikli sürdürülür, yani benzer diğer görevlerden önce çalışır. Sayfa kademeli iyileştirme için await globalThis.scheduler?.yield?.() biçimini önerir; hem global scheduler nesnesinin hem de yield yönteminin var olup olmadığını kontrol etmek gerekir.

Desteğe ilişkin not: Sayfadaki destek tablosuna göre scheduler.yield() Chrome 129, Edge 129 ve Firefox 142 sürümlerinde var; Safari'de desteklenmiyor. Destek olmayan tarayıcılarda yine de yield edilir, ama öncelikli devam özelliği kaybolur. Bu nedenle özellik kontrolü ve bir yedek yol şarttır; scheduler-polyfill de bir seçenektir.

Güncellik notu: scheduler.yield() ve isInputPending() desteği tarayıcı sürümüne bağlıdır; kullanmadan önce güncel tarayıcı desteğini kontrol edin.

Yükleme sırasındaki etkileşimler neden ayrı ele alınmalı

Sayfa yüklenirken ana iş parçacığı betik indirme, ayrıştırma, derleme ve çalıştırma ile doludur. Kullanıcı bu sırada bir menüyü açmaya çalışırsa dokunuş kuyruğa girer ve giriş gecikmesi büyür. Bu yüzden "sayfa tamamen yüklendikten sonra hızlı" olması tek başına yeterli değildir. Menü, arama kutusu ve çerez tercihi gibi sayfa açılır açılmaz kullanılan bileşenlerin kodunu öne alın, ağır ama acil olmayan betikleri sonraya bırakın. Hangi bileşenin ilk saniyelerde en çok kullanıldığını RUM kayıtlarında etkileşimin yükleme sırasında mı yoksa sonrasında mı yaşandığına bakarak görebilirsiniz.

Sık yapılan üç hata

• await'i unutmak: scheduler.yield() yalnızca görevi planlar, duraklatan await'tir.
• forEach ile yield etmeye çalışmak: Yineleyici yöntemler her geri çağırmayı beklemez, aralarda doğru biçimde yield etmez. Bunun yerine döngü ya da for...of kullanılmalıdır.
• Her kısa işten sonra yield etmek: Yield'in kendi maliyeti vardır. Uzun iş kuyruklarında yalnızca bir süre sınırı (sayfanın örneğinde 50 ms) aşıldığında yield etmek toplam tamamlanma süresiyle yanıt verme arasında denge kurar.

isInputPending() ise sayfaya göre artık önerilmiyor: Kullanıcı etkileşiminden sonra yanlışlıkla false dönebilir, girdi yield etmenin tek nedeni değildir ve scheduler.postTask() ile scheduler.yield() bu ihtiyaçları karşılar. Eski kodunuzda bu API varsa gerekçeyi gözden geçirin.

Olay İşleyicileri ve Yeniden Çizim Maliyeti

İşleme süresi ve sunum gecikmesi, doğrudan sizin yazdığınız kodla ve sayfanızın yapısıyla ilgilidir. İki aşama farklı çözümler ister.

Geri çağırmaları hafif tutmak

web.dev'in INP iyileştirme rehberi (yeni sekmede açılır) olay geri çağırmalarında mümkün olan en az işi yapmayı önerir. İşi ayrı görevlere bölmek diğer etkileşimlerin daha erken çalışmasını sağlar. Önerilen sıra şudur: Önce kullanıcının göreceği arayüz güncellemesini yapın, sonra kritik olmayan işi erteleyin. Rehberdeki örnekte kelime sayımı, yazım denetimi ve kaydetme gibi işler, arayüz güncellendikten sonra requestAnimationFrame içindeki iç içe bir setTimeout ile kuyruğa alınır.

Kendi kodunuza uygularsanız bu şu anlama gelir: Bir "sepete ekle" tıklamasında sayaç ve düğme durumu hemen güncellenmeli, analitik çağrısı, öneri listesi yenilemesi ve yerel depolama yazımı sonraya bırakılmalıdır.

Zorunlu yerleşim (layout thrashing)

Aynı görevde önce stil değiştirip sonra yerleşim bilgisini okumak, tarayıcıyı yerleşimi eşzamanlı olarak yeniden hesaplamaya zorlar. Buna layout thrashing denir. Chrome DevTools Performance panelinde bu durum kırmızı üçgenle ve "Recalculate Style" ya da "Layout" etiketiyle görünür. Bir döngü içinde hem öğe boyutu okuyup hem stil yazıyorsanız, önce tüm okumaları, sonra tüm yazmaları yapmak maliyeti azaltır.

DOM boyutu ve sunum gecikmesi

Sunum gecikmesi, geri çağırmalar bittikten sonra sonucun ekranda görünmesine kadar geçen süredir. Rehber, render işinin DOM boyutuyla doğrusal olmasa da arttığını belirtir: Büyük bir DOM hem ilk render'ı hem de etkileşim sonrası render'ı yavaşlatır. Çözüm olarak DOM'u sadeleştirmek ya da öğeleri baştan değil etkileşim sırasında eklemek önerilir. Ekran dışı öğelerin render'ını ertelemek için content-visibility kullanılabilir.

İstemci tarafında JavaScript ile büyük miktarda HTML üreten tek sayfa uygulama modeli, ayrıştırma ve render bitene kadar tarayıcının yield etmesini engelleyebilir. Küçük miktarlarda sorun olmaz, büyük miktarlarda maliyetlidir. Uzun bir ilan listesini tek seferde basmak yerine parça parça eklemek ve ekran dışındakilerin render'ını ertelemek bu yüzden mantıklıdır.

Aşamaya göre karar kuralı

Karar kuralı şu: Önce baskın aşamayı belirleyin, yalnızca o aşamanın çözümünü uygulayın ve tekrar ölçün. Aşama belli değilken yapılan genel "optimizasyon" çoğunlukla etkisiz kalır.

Üçüncü Taraf Yükü ve Öncelik Listesi

Analitik, reklam, sohbet kutusu ve ödeme bileşenleri gibi üçüncü taraf betikler kendi ana iş parçacığı zamanını harcar. Reklam gelirine dayanan sitelerde bu denge ayrıca önemlidir; bu konuyu reklam ve Core Web Vitals dengesi yazısında daha geniş ele aldık.

Yüklemeyi sıraya koymak

web.dev'in üçüncü taraf JavaScript yükleme (yeni sekmede açılır) sayfası, kritik render yolu için zorunlu olmadıkça üçüncü taraf betiklerde async ya da defer kullanmayı önerir. async betiği HTML ayrıştırmasıyla paralel indirir ve çalışmadan önce ayrıştırmayı durdurur; defer ise ayrıştırma bittikten sonra çalıştırır. Erken çalışması gereken bazı analitik betikleri için async, daha az kritik içerik için defer uygundur. jQuery gibi temel kütüphanelerde async kullanılmamalıdır. Blink tabanlı tarayıcılarda her iki öznitelik de istek önceliğini düşürür, dolayısıyla analitik beklediğinizden geç yüklenebilir.

Kaynak ipuçları da yardımcı olur: dns-prefetch DNS çözümlemesini erkenden yapar, preconnect ise TCP ve TLS kurulumunu da kapsar. Sayfa, preconnect'in yükleme süresini önemli ölçüde azaltabileceğini söyler. Alt bilgideki reklam gibi gömülü kaynaklar gerektiğinde yüklenecek şekilde tembel yüklenebilir; bunun için scroll dinleyicisi yerine IntersectionObserver önerilir. Sayfa, tembel yüklemenin JavaScript'e dayandığı için kararsız ağlarda aksayabileceğini de hatırlatır.

Etkisini ölçmeden kaldırmayın

Sayfa, bir üçüncü tarafın maliyetini şöyle ölçmeyi anlatır: Ağ ve işlemci kısıtlamasını açın, başlangıç ölçümünü kaydedin, şüpheli URL'leri DevTools'ta "Block Request URL" ile engelleyip yeniden yükleyin ve en az üç kez ölçün. Performance panelinin Bottom-up görünümünde "Group by product" ile hangi ürünün ne kadar süre harcadığı görülür. Lighthouse'taki JavaScript başlatma süresi ve ağ yükü denetimleri de ipucu verir. Uzun görevleri kod içinde izlemek isterseniz longtask girdileri için PerformanceObserver kullanılabilir.

Sayfada üçüncü tarafların milisaniye bütçesi ya da bayt sınırı gibi sayısal eşikler yok; bu yüzden "şu kadar betik yeter" gibi bir kural kuramazsınız. Karar, kendi ölçümünüze dayanır. Yerleşik bir iframe kullandığınızda, sayfaya göre iframe'e yüklenen üçüncü taraf betik ana sayfanın yürütmesini engellemez, ancak INP sayfa düzeyinde iframe etkileşimlerini de içerir. İlgili etkileşimin hangi çerçevede yaşandığını kontrol edin.

Öncelik listesi

Aşağıdaki sıra, bir çalışma planı önerisidir; her adımın etkisini kendi ölçümünüzle doğrulayın.

1. Alan verisinde INP'nin hangi sayfa grubunda ve hangi cihazda sorunlu olduğunu belirleyin.
2. RUM kaydından etkileşimi (hedef öğe, tür, yükleme sırasında mı sonra mı) bulun.
3. Gecikmeyi üç aşamaya bölün ve baskın aşamayı seçin.
4. Yükleme sırasındaki betik yükünü azaltın: gereksiz üçüncü tarafı kaldırın, kalanlara async ya da defer verin.
5. Ağır olay işleyicilerinde önce arayüzü güncelleyin, kalan işi yield ile bölün.
6. Sunum gecikmesi baskınsa DOM boyutunu ve zorunlu yerleşimi inceleyin.
7. Değişikliği yayına alın, alan verisinin güncellenmesini bekleyin ve karşılaştırın.

Düzeltmeyi Doğrulama ve Raporlama

İyileştirme yapıp laboratuvarda hızlı bir sonuç görmek yeterli değildir; çünkü INP'nin kararı alan verisinde verilir. Alan verisi birikme süresi gerektirir, bu yüzden değişiklik sonrası hemen sonuç beklemeyin. PageSpeed Insights ve Search Console'daki gruplama mantığı için önceki yazılardaki yöntemi izleyebilirsiniz; kapsamlı rehberimiz sayfa hızı ve Core Web Vitals rehberi, puan yorumu için ise PageSpeed Insights puanı ne anlama gelir yazısı kullanışlıdır.

Kontrol listesi

• İyileştirmeden önce hedef etkileşim ve sayfa grubu yazıldı mı?
• Mobil ve masaüstü ayrı izlendi mi?
• Yükleme sırasında yapılan etkileşimler de denendi mi?
• Değişiklik tek aşamayı hedefliyor mu, yoksa aynı anda birçok şey mi değişti?
• Üçüncü tarafın kaldırılması ya da ertelenmesi iş gereksinimini bozuyor mu?
• Özellik desteği kontrolü ve yedek yol (örneğin scheduler.yield için) eklendi mi?
• Alan verisi yeterince güncellendikten sonra sonuç karşılaştırıldı mı?

Rapora yazılacaklar

Müşteriye ya da ekibe sunulan raporda yalnızca "INP iyi/kötü" yazmak yetersizdir. Etkilenen sayfa grubunu, baskın aşamayı, uygulanan değişikliği ve değişiklik tarihini kaydedin. Alan verisinde beklenen iyileşme gecikmeli göründüğü için tarih kaydı, ileride sebep-sonuç ilişkisini kurmanın tek yoludur. Ölçüm yapılamayan durumlarda (yetersiz alan verisi, hiç etkileşim olmaması) bunu açıkça yazın; boş veriyi iyi sonuç gibi sunmayın.

Ekip içinde iş paylaşımı

INP sorunları genellikle tek bir kişinin alanında kalmaz. Giriş gecikmesi çoğu zaman betik yönetimi ve üçüncü taraf kararlarıyla, işleme süresi ön yüz geliştiricisinin yazdığı olay mantığıyla, sunum gecikmesi ise şablon yapısı ve DOM büyüklüğüyle ilgilidir. SEO tarafı hangi sayfa grubunun etkilendiğini ve iş önceliğini belirler; geliştirici attribution kayıtlarından sebebi çıkarır; pazarlama ya da reklam sorumlusu hangi üçüncü tarafın iş açısından vazgeçilmez olduğunu söyler. Bu rollerin ortak bir tablo üzerinden konuşması, "hızlandıralım" gibi belirsiz taleplerin yerine "şu şablondaki şu etkileşimin işleme süresini kısaltalım" gibi sınanabilir görevler üretir.

Önemli bir uyarı daha: Aynı anda birden çok değişiklik yapmak, hangisinin işe yaradığını görünmez kılar. Alan verisi zaten gecikmeli güncellendiği için her sürümde mümkünse tek bir aşamaya yönelik tek bir değişiklik yapmak, öğrenme hızınızı artırır.

Yaygın yanlış okumalar

• "Laboratuvar testinde etkileşim yaşanmadı, demek ki sorun yok": Laboratuvarda tek bir yükleme, gerçek kullanıcıların ne zaman neye tıkladığını bilemez; karar alan verisinde verilir.
• "Ortalama gecikme düşük": INP ortalama değil, en kötü etkileşime yakın bir değerdir ve 75. yüzdelikle okunur.
• "Sayfa hızlı yükleniyor, INP de iyidir": Yükleme hızı ile tepki verme farklı şeylerdir; hızlı yüklenen sayfa ağır bir tıklama işleyicisine sahip olabilir.
• "Tek bir optimizasyon hepsini çözer": Üç aşama farklı kaynaklardan beslenir.

Sık Sorulan Sorular

INP nedir ve hangi değer iyi sayılır?

INP, ziyaret boyunca yapılan tıklama, dokunma ve klavye etkileşimlerinin gecikmesini izleyen ve çoğu sayfada en yüksek gecikmeli etkileşimi raporlayan Core Web Vitals metriğidir. web.dev'e göre 75. yüzdelikte 200 ms ve altı iyi, 200 ile 500 ms arası iyileştirme gerekli, 500 ms üstü zayıftır. Mobil ve masaüstü ayrı değerlendirilir.

INP, FID'in yerini aldı mı, farkları ne?

Evet, INP First Input Delay metriğinin yerini aldı. FID yalnızca ilk etkileşimin giriş gecikmesini ölçerdi. INP ise tüm etkileşimleri giriş gecikmesi, işleme süresi ve sunum gecikmesiyle birlikte, ne zaman yaşandıklarından bağımsız olarak kapsar.

Kaydırma ve üzerine gelme INP'yi etkiler mi?

Kaydırma, üzerine gelme ve yakınlaştırma ölçülmez. Bu hareketlerin içinde tıklama, dokunma ya da tuş basımı varsa o kısım ölçülebilir. Yalnızca kaydırılan ya da hiç etkileşim yaşanmayan sayfalarda INP değeri oluşmayabilir.

INP'yi iyileştirmek için nereden başlamalıyım?

Önce alan verisinde sorunlu sayfa grubunu ve cihazı belirleyin, sonra RUM kaydından yavaş etkileşimi bulun. Gecikmeyi giriş gecikmesi, işleme süresi ve sunum gecikmesi olarak üçe bölüp yalnızca baskın aşamanın çözümünü uygulayın. Ardından alan verisinin güncellenmesini bekleyerek karşılaştırın.

scheduler.yield() her tarayıcıda çalışır mı?

web.dev'in destek tablosuna göre Chrome 129, Edge 129 ve Firefox 142 sürümlerinde desteklenir; Safari'de desteklenmez. Destek yoksa özellik kontrolü yapıp setTimeout tabanlı bir yedek yol kullanmak gerekir. Yedek yolda öncelikli devam özelliği olmaz.

Üçüncü taraf betikleri tamamen kaldırmam gerekir mi?

Hayır. Önce etkisini ölçün: ağ ve işlemci kısıtlamasıyla bir başlangıç kaydı alın, şüpheli URL'yi engelleyip yeniden ölçün. Zorunlu olmayanları kaldırın ya da erteleyin, kalanlarda async veya defer kullanın. Belgelerde üçüncü taraflar için sayısal bir bütçe verilmiyor, karar kendi ölçümünüze dayanır.

Sonuç

INP, sayfanın dokunuşlara ne kadar çabuk görünür yanıt verdiğini ölçer ve karar alan verisinde, 75. yüzdelikte verilir. İyileştirme yolu bellidir: Önce sorunlu etkileşimi bulun, gecikmeyi giriş, işleme ve sunum olarak ayırın, ardından yalnızca baskın aşamaya yönelik düzeltmeyi uygulayın. Uzun görevleri bölmek, olay işleyicilerinde önce arayüzü güncellemek, DOM'u küçültmek ve üçüncü taraf yükünü ölçerek yönetmek bu sürecin ana araçlarıdır. Hiçbir adım belirli bir sıralama sonucunu garanti etmez; hedef, gerçek ziyaretçilerin daha akıcı bir deneyim yaşamasıdır.

Reklam alanı satan ya da reklamla gelir elde eden bir yayıncıysanız, sayfa tepki süresini bozmayan yerleşimler seçmek önemlidir. Kullanılabilir yerleşimleri ve koşullarını incelemek isterseniz Akua Adforce'taki reklam alanları sayfasına bakabilirsiniz; kapsam ve şartlar ürün sayfasında listelenir.