INP Sorunları Nasıl Bulunur ve Düzeltilir? Uzun Görevler Rehberi

Menü düğmesine basılıyor, yarım saniye hiçbir şey olmuyor, kullanıcı ikinci kez basıyor. Interaction to Next Paint (INP) tam olarak bu süreyi ölçer: tıklama, dokunma veya klavye etkileşiminden sonra ekranda bir sonraki karenin çizilmesine kadar geçen zaman. Mart 2024’te Core Web Vitals’ta FID’nin yerini aldı; 75. yüzdelikte 200 ms ve altı “iyi”, 500 ms üstü “zayıf” kabul edilir. Bu rehber INP’si kötü çıkan bir sayfada sorunlu etkileşimi bulmaktan düzeltmeyi doğrulamaya kadar izlediğimiz sırayı anlatıyor; metriklerin genel tanıtımı hızlandırma rehberinde.

INP’nin üç bileşeni

Bir etkileşimin süresi üç parçaya ayrılır ve her parçanın çözümü farklıdır. Teşhisin ilk işi, sorunun hangi parçada olduğunu bulmaktır. Parçayı bilmeden yapılan optimizasyon kör atıştır.

Bileşen	Neyi ölçer	Tipik nedeni
Girdi gecikmesi (input delay)	Etkileşimden olay işleyicisinin başlamasına kadar	O sırada çalışan başka uzun görev (betik yükleme, zamanlayıcı)
İşleme süresi (processing duration)	Olay işleyicilerinin çalışma süresi	Ağır işleyici kodu, senkron hesaplama, çoklu dinleyici
Sunum gecikmesi (presentation delay)	İşleyiciler bittikten sonra karenin çizilmesine kadar	Büyük DOM, stil ve düzen maliyeti, zorunlu senkron düzen

Ana iş parçacığında 50 ms’yi aşan her görev “uzun görev” sayılır. Uzun görev tek başına INP değildir; ancak kullanıcı tam o sırada etkileşime geçerse girdi gecikmesine, işleyicinin kendisi uzun sürerse işleme süresine dönüşür.

Sorunlu etkileşimi saha verisinden bulmak

Search Console’daki Core Web Vitals raporu ve PageSpeed Insights’taki CrUX verisi hangi URL gruplarında INP sorunu olduğunu gösterir, ama hangi öğeye yapılan etkileşimin yavaş olduğunu söylemez. Bunun için kendi ölçümünüz gerekir. Google’ın web-vitals kütüphanesinin attribution derlemesi her INP değeri için etkileşimin hedefini ve üç bileşenin sürelerini verir:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  const veri = {
    inp: Math.round(value),
    durum: rating,                          // good | needs-improvement | poor
    hedef: attribution.interactionTarget,    // ör. "button.menu-toggle"
    tur: attribution.interactionType,        // pointer | keyboard
    girdiGecikmesi: Math.round(attribution.inputDelay),
    isleme: Math.round(attribution.processingDuration),
    sunum: Math.round(attribution.presentationDelay),
    yukDurumu: attribution.loadState,        // etkileşim anında sayfa yükleme durumu
    sayfa: location.pathname
  };
  navigator.sendBeacon('/rum', JSON.stringify(veri));
});

Yukarıdaki alan adları kütüphanenin 4. sürümüyle gelen adlandırmaya göredir; 3. sürümde hedef alanının adı farklıydı ve sonraki sürümlerde de alanlar değişebilir. Kullandığınız sürümün dokümantasyonunu kontrol edin. Toplanan veriyi hedef seçici ve sayfa şablonuna göre gruplayın. Sahada tablo genellikle aynıdır: INP sorununun büyük kısmı birkaç bileşenden gelir — menü açma düğmesi, filtre, akordeon, çerez banner’ı düğmesi. loadState alanı sorunun sayfa yüklenirken mi yoksa yükleme bittikten sonra mı oluştuğunu ayırır. Yükleme sırasındaki gecikme genellikle betik yükünden, sonrasındaki işleyici kodundan kaynaklanır.

Gönderilen veri kişisel veri içermemeli; seçici ve URL yolu teşhis için yeterlidir. Analitik altyapısına aktarım ve olay tasarımında web analitik ve dönüşüm ölçümü çalışmasıyla aynı veri modelini kullanırsanız raporlama tek yerden yürür.

DevTools ile etkileşimi profillemek

Sahada bulunan etkileşimi laboratuvarda yeniden üretin. Geliştirici makineleri sahadaki orta seviye mobil cihazlardan çok daha hızlıdır; CPU yavaşlatma olmadan yapılan ölçüm sorunu gizler. Bu adımda yavaşlatma şart.

