INP nedir, web sitesinde nasıl düzeltilir?

INP, web sitesinde bir kullanıcı etkileşimine görsel yanıt verilene kadar geçen süreyi ölçen Core Web Vitals metriğidir. Buton, form, menü ve sekme gecikmelerini belirlemek için kullanılır.

Bir ziyaretçi butona bastığında ekran hemen tepki vermiyorsa sorun yalnızca internet bağlantısı olmayabilir. Uzun JavaScript görevleri, ağır üçüncü taraf kodları ve gereksiz DOM işlemleri gecikmeye neden olabilir.

INP düzeltmesi, önce gecikmeli etkileşimi bulmayı, sonra tarayıcının ana iş parçacığını rahatlatmayı gerektirir. Sadece görsel sıkıştırmak veya sunucuyu hızlandırmak her INP sorununu çözmez.

INP nedir ve web sitesinde neyi ölçer?

INP, sayfadaki kullanıcı etkileşimlerinin işlenme ve ekranda yanıtlanma süresini ölçer. Kullanıcının tıklama, dokunma veya klavye işlemi sonrasında oluşan görsel değişiklik değerlendirilir.

Ölçüm; etkileşimin giriş gecikmesi, olay işleme süresi ve sunum gecikmesi bileşenlerinden oluşur. Tarayıcı önce olayı kuyruğa alır, JavaScript kodunu çalıştırır ve ardından yeni görünümü ekrana taşır.

Örneğin mobil menü düğmesine dokunulduğunda menü 800 milisaniye sonra açılıyorsa kullanıcı bunu doğrudan hisseder. Lighthouse tek bir etkileşimi gösterebilir, gerçek kullanıcı verileri ise farklı cihazları karşılaştırır.

INP değeri, sayfa boyunca gerçekleşen etkileşimlerin yanıt süresini değerlendirir. Google sınıflandırmasında 200 milisaniye ve altı iyi, 200 ile 500 milisaniye arası geliştirilmesi gereken, 500 milisaniye üzeri zayıf kabul edilir.

Bu eşikler, laboratuvar sonucundan çok gerçek kullanıcı deneyimini yorumlamak için kullanılır. Yavaş bir telefon, yoğun işlemci kullanımı veya düşük bağlantı koşulları sonucu değiştirebilir.

INP, yalnızca ilk açılış hızını göstermez. Sayfa açıldıktan sonra kullanılan filtre, ödeme, arama, açılır menü ve form gibi bileşenlerin yanıtını da görünür hale getirir.

INP ile FID arasındaki fark nedir?

INP, sayfadaki etkileşimlerin genel yanıt performansını ölçerken FID yalnızca ilk kullanıcı etkileşiminin gecikmesini ölçüyordu. Bu nedenle INP, etkileşim deneyimini daha geniş değerlendirir.

FID, kullanıcının ilk tıklamasından JavaScript olayının başlamasına kadar geçen süreyi izlerdi. Olay başladıktan sonra ekranın ne zaman güncellendiğini kapsamlı biçimde ölçmezdi.

INP ise etkileşim tamamlanıp tarayıcı yeni görünümü oluşturana kadar geçen süreci dikkate alır. Bu fark, çalışan fakat ekranı geç güncelleyen JavaScript kodlarını yakalamayı kolaylaştırır.

Örneğin bir filtre düğmesi tıklamayı hemen algılayabilir. Ancak 2.000 ürün kartını aynı anda yeniden oluşturuyorsa kullanıcı sonuçları uzun süre göremez.

Bu durumda FID düşük görünebilir, fakat INP yüksek çıkabilir. Sorun olayın başlamasında değil, olay sonrasında yapılan yoğun hesaplama ve çizim işlemlerindedir.

Yanlış: “İlk tıklama hızlı olduğu için etkileşim performansı iyidir.” Doğru: “Kullanıcının yaptığı etkileşimlerin ekranda ne kadar sürede sonuçlandığı incelenmelidir.”

Bu ayrım, optimizasyon önceliğini değiştirir. Sadece ilk açılış komutlarını değil, kullanıcı etkileşimlerinden sonra çalışan tüm görevleri incelemek gerekir.

INP değeri nasıl ölçülür?

INP ölçümü için PageSpeed Insights, Chrome DevTools, Lighthouse ve Chrome User Experience Report verileri birlikte kullanılabilir. Her araç farklı bir gözlem türü sunar.

PageSpeed Insights, laboratuvar testini ve mevcutsa gerçek kullanıcı verisini ayrı gösterir. Gerçek kullanıcı verisi yoksa sonuç, belirli bir alan adı veya sayfa için sınırlı olabilir.

