Search Console'u açıyorsunuz ve Core Web Vitals altında bir INP uyarısı görüyorsunuz: "200 ms'den uzun". Kulağa teknik geliyor ama konu çok somut: biri tıkladığında, dokunduğunda veya yazdığında siteniz ne kadar hızlı tepki veriyor. Bu uyarının ne anlama geldiğini, neden şimdi çıktığını ve böyle bir sorunu nasıl ele aldığımı anlatıyorum.

INP tam olarak neyi ölçer

Interaction to Next Paint, kısaca INP, bir sayfanın ne kadar hızlı tepki verdiğini Event Timing API verilerine dayanarak ölçen kararlı bir Core Web Vital'dır. web.dev bunu böyle açıklıyor. INP, ziyaretçinin sayfadaki tüm etkileşimlerine bakar ve tüm, ya da neredeyse tüm, etkileşimlerin altında kaldığı tek bir değer raporlar.

Neyin sayılıp neyin sayılmadığını bilmek önemli:

  • Sayılır: fareyle tıklama, dokunmatik ekrana dokunma ve fiziksel ya da ekran klavyesinde tuşa basma.
  • Bu da sayılır: iframe içindeki etkileşimler, örneğin gömülü bir videoda oynat düğmesine tıklamak.
  • Sayılmaz: fareyle üzerine gelme, yakınlaştırma ve kaydırma.

Her 50 etkileşimde en yavaş olanı yok sayılır. Çoğu sayfa ziyaretinde 50'den fazla etkileşim olmadığı için pratikte genellikle en kötü etkileşimi görürsünüz. Bir sayfanın hiç INP değeri olmayabilir de; örneğin ziyaretçi yalnızca kaydırdıysa ya da tarayıcı robotu gibi bir bot söz konusuysa.

Neden sayfanın tüm ömrü boyunca ölçülüyor? Chrome kullanım verilerine göre bir ziyaretçi, sayfada geçirdiği sürenin %90'ını sayfa yüklendikten sonra geçiriyor. Yani hızlı yüklenme tek başına yeterli değil.

Eşik değerler, gerçek ziyaretlerin 75. yüzdelik diliminde, mobil ve masaüstü için ayrı ayrı ölçülür:

  • 200 milisaniye veya daha az: iyi
  • 200'den fazla, 500 milisaniyeye kadar (dahil): iyileştirme gerekli
  • 500 milisaniyeden fazla: kötü

Bu konu neden şimdi gündemde

INP yeni değil. Mayıs 2022'de deneysel bir metrik olarak tanıtıldı ve 12 Mart 2024'te First Input Delay (FID) yerine resmi olarak bir Core Web Vital oldu; bunu web.dev'deki duyuru yazısı aktarıyor. O zamandan beri PageSpeed Insights, FID yerine INP'yi değerlendiriyor. Geliştiricilerin FID verisi çeken araçlarını güncellemek için 9 Eylül 2024'e kadar süresi vardı.

Google Search Central belgeleri üç Core Web Vital sayıyor: yükleme için LCP (hedef 2,5 saniyeden az), tepki hızı için INP (hedef 200 milisaniyeden az) ve görsel kararlılık için CLS. Yani eskiden FID'de sorunsuz görünen bir site, sitede hiçbir şey değişmemiş olsa bile INP'de sorun gösterebilir.

Search Console raporunu nasıl okursunuz

Core Web Vitals raporu URL'leri duruma (Kötü, İyileştirme gerekli, İyi), metriğe (CLS, INP, LCP) ve benzer sayfalardan oluşan URL grubuna göre gruplar. Rapor, Chrome User Experience Report (CrUX) kaynaklı gerçek kullanıcı verilerini kullanır.

