INP Nedir ve Nasıl İyileştirilir? Core Web Vitals Rehberi

INP nedir sorusunun kısa cevabı: Interaction to Next Paint, yani bir kullanıcı etkileşiminden sonraki ilk ekran güncellemesine kadar geçen süredir. Kullanıcı bir düğmeye tıkladığında, bir menüye dokunduğunda ya da bir alana yazı yazdığında sayfanın ne kadar hızlı tepki verdiğini ölçer. Bu metrik, Mart 2024'te First Input Delay'in (FID) yerini alarak Core Web Vitals metriklerinden biri oldu.

Sayfa hızı denince akla genellikle yüklenme süresi gelir. INP ise yüklenmeden sonra olanı ölçer: Sayfa açıldı, kullanıcı bir şey yapmak istedi ve sayfa ona ne kadar sürede cevap verdi? "Sepete ekle"ye basıldığında yarım saniye boyunca hiçbir şey olmuyorsa, kullanıcı ikinci kez basar ya da sayfadan çıkar. INP bu deneyimi sayıya döker.

INP nedir ve neyi ölçer?

INP, ziyaret boyunca sayfada yapılan tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözlemler. Fareyle bir öğenin üzerine gelmek ve sayfayı kaydırmak bu hesaba girmez. Ziyaret sonunda raporlanan INP değeri, o ziyaretteki en yavaş etkileşimlere yakın bir değerdir. Çok sayıda etkileşim olan sayfalarda, aşırı uç değerlerin sonucu bozmaması için her 50 etkileşimde en yüksek olan bir tanesi göz ardı edilir.

Google, INP için şu eşikleri kullanır:

Bir sayfanın "iyi" sayılması için bu eşiğin ziyaretlerin 75. yüzdelik diliminde tutturulması gerekir. Yani ziyaretlerin en az dörtte üçünde INP 200 ms veya altında olmalıdır. Mobil ve masaüstü ayrı ayrı değerlendirilir. Mobil cihazlar genellikle daha yavaş olduğu için INP sorunları çoğunlukla önce mobilde görünür.

Core Web Vitals'ın diğer iki metriği yüklenme hızını ölçen LCP (Largest Contentful Paint) ve görsel kaymayı ölçen CLS'dir (Cumulative Layout Shift). Bu yazı yalnızca INP'ye odaklanıyor.

INP, FID'den neden daha zor bir metrik?

FID yalnızca sayfadaki ilk etkileşime bakıyordu ve o etkileşimin de yalnızca başlangıç gecikmesini ölçüyordu. Yani tarayıcının, kullanıcının tıklamasını işlemeye ne kadar geç başladığını. Tıklamadan sonra kodun ne kadar sürdüğü ve ekranın ne zaman güncellendiği hesaba girmiyordu; INP bunları da ölçüyor.

INP ise ziyaret boyunca tüm etkileşimlere bakar ve gecikmenin tamamını ölçer. Bu yüzden FID'de rahatça geçen birçok site INP'de zorlanır. Özellikle yoğun JavaScript kullanan, filtreli ürün listeleri, açılır menüler ve canlı arama kutuları olan e-ticaret siteleri bu farkı belirgin biçimde hisseder.

INP: bir etkileşimin üç parçası

INP'yi iyileştirmenin ilk adımı, gecikmenin hangi parçada oluştuğunu bulmaktır. Her etkileşim üç aşamadan oluşur:

1. Giriş gecikmesi (input delay): Kullanıcının tıklamasıyla, tarayıcının bu tıklamaya ait kodu çalıştırmaya başlaması arasındaki süre. Tarayıcının ana iş parçacığı o anda başka bir işle meşgulse, örneğin bir üçüncü taraf betiği çalışıyorsa, tıklama sırada bekler.
2. İşleme süresi (processing duration): Tıklamaya bağlı olay işleyicilerinin çalışma süresi. Ağır hesaplamalar, büyük veri dönüşümleri ya da gereksiz yeniden çizimler INP'nin bu aşamasını uzatır.
3. Sunum gecikmesi (presentation delay): Kod bittikten sonra tarayıcının stilleri hesaplaması, yerleşimi belirlemesi ve ekranı yeniden boyaması için geçen süre. Çok büyük bir DOM ağacı ya da tek seferde değişen çok sayıda öğe bu aşamayı yavaşlatır.

Her aşamanın çözümü farklıdır. INP'de giriş gecikmesi uzunsa sorun çoğunlukla arka planda çalışan başka kodlardır. İşleme süresi uzunsa tıklamaya bağlı kodun kendisi yavaştır. INP'de sunum gecikmesi uzunsa sayfanın yapısı ve yeniden çizilen alanın büyüklüğü incelenmelidir.

