Interaction to Next Paint (INP), bir web sayfasının kullanıcı girdilerine ne kadar çabuk görsel yanıt verdiğini ölçen bir Core Web Vitals metriğidir. Google bu metriği Mart 2024 itibarıyla First Input Delay (FID) metriğinin yerine resmen devreye aldı. Artık sayfanın yalnızca ilk tıklamaya verdiği tepki değil, ziyaret boyunca gerçekleşen etkileşimlerin genel akıcılığı değerlendiriliyor. Bu rehberde INP’nin nasıl hesaplandığını, hangi değerlerin kabul edilebilir sayıldığını, sorunun hangi araçlarla tespit edileceğini ve pratikte nasıl çözüleceğini ele alıyoruz.
INP Metriği Nedir ve Neyi Ölçer?
INP, kullanıcı bir sayfayla etkileşime girdiği anda başlayan süreyi, tarayıcının bu etkileşimin sonucunu ekrana yansıttığı ana kadar ölçer. Süre milisaniye cinsinden ifade edilir. Bir butona tıklamak, açılır menüyü açmak, akordeon başlığına dokunmak, ürün filtresini değiştirmek, form alanına klavyeyle veri girmek ya da mobilde bir öğeye dokunmak bu ölçümün konusudur. Kullanıcı bir eylem yaptığında ekranda anlamlı bir değişiklik görmüyorsa, sayfa teknik olarak yüklenmiş olsa bile kullanılabilirlik açısından yetersiz sayılır.
Metrik, sayfa ziyaretinin tamamı boyunca gerçekleşen tüm uygun etkileşimleri gözlemler ve içlerinden en kötü sonuca yakın olanı raporlar. Çok sayıda etkileşim olan uzun oturumlarda, tek seferlik sıra dışı bir gecikmenin skoru haksız yere bozmaması için istatistiksel bir ayıklama uygulanır. Google’ın değerlendirmesi, gerçek kullanıcı verilerinde sayfa ziyaretlerinin %75’lik dilimi üzerinden yapılır. Yani sayfanızı ziyaret edenlerin dörtte üçünde iyi bir değer yakalamanız gerekir.
Kaydırma (scroll), fare ile üzerine gelme (hover) ve yakınlaştırma hareketleri INP kapsamına girmez. Space, Page Up ve Page Down gibi tuşlarla yapılan sayfa içi gezinmeler de hesaba katılmaz. Metrik; fare tıklaması, dokunma ve klavye girdisi gibi, arayüzde bir durum değişikliği bekleyen eylemleri hedef alır.
INP Süresi Hangi Aşamalardan Oluşur?
Bir etkileşimin toplam süresi üç ayrı aşamanın toplamıdır. Optimizasyonda hangi aşamanın uzun sürdüğünü bilmek, doğru müdahaleyi seçmenin ön koşuludur.
Giriş Gecikmesi
Kullanıcı bir öğeye dokunduğunda tarayıcının ilgili olay işleyicisini çalıştırmaya başlaması için geçen süredir. Ana iş parçacığı o sırada başka bir görevle meşgulse, etkileşim kuyrukta bekler. Sayfa yüklenirken çalışan ağır JavaScript paketleri, üçüncü taraf betikler ve zamanlayıcılarla tetiklenen işlemler bu gecikmenin başlıca kaynaklarıdır.
İşleme Süresi
Olay işleyicilerinin (click, keydown, pointerup gibi) çalışması için gereken süredir. İşleyici içinde yapılan senkron hesaplamalar, büyük veri dizileri üzerinde döngüler, DOM’u tekrar tekrar okuyup yazan kodlar ve gereksiz durum güncellemeleri bu süreyi uzatır.
Sunum Gecikmesi
İşleyiciler tamamlandıktan sonra tarayıcının stil hesaplaması, yerleşim (layout) ve boyama (paint) adımlarını yürütüp yeni kareyi ekrana çizmesi için geçen süredir. Çok büyük bir DOM ağacı, karmaşık CSS seçicileri ve her etkileşimde geniş alanı yeniden hesaplatan yerleşim değişiklikleri bu aşamayı şişirir.
İdeal INP Skoru Ne Olmalıdır?
Google, INP değerlendirmesi için sabit eşikler tanımlar. Bu eşikler hem Search Console hem de PageSpeed Insights raporlarında aynı şekilde kullanılır.
| INP Değeri | Değerlendirme | Anlamı |
|---|---|---|
| 200 ms ve altı | İyi | Sayfa etkileşimlere akıcı biçimde yanıt veriyor, ek aksiyon zorunlu değil. |
| 200 ms ile 500 ms arası | İyileştirme gerekli | Kullanıcı gecikmeyi fark ediyor, belirli etkileşimler optimize edilmeli. |
| 500 ms üzeri | Zayıf | Sayfa tepkisiz hissediliyor, tekrar tıklama ve terk riski yüksek. |
Bu eşiklerin pratikteki karşılığı basittir. Kullanıcı bir butona bastığında yaklaşık yarım saniyeden uzun süre hiçbir görsel değişiklik görmüyorsa, aynı butona yeniden basma eğilimi gösterir. Bu davranış hem yinelenen işlemlere hem de memnuniyetsizliğe yol açar. E-ticaret sepetlerinde, çok adımlı formlarda ve ürün varyasyonu seçimlerinde bu risk doğrudan dönüşüm oranına yansır.
FID ile INP Arasındaki Fark Nedir?
FID, yalnızca sayfadaki ilk etkileşimin giriş gecikmesini ölçüyordu. Yani tarayıcının işleyiciyi çalıştırmaya başlamasından önceki beklemeyi kayda alıyor, işleyicinin ne kadar sürdüğüne ve ekranın ne zaman güncellendiğine bakmıyordu. Birçok site bu nedenle FID’de iyi görünürken, sayfa kullanımı sırasında ağır gecikmeler yaşatabiliyordu.
INP ise üç aşamanın tamamını kapsar ve yalnızca ilk etkileşimle sınırlı kalmaz. Ziyaret süresince gerçekleşen tüm etkileşimleri değerlendirir. Dolayısıyla INP, sayfanın yüklenme anındaki durumundan çok kullanım sırasındaki davranışını yansıtır. Daha önce FID eşiğini rahatça geçen sitelerin INP’de geride kalması bu yüzden sık görülen bir durumdur.
INP Sorunları Nasıl Tespit Edilir?
İlk adım, gerçek kullanıcı verisiyle laboratuvar verisini birlikte okumaktır. Gerçek kullanıcı verisi hangi sayfa gruplarının sorunlu olduğunu gösterir. Laboratuvar verisi ise sorunun hangi kod parçasından kaynaklandığını bulmaya yarar.
- Search Console Core Web Vitals raporu INP’de zayıf veya iyileştirme gerektiren URL gruplarını mobil ve masaüstü olarak ayırır.
- PageSpeed Insights alan verisi (CrUX) bölümünde INP değerini gösterir. Laboratuvar tarafında ise Lighthouse’un zaman aralığı (timespan) modu, belirli bir etkileşim senaryosunu kaydederek analiz etmeye olanak tanır.
- Chrome DevTools Performance paneli etkileşim kaydı sırasında ana iş parçacığındaki uzun görevleri, olay işleyicilerini ve yerleşim hesaplamalarını ayrıntılı gösterir.
- web-vitals JavaScript kütüphanesi, kendi analitik altyapınıza gerçek kullanıcıların INP değerlerini ve etkileşim yaptıkları öğeleri aktarmanızı sağlar.
Sorunlu etkileşimi belirledikten sonra hangi aşamanın baskın olduğuna bakılır. Giriş gecikmesi yüksekse ana iş parçacığı o anda meşgul demektir. İşleme süresi yüksekse olay işleyicisi ağırdır. Sunum gecikmesi yüksekse sorun DOM boyutunda veya yerleşim hesaplamalarında aranmalıdır.
INP Metriği Nasıl Optimize Edilir?
Uzun Görevleri Parçalamak
Ana iş parçacığını 50 milisaniyeden uzun süre kesintisiz meşgul eden görevler uzun görev sayılır. Bu görevler çalışırken kullanıcı girdisi kuyrukta bekler. Büyük işlemleri küçük parçalara bölmek ve aralarda tarayıcıya nefes aldırmak, giriş gecikmesini belirgin biçimde azaltır. Bunun için setTimeout tabanlı yaklaşımlar, destekleyen tarayıcılarda scheduler.yield() ve ağır hesaplamalar için Web Worker kullanımı tercih edilebilir.
JavaScript Yükünü Azaltmak
Kullanılmayan JavaScript kodunu ayıklamak, paketleri rota veya bileşen bazında bölmek (code splitting) ve kritik olmayan betikleri ertelemek hem yükleme sırasında hem de sonraki etkileşimlerde ana iş parçacığını rahatlatır. Sohbet pencereleri, A/B test araçları, etiket yöneticileri ve reklam betikleri gibi üçüncü taraf kodlar çoğu sitede en büyük yük kaynağıdır. Her birinin sağladığı değeri, ana iş parçacığında harcadığı süreyle karşılaştırmak gerekir.
Olay İşleyicilerini Hafifletmek
Etkileşimin görsel sonucunu hemen göstermek, ağır işlemleri ise sonraya bırakmak temel ilkedir. Örneğin bir filtre seçildiğinde önce seçim durumunun ve yükleme göstergesinin ekrana yansıması, sonuç listesinin hesaplanması ve çizilmesinin ardından gelmesi gerekir. Sık tetiklenen olaylarda debounce ve throttle teknikleri kullanılmalı, işleyici içinde DOM okuma ve yazma işlemleri gruplanarak zorunlu yerleşim hesaplamalarından (layout thrashing) kaçınılmalıdır.
DOM Boyutunu ve Render Maliyetini Düşürmek
Binlerce düğümden oluşan DOM ağaçları, her stil ve yerleşim hesaplamasını pahalı hale getirir. Ekranda görünmeyen bölümler için CSS’in content-visibility özelliğinden yararlanmak, uzun listelerde sanallaştırma (virtualization) uygulamak ve gereksiz iç içe elementleri sadeleştirmek sunum gecikmesini kısaltır. Çerçeve tabanlı uygulamalarda gereksiz yeniden render’ları ve hidrasyon maliyetini azaltmak da aynı derecede belirleyicidir.
Sunucu Yanıtını ve Kaynak Yüklemeyi İyileştirmek
İlk sunucu yanıt süresinin kısalması ve render’ı engelleyen kaynakların azalması, sayfa yüklenirken ana iş parçacığının daha erken boşalmasını sağlar. Kullanıcı sayfa tam olarak hazır olmadan etkileşime girmeye başladığı için, yükleme dönemindeki yoğunluk INP’yi doğrudan etkiler. Kritik CSS’in öne alınması, görsellerin ve yazı tiplerinin doğru önceliklendirilmesi bu çalışmanın tamamlayıcı parçalarıdır.
Gerçek Senaryolarda INP Sorunları
Akordeon yapısındaki bir sıkça sorulan sorular alanında, ilk tıklamada yaşanan gecikme tipik bir örnektir. Çoğu zaman sebep, tıklama anında ağır bir betiğin yüklenmesi veya çalıştırılmasıdır. Çözüm, açılma davranışını hafif bir işleyiciyle hemen tetiklemek ve ek hesaplamaları sonraya ertelemektir.
Ürün sayfalarındaki renk veya beden seçimi de benzer şekilde sorun çıkarabilir. Seçim sonrası fiyat, stok ve görsel güncellemeleri tek bir senkron işlemde yapılıyorsa kullanıcı uzun süre değişiklik göremez. Seçilen seçeneğin anında işaretlenmesi, güncellemelerin ise parçalı ve gösterge eşliğinde yapılması hem metriği hem de algılanan hızı iyileştirir. Bu tür varyasyon ve filtre akışlarının yoğun olduğu yapılarda, e-ticaret SEO çalışmalarının nasıl sonuç verdiğini gösteren vaka analizi teknik performans ile organik büyüme arasındaki bağı somut biçimde görmenize yardımcı olabilir.
INP’nin SEO ve Dönüşüm Üzerindeki Etkisi
Core Web Vitals, Google’ın sayfa deneyimi sinyalleri arasında yer alır. INP tek başına sıralamayı belirleyen bir faktör değildir. İçerik uygunluğu ve arama niyeti karşılanmadan yalnızca hız metriklerini düzeltmek sıralama garantisi vermez. Bununla birlikte rekabetin yoğun olduğu sorgularda, benzer kalitedeki sayfalar arasında kullanıcı deneyimi farkı yaratması mümkündür. Kullanıcının beklentisini hızlı karşılayan bir arayüz, arama niyetini doğru okuyan içeriğin değerini de tamamlar.
Asıl etki dönüşüm tarafında görülür. Gecikmeli bir sepete ekleme butonu, tepkisiz bir menü veya geç yanıt veren bir form, kullanıcı güvenini zedeler. Teknik performans çalışmalarını yönetirken metriği tek başına bir hedef olarak değil, görünürlük ve iş sonuçlarıyla birlikte okunacak bir gösterge olarak ele almak daha sağlıklı bir yaklaşımdır.
Teknik Performans ve Yapay Zekâ Botları
Sayfa hızı ve etkileşim performansı, arama motoru botlarının ve yapay zekâ sistemlerinin siteyi nasıl işlediğiyle de dolaylı olarak bağlantılıdır. Ağır JavaScript’e bağımlı, istemci tarafında geç render edilen içerikler hem kullanıcıyı hem de tarayıcıları zorlar. Sunucu tarafında erişilebilir, temiz ve hızlı yapılar kurmak teknik GEO yaklaşımının de temel ilkelerinden biridir. Aynı mantık, mağaza yapılarında e-ticaret siteleri için GEO çalışmalarında da geçerlidir.
INP Optimizasyonu İçin Çalışma Sırası
Dağınık müdahaleler yerine ölçüm odaklı bir sıra izlemek, harcanan geliştirme eforunun karşılığını almayı kolaylaştırır.
- Search Console’da INP açısından sorunlu sayfa gruplarını ve cihaz türünü belirleyin.
- Bu gruplardan temsilci sayfalar seçip DevTools ile gerçek etkileşim senaryolarını kaydedin.
- Giriş gecikmesi, işleme süresi ve sunum gecikmesinden hangisinin baskın olduğunu tespit edin.
- Uzun görevleri bölün, üçüncü taraf betikleri gözden geçirin ve olay işleyicilerini sadeleştirin.
- Değişiklikleri canlıya aldıktan sonra alan verisinin güncellenmesini bekleyin. CrUX verisi 28 günlük bir pencerede toplandığından iyileşme hemen yansımaz.
Teknik değişikliklerin hangisinin nasıl bir etki yarattığını doğru yorumlamak, hem geliştirme hem SEO tarafında deneyim gerektirir. Bu tür çalışmalarda profesyonel SEO hizmeti yaklaşımı, teknik bulguları içerik ve görünürlük stratejisiyle aynı çerçevede değerlendirmeyi mümkün kılar.
INP’yi Doğru Konumlandırmak
INP, sayfanın yalnızca hızlı açılmasını değil, kullanıcı girdilerine tutarlı ve öngörülebilir biçimde yanıt vermesini ölçen bir kalite göstergesidir. 200 milisaniyenin altında kalmak hedef olmalı, ancak bu hedefe ulaşmak için önce hangi etkileşimin neden yavaşladığı veriyle ortaya konmalıdır. Uzun görevlerin bölünmesi, JavaScript yükünün azaltılması, olay işleyicilerinin hafifletilmesi ve DOM’un sadeleştirilmesi birlikte uygulandığında hem Core Web Vitals raporlarındaki durum düzelir hem de ziyaretçilerin siteyle kurduğu etkileşim daha güvenilir hale gelir. Kalıcı
olarak değerlendirilen bu iyileşme, tek seferlik bir düzeltmeyle değil, yayına alınan her yeni bileşenin etkileşim maliyetinin önceden test edilmesiyle sürdürülebilir. Gerçek kullanıcı verisinin düzenli izlenmesi, yeni eklenen üçüncü taraf betiklerin ve arayüz özelliklerinin performans bütçesi içinde kalmasını sağlar. Bu disiplin, sayfa deneyimini rastlantıya bırakmadan ölçülebilir ve yönetilebilir bir kalite standardına dönüştürür.
