INP nedir ve kullanıcı deneyiminde neyi ölçer?

Interaction to Next Paint (INP), bir ziyaretçinin sayfada gerçekleştirdiği tıklama, dokunma ve klavye etkileşimlerinin ardından arayüzün bir sonraki görsel güncellemeyi ne kadar hızlı gösterebildiğini değerlendiren Core Web Vitals metriğidir. Yalnızca ilk etkileşimi ölçen eski First Input Delay yaklaşımından farklı olarak sayfanın yaşam süresindeki etkileşimleri gözlemler ve genel yanıt verebilirliği temsil eden bir değer üretir. Bu nedenle hızlı açılan fakat menüsü, filtresi veya formu geç tepki veren bir sayfa iyi yükleme süresine rağmen zayıf INP gösterebilir.

INP değeri; girdinin işlenmeye başlamasını beklediği süre, olay işleyicilerinin çalışması ve tarayıcının sonucu ekrana sunması için gereken zamanı birlikte yansıtır. web.dev, 75. yüzdelikte ve mobil ile masaüstü ayrı değerlendirilmek üzere 200 milisaniye veya altını iyi, 200–500 milisaniye aralığını iyileştirme gereken, 500 milisaniyenin üzerini zayıf kabul eder. Bu eşikler bir sıralama garantisi değildir; kullanıcıların arayüzü akıcı kullanabilmesi için ortak bir kalite hedefidir.

Önce saha verisini, sonra laboratuvar testini okuyun

INP çalışmasına tek bir Lighthouse ekran görüntüsüyle başlanmamalıdır. Search Console Core Web Vitals raporu ve Chrome User Experience Report gibi saha kaynakları, uygun miktarda verisi bulunan sayfalarda gerçek ziyaretçilerin cihaz, ağ ve kullanım koşullarını toplu biçimde gösterir. Bu veri son 28 günlük hareketli dönemi ve URL gruplarını yansıtabildiği için yapılan düzeltmenin rapora hemen düşmemesi normaldir. Mobil ve masaüstü sonuçlarını, sayfa şablonlarını ve trafik yoğunluğunu ayrı değerlendirmek yanlış önceliklendirmeyi önler.

Laboratuvar testi ise sorunun hangi etkileşimde oluştuğunu tekrar üretmek için kullanılır. Chrome DevTools Performance kaydıyla menü açma, filtre seçme, form doğrulama, sekme değiştirme ve modal kapatma gibi gerçek görevleri tek tek deneyin. Yavaş etkileşimi yalnızca toplam süreyle değil; input delay, processing duration ve presentation delay bölümleriyle inceleyin. Saha verisi sorunun nerede yoğunlaştığını, laboratuvar kaydı ise muhtemel teknik nedeni gösterir; iki veri türü birbirinin yerine değil, birlikte kullanılır.

Uzun görevleri ve gereksiz JavaScript yükünü azaltın

Tarayıcının ana iş parçacığı uzun süre JavaScript çalıştırdığında yeni kullanıcı girdisi sırada bekler. Önce kullanılmayan kütüphaneleri, yinelenen izleme etiketlerini ve ilk görünüm için gerekli olmayan bileşen kodlarını belirleyin. Kod bölme, koşullu yükleme ve sunucu tarafında üretilebilecek içeriği istemciye bırakmama gibi kararlar başlangıç rekabetini azaltır. Üçüncü taraf sohbet, analitik veya reklam betikleri de kendi dosyanız olmasa bile aynı ana iş parçacığını kullandığı için etkileri ölçülmeden sayfaya eklenmemelidir.

Kaldırılamayan büyük işleri daha küçük parçalara ayırmak, tarayıcıya arada kullanıcı girdisini ve görsel güncellemeyi işleme fırsatı verir. Ancak her işi gelişigüzel zamanlayıcıya taşımak doğru değildir; önce gerçekten gereksiz hesaplamayı kaldırın, sonra kalan işi önceliğine göre bölün. Bir arama kutusunda her tuş vuruşunda tüm listeyi yeniden hesaplamak yerine girdiyi sınırlı aralıklarla işlemek veya sonucu daha dar veri üzerinde üretmek daha etkilidir. Amaç ölçümü kandırmak değil, etkileşim anındaki gerçek işi azaltmaktır.

