Web sitesinde INP raporu PageSpeed’de nasıl okunur?

Web sitesinde INP raporu PageSpeed’de, gerçek kullanıcı verisindeki 75. yüzdelik etkileşim gecikmesi okunarak değerlendirilir. PageSpeed Insights, uygun veri varsa URL veya alan adı için INP değerini gösterir. Bu değer, kullanıcıların tıklama, dokunma veya klavye etkileşiminden sonra sayfanın görsel yanıt vermesine kadar geçen süreyi ifade eder.

INP, Core Web Vitals içinde yer alan kullanıcı deneyimi metriklerinden biridir. Tek bir tıklamanın en hızlı yanıtını değil, sayfa boyunca gerçekleşen etkileşimlerin genel tepkisini ölçer. Bu nedenle yalnızca ana sayfayı test etmek yeterli değildir.

INP nedir ve PageSpeed Insights’ta nerede görünür?

INP, bir sayfanın kullanıcı etkileşimlerine ne kadar hızlı yanıt verdiğini gösteren milisaniye cinsinden metriktir. Kullanıcı bir butona bastığında, menüyü açtığında veya forma veri girdiğinde tarayıcı yanıt üretir.

PageSpeed Insights raporunda INP, genellikle “Gerçek kullanıcı deneyimi” veya “Kullanıcı deneyimi” bölümünde görünür. Bu bölümdeki veri, Lighthouse testinden değil, Chrome kullanıcılarının anonimleştirilmiş saha ölçümlerinden gelir.

INP değeri milisaniye olarak okunur. 200 milisaniye ve altı iyi kabul edilir. 200 ile 500 milisaniye arası iyileştirme gerektirir. 500 milisaniyenin üzeri zayıf kabul edilir.

Bu eşikler tek başına teşhis koydurmaz. Örneğin 240 ms değerindeki sorun yalnızca mobil menüde yaşanabilir. 180 ms değeri ise ödeme adımındaki kritik butonda ölçülüyorsa yine incelenmelidir.

PageSpeed Insights’ta saha verisi ile laboratuvar verisi nasıl ayrılır?

Saha verisi gerçek kullanıcı oturumlarından, laboratuvar verisi ise kontrollü bir test çalıştırmasından elde edilir. PageSpeed raporundaki iki bölümün amacı ve yorumlama biçimi farklıdır.

Gerçek kullanıcı verisi bölümünde INP, LCP ve CLS gibi Core Web Vitals metrikleri gösterilebilir. Bu veriler, farklı cihaz, bağlantı, işletim sistemi ve kullanım koşullarını içerir. Sonuç, sitenizin gerçek trafik içindeki davranışını yansıtır.

Laboratuvar bölümünde Lighthouse, belirli cihaz ve ağ koşullarıyla yeni bir test yapar. Bu testte INP yerine çoğunlukla Total Blocking Time, yani TBT gösterilir. TBT, ana iş parçacığının uzun görevlerle ne kadar meşgul olduğunu ölçer.

Bu nedenle PageSpeed’te laboratuvar bölümünde doğrudan INP görmemeniz normaldir. TBT düşük olsa bile gerçek kullanıcı INP’si yüksek çıkabilir. Bunun tersi de bazı trafik profillerinde mümkündür.

Yanlış: “Lighthouse skoru 90 olduğu için INP sorunu yoktur.” Doğru: “Saha verisindeki INP durumunu ve laboratuvar TBT bulgularını ayrı ayrı kontrol etmeliyim.”

Laboratuvar sonucu geliştirme sırasında hızlı karşılaştırma sağlar. Saha verisi ise yayınlanmış sayfanın gerçek performansını değerlendirmek için önceliklidir. İki veri aynı soruya cevap vermez.

INP değerinde p75 ne anlama gelir?

PageSpeed Insights’taki INP değeri genellikle 75. yüzdelik dilimi, yani p75’i ifade eder. Kullanıcıların yüzde 75’inin ölçülen değere eşit veya daha hızlı bir deneyim yaşadığı anlamına gelir.

Örneğin p75 INP değeri 320 ms ise oturumların en az yüzde 75’i 320 milisaniye veya daha kısa sürede yanıtlanmıştır. Daha yavaş kalan yüzde 25’lik bölüm bu özet değerin dışında kalır.