INP nasıl ölçülür?

INP'yi ölçmenin iki yolu vardır ve ikisinin de rolü farklıdır.

INP saha verisi: gerçek kullanıcılar

Google'ın değerlendirmesi, Chrome kullanıcılarından toplanan gerçek kullanım verisine (Chrome UX Report, kısaca CrUX) dayanır. Bu veri 28 günlük kayan bir pencereyle hesaplanır. Bu yüzden yaptığınız bir INP düzeltmesinin raporlara tam yansıması birkaç hafta sürer.

• PageSpeed Insights: Sayfanın üst bölümünde, yeterli veri varsa o URL'nin ya da tüm alan adının gerçek kullanıcı INP değerini gösterir.
• Search Console Core Web Vitals raporu: Benzer URL'leri gruplayarak hangi sayfa tiplerinde sorun olduğunu gösterir. Trafiği düşük sitelerde veri hiç görünmeyebilir.
• Kendi ölçümünüz: Google'ın açık kaynaklı web-vitals JavaScript kütüphanesiyle INP değerini kendi analitik aracınıza gönderebilirsiniz. Kütüphanenin "attribution" sürümü, hangi öğeye tıklandığını ve gecikmenin hangi aşamada oluştuğunu da raporlar. Hangi etkileşimin yavaş olduğunu bulmanın en verimli yolu budur.

INP laboratuvar verisi: kontrollü test

INP saha verisi sorunun varlığını gösterir, laboratuvar ise nedenini bulmaya yarar. Chrome DevTools'taki Performance paneli, sayfada gezinirken etkileşimlerinizi canlı olarak ölçer ve her etkileşimin ayrıntılı zaman çizelgesini çıkarır. Testleri CPU yavaşlatma açıkken yapın. Güçlü bir geliştirici bilgisayarında iyi INP veren bir etkileşim, orta seviye bir telefonda çok daha yavaş olabilir.

Lighthouse'un standart sayfa yükleme testi INP'yi ölçemez, çünkü bu testte kullanıcı etkileşimi yoktur. Bu testteki Total Blocking Time (TBT) değeri, ana iş parçacığının ne kadar meşgul olduğunu gösterdiği için INP sorunlarına dair yararlı bir ön işarettir.

INP'yi kötüleştiren yaygın nedenler

• Uzun görevler: Ana iş parçacığını 50 ms'den uzun süre meşgul eden her JavaScript görevi, o sırada gelen tıklamaları bekletir.
• Üçüncü taraf betikler: Etiket yöneticileri, canlı destek pencereleri, A/B test araçları, ısı haritaları ve reklam pikselleri. Her biri INP üzerinde tek başına küçük görünür, birlikte ana iş parçacığını ciddi biçimde doldurur.
• Ağır olay işleyicileri: Bir tıklamada hem arayüzü güncelleyen, hem analitik olayı gönderen, hem de büyük bir listeyi yeniden hesaplayan kod.
• Hidrasyon maliyeti: Sunucuda oluşturulup tarayıcıda JavaScript ile etkileşimli hâle getirilen sayfalarda, bu işlem sürerken yapılan tıklamalar gecikir.
• Büyük DOM ve geniş yeniden çizimler: Binlerce öğe içeren sayfalarda küçük bir değişiklik bile pahalı bir stil ve yerleşim hesabını tetikleyebilir.
• Gereksiz yeniden oluşturma: Bileşen tabanlı arayüzlerde, küçük bir durum değişikliğinin sayfanın büyük bölümünü yeniden oluşturması.

INP nasıl iyileştirilir?

1. Önce yavaş etkileşimi bulun

Tahmine dayalı optimizasyon zaman kaybettirir. Saha verisinden hangi sayfada ve hangi öğede sorun olduğunu bulun, sonra o etkileşimi DevTools'ta yeniden üretin. Çoğu sitede INP sorunu birkaç belirli etkileşimde toplanır: filtre seçimi, varyant değiştirme, menü açma, sepete ekleme.

2. Uzun görevleri bölün ve ana iş parçacığına nefes aldırın

Uzun bir işi tek seferde yapmak yerine küçük parçalara bölün ve parçalar arasında tarayıcıya kontrolü geri verin. Bu, setTimeout ile ya da destekleyen tarayıcılarda scheduler.yield() ile yapılabilir. Böylece arada gelen kullanıcı etkileşimleri bekletilmez.

3. Önce görsel geri bildirim, sonra ağır iş