Chrome DevTools içinde Performance panelini açarak sayfayı kaydedin. Ardından sorunlu butona, forma veya menüye birkaç kez tıklayın.

Kaydı durdurduktan sonra uzun görevleri, olay işleyicilerini ve yeniden çizim işlemlerini inceleyin. 50 milisaniyeden uzun ana iş parçacığı görevleri, etkileşim sırasında gecikme oluşturabilir.

Lighthouse etkileşim gecikmesini laboratuvar koşullarında gösterir. Bu sonuç, gerçek kullanıcıların eski telefonlarını veya yoğun ağ koşullarını tam olarak temsil etmeyebilir.

Gerçek veriyi yorumlarken yalnızca ortalamaya bakmayın. Yavaş cihazların deneyimini görmek için dağılımın 75. yüzdelik değerini ve sayfa türlerini karşılaştırın.

Ölçümü ana sayfayla sınırlamayın. Ürün listeleme, ürün detay, sepet, iletişim formu ve ödeme gibi etkileşim yoğun sayfaları ayrı test edin.

Web sitesinde 404 hatalarını bulma çalışması, INP ölçümünün yerine geçmez. Ancak kırık istekler ve başarısız bileşen yüklemeleri, etkileşim akışını bozabileceği için ayrıca kontrol edilmelidir.

INP neden yükselir?

INP genellikle ana iş parçacığını uzun süre meşgul eden JavaScript görevleri nedeniyle yükselir. Tarayıcı bu sırada yeni tıklamaları işleyemez veya ekranı güncelleyemez.

En yaygın nedenlerden biri, bir etkileşimden sonra büyük bir listeyi tamamen yeniden oluşturmaktır. Filtre değişiminde yüzlerce kartın tekrar hesaplanması buna örnek verilebilir.

Üçüncü taraf kodları da gecikme oluşturabilir. Analiz araçları, sohbet kutuları, reklam etiketleri, kişiselleştirme sistemleri ve harici widget'lar ana iş parçacığını kullanabilir.

Gereksiz DOM büyüklüğü başka bir etkendir. Çok sayıda iç içe öğe, stil hesaplama ve yeniden çizim maliyetini artırır.

Olay dinleyicilerinin her tıklamada yeniden tanımlanması da performansı düşürebilir. Aynı işin birden fazla kez tetiklenmesi, özellikle mobil cihazlarda belirgin gecikme yaratır.

Beklenmeyen düzen değişiklikleri, görsel yükleme sırası ve senkron ağ istekleri de etkileşimi yavaşlatabilir. Kullanıcı işlemi sırasında ağ yanıtı beklemek, çoğu arayüzde riskli bir yaklaşımdır.

Animasyonlar da incelenmelidir. Yüksek maliyetli CSS özellikleri veya JavaScript ile sürekli konum hesaplama, etkileşim sonrasındaki boyama süresini uzatabilir.

Bu nedenler her sitede aynı ağırlıkta görülmez. Profil kaydı alınmadan yapılan genel değişiklikler, gerçek darboğazı çözmeden başka sorunlar doğurabilir.

JavaScript INP sorununu nasıl azaltır?

JavaScript kaynaklı INP sorununu azaltmak için uzun görevleri bölmek, gereksiz kodu kaldırmak ve kritik olmayan çalışmaları ertelemek gerekir.

Önce Performance kaydında uzun görevin hangi dosyadan geldiğini bulun. Fonksiyon adını, kaynak dosyasını ve tetikleyen etkileşimi not edin.

1. 50 milisaniyeyi aşan görevleri listeleyin.
2. Her görevin hangi buton, form veya menüyle başladığını belirleyin.
3. Büyük döngüleri küçük parçalara ayırın.
4. Kritik olmayan işleri etkileşim sonrasına veya boşta kalma zamanına taşıyın.
5. Aynı ölçümü tekrarlayıp INP ve görev süresini karşılaştırın.

Uzun bir döngüyü tek seferde çalıştırmak yerine işi parçalara bölmek, tarayıcıya yeni etkileşimleri işleme fırsatı verir. Bunun için uygun durumlarda zamanlayıcılar veya tarayıcının boşta çalışma API'leri kullanılabilir.

Kullanıcının görmesi gereken ilk sonucu önce üretin. Ayrıntılı sıralama, analitik kayıt veya ikincil hesaplamaları daha sonra çalıştırın.

JavaScript paketlerini de küçültün. Kullanılmayan kütüphaneleri kaldırın, kod bölme uygulayın ve yalnızca ilgili sayfada gereken modülleri yükleyin.

Web worker, yoğun hesaplamaları ana iş parçacığından ayırabilir. Ancak arayüz güncellemesi yine ana iş parçacığında yapılır; bu nedenle worker her sorunu tek başına çözmez.

