Yedi Dalda Başarısız Bir INP'nin Kod Satırını Geriye Doğru İzleyin

Kırmızı bir INP puanı, üç aşamadan hangisinin zaman kaybına neden olduğunu bilene kadar bir performans sorunu değildir. Çoğu ekip bu adımı atlar, bir önbellekleme eklentisi satın alır veya bir komut dosyasını erteler ve 75. yüzdelik dilimin hareket etmeyi reddettiğini izler. Bu kılavuz, bunun yerine kullandığımız karar ağacıdır: başarısız bir Chrome UX Raporu numarasından sorumlu belirli işleyiciye, komut dosyasına veya üçüncü taraf etiketine götüren yedi dal ve her dalda belirtilen bir eşik. Dönüşüm sayısına ve Lighthouse puanına sahip ön uç yöneticileri ve büyüme ekipleri için yazılmıştır.

Aradaki fark gerçek. 2025 Web Yıllığı'nda, Mobil kaynaklı aramaların %77'sinde iyi bir INP (Giriş-Çıkış Profili) vardı. masaüstünde %97'ye karşı ve sadece Mobil kaynaklı erişimlerin %48'i üç temel web ölçütünün tamamını karşıladı. (HTTP ArşiviMobil cihazlarda hâlâ sorunlu olan şey çoğunlukla etkileşim gecikmesidir ve bu sorun büyük ölçüde teşhis edilebilir.

INP'nin ölçtüğü ve sessizce görmezden geldiği şeyler

Interaction to Next Paint, sayfa ziyareti başına bir etkileşim gecikmesi bildirir. 75. persentil Kökeniniz boyunca. İyidir. 200 ms veya daha az200 ms ile 500 ms arası değerler "geliştirilmesi gerekiyor", 500 ms üzeri değerler ise "kötü" olarak değerlendirilebilir.web.devBu tanımı değiştiren üç şey, hata ayıklama şeklinizi etkiler:

• Sadece tıklamalar, dokunmalar ve tuş vuruşları sayılır. Fareyle üzerine gelme, yakınlaştırma ve kaydırma işlemleri ölçülmez.Bu nedenle, düzensiz bir kaydırma işlemi, INP yeşil kalırken sayfanın bozuk görünmesine neden olabilir.
• Etkileşim sayısının yüksek olduğu sayfalarda, INP her 50 etkileşimden birini göz ardı eder.Dolayısıyla nadir görülen, felaket niteliğindeki bir etkileşim, yüksek etkileşimli bir sayfada gizlenebilir ve düşük etkileşimli bir sayfada ortaya çıkabilir.
• Her etkileşim şu şekilde bölünür: giriş gecikmesi (işleyicileriniz çalışmadan önce), işlem süresi (işleyicileriniz çalışıyor) ve sunum gecikmesi (işlemcilerinizden sonra, çerçeve boyanmadan önce). Bu üçünün mühendislik sorunları olarak neredeyse hiçbir ortak noktası yok (web.dev).

Son nokta, yöntemin tamamını özetliyor. "INP" üzerinde hata ayıklama yapmıyorsunuz. Üç aşamadan birinde hata ayıklama yapıyorsunuz ve her birinin farklı bir çözümü var.

Şube 0: Koda dokunmadan önce numaranın gerçek olduğunu doğrulayın.

PageSpeed ​​Insights'ı açın ve laboratuvar puanına değil, alan bölümüne bakın. Laboratuvar araçları INP'yi ölçemez çünkü INP, gerçek bir kullanıcının bir şeye basmasını gerektirir. Eğer kaynakta alan verisi yoksa, performans sorunu değil, trafik sorununuz var demektir ve aşağıdakilerin hiçbiri henüz geçerli değildir. Ardından mobil ve masaüstü verilerini ayrı ayrı çekin - 2025 yılında küresel olarak %20 puanlık bir fark vardı. Eğer mobil kırmızı, masaüstü yeşil ise, dizüstü bilgisayarınızda test yapmayı bırakın.

Dal 1: Yavaş etkileşim yükleme sırasında mı yoksa sonrasında mı gerçekleşiyor?

Tarlayı aşağıdaki aletlerle donatın: web-vitals Atıf oluşturma. Dört satır size verileri sağlar:

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

Okumak attribution.loadState Öncelikle, olumsuz etkileşimlerin çoğunun bir yük durumu taşıması durumunda... yükleme or dom-etkileşimliKullanıcılar komut dosyalarınız hala değerlendirilirken tıklama işlemi yapıyor: Bu bir teslimat sorunudur ve işleyici tarafında değil, paket ve etiket yöneticisi tarafında düzeltilir. Kötü etkileşimler tamamen yüklenmiş sayfalara yayılmışsa, 2. Dal'a geçin.

Şube 2: Zamanın sahibi hangi alt birimdir?

Giriş inputDelay, processingDuration hem de presentationDelay Her örnek için. Çalışma kuralımız: bir alt parça, her örnek için etkileşimi hesaba kattığında etkileşimin sahibi olur. toplam INP'nin %50'sinden fazlasıEğer hiçbiri %50'yi temizleyemezse, öncelikle bunu bir giriş gecikmesi durumu olarak ele alın; yaygın ana iş parçacığı tıkanıklığı genellikle diğer iki durumu daha da kötüleştirir.

Dal 3: komut dosyasına isim verin

Bu özellik derlemesi, her INP örneğinin yanında Uzun Animasyon Karesi girişlerini de içerir. attribution.longestScript Etkileşimdeki en kötü komut dosyasının çağırıcısını, işlevini ve kaynak dosyasını size verir; totalScriptDuration 5 ms'nin üzerindeki her şeyi toplar. İşte burada belirsiz "React yavaş" ifadesi bir dosya yoluna dönüşüyor. Çağırıcı türünü kontrol edin: classic-script or module-script Yükleme süresi değerlendirmesine ilişkin noktalar, user-callback or event-listener Yükleme sonrasında çalışan bir şeye işaret eder — bir gözlemci, bir zamanlayıcı, bir analiz dinleyicisi (web.dev).

Şube 4: Bu sizin mi yoksa üçüncü bir şahsın mı?

Komut dosyası atıflarınızı kaynağa göre sıralayın. Etiket yöneticileri, onay platformları, oturum kayıt araçları ve sohbet widget'ları, her tıklamada sizin komut dosyanızdan önce çalışan genel dinleyiciler yükler. En kötü örneklerinizin dörtte birinden fazlasında üçüncü taraf bir kaynak görünüyorsa, çözüm teknik olmaktan önce ticari olmalıdır: etiketin kapsamını azaltın, etkileşimde yükleyin veya sunucu tarafına taşıyın. Sohbet widget'ının zaten harcadığı 40 ms'yi geri kazanmak için işleyicinizi yeniden düzenlemeyin.

Dal 5: Laboratuvarda yeniden oluşturun, ardından çerçeveyi düzeltin.

Seçiciyi şuradan alın: attribution.interactionTargetChrome Geliştirici Araçlarını, saha cihaz karışımınıza uygun CPU kısıtlamasıyla açın ve etkileşimi kaydedin. Üzerinde bir görev olup olmadığını kontrol edin. 50 ms, uzun görev eşiği (web.dev), ve onu verim vererek böl.

Gemi scheduler.yield() Yedekleme seçeneğiyle birlikte. Chrome ve Edge 129 sürümünden itibaren, Firefox ise 142 sürümünden itibaren bunu destekliyor, ancak Safari, masaüstü veya iOS'ta bunu yapmaz.ve MDN bunu Temel Sürüm yerine sınırlı kullanılabilirlik olarak işaretliyor (DND, kullanabilirmiyimiOS kullanım oranı yüksek olan Türk veya Körfez ülkeleri için, setTimeout Yedekleme seçeneği zorunlu.

6. Dal: Gerçekte satış yaptığınız pazarı ölçün

Küresel CrUX ortalamaları, size ödeme yapan piyasayı gizler. CrUX BigQuery veri seti ülke tablolarını yayınlar — chrome-ux-report.country_tr.YYYYMM Türkiye için, aynı model herhangi bir iki harfli ülke kodu için geçerlidir - cihaz biçim faktörü ve etkin bağlantı türü boyutları dikkate alınarak aylık olarak güncellenir (Geliştiriciler için ChromeCrUX'un herkese açık API'si ülke bilgisini sunmadığı için bu dilim yalnızca BigQuery'ye özeldir.

Satış yaptığınız her pazar için menşe ülkenizi ülke tablosuyla karşılaştırın. Türkiye, Almanya ve Körfez ülkelerine hizmet veren bir perakendeci, cihaz karışımı ve ağ koşulları farklı olduğu için tek bir kod tabanından genellikle üç farklı INP dağılımı bulur. Ofisinizin bulunduğu pazarı değil, gelirinizin olduğu pazarı düzeltin.

Dal 7: Bir şeyin hareket ettiğini kanıtla

Bu düzeltmeyi bir uygulama değil, bir deney olarak ele alın. TrendyolBir Türk pazaryeri olan, 963 ms'lik bir mobil INP'yi, bir React bileşeni içindeki IntersectionObserver geri çağırma işlevinden kaynaklanan 700-900 ms uzunluğundaki bir göreve bağladı ve durum güncellemesini şu şekilde erteledi: scheduler.yield()ve altı ay içinde 75. yüzdelik dilimdeki INP değerini yaklaşık 1,400 ms'den yaklaşık 650 ms'ye düşürdü. A/B testi şunu gösterdi: Her oturumda listelemelerden ürün detaylarına tıklama oranında %1'lik artış. (web.dev). kırmızı otobüs Tembel yükleme etkileşimlerini 870-900 ms'den 350-370 ms'ye düşürdü, metin girişi etkileşimini %72 oranında iyileştirdi ve raporladı. Toplam satışlarda %7 artış (web.dev).

Dürüst ölçeğe dikkat edin: %1, %40 değil. Bu da bizi düzeltilmesi gereken bir sayıya getiriyor.

%8.4 rakamı bir uyarıyı hak ediyor.

Bu alanda en çok alıntı yapılan rakam, mobil hızda 0.1 saniyelik bir iyileşmenin perakende dönüşümünü %8.4 ve seyahati %10.1 oranında artırdığıdır. Bu, Google'ın görevlendirdiği, 37 marka ve 30 milyondan fazla oturumu kapsayan gerçek bir araştırmadan (55 ve Deloitte) geliyor.web.devAncak sayfa yükleme süresi ve sunucu gecikmesi gibi yük metriklerini ölçtü. INP değilVeriler 2019 yılının sonundaki 30 günü kapsıyor; ve kontrol grubu bulunmadığı için bu bir gözlemsel korelasyon, nedensel bir etki değil. Bunu bir bütçe görüşmesi başlatmak için kullanın, etkileşim gecikmesi düzeltmesinin getirisini tahmin etmek için değil.

[DAHİLİ VERİLER GEREKLİ: Kamuoyuna açık vaka çalışmalarının yerine birinci elden kanıtlarla sunulacak veriler için, Switas'ın p75 INP öncesi/sonrası verileri ve müşteriyle yapılan görüşmelerden elde edilen dönüşüm farkı bilgileri.]

Bu karar ağacının bozulduğu nokta

• Düşük trafikli başlangıç ​​noktaları. Az veri içeren alanlarda 75. yüzdelik dilim gürültüdür. Şablon başına haftada yaklaşık 1,000 etkileşimin altında, laboratuvarda profil oluşturun ve CrUX'ta kazanımı doğrulayamayacağınızı kabul edin.
• Safari ve Firefox kullanıcıları görünmezdir. CrUX yalnızca Chrome'da çalışır. Gelirinizin önemli bir kısmı iOS Safari üzerinden geliyorsa, INP verileriniz tam olarak ölçmediğiniz bir popülasyonu tanımlar.
• Kaydırma takılmaları kapsam dışındadır. INP kaydırmayı dikkate almaz, bu nedenle bu ağaç, kullanımı berbat görünen ancak testlerde başarılı olan sonsuz kaydırma listesindeki sorunu asla bulamayacaktır.
• Tasarım hatalarını değil, gecikme sürelerini buluyor. Kafa karıştırıcı bir filtre panelinde 180 ms'lik bir etkileşim, bu ağacın göremediği bir kullanıcı deneyimi sorunudur.

SSS

INP ile First Input Delay aynı şey midir?
Hayır. FID yalnızca ilk etkileşimin işleyicilerinin çalıştırılmasından önceki gecikmeyi ölçtü. INP ise, işleyici yürütülmesi ve ardından gelen boyama işlemi de dahil olmak üzere, ziyaret boyunca temsili bir etkileşimin tüm gecikme süresini kapsar.

INP kırmızı renkteyken Lighthouse puanım neden normal görünüyor?
Lighthouse bir laboratuvar aracıdır ve INP'yi ölçemez: gerçekte hiçbir kullanıcı bir şeye basmaz. Toplam Engelleme Süresi gibi vekiller zayıf bir korelasyon gösterir. Bunun yerine PageSpeed ​​Insights'ın alan bölümünü okuyun.

CruUX'ta düzeltmenin görünmesi ne kadar sürer?
CrUX, 28 günlük kayan bir pencere üzerinden raporlama yapar ve BigQuery tabloları aylık olarak yayınlanır. Yaklaşık dört hafta sonra kısmi bir sinyal ve iki aylık yayından sonra da temiz bir okuma bekleyin.

Çerçeveye dokunmadan INP hatasını düzeltebilir miyim?
Genellikle evet. Trendyol'un çözümü, React 16.9'da bir geri çağırma fonksiyonu içinde bir `yield` kullanmaktı ve herhangi bir yükseltmeye gerek yoktu. Üçüncü taraf etiketlerin ertelenmesi de çerçeveden bağımsızdır.

Onay banner'ı INP'yi etkiler mi?
Bu durum iki şekilde gerçekleşebilir: afişin kendi betiği yükleme sırasında ana iş parçacığıyla rekabet eder ve onay kararı genellikle hemen ardından etiket yüklemesinde bir artışa neden olur. Onaydan sonraki ilk etkileşimi ayrı olarak ölçün.

Bir RUM sağlayıcısına ihtiyacım var mı, yoksa web-vitals kütüphanesi yeterli mi?
Bu ağacı çalıştırmak için ilişkilendirme yapısı ve bir işaretçi uç noktası yeterlidir. Bir satıcı daha iyi ilişkilendirme verileri değil, elde tutma, segmentasyon ve gösterge panoları satın alır.

INP'yi SEO için mi yoksa dönüşüm için mi optimize etmeliyim?
Dönüşüme odaklanın. Temel Web Vitalleri bir sıralama sinyalidir, ancak belgelenmiş iş örnekleri (Trendyol'da %1, redBus'ta %7) kendi başlarına çalışmayı haklı çıkaran etkileşim kalitesi etkileridir.

Bunu kendi ilan sayfanızda çalıştırın.

En yüksek trafiğe sahip şablonunuzu alın, ilişkilendirme yapısıyla donatın ve 0'dan 7'ye kadar olan dalları sırayla inceleyin. Eğer ağacın kendi saha verilerinize göre, ülke dilimi ve deney tasarımı da dahil olmak üzere çalışmasını tercih ederseniz, web performans ekibi Bu etkileşimi tam olarak gerçekleştiriyor.

kaynaklar

• Sonraki Boyama İşlemine (INP) Etkileşim — web.dev
• Sonraki Boyama İşlemi İçin Etkileşimi Optimize Edin — web.dev
• Saha çalışmalarında yavaş etkileşimleri bulun — web.dev
• Uzun süren görevleri optimize edin — web.dev
• Performans — Web Yıllığı 2025, HTTP Arşivi
• Trendyol, INP'yi %50 oranında nasıl azalttı? — web.dev
• redBus, INP'yi nasıl iyileştirdi ve satışlarını %7 artırdı — web.dev
• Milisaniyeler milyonlar yaratır — web.dev / 55 / Deloitte
• BigQuery'de CruUX — Geliştiriciler için Chrome
• Zamanlayıcı: yield() — MDN
• Zamanlayıcı API'si: verim — caniuse
• web-vitals JavaScript kütüphanesi — GoogleChrome/web-vitals