Tıklamanın ardından kullanıcıya hemen bir tepki gösterin: düğmenin durumu değişsin, bir yükleniyor göstergesi çıksın. Analitik gönderimi, öneri hesaplama ya da ikincil veri yükleme gibi acil olmayan işleri bir sonraki ekran güncellemesinden sonraya erteleyin. INP, ilk ekran güncellemesine kadar geçen süreyi ölçtüğü için bu yaklaşım doğrudan etki eder.

4. Üçüncü taraf betiklerini denetleyin

Sitedeki her betiğin listesini çıkarın ve her biri için "bunu hâlâ kullanıyor muyuz?" sorusunu sorun. Kullanılmayanları kaldırın. Gerekli olanları sayfa yüklendikten ve kullanıcı etkileşime başladıktan sonra yükleyin. Etiket yöneticisindeki tetikleyicileri de gözden geçirin. Her tıklamada çalışan çok sayıda etiket, doğrudan INP'ye yansır.

5. Sayfanın yapısını hafifletin

DOM boyutunu küçültün, ekranda görünmeyen bölümlerin çizimini erteleyin (CSS content-visibility özelliği bunun için kullanılabilir) ve bir etkileşimde değişen alanı mümkün olduğunca küçük tutun. Uzun listelerde yalnızca görünen öğeleri çizen sanal liste yaklaşımı INP'de ciddi kazanç sağlar.

6. Çerçeveye özgü iyileştirmeler yapın

React ve Next.js gibi çerçevelerde gereksiz yeniden oluşturmayı engellemek, acil olmayan güncellemeleri düşük öncelikli olarak işaretlemek (React'teki useTransition gibi) ve hidrasyonu sayfanın gerçekten etkileşimli olan bölümleriyle sınırlamak etkili yöntemlerdir. Arama kutusu gibi her tuşta çalışan alanlarda işlemi kısa bir bekleme süresiyle sınırlamak da gereksiz yükü azaltır.

7. Ağır hesaplamayı ana iş parçacığından çıkarın

INP'yi korumak için büyük veri işleme, karmaşık filtreleme ya da şifreleme gibi işler Web Worker'a taşınabilir. Böylece hesaplama sürerken arayüz tepki vermeye devam eder.

Kullandığınız platforma göre gerçekçi INP beklentisi

INP'yi ne kadar iyileştirebileceğiniz, kodun ne kadarının sizin kontrolünüzde olduğuna bağlıdır. Hazır bir e-ticaret paketi ya da kiralık bir site altyapısı kullanıyorsanız çekirdek koda dokunamazsınız. Bu durumda INP kazancı genellikle tema seçiminden, eklenti ve uygulama sayısını azaltmaktan ve üçüncü taraf betiklerini düzenlemekten gelir.

WordPress gibi açık kaynak sistemlerde daha fazla kontrolünüz vardır, ama eklenti sayısı arttıkça sorun da büyür. Kendi kodunuzu yazdığınız projelerde ise en geniş alana sahipsiniz. Performansı baştan hedef olarak koyan bir kurumsal web tasarım süreci, sonradan yapılan düzeltmelerden çok daha az maliyetlidir.

INP ve sıralama: beklentiyi doğru kurun

Google, Core Web Vitals'ı sayfa deneyimini değerlendirdiği sinyaller arasında kullanır. Ancak Google'ın kendi açıklamalarına göre arama sistemleri öncelikle en alakalı ve faydalı içeriği öne çıkarır. İyi bir INP değeri zayıf bir içeriği üst sıralara taşımaz. Benzer kalitedeki sayfalar arasında ise deneyim farkı rol oynayabilir.

Bu yüzden INP'yi yalnızca bir sıralama hamlesi olarak görmemek gerekir. INP'deki asıl kazanç kullanıcı tarafındadır: Tıklamalara hemen tepki veren bir sayfa daha güvenilir hissettirir, daha az terk edilir ve özellikle mobilde satın alma sürecini kolaylaştırır. INP'yi tarama, indeksleme ve site mimarisiyle birlikte ele aldığımız işleri teknik SEO hizmetimiz sayfasında anlattık.

Nereden başlamalı?

Search Console'da INP uyarısı görüyorsanız önce hangi sayfa grubunun etkilendiğine bakın, sonra o gruptaki en sık kullanılan etkileşimi DevTools'ta inceleyin. Çoğu zaman INP sorununun büyük kısmı birkaç betikte ya da tek bir ağır olay işleyicisinde toplanır.

Bu INP incelemesini birlikte yapmak isterseniz ücretsiz ön analiz talebi bırakabilirsiniz. Sitenizin saha verisine bakar, en çok etki edecek iki üç düzeltmeyi öncelik sırasıyla paylaşırız.