INP Nedir?

Etkileşimden bir sonraki boyamaya kadar geçen süreyi ölçer

Kısaltmanın açılımı Interaction to Next Paint. Türkçeye kabaca “bir kullanıcı etkileşiminden sonraki ilk görsel yanıtın gecikmesi” diye çevrilebilir.

Buradaki odak, tıklamanın kayıt altına alınması değil, kullanıcı bir şey yaptığında tarayıcının ne kadar sürede görünür karşılık verdiğidir. Yani yalnızca olayın tetiklenmesi ölçülmez; o olayın işlenmesi ve ekranda yeni durumun çizilmesi de hesaba katılır.

• İyi: Çoğu durumda 200 ms ve altı değerler akıcı kabul edilir.
• Geliştirilmeli: 200-500 ms aralığı kullanıcıyı bekletmeye başlayabilir.
• Zayıf: 500 ms üzeri değerler özellikle mobilde belirgin gecikme hissi üretir.

Metrik kabaca üç parçanın toplamı gibi düşünülebilir: olayın kuyruğa girmeden önce beklediği süre, JavaScript tarafında işlendiği süre ve sonunda yeni ekran durumunun boyanması için geçen süre. Sorun bu üç katmandan herhangi birinde çıkabilir.

Yüklenme hızı ile kullanım hızı ayrı şeylerdir

Yüklenme performansı ile kullanım performansı aynı şey değildir. Bir sayfa iyi bir critical CSS düzeni sayesinde ilk ekranı çabuk gösterebilir; fakat kullanıcı etkileşimi başladığında ana iş parçacığı doluysa butonlar halen geç tepki verir.

Bu yüzden INP, klasik “site açılıyor mu açılmıyor mu” bakışını genişletir. Kullanıcının zihnindeki hız hissi çoğu zaman ilk pikselle değil, ilk karşılıkla oluşur. Bir filtre paneli geç açılıyorsa ya da sepete ekleme butonu tıklamadan sonra gecikmeli değişiyorsa, sayfa teknik olarak yüklenmiş olsa bile deneyim yavaş kalır.

Sayfa hızının kullanıcı davranışına etkisi bu noktada görünür olur. Bekleme hissi yalnızca çıkış oranını değil, güveni de zedeler; kullanıcı komut verdiği halde ekranın yanıt vermediğini düşünür.

INP'nin değerli tarafı şudur: sorunu “site yavaş” gibi genel bir etiketten çıkarır ve “kullanıcı etkileşim anında bekliyor” noktasına indirir. Bu ayrım yapılmadan doğru optimizasyon sırası kurmak zordur.

Etkileşim gecikmesini artıran başlıca nedenler

En yaygın neden uzun süren JavaScript işleridir. Tarayıcı tek bir büyük görevle meşgulken tıklama gelse bile onu hemen işleyemez. Kullanıcı tam bu sırada “ekran dondu” hissi yaşar.

Özellikle JavaScript yükünü dağıtan stratejiler kurulmadığında sorun yalnızca açılışta değil, sonradan yapılan her etkileşimde yeniden ortaya çıkar. Ağır paketler, senkron çalışan script'ler, üçüncü taraf etiketler ve toplu DOM güncellemeleri ana iş parçacığını gereksiz yere dolu tutar.

• Uzun görevler: 50 ms üzerindeki bloklar üst üste gelirse tarayıcı kullanıcı girdisini araya sokmakta zorlanır.
• Ağır bileşen yenilemeleri: Bir tıklama sonrasında büyük listeyi baştan çizdirmek ya da yüzlerce öğeyi aynı anda güncellemek sunumu geciktirir.
• Üçüncü taraf kodlar: Sohbet aracı, reklam etiketi, izleme script'i veya A/B test parçaları kritik anda işlem süresini uzatabilir.
• Zincirleme stil ve layout hesapları: Her olayda ölçüm yapıp hemen stil değiştirmek tarayıcıyı tekrar tekrar hesap yapmaya iter.
• Görünmeyen ama bloklayan kaynaklar: Render blocking kaynakların kötü yönetimi, sayfa yüklendikten sonra da iş kuyruğunu şişirebilir.

Burada kritik nokta, kötü INP'nin her zaman “çok fazla istek” anlamına gelmemesidir. Bazen dosya sayısı düşük olsa bile tek bir etkileşimde çalışan iş mantığı aşırı pahalıdır. Özellikle filtreleme, arama önerisi, modal açılışı ve sekme geçişleri bu tür darboğazları kolayca ortaya çıkarır.

