INP pratikte: Yavaş etkileşimleri bulmak ve düzeltmek

Interaction to Next Paint (INP), Mart 2024’te First Input Delay’in (FID) yerini alarak Core Web Vitals metriklerinden biri oldu ve FID’i rahatça geçen bir site INP’de yine de takılabiliyor. FID yalnızca sayfanın ilk etkileşimi işlemeye başlamadan önceki bekleme süresini ölçüyordu; INP ise ziyaret boyunca tıklamalara, dokunmalara ve tuş basışlarına verilen yanıtın tamamını ölçüyor. İyi haber şu: Yavaş etkileşimler iz bırakır. Bu yazıda onları saha verisinde nasıl bulduğumuzu ve nasıl düzelttiğimizi anlatıyoruz.

INP neyi ölçer?

INP, ziyaret boyunca gerçekleşen her tıklamayı, dokunmayı ve tuş basışını izler (kaydırma ve fareyle üzerine gelme sayılmaz) ve bunların en yavaşlarından birini raporlar. Her etkileşimin üç aşaması vardır:

• Girdi gecikmesi (input delay): Olay işleyicilerinizin başlayabilmesi için geçen bekleme süresi. Genellikle ana iş parçacığı (main thread) başka bir işle meşgul olduğu için oluşur.
• İşleme süresi (processing duration): Olay işleyicilerinizin çalışması için geçen süre.
• Sunum gecikmesi (presentation delay): İşleyiciler bittikten sonra bir sonraki karenin ekrana gelmesine kadar geçen süre. Stil hesaplama, yerleşim (layout) ve boyama (paint) bu aşamadadır.

Bir etkileşimin yaşam döngüsü

1. GirdiTıklama, dokunma ya da tuş basışı
2. Girdi gecikmesiAna iş parçacığı önce elindeki işi bitirir
3. İşlemeOlay işleyicileri çalışır
4. SunumStil, yerleşim ve boyama
5. Sonraki boyamaZiyaretçi bir yanıt görür

FID’i geçmenin neden bu kadar az şey kanıtladığı buradan anlaşılıyor. Bir sayfa ilk tıklamayı hızla işlemeye başlayıp yine de bir şey göstermek için yarım saniye harcayabilirdi; çünkü işleyici fazla iş yapıyordu ya da tarayıcının yeniden çizmesi gereken devasa bir sayfa vardı. FID bunu hiç görmedi. INP görüyor ve yalnızca ilkini değil, her etkileşimi izliyor.

Google INP’yi gerçek ziyaretlerin 75. yüzdelik diliminde değerlendirir: 200 ms ve altı iyi, 500 ms’nin üzeri zayıf kabul edilir.

Core Web Vitals eşikleri

LCP Largest Contentful Paint · yüklenme

İyi≤ 2,5 sİyileştirilmeli2,5–4 sZayıf> 4 s

INP Interaction to Next Paint · yanıt hızı

İyi≤ 200 msİyileştirilmeli200–500 msZayıf> 500 ms

CLS Cumulative Layout Shift · görsel kararlılık

İyi≤ 0,1İyileştirilmeli0,1–0,25Zayıf> 0,25

Yavaş etkileşimleri bulmak

Önce gerçek ziyaretçilerin bir sorun yaşayıp yaşamadığını gösteren saha verisiyle başlayın, ardından sorunu etkileşime ve aşamaya kadar daraltın.

Search Console’daki Core Web Vitals raporu. Benzer URL’leri gruplar; böylece mobilde ve masaüstünde hangi şablonların INP’yi geçemediğini görürsünüz. Denetimlerimizde filtreli listeleme sayfaları ve yoğun etiket yükü taşıyan sayfalar en sık karşımıza çıkan sorunlu şablonlar arasında.

PageSpeed Insights’taki CrUX verisi. Bir URL’nin ya da tüm origin’in son 28 günlük saha INP değeri. Sorunu doğrular ama hangi etkileşimin buna yol açtığını söyleyemez.

web-vitals kütüphanesinin attribution sürümü. Sayfalarınıza ekleyip sonuçları analitik aracınıza gönderdiğinizde hangi öğenin söz konusu olduğunu ve her aşamanın ne kadar sürdüğünü öğrenirsiniz:

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

onINP(({ value, attribution }) => {
  sendToAnalytics({
    inp: value,
    element: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processing: attribution.processingDuration,
    presentation: attribution.presentationDelay,
  });
});

Sonuçları şablona ve öğeye göre gruplayın; genellikle bir örüntü kısa sürede ortaya çıkar.

DevTools Performance paneli. Etkileşimi CPU kısıtlaması açıkken tekrarlayın: 4x ya da 6x yavaşlatma, dizüstü bilgisayarınızdan çok orta segment bir telefonu andırır. Canlı metrikler görünümü siz etkileşime girdikçe INP’yi günceller; kaydedilmiş bir trace ise yavaş bir etkileşimin arkasındaki uzun görevleri gösterir.