Event listener kodunu da inceleyin. Aynı işlevin birden fazla dinleyiciyle çalışması, tek tıklamada gereksiz tekrarlar oluşturabilir.

Buton ve form gecikmesi nasıl düzeltilir?

Buton ve form gecikmesini düzeltmek için etkileşim sırasında yapılan işin kapsamı küçültülmeli, kullanıcıya erken görsel geri bildirim verilmelidir.

Bir butona basıldığında önce durum değişikliğini gösterin. Örneğin düğmeyi pasifleştirin, yükleniyor durumunu ekleyin veya hata mesajı alanını güncelleyin.

Ardından ağ isteğini ve ikincil hesaplamaları yönetin. Kullanıcı, işlem başladığını 100 milisaniye içinde görebiliyorsa gecikmeyi daha az sorun olarak algılar; ancak teknik INP değeri yine ölçülmelidir.

Formlarda her tuş vuruşunda ağır doğrulama çalıştırmak yerine uygun bir bekleme yaklaşımı kullanın. Özellikle arama ve adres alanlarında her karakter için büyük veri işlemi yapılmamalıdır.

Filtreli listelerde tüm sonuçları yeniden çizmek yerine yalnızca değişen bölümü güncelleyin. Sanal liste yaklaşımı, ekranda görünmeyen çok sayıda öğenin oluşturulmasını azaltabilir.

Modal pencere açılırken arka plandaki sayfanın tamamını yeniden düzenlemeyin. Sadece görünür paneli oluşturun ve gereksiz animasyonları azaltın.

Form gönderiminde doğrulama mesajlarının erişilebilir olduğundan emin olun. WCAG 2.2 AA uyum kontrolü, yalnızca klavye erişimini değil, hata mesajlarının anlaşılır sunulmasını da incelemeye yardımcı olur.

Gecikme her zaman koddan kaynaklanmaz. Formun bağlı olduğu üçüncü taraf servis geç yanıt veriyorsa arayüz, ağ sonucunu beklemeden işlem durumunu göstermelidir.

Görseller ve üçüncü taraf kodlar INP'yi nasıl etkiler?

Görseller ve üçüncü taraf kodlar, doğrudan etkileşim sırasında çalıştığında INP'yi yükseltebilir. Bu nedenle yükleme zamanını ve çalışma zamanını ayrı değerlendirin.

Görseller genellikle INP'nin ana nedeni değildir, fakat büyük görsel işleme işlemleri tarayıcıyı meşgul edebilir. Boyutları belirlenmiş, uygun formatta ve ihtiyaca göre yüklenen görseller daha az kaynak tüketir.

Web sitesinde AVIF görsel kullanımı, dosya boyutunu azaltmaya yardımcı olabilir. Ancak AVIF kullanmak, büyük DOM yapısını veya uzun JavaScript görevini tek başına düzeltmez.

Reklam, analiz, sohbet ve kişiselleştirme kodlarını envanter halinde çıkarın. Her kod için sağlayıcı, yüklenme zamanı, çalıştırdığı fonksiyon ve kaldırıldığında oluşan etkiyi kaydedin.

Üçüncü taraf etiketi kullanıcı tıklamasından hemen sonra çalışıyorsa gecikme yaratabilir. Etiketin olay sonrasında ertelenmesi veya yalnızca gerekli sayfalarda yüklenmesi daha kontrollü bir çözüm olabilir.

Ancak ölçüm veya reklam etiketini rastgele kaldırmayın. Önce hangi iş verisinin kaybolacağını ve ilgili pazarlama akışının etkilenip etkilenmeyeceğini belirleyin.

Web yazı tipleri de etkileşim sonrasında yeniden düzenleme oluşturabilir. Kullanılan ağırlıkları azaltın, yazı tipi değişimini kontrol edin ve görünür metinlerin beklemesini önleyin.

Görsel optimizasyonu için web sitesinde erişilebilirlik kontrollerini de birlikte yürütün. Daha hafif bir bileşen, erişilebilir etiketleri veya klavye davranışını bozuyorsa çözüm tamamlanmış sayılmaz.

INP düzeltmesi için hangi yöntemler karşılaştırılmalı?

INP düzeltmesinde yöntem seçimi, gecikmenin kaynağına göre yapılmalıdır. Ağ yanıtı, JavaScript, DOM ve görsel çizim sorunları aynı müdahaleyi gerektirmez.

Tablodaki çözümler başlangıç noktasıdır. Aynı sayfada iki veya daha fazla sorun birlikte bulunabilir.