1. Chrome DevTools’ta Performance panelini açın, CPU yavaşlatmayı (ör. 4x veya 6x) seçin.
2. Kaydı başlatın, sahada sorunlu görünen etkileşimi gerçekleştirin, kaydı durdurun.
3. Interactions izinde etkileşimi bulun; üzerine geldiğinizde girdi gecikmesi, işleme süresi ve sunum gecikmesi ayrı ayrı gösterilir.
4. Main izinde aynı zaman aralığındaki görevleri inceleyin. Sağ üst köşesi kırmızı üçgenle işaretlenen görevler uzun görevlerdir. Alttaki Bottom-Up görünümü en çok zamanı harcayan fonksiyonları ve dosyaları listeler.
5. Mor renkli “Recalculate Style” ve “Layout” blokları sunum gecikmesine; sarı betik blokları işleme süresine işaret eder.

Performance panelinin canlı metrikler görünümü, sayfayla etkileşim kurdukça yerel INP değerini ve etkileşim listesini kayıt almadan da gösterir; hızlı tarama için kullanışlıdır. Sahada hangi betiğin geciktirdiğini görmek için Long Animation Frames API (long-animation-frame girdileri) betik kaynağını ve süresini raporlar. web-vitals 4. sürümden itibaren attribution çıktısı bu girdileri longAnimationFrameEntries alanında taşır. Suçlu dosya adıyla görünür.

Uzun görevleri bölmek

Bir olay işleyicisi hem ekran güncellemesini hem de ağır işi aynı görevde yapıyorsa, en etkili düzeltme işi ikiye ayırmaktır: önce kullanıcıya görsel geri bildirim verilir, ardından ana iş parçacığı bırakılır ve kalan iş sonraki görevlerde yapılır.

function anaIsParcacigininaBirak() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

filtreDugmesi.addEventListener('click', async () => {
  // 1. Anında görsel geri bildirim
  filtreDugmesi.setAttribute('aria-pressed', 'true');
  sonucAlani.classList.add('yukleniyor');

  // 2. Tarayıcının kareyi çizmesine izin ver
  await anaIsParcacigininaBirak();

  // 3. Ağır iş: filtreleme ve yeniden çizim
  const sonuc = urunleriFiltrele(tumUrunler, seciliFiltreler);
  listeyiGuncelle(sonuc);

  // 4. Acil olmayan iş: analitik olayı
  await anaIsParcacigininaBirak();
  analitikOlayiGonder('filtre_uygulandi');
});

scheduler.yield() Chromium tabanlı tarayıcılarda bulunur; diğer tarayıcılardaki destek durumunu MDN uyumluluk tablosundan kontrol edin. Desteklemeyen tarayıcılarda setTimeout yedeği aynı amaca hizmet eder ama devam eden işin önceliğini korumaz. Büyük bir diziyi işlerken her öğeden sonra bırakmak yerine belirli bir süre (ör. 50 ms) dolduğunda bırakın; gereksiz bağlam geçişi oluşmaz.

Olay işleyicileri ve render maliyeti

İşleme süresi ve sunum gecikmesinde sahada en sık gördüğümüz nedenler ve düzeltmeleri:

• Aynı olaya bağlı çok sayıda dinleyici: Tema, sayfa oluşturucu, Tag Manager tıklama tetikleyicileri ve eklentiler aynı tıklamaya ayrı ayrı dinleyici ekleyebilir. DevTools Elements panelindeki Event Listeners sekmesinden öğeye bağlı dinleyicileri görün; gereksiz olanları kaldırın.
• Zorunlu senkron düzen (layout thrashing): Bir döngüde önce stil değiştirip hemen ardından offsetHeight veya getBoundingClientRect() okumak tarayıcıyı her adımda düzen hesaplamaya zorlar. Önce tüm okumaları, sonra tüm yazmaları yapın.
• Sık tetiklenen olaylar: input veya resize olaylarında ağır iş yapmak yerine işi debounce edin veya requestAnimationFrame ile kare başına bir kez çalıştırın.
• Büyük DOM: Gizli mega menü içerikleri, iç içe sarmalayıcılar ve uzun listeler stil ve düzen maliyetini artırır. Ekran dışındaki büyük bölümler için CSS content-visibility: auto (birlikte contain-intrinsic-size ile) render işini görünür olana kadar erteler.
• Etkileşimde büyük HTML enjeksiyonu: Açılan menü veya modal içeriği her seferinde innerHTML ile yeniden oluşturuluyorsa, içeriği bir kez oluşturup görünürlüğünü değiştirmek daha ucuzdur.