Ölçüm tarafında saha verisi ile laboratuvar testini ayırın

INP yorumlanırken en sık yapılan hata, laboratuvar raporundaki tek koşullu sonucu saha davranışıyla birebir eşitlemektir. Oysa gerçek kullanıcı verisi; cihaz sınıfı, ağ kalitesi, sayfada geçirilen süre ve yapılan etkileşim tipine göre ciddi biçimde değişir.

Bu nedenle Lighthouse raporunu bağlamlı okumak halen önemlidir ama yeterli değildir. Lighthouse size çoğunlukla kök nedenleri gösterir; gerçek INP ise kullanıcıların sayfada neler yaptığına bağlı olarak saha verisinde netleşir.

Lighthouse, Chrome DevTools Performance kaydı ve gerçek kullanıcı verisini yan yana okumak daha sağlıklı sonuç verir. Etkileşim gecikmesine zemin hazırlayan JavaScript yükünü, render baskısını ve sayfa içindeki belirli etkileşim akışlarını birbirinden ayırmak asıl hedeftir.

Pratikte işleyen yaklaşım genelde şöyledir:

1. Gerçek kullanıcı verisinde hangi sayfa grubunun zayıf kaldığını bulun.
2. Aynı grupta en çok kullanılan etkileşimleri listeleyin.
3. Performans kaydında bu etkileşim anında uzun görev var mı bakın.
4. İşleme süresi mi, sunum gecikmesi mi baskın, ayırın.

Aynı metriğe tek araçtan bakmaya çalışmak çoğu zaman resmi daraltır. INP tarafında sorun yaşayan ekiplerin önemli bir bölümü, ölçüm katmanlarını ayırdıktan sonra asıl darboğazın tahmin ettiklerinden farklı olduğunu fark eder.

Düzeltmede başlangıç noktası

INP iyileştirmesi küçük ama etkili kesintilerle ilerler. Her şeyi aynı anda azaltmaya çalışmak yerine, etkileşim anında gerçekten çalışan işi küçültmek daha doğru sonuç verir.

• Etkileşimi parçalara ayırın: Tıklama sonrası çalışan tek bir büyük işi daha küçük görevler halinde bölmek tarayıcıya nefes alanı açar.
• Önce görünür yanıtı verin: Panel açılacaksa iskelet durumu veya yükleniyor göstergesi gecikmeyi maskelemek için değil, kullanıcıya komutun alındığını göstermek için kullanılmalıdır.
• Üçüncü tarafları sorgulayın: Her etiket gerçekten gerekli mi, her script etkileşim anında mı çalışmalı, yeniden düşünün.
• Bileşen kapsamını daraltın: Bir filtre değişince tüm sayfayı değil, sadece ilgili parçayı güncelleyin.
• Düşük donanımı hedefleyin: Orta seviye Android cihazlarda akıcı olmayan bir etkileşim, masaüstünde temiz görünse bile üretimde sorun yaratır.

Birçok projede ilk büyük kazanç, ağır iş mantığını kullanıcı etkileşiminden sonraki kritik anın dışına taşıyarak gelir. Veriyi hazırlamak, sıralamak ya da analiz etmek gerekiyorsa bunların hepsini aynı tıklama içinde bitirmeye çalışmak çoğu zaman gereksiz maliyet üretir.

Tarayıcıya yalnızca daha az kod göndermek her zaman yeterli olmaz; bazen aynı kodun ne zaman çalıştığını değiştirmek daha büyük fark yaratır. INP bu yüzden sadece boyut optimizasyonu değil, iş akışı optimizasyonu metriğidir.

Önce izlenecek etkileşimleri seçin

Her tıklama aynı önemde değildir. Kullanıcının hedefe ulaşmak için en sık başvurduğu hareketler zayıfsa, geri kalan iyileştirmeler metrikte küçük toparlanma yaratsa bile deneyim tatmin edici görünmez.

Bu yüzden INP çalışmasında önce iş değeri yüksek etkileşimleri ayırmak gerekir. E-ticaret tarafında ürün filtresi, varyant seçimi, sepete ekleme ve arama önerisi; içerik sitelerinde mobil menü, içindekiler paneli ve yapışkan gezinme; yönetim panellerinde tablo sıralama, sekme değişimi ve modal açılışı daha öncelikli olur.