Örneğin büyük bir ürün filtresi, hem JavaScript hesaplaması hem de DOM yenilemesi yapabilir. Sadece görselleri küçültmek, bu durumda ölçülebilir bir iyileşme sağlamayabilir.

Bir değişiklikten sonra önce aynı cihaz sınıfında tekrar ölçüm yapın. Ardından farklı mobil cihazlarda ve gerçek kullanıcı verisinde sonucu doğrulayın.

INP düşerken hata oranı artıyorsa optimizasyon başarılı değildir. Özellikle ödeme, form ve hesap işlemlerinde hız ile doğruluk birlikte takip edilmelidir.

Ayrıca masaüstü sonucunu mobil sonuçla karıştırmayın. Mobil işlemciler, aynı JavaScript görevini daha uzun sürede tamamlayabilir.

INP için yayın öncesi kontrol listesi nedir?

Yayın öncesi INP kontrolü, kritik etkileşimlerin ölçülmesi ve işlev kaybı olmadığının doğrulanmasıyla tamamlanır.

• Mobil menü açılışı farklı cihazlarda test edildi mi?
• Form gönderiminde erken görsel geri bildirim var mı?
• Filtre ve arama işlemleri 50 milisaniyeyi aşan görev oluşturuyor mu?
• Üçüncü taraf etiketler etkileşim sırasında çalışıyor mu?
• Görünmeyen liste öğeleri gereksiz yere oluşturuluyor mu?
• Klavye ve ekran okuyucu kullanıcıları aynı geri bildirimi alıyor mu?
• Değişiklikten sonra PageSpeed Insights ve DevTools sonuçları karşılaştırıldı mı?
• Hata oranı, dönüşüm akışı ve form tamamlanma oranı ayrıca izlendi mi?

Bu liste yalnızca performans kontrolü değildir. Etkileşimin doğru çalışması, hata mesajının görünmesi ve klavye odağının korunması da aynı test planında yer almalıdır.

Her etkileşim için başlangıç ve bitiş koşulunu yazılı hale getirin. “Buton hızlı” yerine “Tıklamadan sonra yükleniyor durumu görünür ve form sonucu güncellenir” gibi ölçülebilir bir tanım kullanın.

Kontrolü tek bir tarayıcıda yapmak yeterli değildir. En az bir masaüstü ve bir mobil cihaz sınıfında, mümkünse farklı işletim sistemlerinde test yapın.

Üretim ortamındaki kodu da inceleyin. Geliştirme ortamında kapalı olan analiz, reklam veya sohbet kodları canlı sitede INP sonucunu değiştirebilir.

Bir performans değişikliğini aşamalı yayınlamak daha güvenlidir. Önce sınırlı sayfada ölçün, sonra tüm siteye uygulayın.

INP düzeltmesi nasıl kalıcı olarak izlenir?

INP'yi kalıcı olarak izlemek için sayfa türü, cihaz grubu ve kritik etkileşim bazında düzenli ölçüm yapılmalıdır.

Aylık tek bir PageSpeed testi, zaman içindeki değişimi açıklamak için yeterli değildir. Yeni bir kampanya etiketi, tema güncellemesi veya JavaScript paketi sonucu değiştirebilir.

Önce kritik sayfaları sınıflandırın. Ana sayfa, ürün detay, sepet, iletişim formu ve ödeme akışı farklı etkileşim risklerine sahiptir.

Her sayfa için en önemli üç etkileşimi belirleyin. Örneğin ürün detayında galeri, varyant seçimi ve sepete ekleme; iletişim sayfasında alan doğrulama, dosya yükleme ve gönderim olabilir.

Gerçek kullanıcı verisinde düşüş başladığında sürüm geçmişini kontrol edin. Sorun belirli bir yayınla aynı dönemde ortaya çıktıysa ilgili JavaScript değişikliklerini ve üçüncü taraf kodlarını karşılaştırın.

INP iyileşirken başka Core Web Vitals metriklerini bozmayın. Büyük bir scripti ertelemek ilk açılışı iyileştirebilir, fakat gerekli etkileşimi kullanılmaz hale getirebilir.

Mobil kullanıcıların oranı yüksekse önceliği mobil etkileşimlerden başlatın. Buton, menü ve form işlemleri, masaüstünde fark edilmeyen gecikmeleri mobilde daha görünür hale getirir.

Performans raporuna yalnızca puan eklemeyin. Etkilenen URL, etkileşim türü, cihaz grubu, kaynak dosya ve uygulanan değişikliği kaydedin.

İnceleme sırasında erişilebilirlik, 404 ve görsel dosya kontrollerini de ayrı başlıklar olarak takip edin. Böylece tek bir metriği düzeltirken kullanıcı akışındaki diğer sorunlar gözden kaçmaz.