Etkileşim gecikmesi performans denetimlerinde genelde geç fark edilir. Ekip açılış ekranına bakar, ana içerik zamanında geldi mi diye kontrol eder ve asıl yükleme aşaması tamamlandığında işlerin yolunda olduğu sanılır. Oysa kullanıcı için performansın kalitesi filtre açılırken, sekmeler arasında gezinirken ya da bir mobil menü ilk kez tetiklenirken ortaya çıkar.

Core Web Vitals kümesinde INP (Interaction to Next Paint) tam olarak arayüzün bu canlı kalabilme refleksini ölçer. İlk boyama ne kadar hızlı olursa olsun, tıklamaların ardından yaşanan milisaniyelik takılmalar, hissedilen kaliteyi doğrudan aşağı çeker.

INP beklemeyi nasıl sayar?

INP, tek bir işlemden ziyade olay örgüsünün bütününe bakar. Gecikme zinciri kullanıcının ekrana dokunduğu an başlar. Tarayıcı olayı sıraya alır, JavaScript olay işleyicisi (event handler) çalışır, ardından stil ve yerleşim DOM ağacında güncellenir ve en nihayetinde son kare boyanır. Kullanıcıya yansıyan o ufak yavaşlık aslında bu zincirdeki hantallıkların toplamıdır.

Örneğin ilgili butona atanan kod yalnızca 80 milisaniyede tamamlanmış olabilir. Fakat ana iş parçacığı (main thread) halihazırda yoğunsa, boyama alanı genişse veya bir DOM güncellemesi kuyrukta bekliyorsa, arayüz komuta geç tepki verecektir. Bu yüzden problem tek satırlık JavaScript sokağına sıkıştırılamaz.

Tavsiye edilen standart 200 ms ve altıdır. Bu sınırın üzeri sınır bölgeye ilerlerken 500 ms üstündeki her etkileşim, mobil cihazlarda belirgin bir takılmaya yol açar. Masaüstünde fark edilmeyen ufak yığılmalar, orta segment bir telefonda bariz bir sabırsızlık senaryosu doğuracaktır.

Ana iş parçacığı darboğazı fonksiyonların toplamıdır

Gecikme saptandığında ilk akla gelen ağır bir JavaScript fonksiyonudur. Ancak büyük paketler indirme sorunu üretmenin yanında parse, compile ve execute sürelerini de uzatır. Bu sebeple code splitting ve dosya küçültme sadece açılış metriğini değil, etkileşim akıcılığını da destekler.

Bakım sırasında atlanan bir başka bariyer ise atıl kod birikimidir. Yönetim panelinden miras kalan modüller veya eski kampanya araçları ilk etkileşim anında faturayı kullanıcıya ödetir. Kullanılmayan kaynak temizliği bir klasör düzenleme pratiği değil, doğrudan bir INP çalışmasıdır.

Önemli ayrım: INP tek bir "yavaş buton" problemi değildir. Parçalı çalışan scriptler, ana iş parçacığını farklı anlarda kilitleyerek genel skoru düşürür.

Her gecikme hissi INP kaynaklı değildir

Bir filtre butonuna basıldığında sonuçların geç gelmesi doğrudan INP'yi bozmayabilir. Butonun dokunma durumu anında belli oluyor, yani tarayıcı kullanıcı etkileşimini vizüel olarak "tamamlandı" sayıp ağ isteği sonucunu beklemeye geçiyorsa bu bir ağ trafiği pürüzüdür. Fakat butona basıldığında arayüz hiç oynamıyor ve CSS ":active" durumu dahi ekrana yansımıyorsa sorun işlem tarafındadır.

Özellikle etiket yöneticileri, canlı destek penceresi tetikleri ve A/B testi araçları birlikte yüklendiğinde işlem gücü hızla tükenir. Kullanıcı sayfayla girdiği ilk anlamlı kontakta tüm bu analiz scriptlerinin uyandırma yüküyle karşılaşır. Masaüstünde 100 ms civarında atlatılan işlemlerin, orta segment bir mobil yongada 600 ms bandına yaklaşmasının sebebi budur.

İyileştirme adımları ve test kültürü