• En sık kullanılan akışlar: Trafiğin büyük bölümü aynı 3-4 etkileşim üzerinden akıyorsa, ölçümü oralarda derinleştirin.
• Gelire ya da göreve yakın anlar: Satın alma, form gönderme, aramayı tamamlama gibi adımlar gecikiyorsa kullanıcı sabrı çok daha hızlı tükenir.
• Mobilde tekrar eden temaslar: Açılır filtreler ve sekmeler, düşük işlem gücünde sorunu en erken belli eden bölgelerden biridir.
• Yoğun veri güncelleyen alanlar: Grafik, tablo ve canlı arama gibi bölümlerde görünür yanıt ile arka plan hesabını ayırmak gerekir.

INP kötü diye bütün olay dinleyicilerini tek tek kovalamak çoğu ekipte zaman kaybına dönüşür. Asıl verimli yaklaşım, kullanıcı yolculuğundaki yüksek etkili birkaç temas noktasını seçip oralarda gecikmeyi katman katman çözmektir.

Ayrıca sayfa türleri arasında aynı eşiği aynı rahatlıkla koruyamayabilirsiniz. Blog yazısı ile filtre ağırlıklı kategori sayfasını aynı etkileşim karmaşıklığında görmek yanıltıcıdır. Ölçüm notlarını sayfa şablonuna göre ayırmak, hangi gecikmenin yapısal hangisinin kod kaynaklı olduğunu daha net gösterir.

Etkileşim gecikmesini düşürürken yapılan yaygın hatalar

Etkileşim gecikmesini fark eden ekipler bazen problemi görünür olmaktan çıkarınca çözdüğünü sanır. Oysa kullanıcıya yükleniyor göstergesi vermek ile gerçek gecikmeyi azaltmak aynı şey değildir.

• Her yere loader koymak: Ekran tepki veriyor gibi görünür ama arka plandaki ağır iş aynı sürüyorsa metrik ve his birlikte düzelmez.
• Aşırı debounce kullanmak: Bazı aramalarda faydalıdır ama her etkileşimi geciktirerek sorun çözmek yerine yeni bekleme hissi oluşturabilir.
• Toplu code splitting yapmak: Paket küçülürken bu kez etkileşim anında yeni dosya beklemek zorunda kalabilirsiniz.
• Animasyonla gecikmeyi örtmek: Görsel geçişler akıcılık hissi yaratabilir; fakat ana iş parçacığı doluysa animasyon bile takılarak sorunu büyütür.

En sık görülen yanılgı, yalnızca transfer boyutunu azaltmanın yeterli olacağını düşünmektir. Oysa bazı arayüzlerde asıl maliyet indirme değil, olaydan sonra çalışan iş mantığıdır. Kod küçülür ama yanlış anda çalışmaya devam ederse kullanıcı halen bekler.

Bir başka hata da bütün iyileştirmeyi tek seferde canlıya taşımaktır. INP tarafında küçük davranış değişiklikleri bile bileşen sırasını, state akışını ve izleme kodlarını etkileyebilir. Bu yüzden iyileştirmeyi parça parça açmak, hangi adımın gerçekten işe yaradığını anlamayı kolaylaştırır.

200 milisaniyenin altı her projede aynı yoldan gelmez

Etkileşim tipi farklıysa çözüm de farklı olur. Bir içerik sitesindeki menü açılışı ile ürün filtreleme paneli aynı zorlukta değildir. Dashboard, editör ve e-ticaret gibi yoğun arayüzlerde kullanıcı komutundan sonra yapılan iş miktarı doğal olarak daha yüksektir.

Burada önemli olan, her özelliği kör biçimde sadeleştirmek değil; hangi işlem gerçekten ilk karede görünür yanıt üretmek zorunda, bunu ayırmaktır. Kullanıcı önce panelin açıldığını görmeli, sonra pahalı hesaplar arkadan ilerlemelidir. Tam tersini yaparsanız teknik olarak doğru çalışan arayüz bile hantallaşır.

INP'yi iyileştirme süreci biraz disiplin ister. Her yeni bileşen, her yeni script ve her yeni tasarım kararı aslında bir etkileşim bütçesi tüketir. Bu bütçe görünmez kaldığında metrik bozulur; görünür hale geldiğinde ekip hangi bedelin hangi özellikle ödendiğini daha net görür.