Microsoft Clarity'yi, Switas gibi şirketlerin karşılaştığı zorlukları anlayan gerçek ürün geliştiriciler tarafından, pratik ve gerçek dünya kullanım senaryoları göz önünde bulundurularak geliştirilmiş bir ürün olarak öne çıkardık. Öfkeli tıklamaları ve JavaScript hata izleme gibi özellikler, kullanıcı hayal kırıklıklarını ve teknik sorunları belirlemede, kullanıcı deneyimini ve dönüşüm oranlarını doğrudan etkileyen hedefli iyileştirmeler sağlamada paha biçilmez olduğunu kanıtladı.
Sonraki Boyayla Etkileşim (INP)
Etkileşimden Sonraki Boyamaya Kadar Olan Süre, bir sayfanın kullanıcı girdisine görsel olarak ne kadar hızlı yanıt verdiğini ölçer ve bir ziyaret sırasında yaşanan en kötü etkileşim gecikmelerini temsil eden bir değer bildirir. Mart 2024'te Temel Web Yaşam Ölçütleri yanıt verme metriği olarak İlk Giriş Gecikmesinin yerini aldı ve değişiklik önemliydi: eski ölçüm yalnızca ilk etkileşimde işleme başlamadan önceki gecikmeyi yakalarken, bu yeni ölçüm oturumdaki tüm etkileşimler boyunca girişten işleme ve bir sonraki karenin boyanmasına kadar geçen tam süreyi ölçer.
Bu fark önemlidir çünkü önceki ölçüt birçok siteyi olduğundan daha iyi gösteriyordu. Bir sayfa, ilk giriş gecikmesinde mükemmel bir değer kaydederken, sayfa boyunca yavaş kalabiliyordu; çünkü bu ölçüt, olay işleyicisinin ne kadar sürede çalıştığını ve tarayıcının sonucu ne kadar sürede oluşturduğunu göz ardı ediyordu ve yalnızca tek bir etkileşime bakıyordu. Eski ölçüte göre duyarlı görünen siteler, özellikle tek sayfa uygulamaları ve yoğun istemci tarafı mantığı içeren arayüzler, yeni ölçüte göre genellikle duyarlı görünmüyor.
Bildirilen değer, gözlemlenen en uzun etkileşimlerden elde edilir ve çok sayıda etkileşimin olduğu sayfalardaki aykırı değerler dikkate alınır. Google'ın yayınladığı eşik değeri ise 200 milisaniye veya daha azını gerçek kullanıcı deneyimlerinin yetmiş beşinci yüzdelik diliminde iyi olarak kabul eder. Girişten boyamaya kadar tüm yolu kapsadığı için, düşük puanlar çeşitli noktalardan kaynaklanabilir: ana iş parçacığında uzun süren görevlerin tarayıcının olayı işlemesini engellemesi, olay işleyicilerinin eşzamanlı olarak aşırı iş yapması, stillerin iç içe geçmiş bir şekilde okunması ve yazılmasından kaynaklanan düzen karmaşası ve durum değişikliklerinden sonra pahalı işleme.
Teşhis genellikle ağ koşullarından ziyade JavaScript yürütülmesine işaret eder; bu da bu metriği yükleme ölçümlerinden ayırır. Yaygın nedenler arasında ana iş parçacığında çalışan büyük, monolitik paketler, etkileşim sırasında rastgele işler yürüten üçüncü taraf komut dosyaları, değişikliğin gerektirdiğinden çok daha fazla ağacı etkileyen çerçeve yeniden oluşturmaları ve ertelenebilecek veya ana iş parçacığından taşınabilecek eşzamanlı hesaplamalar gerçekleştiren işleyiciler bulunur. Çoğu durumda altta yatan mekanizma uzun süren görevlerdir, çünkü bir görev çalışırken tarayıcı girdiye yanıt veremez.
Teşhisin ardından düzeltme yapılır. Uzun görevleri açıkça veri işleme seçeneğiyle daha küçük parçalara bölmek, tarayıcının aralarındaki girdileri işlemesine olanak tanır. Kullanıcının yanıtı hemen görmesi için, görsel güncellemeden sonraya kadar gereksiz işleri ertelemek en yaygın sorunu ele alır. Gönderilen JavaScript miktarını azaltmak, üçüncü taraf komut dosyalarını ana iş parçacığı maliyeti açısından denetlemek, uzun listeleri sanallaştırmak ve ağır hesaplamaları bir işçiye taşımak, her biri belirli nedenleri ele alır. Yavaş işlemler için anında görsel geri bildirim sağlamak, ölçülen değeri iyileştirmez ancak gecikmenin nasıl deneyimlendiğini değiştirir.
Üçüncü taraf komut dosyaları, sık karşılaşılan bir sorun kaynağı oldukları ve ekibin doğrudan kontrolü dışında oldukları için özel bir incelemeyi hak etmektedir. Sohbet widget'ları, onay yöneticileri, analiz kütüphaneleri, kişiselleştirme araçları ve reklam komut dosyaları ana iş parçacığında çalışır ve ziyaretçinin etkileşim kurmaya çalıştığı anlarda bu iş parçacığını meşgul edebilir. Her bir üçüncü tarafın ana iş parçacığı maliyetini denetlemek, ideal olarak sayfanın bu araçla ve onsuz durumunu ölçerek, her bir satıcının yanıt verme açısından maliyetinin somut bir listesini oluşturur. Bu rakam, her aracı talep eden ekiplerle bu dengeyi tartışmayı mümkün kılar; bu da genellikle mevcut bütçenin çoğunu tüketen bir komut dosyası etrafında uygulama kodunu optimize etmeye çalışmaktan daha verimli bir yoldur.
Bu ölçüt, varlık teslimatından ziyade uygulama koduna dayalı olduğundan, iyileştirilmesi genellikle yapılandırmadan ziyade mühendislik çalışması gerektirir. Pratikte, bu ölçüt, varlık teslimatı ile uygulama kodu arasındaki sınırda yer alır. web performansı hem de ürün geliştirmeBu durum özellikle etkileşimli ticaret ve rezervasyon arayüzleri için önemlidir; zira yanıt vermeyen filtreleme, yapılandırma ve sepet etkileşimleri, analitiklerde belirgin bir neden olmaksızın sıradan terk etme olarak görünen bir durum yaratır.
Switas'ın Görüldüğü Gibi