Olay işleyicilerini kısa, öngörülebilir ve görünür geri bildirimli tutun

Bir buton tıklandığında olay işleyicisi ağ isteği, büyük veri dönüşümü, depolama erişimi ve kapsamlı durum güncellemesini aynı blokta yapıyorsa kullanıcı ilk görsel yanıtı geç görür. Etkileşimin zorunlu bölümünü ayırın: butonun durumunu güncelleyin, gerekli erişilebilirlik bilgisini duyurun ve pahalı ikincil işi daha sonra çalıştırın. Ağ yanıtı beklenen işlemlerde yükleniyor göstergesi veya devre dışı durumu hızlıca görünmelidir. Görsel geri bildirim işlemi hızlandırmasa bile belirsizliği azaltır; yine de ölçülen gecikmenin teknik nedenini çözmenin yerini tutmaz.

Event delegation kullanımı çok sayıda benzer öğede dinleyici maliyetini düşürebilir; fakat her projede otomatik çözüm değildir. React benzeri yapılarda gereksiz yeniden render, geniş bağlam güncellemeleri ve her renderda yeniden oluşturulan pahalı hesaplamalar incelenmelidir. Kullanıcı girdisinden sonra değişmesi gerekmeyen bileşenleri sabit tutmak ve state kapsamını daraltmak daha küçük bir render ağacı oluşturur. Optimizasyon öncesi ve sonrası aynı kullanıcı görevini aynı cihaz profiliyle kaydetmek, yapılan değişikliğin gerçekten etkileşime katkısını kanıtlar.

Büyük render ve stil hesaplamalarını kontrol altına alın

INP yalnızca JavaScript çalışma süresi değildir. Bir etkileşim binlerce DOM öğesini değiştiriyor, karmaşık stilleri yeniden hesaplatıyor veya geniş bir alanı yeniden boyuyorsa presentation delay büyüyebilir. Uzun listelerde görünür alanı sınırlamak, DOM boyutunu makul tutmak ve tek etkileşimde gereksiz sınıf değişikliklerini azaltmak önemlidir. Tarayıcıyı düzen bilgisini hesaplamaya zorlayan ardışık okuma-yazma kalıpları da layout thrashing oluşturabilir; ölçüm ve güncellemeleri gruplayarak bu tekrarlar azaltılmalıdır.

Animasyonlarda transform ve opacity gibi kompozitör dostu özellikler çoğu durumda top, left, width veya height değişimlerine göre daha az düzen maliyeti üretir. Buna rağmen gereksiz ve sürekli animasyonlar kaldırılmalı, kullanıcının azaltılmış hareket tercihi gözetilmelidir. Açılır menü, akordeon ve filtre paneli gibi sık kullanılan parçalar düşük donanımlı mobil cihaz profillerinde test edilmelidir. Güçlü bir geliştirme bilgisayarındaki akıcı deneyim, gerçek ziyaretçi kitlesinin tamamını temsil etmez.

Üçüncü taraf kodu iş hedefiyle birlikte yönetin

Etiket yöneticisi üzerinden zamanla eklenen pazarlama araçları INP sorunlarının görünmeyen kaynağı olabilir. Her etiket için sahibi, amacı, tetiklenme koşulu, veri gereksinimi ve performans bütçesi kaydedilmelidir. Sayfa açılışında çalışması gerekmeyen bir müşteri destek aracı kullanıcı niyeti oluştuğunda yüklenebilir; aynı olayı birden fazla analitik aracına gönderen kopya kodlar kaldırılabilir. Bir etiketi geciktirirken ölçüm doğruluğu, izin yönetimi ve hukuki yükümlülükler birlikte değerlendirilmelidir.

Performans bütçesi yalnızca toplam dosya boyutu olarak tanımlanmamalıdır. Etkileşim anındaki uzun görev sayısı, belirli bir bileşenin işlem süresi ve ana iş parçacığına eklenen üçüncü taraf maliyeti de kabul ölçütü olabilir. Yeni bir araç yayına alınmadan önce temsilî sayfalarda temel ölçüm alın, aracı ekleyin ve aynı senaryoyu yeniden çalıştırın. Değer üretmeyen veya ölçülebilir biçimde deneyimi bozan kodun kaldırılması, çoğu mikro optimizasyondan daha güçlü sonuç verir.