Long Animation Frames API. Chromium tabanlı tarayıcılarda kullanılabilen bu API, 50 ms’den uzun süren kareleri raporlar ve süreyi belirli script’lere ve fonksiyonlara bağlar. Attribution sürümü bu kayıtları da içerir; sorunun bir üçüncü taraf etiketten kaynaklandığını kanıtlamanın çoğu zaman en hızlı yolu budur.

Sık görülen nedenler

Yavaş etkileşimlerin çoğu, ziyaretçi bir şey yaptığında ana iş parçacığının meşgul olmasına ya da yanıt olarak ona fazla iş yüklenmesine dayanır.

• Uzun görevler. 50 ms’yi aşan her görev ana iş parçacığını kilitler. Ziyaretçi tıkladığında böyle bir görev çalışıyorsa tıklama bekler; bu bekleme girdi gecikmesidir.
• Ağır olay işleyicileri. Uzun bir listeyi filtreleyen, sepeti yeniden hesaplayan ya da tüm formu tek seferde doğrulayan bir tıklama.
• Üçüncü taraf script’ler ve etiket yöneticileri. Analitik, canlı destek, test ve çerez onayı araçları çoğu zaman aynı tıklamalara kendi dinleyicilerini ekler ve yaptıkları iş sizin etkileşiminizin süresine eklenir.
• Büyük yeniden render’lar ve hydration. Küçük bir değişiklik için büyük bir bileşen ağacını yeniden render eden ya da ziyaretçi sayfayı kullanmaya çalışırken tüm sayfayı hydrate eden framework’ler.
• Layout thrashing. Stilleri değiştirip ardından offsetHeight gibi yerleşim değerlerini bir döngü içinde okuyan ve tarayıcıyı yerleşimi tekrar tekrar hesaplamaya zorlayan kod.

Yavaş bir tıklamanın süresi nereye gidiyor?

Girdi gecikmesi80 ms

İşleme süresi300 ms

Sunum gecikmesi140 ms

Etkileşimin tamamı520 ms

İşe yarayan çözümler

Uzun görevleri bölün ve ana iş parçacığını serbest bırakın. İşi küçük parçalara ayırın ve tarayıcının aralarda girdilere yanıt vermesine izin verin. scheduler.yield() bunu destekleyen tarayıcılarda (şu an Chromium tabanlı olanlarda) yapar; diğerlerinde setTimeout ile kurulan bir yedek çözüm devreye girer:

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

async function onFilterClick(button) {
  button.classList.add('is-loading'); // önce geri bildirim
  await yieldToMain(); // tarayıcı ekranı çizsin
  applyFilters(); // ağır iş sonra
}

Önce görsel geri bildirim verin, işi sonra yapın. Ziyaretçinin bir şeyin olduğunu görmesi gerekir: basılı görünen bir düğme, bir yükleniyor simgesi, açılan bir menü. Kaydetme, analitik çağrıları ve yeniden hesaplamalar o kare ekrana çizildikten sonra gelebilir.

Girdi işleyicilerine debounce uygulayın. Yazdıkça arama yapan kutular ve canlı filtreler her tuş basışında yeniden çalışmamalı. Ziyaretçinin duraksamasını bekleyin.

DOM boyutunu küçültün. Daha az öğe, her güncellemede daha az stil ve yerleşim işi demektir; bu da sunum gecikmesini kısaltır. Uzun listeleri sayfalara bölün ya da sanallaştırın, ihtiyacınız olmayan gizli işaretlemeleri kaldırın.

Kritik olmayan üçüncü tarafları erteleyin. Canlı destek bileşenlerini ziyaretçi istediğinde yükleyin, etiket yöneticinizi düzenli olarak gözden geçirin ve kimsenin kullanmadığı etiketleri kaldırın.

Ağır işleri web worker’lara taşıyın. Büyük veri setlerini ayrıştırmak, sıralamak ve filtrelemek gibi işler tamamen ana iş parçacığının dışında çalışabilir; böylece ana iş parçacığı yanıt vermeye hazır kalır.

Düzeltmeyi kanıtlamak

Saha verisi kayan bir 28 günlük pencereyi kapsar; bu yüzden bir düzeltmeyi CrUX’ta ya da Search Console’da değerlendirmeden önce yaklaşık dört hafta bekleyin. Kendi web-vitals verileriniz değişimi daha erken gösterir ve düzelttiğiniz öğenin en kötüler listesinden çıkıp çıkmadığını söyler.

INP’yi teknik SEO çalışmalarımızın bir parçası olarak inceliyoruz; sorunun kaynağı ön yüzün kendisiyse web tasarım ve geliştirme ekibimiz yavaş bileşenleri yeniden inşa edebilir. Yanıt hızının bu yılki diğer işlerle nasıl bir araya geldiğini görmek için 2025’te nelere odaklandığımıza göz atın.

---

Sayfalarınızı hangi etkileşimlerin yavaşlattığından emin değil misiniz? Ücretsiz SEO analizi isteyin; gerçek kullanıcı INP, LCP ve CLS değerlerinizi olası nedenleriyle birlikte paylaşalım.