Blog details
Bir sayfa hızlı açılabilir, ama yine de yavaş hissedilebilir. Kullanıcı düğmeye basar, kısa bir donma olur, sonra arayüz tepki verir. 2026’da INP, tam da bu hissi ölçen temel metriktir.
Google, 2024’te FID yerine INP’yi aldı ve Core Web Vitals içinde bunu kullanmayı sürdürüyor. Bu yüzden LCP iyi olsa bile etkileşimler ağırsa sayfa deneyimi zayıf kalır.
Zor kısım şurada başlar: INP sorunları çoğu zaman tek bir bug’dan çıkmaz. Sağlam bir teşhis için Search Console, PageSpeed Insights, DevTools, Lighthouse ve RUM verisini birlikte okumak gerekir.
INP neden yükselir, 2026’da neden hâlâ bu kadar önemli?
INP, kullanıcının tıklama, dokunma veya klavye etkileşimine arayüzün ne kadar geç cevap verdiğini ölçer. Ölçüm, yalnızca olay dinleyicisinin çalışma süresine bakmaz. JavaScript’in bitmesini, stil ve layout hesaplarını, ardından ekrana gelen ilk görsel güncellemeyi de kapsar.
Bugün için genel eşikler nettir. 200 ms ve altı iyi, 200 ile 500 ms arası geliştirilmesi gereken alan, 500 ms üstü zayıf kabul edilir. INP’nin farkı şudur: Sayfa yaşam döngüsü boyunca görülen etkileşimlerin içinden en kötüye yakın deneyimi öne çıkarır. Yani tek bir ağır tıklama bile genel hissi bozabilir.
Bu yüzden INP, “sayfa açıldı mı” sorusunu değil, “sayfa bana cevap verdi mi” sorusunu yanıtlar. Core Web Vitals üçlüsünde LCP görünür başlangıcı, CLS görsel stabiliteyi, INP ise tepki hızını anlatır. 2026’da da bu denge değişmiş değil.
Bir ayrımı netleştirmek gerekir. Web tarafındaki INP, oyun forumlarında geçen input lag ile aynı şey değildir. Oyunlardaki input lag tartışmaları çoğunlukla FPS ve ağ gecikmesine odaklanır. Genel input delay videoları da cihaz ve sürücü ayarlarını anlatır. Tarayıcıdaki INP ise daha çok ana iş parçacığı yükü, JavaScript maliyeti ve render gecikmesiyle ilgilidir.
INP sorunlarını tespit etmek için en doğru akış
Teşhiste en sık yapılan hata, tek bir araca bakıp karar vermektir. Oysa INP için saha verisi ve laboratuvar verisi birlikte okunmalıdır.
Önce Search Console’daki Core Web Vitals raporuna bakın. Burada sorunlu URL’ler tek tek değil, benzer şablon grupları halinde görünür. Mobil ve masaüstü ayrımını mutlaka kontrol edin. Çünkü INP sorunları çoğunlukla düşük güçlü mobil cihazlarda sertleşir. Ayrıca bu veri 28 günlük saha verisine dayanır. Bugün düzeltip yarın raporda temiz sonuç görmeyi beklemeyin.
Search Console iyi bir alarmdır. Hata ayıklama aracı değildir.
Sonra aynı şablonu PageSpeed Insights’ta açın. PSI iki farklı katman sunar: Chrome kullanıcı verisine dayalı saha verisi ve Lighthouse lab testi. Saha verisi sorunun gerçek kullanıcılarda yaşanıp yaşanmadığını söyler. Lab testi ise muhtemel darboğazları gösterir.
Araçları birlikte kullanırken şu tablo pratik olur:
| Araç | En iyi kullanım alanı | Güçlü yanı | Sınırı |
|---|---|---|---|
| Search Console | Hangi şablonların sorunlu olduğunu bulmak | Site çapında öncelik verir | Satır düzeyinde neden söylemez |
| PageSpeed Insights | Saha ve lab verisini yan yana görmek | Hızlı karşılaştırma sağlar | Tek test her sorunu yakalamaz |
| Chrome DevTools | Sorunlu etkileşimi profil almak | Kök nedeni gösterir | Gerçek kullanıcı dağılımını vermez |
| Lighthouse | JS yükü ve ana iş parçacığı maliyetini taramak | Tekrarlanabilir test üretir | Her zaman gerçek INP’yi temsil etmez |
| RUM araçları | Gerçek kullanıcı etkileşimlerini izlemek | Cihaz, sayfa ve aksiyon bazında görünürlük sağlar | Kurulum ve etiketleme ister |
Bu aşamada RUM tarafı devreye girmelidir. web-vitals kütüphanesiyle INP’yi gerçek oturumlarda toplayabilir, veriyi GA4, BigQuery, Sentry, Datadog veya benzeri sistemlere taşıyabilirsiniz. Asıl değer, metriği sadece sayfa bazında değil, etkileşim bazında topladığınızda ortaya çıkar. “Sepete ekle”, “filtre uygula”, “menü aç” gibi aksiyonları ayırın. Yüksek INP’nin hangi hareket sırasında oluştuğunu görmeden doğru düzeltme zorlaşır.
Chrome DevTools ve Lighthouse ile kök nedeni bulun
Teşhis burada netleşir. DevTools Performance panelinde kayıt başlatın, sorunlu etkileşimi yapın, sonra ana iş parçacığını inceleyin. Aradığınız şey genelde uzayan bir görevdir. 50 ms üstüne taşan işler, etkileşimi bekletmeye başlar.
Zaman çizelgesinde şu izlere bakın: uzun JavaScript çalışması, ağır style recalculation, layout patlaması, pahalı paint işlemleri ve interaction’dan hemen sonra çalışan üçüncü taraf betikler. Tıklamanın ardından açılan akordeon, modal ya da filtre paneli bazen sorunun kendisi değildir. Asıl sorun, aynı anda çalışan analytics kodu, DOM’a basılan yüzlerce düğüm veya senkron JSON işleme olabilir.
Lighthouse burada ikinci katmandır. Gerçek kullanıcıdaki INP’yi bire bir üretmeyebilir, ama kötü alışkanlıkları çabuk gösterir. Kullanılmayan JavaScript, ağır üçüncü taraf script’leri, yüksek main-thread time ve büyük render-blocking kaynaklar genelde ilk ipuçlarını verir. Bu yüzden Lighthouse’u sonuç aracı gibi değil, şüpheli alanları sıralayan bir tarama aracı gibi görmek daha doğrudur.
Bir ayrıntı daha önemli: yüksek INP her zaman ilk yükleme anında çıkmaz. Sayfa açıldıktan 20 saniye sonra çalışan canlı arama, filtreleme veya sonsuz kaydırma da sorumlu olabilir. Bu yüzden sadece sayfa açılışını profile almak yetmez. Kullanıcının asıl etkileşim akışını kaydetmek gerekir.
INP’yi düşüren teknik müdahaleler
Teşhis tamamlandıysa sıra müdahalede. Hedef basittir: etkileşim anındaki işi azaltmak ve görsel yanıtı öne çekmek.
Ana iş parçacığını boşaltın
En yaygın sebep, tıklama anında fazla iş yapmaktır. Bir butona basıldığında aynı görev içinde doğrulama, analytics, DOM güncellemesi ve veri işleme çalışıyorsa gecikme artar. Görsel güncellemeyi önce yapın, ağır işi sonra taşıyın. Örneğin paneli açma işini requestAnimationFrame() ile öne alıp, raporlama veya pahalı hesapları sonraya bırakmak çoğu arayüzde fark yaratır.
Uzun döngüleri bölmek de işe yarar. 500 öğelik filtre sonucunu tek seferde basmak yerine parçalayın. Uygun senaryolarda Web Worker kullanın. Arama, sıralama, büyük JSON parse işlemleri ve metin işleme işleri ana iş parçacığından çıkınca INP genelde düşer.
DOM ve layout maliyetini azaltın
Bazı sayfalarda JavaScript kısa sürer, ama asıl zaman layout hesaplarında gider. Bunun tipik nedeni, DOM yazımı ile okumasını art arda karıştırmaktır. Önce ölçün, sonra yazın. getBoundingClientRect() gibi ölçümlerle DOM değişikliklerini aynı akışta sık sık karıştırırsanız tarayıcı zorunlu layout çalıştırır.
Büyük liste ve tablo bileşenleri de risklidir. Sanallaştırma, görünmeyen öğeleri üretmemek ve gereksiz alt ağaçları render etmemek etkileşim süresini kısaltır. Özellikle filtre, sekme ve açılır menü gibi bileşenlerde ilk tepkiyi küçük tutmak gerekir.
JavaScript yükünü ve üçüncü tarafları azaltın
Ağır paketler yalnızca LCP’yi bozmaz, INP’yi de vurur. Çünkü daha fazla kod, daha fazla parse ve daha fazla çalışma süresi demektir. Gerekmeyen modülleri çıkarın, etkileşim sonrası lazım olacak kodu import() ile geç yükleyin. Bu yaklaşım, büyük SPA’larda çoğu zaman hızlı sonuç verir.
Üçüncü taraf script’ler ayrı bir başlık hak eder. Isı haritası, sohbet kutusu, A/B test aracı ve reklam etiketleri tıklama anına yapışıyorsa sorun büyür. Gereksiz olanları kaldırın. Gerekli olanları geciktirin veya kullanıcı etkileşiminden bağımsız bir zamana taşıyın. Daha kapsamlı bir plan gerekiyorsa, Core Web Vitals odaklı hız optimizasyonu çalışmaları bu alanları birlikte ele alır.
Kalıcı iyileşme için ölçümü yayına bağlayın
Bir kez düzeltip bırakmak yetmez. INP sorunları çoğu ekipte yeni sürümle geri gelir. Bu yüzden ölçümü yayın sürecine bağlamak gerekir.
Pratik düzen şu şekilde işler:
- RUM verisinde sayfa şablonu, cihaz türü ve ana etkileşim adı tutulur.
- Yeni sürümden sonra bu segmentlerde p75 değişimi izlenir.
- Search Console’da doğrulama başlatılır, ama karar yalnızca oradaki gecikmeli veriye bırakılmaz.
- Sorunlu şablonlar için düzenli DevTools profili alınır.
Bu rutin, teknik SEO ve ürün geliştirme ekiplerini aynı tabloya toplar. Çünkü kötü etkileşim, sadece frontend sorunu değildir. Bazen etiket yönetimi, bazen CMS çıktısı, bazen de arayüz kararı işin içindedir. Bu yüzden performans takibini teknik SEO uygulama çözümleri ile birlikte düşünmek daha sağlıklıdır.
Sonuç
INP sorunları en hızlı, doğru sırayla ele alındığında çözülür. Önce Search Console ile sorunlu şablonu bulun, sonra PageSpeed Insights ve RUM ile gerçek etkisini doğrulayın, son olarak DevTools’ta etkileşim profilini açıp ağır görevi parçalayın.
Hızlı aksiyon planı basit olabilir:
- En kötü mobil şablonu seçin.
- O şablodaki tek bir sorunlu etkileşimi adlandırın.
- Görsel yanıtı öne çekip uzun görevi bölün, ardından yeniden ölçün.
Kullanıcı düğmeye bastığında sayfa hemen karşılık veriyorsa, INP düzelmeye başlar. Asıl farkı da kullanıcı hisseder.
This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.