p75, ortalama değildir. Ortalama değer, birkaç çok yavaş etkileşimin etkisini gizleyebilir. p75 ise kullanıcıların daha yavaş bölümünü de dikkate aldığı için Core Web Vitals değerlendirmelerinde daha anlamlıdır.

Bir sayfanın INP değeri 190 ms’den 210 ms’ye çıktığında küçük görünen değişim, iyi durumdan iyileştirme gereken duruma geçiş anlamına gelir. Bu nedenle yalnızca milisaniye farkına değil, eşik üzerindeki duruma da bakılmalıdır.

Saha verisi değişken olduğu için tek bir günlük raporla kesin karar verilmemelidir. Aynı URL’yi farklı günlerde, mümkünse Search Console’daki Core Web Vitals raporuyla birlikte izlemek daha sağlıklıdır.

INP’yi değerlendirirken cihaz dağılımını da düşünün. Mobil kullanıcı oranı yüksek bir sitede masaüstü test sonucu, ziyaretçilerin önemli bölümünü temsil etmeyebilir. Özellikle e-ticaret sitelerinde filtre, sepet ve ödeme etkileşimleri ayrı incelenmelidir.

PageSpeed’te URL verisi ile origin verisi arasındaki fark nedir?

URL verisi yalnızca belirli sayfayı, origin verisi ise aynı alan adındaki sayfaların toplu saha performansını ifade eder. PageSpeed Insights, yeterli veri bulunmadığında bu iki görünümden birini sunabilir.

Bir ürün sayfası için URL verisi mevcut değilse rapor alan adı verisini gösterebilir. Bu durumda görülen INP değeri yalnızca test ettiğiniz ürün sayfasına ait olmayabilir. Ana sayfa, kategori ve ödeme sayfalarının verileri de toplama dahil olabilir.

URL ile origin sonuçları farklıysa bu çelişki değildir. Örneğin ana sayfanın etkileşimleri hızlı, filtreleme kullanan kategori sayfaları yavaş olabilir. Origin değeri bu farklı şablonların birleşik etkisini gösterebilir.

Raporu okurken önce veri başlığını kontrol edin. “Bu URL” ifadesi sayfa özelini, “Origin” ifadesi alan adı geneli eğilimi belirtir. Karar verirken hangi kapsamın kullanıldığını not edin.

• Test edilen URL’nin doğru protokol ve alan adıyla açıldığını kontrol edin.
• Raporun URL verisi mi, origin verisi mi sunduğunu okuyun.
• Mobil ve masaüstü sonuçlarını ayrı değerlendirin.
• Sonucun yeterli saha verisine dayanıp dayanmadığını kontrol edin.
• Aynı şablondaki ikinci bir URL’yi karşılaştırın.

Origin verisi, şablon düzeyinde sorun aramak için yararlıdır. Ancak tek bir kampanya landing page’i için doğrudan düzeltme kararı vermeden önce URL seviyesinde yeterli veri beklenmelidir.

INP yüksekse hangi kullanıcı etkileşimi soruna neden oluyor?

Yüksek INP’nin kaynağını bulmak için etkileşimden sonra çalışan JavaScript görevlerini ve tarayıcının yeniden çizim süresini incelemek gerekir. Sadece skor ekranına bakmak yeterli değildir.

Yaygın nedenler arasında büyük JavaScript paketleri, uzun ana iş parçacığı görevleri, gereksiz DOM güncellemeleri ve üçüncü taraf kodları bulunur. Çerez bannerı, canlı destek, reklam pikseli ve analiz araçları da etkileşim anında çalışabilir.

Örneğin kullanıcı menü butonuna bastığında site aynı anda yüzlerce DOM öğesini yeniden hesaplıyorsa INP yükselir. Menü görsel olarak basit olsa bile arka plandaki işlem ağır olabilir.

Chrome DevTools Performance paneli, bu işlemleri incelemek için kullanılabilir. Etkileşimi kaydedin, uzun görevleri bulun ve hangi fonksiyonun ana iş parçacığını meşgul ettiğini kontrol edin. 50 milisaniyeyi aşan görevler kullanıcı etkileşimini geciktirebilir.