INP iyileştirmesini yayın ve izleme döngüsüne bağlayın

Önceliklendirme için yüksek trafik alan ve gelir, başvuru ya da iletişim gibi önemli görevleri taşıyan şablonlardan başlayın. Her sorun kaydında yavaş etkileşim, etkilenen URL grubu, cihaz türü, saha metriği, laboratuvar izi, sorumlu ekip ve beklenen teknik değişiklik yer alsın. Bir seferde çok sayıda değişiklik yapmak hangi müdahalenin etkili olduğunu belirsizleştirir. Küçük, geri alınabilir sürümler ve aynı senaryoya dayalı karşılaştırmalar daha güvenilir bir öğrenme döngüsü kurar.

Canlıya çıktıktan sonra hata oranı, dönüşüm olayları ve erişilebilirlik davranışı performansla birlikte kontrol edilmelidir. Daha düşük INP uğruna form doğrulamasını, klavye erişimini veya güvenlik kontrolünü bozmak kabul edilemez. Saha verisinin yenilenmesi için yeterli süre tanıyın; bu sırada yeni uzun görevleri geliştirme ortamında ve gerçek kullanıcı izleme sisteminde takip edin. Google da iyi Core Web Vitals değerlerinin tek başına üst sıralama garantisi olmadığını açıkça belirtir; hedef, faydalı içeriğe hızlı ve güvenilir erişim sağlamaktır.

Kalıcı INP başarısı için teknik özet

Sağlam bir INP planı ölçüm, teşhis, azaltma ve doğrulama sırasını izler. Önce 75. yüzdelikteki saha verisiyle problemli şablonu belirleyin; ardından gerçek kullanıcı görevini laboratuvarda kaydedin. Gecikmenin girdi bekleme, işlem veya sunum bölümünde yoğunlaştığını görün. Gereksiz JavaScript'i kaldırın, uzun görevleri bölün, olay işleyicilerini kısaltın, render kapsamını daraltın ve üçüncü taraf kodunu yönetin. Son olarak aynı etkileşimi tekrar ölçüp işlev, erişilebilirlik ve iş sonuçlarını birlikte doğrulayın.

Fırat Averbek’in özel web tasarımı ve ileri düzey SEO yaklaşımında performans, yayından sonra alınan tek bir puan değil; tasarım sistemi, içerik mimarisi ve geliştirme kararlarının ortak kabul kriteridir. Kesin sıralama veya dönüşüm vaadi yerine ölçülebilir kullanıcı deneyimi hedefleri konur. Fırat Averbek imzasıyla hazırlanan bu rehberin pratik sonucu şudur: en kötü puanın peşinden körlemesine koşmayın; gerçek kullanıcının en önemli görevini yavaşlatan işi bulun ve kanıtla azaltın.

İlgili Fırat Averbek kaynakları

Fırat Averbek özel ve 3D web tasarımı: Animasyon, etkileşim ve görsel kaliteyi ölçülebilir performans hedefleriyle birlikte planlayın.

Fırat Averbek ileri düzey SEO hizmeti: Core Web Vitals, taranabilirlik ve içerik sinyallerini ortak teknik yol haritasında yönetin.

JavaScript SEO ve indeksleme rehberi: İstemci kodunun render, sunucu HTML'i ve arama motoru keşfi üzerindeki etkisini inceleyin.

Site taşıma SEO kontrol listesi: Yeni altyapıya geçerken performans ve indeksleme sinyallerini birlikte koruyun.

Resmî kaynaklar

Bu rehber hazırlanırken aşağıdaki resmî ve birincil kaynaklar makalenin yayın veya son güncelleme tarihinde kontrol edilmiştir.

Sık sorulan sorular

Bu rehber hangi standarda göre hazırlanmıştır?

Metin; doğrulanabilir kaynak, açık yöntem, insan editoryal incelemesi ve yanıltıcı sonuç garantilerinden kaçınma ilkeleriyle hazırlanmıştır.

Bilgiler uygulama kararı için tek başına yeterli mi?

Hayır. Teknik, hukuki veya ticari kararlar güncel koşullar ve yetkili uzman görüşüyle doğrulanmalıdır.