Sayfa oluşturucuyla kurulmuş sitelerde son iki madde çoğu zaman birlikte gelir. Mega menü her sayfada DOM’a basılır, gizli durur, ama her stil hesaplamasında maliyet çıkarır.

Girdi gecikmesi baskınsa sorun genellikle etkileşim anında çalışan başka bir betiktir: sayfa yüklenirken çalışan analitik, sohbet veya reklam betikleri. Bu durumda çözüm toplam betik yükünü ve yükleme zamanlamasını yönetmektir; konu JavaScript bütçesi ve üçüncü taraf betikler rehberinde ayrıca ele alınıyor.

Düzeltmeyi doğrulamak

Doğrulama üç katmanda yapılır ve her katmanın gecikmesi farklıdır:

Katman	Yöntem	Geri bildirim süresi
Laboratuvar	Aynı etkileşimi aynı CPU yavaşlatmayla yeniden kaydetmek	Anında
Kendi RUM ölçümünüz	Hedef seçici bazında INP dağılımını önce/sonra karşılaştırmak	Birkaç gün (trafiğe bağlı)
CrUX / Search Console	URL grubu durumunun değişmesi	28 günlük kayan pencere

Laboratuvarda tek kayda güvenmeyin. Aynı etkileşimi birkaç kez tekrarlayın ve medyanı not edin. RUM verisinde düzeltmenin yayın tarihini işaretleyin ve 75. yüzdeliği sayfa grubu bazında izleyin. Yayın tarihi işaretlenmemişse iki hafta sonra iyileşmenin neden geldiğini kimse söyleyemez. Kalıcı izleme düzeni için CrUX ve RUM ile Core Web Vitals izleme rehberi ayrıntılı bir yapı öneriyor.

Kapatmadan önce kontrol listesi:

• Sorunlu etkileşimin hedefi ve baskın bileşeni (girdi, işleme, sunum) belirlendi.
• Etkileşim CPU yavaşlatmalı laboratuvar ortamında yeniden üretildi.
• Görsel geri bildirim ağır işten önce veriliyor, acil olmayan iş sonraya erteleniyor.
• Gereksiz dinleyiciler ve zorunlu senkron düzen kaldırıldı.
• Değişiklik sonrası RUM ve CrUX değerleri izleniyor.

INP teşhisini ve düzeltmelerini kurumsal sitenizin şablonlarında sistematik biçimde ele almak için web performansı ve Core Web Vitals hizmetimizi inceleyebilirsiniz. Metriğin resmi tanımı için web.dev INP dokümantasyonuna başvurabilirsiniz.

Sık sorulan sorular

Lighthouse INP ölçer mi?

Standart Lighthouse sayfa yükleme denetimi kullanıcı etkileşimi içermediği için INP ölçmez; ana iş parçacığı yükünü gösteren Total Blocking Time (TBT) yalnız yaklaşık bir göstergedir. INP için saha verisi (CrUX veya kendi RUM ölçümünüz) ya da DevTools Performance panelinde gerçek etkileşim kaydı gerekir. Lighthouse’un timespan modu kaydedilen etkileşimler üzerinden INP raporlayabilir.

Düzeltme sonrası Search Console’da iyileşme ne zaman görünür?

CrUX verisi son 28 günün kayan penceresiyle hesaplanır. Değişikliğin etkisi saha verisine kademeli yansır ve tam etki yaklaşık dört hafta sonra görülür. Daha hızlı geri bildirim için web-vitals kütüphanesiyle kendi RUM ölçümünüzü kurun.

setTimeout ile scheduler.yield arasındaki fark nedir?

İkisi de ana iş parçacığını bırakıp tarayıcının bekleyen girdi ve render işlerini yapmasına izin verir. setTimeout ile ertelenen devam işi görev kuyruğunun sonuna eklenir ve diğer betiklerin görevlerinin arkasında kalabilir. scheduler.yield ile bırakılan iş önceliğini koruyarak devam eder; desteklemeyen tarayıcılar için setTimeout yedeği ekleyin.

DOM boyutu INP’yi neden etkiler?

Bir etkileşimden sonra yapılan DOM değişikliği stil yeniden hesaplama ve düzen (layout) işlerini tetikler; bu işlerin maliyeti etkilenen öğe sayısıyla artar. Binlerce öğeden oluşan bir sayfada küçük bir sınıf değişikliği bile sunum gecikmesini uzatabilir. Başlıca kaynaklar gizli mega menü içerikleri, sayfa oluşturucuların iç içe sarmalayıcıları ve uzun listelerdir.