Kısa cevap
INP, bir sayfanın kullanıcı etkileşimlerine görsel yanıt verme gecikmesini değerlendiren etkileşim metriğidir.
Nerede işine yarar?
Girdi gecikmesi, olay işleme ve sonraki çizime kadar bekleme birlikte rol oynar. Uzun görevler, yoğun hesaplama veya büyük render işi yanıtı geciktirebilir. Yalnız açılış hızına bakmak etkileşim sırasında yaşanan sorunu göstermeyebilir.
Tanımdan uygulamaya, kendi denemene.
Bir cümlede uygulaması
Arama alanına yazıldığında yüzlerce kaydı gereksiz yeniden hesaplayan davranışı incelemek.
Neyle karıştırılmamalı?
INP ile laboratuvarda ölçülen Total Blocking Time ilişkili olabilir; aynı metrik değildir.
Dokundun. Ekran seni duydu mu?
Bir ürün listesindeki filtreye basıyorsun. Düğme uzun süre değişmiyor, liste de aynı görünüyor. İşlemin başlayıp başlamadığını anlayamadığın için yeniden basıyorsun. INP, sayfanın kullanıcı etkileşimlerine ne kadar hızlı görsel yanıt verdiğini değerlendiren bir ölçüdür. Yalnız ilk tıklamayı değil, ziyaret boyunca oluşan uygun etkileşimleri ele alır. Hızlı açılan bir sayfanın sonradan ağırlaşması bu yüzden ayrı bir performans konusudur.
Gecikme düğmenin olay işleyicisinden önce başlayabilir. Tarayıcının ana iş parçacığı başka bir uzun işi bitiriyorsa kullanıcının girdisi bekler. Ardından olayla ilgili kod çalışır; son olarak yeni görüntünün çizilebilmesi gerekir. Bu üç bölüm farklı nedenlerle uzayabilir. Büyük bir veri listesini aynı anda hesaplamak, fazla bileşen güncellemek veya gereksiz yerleşim hesapları yapmak benzer hissi üretse de çözüm aynı olmayabilir.
Bir sözlük aramasını düşün. Kullanıcı her harfi yazdığında bütün uzun açıklamaları tarayıcıya taşıyıp yeniden işlemek yerine arama için gereken sınırlı veriler kullanılabilir. Sonuçlar anlaşılır bir boyutta gösterilebilir. Ağ üzerinden sorgu gerekiyorsa bekleme durumu açıkça belirtilir. Böylece hem hesaplama maliyeti hem belirsizlik yönetilir. Kullanıcıya bir yükleniyor işareti göstermek, ağır işi sınırsızca büyütmenin gerekçesi değildir; ikisi birlikte ele alınır.
INP, uzaktaki sunucuda bütün işlemin tamamlanma süresiyle aynı şey değildir. Kullanıcı kaydet dediğinde düğmenin hemen yanıt vermesi ile dosyanın gerçekten saklanması iki ayrı andır. Arayüz bu farkı dürüstçe anlatmalıdır: başladı, sürüyor, tamamlandı veya başarısız oldu. Henüz sonuç gelmeden başarı göstermek hızlı hissettirebilir ama yanlış beklenti yaratır. Etkileşim performansı, teknik süre kadar doğru geri bildirimin zamanlamasını da gerektirir.
Klavye kullanıcısının etkileşimi de aynı tasarım sorumluluğuna dahildir. Bir filtre fareyle hızlı çalışırken klavye odağı sonuç güncellemesinden sonra kayboluyorsa deneyim tamamlanmış değildir. Yeni sonuçları anlaşılır biçimde duyurmak ve odağı kullanıcının görevini sürdürdüğü yerde tutmak gerekir. Bir seçim yalnız küçük bir listeyi değiştirdiğinde tüm sayfayı yeniden kurmak hem gereksiz iş hem yön kaybı yaratabilir. Performans ile erişilebilirlik burada aynı yönde ilerler: değişen alanın kapsamını küçük ve anlamlı tutmak. Hızlı görsel tepkinin yanında hangi bilginin değiştiğini de açıkça göstermek, kullanıcının tekrar tekrar denemesini azaltır.
İşlem başladı ile işlem bitti aynı söz değil.
Hızlı geri bildirim
Kaydet düğmesi basıldığında işlem durumunu gösterir ve tekrar gönderimi uygun biçimde yönetir. Kullanıcı girdisinin alındığını anlar. Bu ilk görsel yanıt etkileşimin akıcılığına katkı sağlar. Ancak sistemin henüz tamamlamadığı bir işi tamamlandı diye sunmamak gerekir; geri bildirim gerçek durumu taşımalıdır.
Gerçek tamamlanma
Sunucunun dosyayı işlemesi veya bir dış hizmetin yanıt vermesi daha uzun sürebilir. Bu sürede ilerleme, bekleme, iptal veya yeniden deneme seçenekleri göreve göre tasarlanır. INP bu uçtan uca iş süresinin yerine geçmez. Ürün deneyimi hem hızlı tepkiyi hem doğru sonuç yönetimini kapsar.
Etkileşimin neden geciktiğini bulmak
INP incelenirken yalnız tıklama işleyicisinin süresine bakılmaz. Ana iş parçacığının önceden meşgul olması ve sonraki görüntünün hazırlanması da gecikmeyi etkileyebilir. Yoğun filtreleme, uzun hesaplama veya büyük DOM güncellemesi gerçek görev sırasında ölçülmelidir.
- Yavaş hissedilen kontrolü gerçek içerik miktarıyla dene.
- Uzun işleri böl veya uygun iş parçacığına taşı.
- İşlem sürerken durum bilgisini geciktirmeden göster.
Hızlı açılan sayfa hızlı etkileşir mi?
Her zaman değil. Yükleme ve etkileşim farklı aşamalardır. İlk görüntü hızlı gelirken filtre veya menü pahalı işlem yapabilir. Bu yüzden yükleme ölçümlerinin yanında kullanıcı eylemleri de değerlendirilir.
İşin içinde sorulacaklar.
İyi INP değeri nasıl okunur?
Core Web Vitals için iyi INP eşiği 200 milisaniye ve altıdır; gerçek ziyaretlerin yüzde 75'lik diliminde değerlendirilir. Tek bir hızlı düğme denemesi bütün sayfanın etkileşim sağlığını açıklamaz. Uzun ziyaretler, farklı cihazlar ve ağır işlemler de tabloya girer. Sonucu yorumlarken hangi etkileşimlerin geciktiğini ve hangi kullanıcı koşullarında sorunun belirginleştiğini araştırmak gerekir.
Her animasyonu kaldırmak gerekir mi?
Hayır. Hafif ve amaca hizmet eden bir hareket, durum değişimini anlaşılır kılabilir. Sorun etkileşimle yarışan ağır iş veya gereksiz çizim maliyetidir. Bir düğmenin renk tepkisiyle tüm ekranı yeniden hesaplatan görsel etki aynı maliyette değildir. Hareketin nasıl üretildiğini, ne zaman başladığını ve hangi alanı etkilediğini incele. Tasarımın kimliğini koruyarak işi küçültmek çoğu zaman mümkündür.
Arama kutusunda debounce her sorunu çözer mi?
Debounce peş peşe gelen girdilerde işi belli bir bekleme sonrasına bırakabilir; özellikle ağ isteği sayısını yönetmekte yararlı olabilir. Fakat büyük bir hesaplamayı yalnız geciktirmek onu hafifletmez. Kullanıcının yazdığı harflerin görünmesi de gecikmemelidir. Girdi geri bildirimiyle sonuç hesaplamasını ayır, veri kapsamını küçült ve bekleme davranışının kullanıcıya nasıl hissettirdiğini düşün. Teknik araç, görevin ihtiyacına hizmet etmelidir.
Sadece güçlü bilgisayarda incelemek yeterli mi?
Güçlü işlemciler pahalı işleri görünmez hâle getirebilir. Daha sınırlı cihazlarda aynı kod belirgin gecikme üretir. Bu nedenle hedef kitlenin cihazları ve gerçek ziyaret verisi önemlidir. Bir animasyon geliştirici bilgisayarında akıcıyken mobilde filtrelemeyi zorlaştırabilir. Tasarım kararı yalnız üretildiği makinenin konforuna göre verilirse kullanıcıların önemli bir bölümü farklı bir ürün deneyimler.
Bir filtreye üç açıdan bak.
Kategori değiştiren bir liste seç. Kullanıcının dokunuşundan yeni sonucun görünmesine kadar olan akışı bekleme, işlem ve çizim diye ayır. Her bölüm için gereksiz işi bulmaya çalış.
Etkileşim, kullanıcının sözüne verilen cevaptır. Önce onu duyduğunu göster; sonra gerekli işi küçük, anlaşılır ve doğru adımlarla tamamla.
Bağlantılı kavramlar
- LCPLCP, sayfanın görünür alanındaki en büyük uygun içerik öğesinin gösterilme zamanını ölçen bir yükleme metriğidir.
- CLSCLS, beklenmeyen yerleşim kaymalarının sayfa deneyimi boyunca oluşturduğu görsel kararsızlığı ölçer.
- HydrationHydration, önceden oluşturulmuş HTML üzerine tarayıcıda uygulamanın etkileşimli davranışlarının bağlanması sürecidir.