Özellikle şu etkileşimleri ayrı test edin:

• Mobil menünün açılması ve kapanması.
• Arama kutusuna karakter girilmesi.
• Filtre veya sıralama seçiminin uygulanması.
• Sepete ürün eklenmesi.
• Form doğrulama ve ödeme butonu işlemleri.

Bir etkileşimde sorun görülmemesi diğerlerinin hızlı olduğu anlamına gelmez. INP, sayfa boyunca gerçekleşen etkileşimleri kapsadığı için test senaryosu gerçek kullanıcı yolculuğunu izlemelidir.

Yüksek INP için hangi teknik iyileştirmeler yapılır?

Yüksek INP için ilk teknik adım, etkileşim sırasında çalışan işi küçültmek ve ana iş parçacığını boş bırakmaktır. Kodun tamamını kaldırmak yerine gereksiz çalışmayı ertelemek çoğu projede daha güvenlidir.

JavaScript paketlerini küçültmek, kullanılmayan kodu ayırmak ve yalnızca ihtiyaç duyulan bileşeni yüklemek etkili olabilir. Kod bölme yöntemiyle ödeme, filtre veya galeri işlevleri ilk sayfa yüklemesinden ayrılabilir.

Uzun görevler küçük parçalara bölünmelidir. Tarayıcıya her parça arasında kullanıcı etkileşimini işleme fırsatı vermek, tek seferde yapılan ağır işlemin gecikmesini azaltabilir.

DOM güncellemelerini toplu yapmak da önemlidir. Her değişiklikte layout hesaplatmak yerine, gerekli verileri hazırlayıp arayüzü daha az sayıda güncellemek daha iyi sonuç verir.

Üçüncü taraf betikleri de ayrı ölçülmelidir. Analiz, reklam veya sohbet kodunu tamamen kaldırmak her zaman mümkün değildir. Ancak yükleme zamanını ertelemek, tetikleyiciyi belirli sayfalara sınırlamak ve gereksiz etiketleri temizlemek uygulanabilir.

Filtreleme ve arama gibi yoğun işlevlerde istemci tarafında tüm veriyi tekrar işlemek yerine sunucu tarafı istekleri kullanılabilir. Bu yöntem, veri miktarı büyüdüğünde işe yarar. Küçük veri kümelerinde ise ağ gecikmesi ekleyebileceği için önce ölçüm yapılmalıdır.

Arayüz erişilebilirliği de etkileşim koduyla birlikte değerlendirilmelidir. Klavye odağı, görünür odak stili ve doğru buton davranışı için web sitesinde erişilebilirlik testi nasıl yapılır rehberindeki kontroller kullanılabilir.

INP ile sayfa tasarımı ve üçüncü taraf bileşenleri nasıl ilişkilidir?

INP yalnızca yazılım koduyla değil, sayfadaki bileşenlerin tasarım biçimiyle de ilişkilidir. Aynı anda açılan modallar, mega menüler ve canlı filtreler daha fazla işlem gerektirebilir.

Bir çerez bannerı her tıklamada tüm sayfayı yeniden oluşturuyorsa küçük bir onay işlemi pahalı hale gelir. Banner tasarımında yalnızca gerekli alanı güncellemek gerekir. Bu konu için web sitesinde çerez bannerı nasıl tasarlanır rehberindeki davranış ve yerleşim kontrolleri incelenebilir.

E-ticaret sitelerinde ürün filtreleri INP için sık görülen temas noktalarıdır. Çok sayıda filtreyi aynı anda uygulamak, ürün kartlarını ve sayfalama alanını yeniden oluşturabilir. Faceted navigation yapısı için web sitesinde faceted navigation SEO’yu bozar mı yazısındaki teknik ayrımlar ayrıca değerlendirilmelidir.

Landing page’lerde de animasyon sayısı tek başına performans ölçüsü değildir. Bir animasyon kullanıcı tıklamasıyla yüzlerce öğeyi etkiliyorsa gecikme üretebilir. Landing page nedir ve dönüşüm optimizasyonu içeriğindeki bileşen planı, gereksiz etkileşimleri azaltmaya yardımcı olur.