Sık kafa karıştıran birkaç nokta:

  • "Group INP", son 28 gündeki sayfa isteklerinin %75'inin bu tepki süresine veya daha azına sahip olduğu anlamına gelir.
  • Durumu en kötü metrik belirler. İyi bir INP ile kötü bir CLS yine de "kötü" sonucunu verir.
  • Durum tek bir sayfaya değil, tüm gruba uygulanır.
  • Mobil ve masaüstü ayrı değerlendirilir. Mobilde iyi olmak, masaüstünde de iyi olmak anlamına gelmez; tersi de geçerli.

Gecikme nereden kaynaklanır

Bir etkileşim üç bölümden oluşur. Önce event handler'lar başlayana kadar geçen bir giriş gecikmesi vardır; bunun nedenlerinden biri main thread üzerindeki uzun görevlerdir. Sonra event handler'ların kendisi çalışır. Ardından bir sonraki kare ekranda görünene kadar bir gecikme daha olur.

INP optimizasyonu rehberine göre, script'lerin yüklenmesi ve çalışması sırasında oluşan uzun görevler, sayfa yüklenirken yapılan etkileşimleri geciktirebilir. Kısacası tarayıcının sayfa açılırken işlemesi gereken iş ne kadar fazlaysa, bir tıklamanın bir an takılma ihtimali o kadar artar.

Somut olarak ne yaparsınız, bu sırayla

  1. Core Web Vitals raporunu açın ve hangi URL gruplarında INP'nin kötü olduğunu mobil ve masaüstü için ayrı ayrı not edin. Böylece sorunun hangi tür sayfada olduğunu görürsünüz, örneğin ürün sayfalarınız ya da iletişim formunuz.
  2. Saha verileriyle başlayın. Siteniz CrUX'a uygunsa INP verilerini PageSpeed Insights'ta bulursunuz. Gerçek kullanıcılardan kendi ölçümleriniz (RUM) daha fazla ayrıntı verir: hangi etkileşimin yavaş olduğu, yükleme sırasında mı sonrasında mı gerçekleştiği ve etkileşimin hangi bölümünün gecikmeye yol açtığı.
  3. Ardından nedeni bir laboratuvar ortamında arayın. O yavaş etkileşimi yeniden oluşturun ve main thread üzerinde neler olduğuna bakın.
  4. Nedeni giderin. Script yüklerken uzun görevlerden kaçının. Event callback'leri bölün ve main thread'e sık sık başka işler yapma fırsatı verin, örneğin setTimeout ile; çünkü callback bu durumda yeni bir görevde çalışır. Böylece ekran görsel geri bildirimi daha hızlı gösterir. Bir sonraki kare için gerekmeyen işleri daha sonraki bir göreve kaydırın. Ayrıca DOM'u küçük tutun, büyük ve karmaşık düzenlerden kaçının ve stil hesaplamalarını sınırlayın.
  5. Sorunun çözüldüğünü düşündüğünüzde, rapordaki sorunun ayrıntı sayfasında "Start Tracking" düğmesine tıklayın. Sonra trafiğinizi ve grubun INP değerlerini takip edin. Rapor son 28 günün verileriyle çalıştığı için etkiyi hemen görmezsiniz.

Ne zaman dışarıya vermelisiniz

İlk adımı kendiniz yapabilirsiniz: raporu okumak ve hangi sayfaların etkilendiğini görmek. Üçüncü adımdan itibaren iş teknikleşir. Bir performans profilini okuyabilmeniz, hangi script'in uzun göreve yol açtığını bilmeniz ve formunuzu ya da alışveriş sepetinizi bozmadan kodu değiştirebilmeniz gerekir. Siteniz kendi yönetmediğiniz bir tema veya eklentiler üzerinde çalışıyorsa, neden bir işletme sahibi olarak dokunmak istemeyeceğiniz bir kodda olabilir.

Bu tür işleri bakım ve güvenlik hizmetimin bir parçası olarak yapıyorum: ölçmek, nedeni bulmak, çözmek ve ardından grup yeniden iyi duruma gelene kadar 28 gün boyunca takip etmek. Uyarınızın ne kadar ciddi olduğundan emin değilseniz, Search Console verilerinizle birlikte iletişime geçin, birlikte bakalım.