Ana iş parçacığını ipotek altına alan uzun görevleri (long tasks) temizlemekle işe başlanmalıdır. Bir site analiz aracı üzerinden cihaz simülasyonları kurgulayarak bloklayıcı sızıntıları yakalayabilirsiniz.

Müdahale için somut yol haritası:

  1. İlk görsel geri bildirimi (loader veya active class değişimini) hemen ekrana verin.
  2. Uzun süren JavaScript hesaplamalarını setTimeout veya requestIdleCallback ile kırpıp bölün.
  3. Etkileşim başladığı anda gürültüye sebep olan üçüncü taraf tetikleyicilerini (lazy execution) geciktirin.
  4. Güncellenecek DOM segmentinin boyutunu daraltıp maliyeti azaltın.
async function performHeavyTaskChunked(items, chunkSize = 40) {
  for (let index = 0; index < items.length; index += chunkSize) {
    processItems(items.slice(index, index + chunkSize));
    // Ana iş parçacığına nefes aldırır
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

Yukarıdaki parça, büyük liste süzme işlemlerini ana blokajlardan kurtarır. Tarayıcı yarattığınız o ufak asenkron boşluklarda yeni tıklama veya kaydırma komutlarını işleme fırsatı bulur.

Değişiklikleri uygulamaya alırken kontrollü hareket etmek önemlidir. Bildiğiniz tüm betikleri birden erteleyip aynı gün listeleme mantığını değiştirdiğinizde, hangi aksiyonun metrik üzerinde gerçek bir rahatlama yarattığını test edemezsiniz.

Etkileşimdeki anlık takılmaların arkasında yatan render maliyetlerine daha yakından bakmak için render engelleyen kaynaklar başlığını da inceleyebilirsiniz.

Yavaş his var ama her vaka aynı değil

Her bekleme hissi aynı sebepten doğmaz. FID döneminden kalan alışkanlıkla birçok ekip ilk giriş gecikmesine odaklanır. Oysa INP daha geniştir; yalnızca handler'ın ne zaman başladığını değil, arayüzün ne zaman görünür karşılık verdiğini hesaba katar. Kullanıcı da zaten bunu hisseder.

Bir başka karışıklık ağ gecikmesi ile ana iş parçacığı gecikmesini aynı sepete atmaktır. Diyelim ki kullanıcı filtreye bastı. Buton hemen aktif oldu, yükleniyor durumu göründü, veri biraz sonra geldi. Burada ağ beklemesi vardır; ama arayüz komutu zamanında aldıysa INP tarafı daha sağlıklı olabilir. Buna karşılık hiçbir görsel geri bildirim yoksa, ağ hızlı olsa bile sayfa hantal görünür.

Bu ayrımı net kurmak gerekir. Sorun ağ tarafında mı, ana iş parçacığı doygunluğunda mı, yoksa gereksiz büyük boyama alanında mı? Yanlış sınıflandırılan problem, yanlış optimizasyon üretir.

Gerçek projede bu ayrım özellikle filtreli listeleme ekranlarında görünür olur. Kullanıcı bir renk filtresi seçer. Eğer buton hemen aktifleşiyor ama sonuçlar birkaç yüz milisaniye sonra geliyorsa burada çoğu zaman veri ve işleme maliyeti vardır. Buna karşılık filtre butonunun kendisi geç tepki veriyor, aktif durumu bile zamanında görünmüyor ve kaydırma anlık takılıyorsa problem daha çok ana iş parçacığı tarafındadır. İki senaryo kullanıcıya aynı “yavaşlık” duygusunu verebilir; ama çözüm aynı olmaz.

Özellikle etiket yöneticisi, analitik, ısı haritası, canlı destek ve A/B testi katmanları birlikte kullanıldığında INP tarafındaki yük sessizce büyür. Çünkü ekip bu servisleri çoğu zaman ayrı ayrı değerlendirir. Oysa kullanıcı tek bir tıklama yapar ve bütün bu küçük işlerin toplam etkisini hisseder. INP çalışması burada teknik borcu görünür hale getirir: tek tek bakıldığında masum duran çağrılar, aynı etkileşim anında birleşince ağır bir kuyruk oluşturabilir.

Lab verisi ile gerçek kullanıcı verisinin farkı da bu metrikte daha sert hissedilir. Temiz test ortamında iyi görünen bir etkileşim, düşük güçlü telefonda veya arka planda başka sekmeler açıkken daha ağır davranabilir. Bu yüzden tek bir masaüstü ölçümüne bakıp “tamamdır” demek risklidir. INP tarafında asıl değer, farklı cihaz sınıflarında hâlâ kabul edilebilir kalan etkileşim davranışı kurabilmektir.

Önce nerede bekletildiğinizi bulun

En verimli başlangıç noktası, kullanıcının sabrını en çok zorlayan etkileşimi seçmektir. Filtre mi, sekme değişimi mi, arama önerisi mi, mobil menü mü? Önce bunu belirleyin. Sonra zinciri ayırın: gecikme olay kuyruğunda mı, handler içinde mi, yoksa boyama tarafında mı büyüyor?

PageSpeed Insights raporu bazı sinyaller verir; fakat INP tarafında yalnızca puana bakmak çoğu zaman yeterli olmaz. Daha yararlı yaklaşım, aynı sayfayı Lighthouse tabanlı bir site analizi aracı üzerinden mobil ve masaüstü sonuçlarıyla birlikte okuyup hangi görev kümelerinin ana iş parçacığını meşgul ettiğini ayırmaktır. Amaç araç övmek değil; gecikmeyi katmanlarına bölmektir.

Sorunun kökü bazen beklediğiniz yerde çıkmaz. Siz yavaşlığı tek bir filtre fonksiyonunda ararsınız; oysa önce izleme betiği çalışıyordur, sonra ağır paket çözülüyordur, sonra büyük liste yeniden boyanıyordur. INP teşhisi biraz da yanlış şüpheliyi eleme işidir.

İyi sonuç veren düzeltme sırası

Her şeyi aynı anda hafifletmeye çalışmak yerine görünür etki üreten birkaç hamleye odaklanmak daha iyi sonuç verir.

  1. İlk görsel geri bildirimi erkene alın.
  2. Uzun görevleri bölün.
  3. Etkileşim anında tetiklenen üçüncü taraf scriptleri azaltın.
  4. Güncellenen DOM alanını daraltın.
  5. Gereksiz paketleri ilk etkileşimin dışına taşıyın.

Özellikle büyük liste güncellemelerinde işi parçalara ayırmak ciddi fark yaratır. Kullanıcı önce sistemin uyandığını görür, ağır iş arka planda kontrollü ilerler.

async function renderInChunks(items, chunkSize = 40) {
  for (let index = 0; index < items.length; index += chunkSize) {
    renderItems(items.slice(index, index + chunkSize));
    await new Promise(requestAnimationFrame);
  }
}

Bu yöntem her senaryoya uymaz; ama canlı filtreleme, büyük tablo güncellemesi ve pahalı liste boyamaları gibi alanlarda arayüzü nefessiz bırakmamak için çok işe yarar. Bir başka etkili hamle de geri bildirimi geciktirmemektir. Kullanıcı tıkladığında aktif durumun ya da yükleniyor işaretinin hemen görünmesi, toplam bekleme aynı kalsa bile hissi iyileştirir.

Burada küçük ama faydalı bir çalışma biçimi var: değişiklikleri tek tek yayınlamak. Önce yalnızca üçüncü taraf tetiklerini sadeleştirirsiniz. Sonra büyük liste güncellemesini parçalarsınız. Ardından ağır scriptin ilk etkileşim dışına taşınmasına bakarsınız. Böyle ilerlediğinizde hangi hamlenin gerçekten işe yaradığını görebilirsiniz. INP çalışmalarında en sık kaybedilen şeylerden biri budur; ekip bir anda çok fazla şeyi değiştirir ve sonra hangi kararın ne kadar fark yarattığını artık ayıramaz.

Etkileşim bütçesi fikri de burada işe yarar. Örneğin belirli bir filtre eyleminde 200 ms üstünü riskli kabul ediyorsanız, o etkileşim altında çalışan her katmanı bu bütçeye göre tartabilirsiniz. Tek bir büyük görev değil, birkaç küçük görev toplamı da bütçeyi aşabilir. Bu bakış açısı ekip içi tartışmayı çok sadeleştirir: “Bu özellik güzel mi?” yerine “Bu özellik tıklama bütçesini ne kadar yiyor?” diye sormaya başlarsınız.

INP'nin ekip kültürüne katkısı bu noktada belirginleşir. Tasarımcı geç açılan panelin kullanıcıyı nasıl beklettiğini görür, geliştirici aynı davranışın hangi görevleri tetiklediğini çıkarır, ürün tarafı ise hangi etkileşimin gerçekten öncelikli olduğunu netleştirir. Metrik bu yüzden yalnızca performans raporu değil, ortak karar dili haline gelebilir. Doğru kullanıldığında ekibe “önce nereyi hafifletmeliyiz” sorusunun daha sakin cevabını verir.

Etkileşim canlılığı proje büyüdükçe yeniden bozulur

INP bir kez düzeltilip rafa kaldırılacak metrik değil. Proje büyüdükçe yeni scriptler, yeni bileşenler, yeni ölçüm araçları ve yeni üçüncü taraf servisler aynı baskıyı yeniden kurar. Bu yüzden ekip içinde küçük bir refleks yerleşmelidir: bu özellik tıklandığında ana iş parçacığında gerçekten neler olacak?

Bu soru tasarım kararını da, geliştirme kararını da olgunlaştırır. Yeni filtre sistemi eklenirken, modal akışı kurgulanırken ya da canlı arama tasarlanırken ilk tepkinin ne kadar hızlı geleceği baştan düşünülürse, sonradan yapılan kurtarma işleri azalır.

Bir sayfanın hızlı görünmesi önemlidir. Canlı hissettirmesi ise çoğu zaman daha akılda kalır. Kullanıcı dokunduğunda arayüzün gerçekten karşılık verdiğini görüyorsa, kalite algısı sessizce yükselir.

Bu yüzden INP çalışması yalnızca teknik bir temizlik listesi olarak görülmemeli. Aynı zamanda ürünün hangi etkileşimlerinin gerçekten değer taşıdığını da açığa çıkarır. Eğer kullanıcı her girişimde aynı paneli açıyor, aynı filtreyi kullanıyor ya da aynı sekmede vakit geçiriyorsa, o davranışların bütçesi diğerlerinden daha sıkı yönetilmelidir. Ekip bu önceliği kuramadığında her etkileşimi aynı ağırlıkta görür ve gerçek kullanıcı etkisi yüksek olan alanlara yeterince odaklanamaz.

Olgun ürünlerde fark genelde burada oluşur. Her şey bir miktar hızlı olmak yerine, en sık kullanılan akışlar belirgin biçimde akıcı hale gelir. INP tam da bu bakış açısını destekler. Kullanıcıya nerede gerçekten zaman kaybettirdiğinizi anlarsanız, geri kalan teknik kararlar daha sadeleşir. Hangi script ertelenecek, hangi liste güncellemesi parçalanacak, hangi üçüncü taraf tetik azaltılacak soruları bir anda daha net cevap bulur.

Kısacası bu metrik yalnızca geç tepkiyi saymaz; ürünün hangi hareketlerde gereğinden ağırlaştığını da öğretir. Böyle bakıldığında INP düzeltmesi tek bir optimizasyon değil, ekip içinde “önce neyi hafifletmeliyiz” sorusuna verilen daha akıllı bir yanıttır.

Bir başka faydası da şu: ekip zamanla hız konuşmasını tek bir puan ya da genel “yavaşlık” şikâyeti üzerinden değil, belirli etkileşim anları üzerinden yapmaya başlar. Bu değişim küçük görünür; ama doğru performans kültürü genelde bu noktada başlar.

Bu da zamanla daha az dağınık karar üretir.

Ve daha tutarlı, daha ölçülebilir, daha sakin bir performans pratiği kurar.

Etkileşim anındaki yükün script zamanlamasıyla nasıl birleştiğini görmek isterseniz, defer ve async farkı bu konuyu iyi tamamlar.