Bir bileşenin görsel olarak sade olması, teknik olarak hafif olduğu anlamına gelmez. Hazır slider, pop-up, harita ve kişiselleştirme araçları kendi JavaScript kodlarını çalıştırabilir. Her bileşen eklenmeden önce tetiklenme zamanı ve etkileşim etkisi ölçülmelidir.

Bu noktada amaç bütün hareketleri kaldırmak değildir. Kullanıcıyı yönlendiren animasyon korunabilir. Ancak animasyonun tıklama yanıtını bloke edip etmediği, gerçek cihazda test edilmelidir.

INP düzeltmeleri PageSpeed Insights’ta ne zaman görünür?

Laboratuvar değişiklikleri hemen yeni testte görülebilir, fakat saha INP verisinin değişmesi daha uzun sürebilir. Çünkü saha verisi gerçek kullanıcı oturumlarından toplanır ve günlük güncellemelerle rapora yansır.

Yeni kodu yayınladıktan sonra önce Chrome DevTools veya Lighthouse ile teknik doğrulama yapın. Ardından PageSpeed Insights’ta aynı URL’yi tekrar test edin. Laboratuvar TBT değerinin düşmesi, yapılan değişikliğin ana iş parçacığını rahatlattığını gösterebilir.

Saha verisi için yeterli yeni trafik oluşması gerekir. Düşük ziyaret alan sayfalarda sonuçların değişmesi daha yavaş olabilir. Bu nedenle yayın sonrası tek bir günlük sonuca bakarak başarısızlık kararı vermeyin.

1. Değişiklikten önce URL, cihaz ve INP durumunu kaydedin.
2. Sorunlu etkileşimi DevTools Performance ile yeniden üretin.
3. Uzun görevi veya üçüncü taraf betiğini belirleyin.
4. Tek bir teknik değişiklik yapıp yeniden ölçün.
5. Lighthouse TBT ve saha INP sonuçlarını ayrı not edin.
6. Sonraki saha güncellemelerinde p75 durumunu takip edin.

Birden fazla optimizasyonu aynı anda yapmak, hangi değişikliğin sonuç verdiğini belirsizleştirir. Kritik projelerde her sürüm için değişiklik, test koşulu ve sonuç kaydı tutulmalıdır.

PageSpeed puanı değişmese bile INP iyileşebilir. Performans puanı birden fazla laboratuvar metriğinin birleşimidir. Bu yüzden INP kararını yalnızca genel puana göre vermek doğru değildir.

INP raporu okunurken hangi hatalardan kaçınılır?

En yaygın hata, laboratuvar skorunu gerçek kullanıcı deneyimiyle eşitlemektir. PageSpeed Insights’ın laboratuvar testi belirli koşulları temsil eder. Saha verisi ise gerçek trafik dağılımını gösterir.

İkinci hata, yalnızca ana sayfayı kontrol etmektir. Kullanıcılar sitenin farklı şablonlarında gezinir. Ürün, kategori, arama, sepet ve ödeme sayfaları farklı JavaScript yüklerine sahip olabilir.

Üçüncü hata, origin verisini URL verisi gibi yorumlamaktır. Raporun kapsamı okunmadan yapılan karşılaştırmalar, yanlış sayfada optimizasyon yapılmasına neden olabilir.

Dördüncü hata, her gecikmeyi görsel tasarıma bağlamaktır. INP çoğu zaman tıklama sonrası çalışan JavaScript, DOM güncellemesi veya üçüncü taraf koduyla ilgilidir. Görsel sadeleştirme tek başına çözüm olmayabilir.

Beşinci hata, yalnızca masaüstü cihazda test yapmaktır. Mobil işlemciler ve bağlantılar farklı koşullar sunar. Mobilde kullanılan menü, filtre ve form akışları ayrıca kaydedilmelidir.

Raporu şu sırayla okuyun: veri kaynağı, kapsam, p75 değeri, durum etiketi, ilgili şablon ve tekrar üretilebilir etkileşim. Bu sıra, rastgele kod değişikliği yapma riskini azaltır.

INP’nin iyi çıkması da tüm kullanıcı deneyiminin kusursuz olduğu anlamına gelmez. LCP, CLS, erişilebilirlik, form kullanılabilirliği ve hata mesajları ayrıca incelenmelidir. Performans metrikleri birbirinin yerine kullanılmaz.