Daha iyi bir yanıt verme metriğine yönelik

Duyarlılığı ölçmeyle ilgili düşüncelerimizi öğrenin ve bize geri bildirimde bulunun.

Chrome Hız Metrikleri ekibinde, web sayfalarının kullanıcı girişlerine ne kadar hızlı yanıt verdiğine dair bilgimizi derinleştirmek için çalışıyoruz. Yanıt verme metriklerini iyileştirmeye yönelik bazı fikirleri paylaşmak ve geri bildirimlerinizi öğrenmek istiyoruz.

Bu yayında iki ana konu ele alınacaktır:

1. Mevcut yanıt verme metriğimiz olan First Input Delay (FID) seçeneğini inceleyin ve alternatiflerin bazıları yerine neden FID'yi seçtiğimizi açıklayın.
2. Bağımsız etkinliklerin uçtan uca gecikmesini daha iyi yakalayabilecek, üzerinde durduğumuz bazı iyileştirmeleri sunabiliriz. Bu iyileştirmeler, bir sayfanın kullanım ömrü boyunca genel yanıt verme hızının daha bütünsel bir resmini çekmeyi de hedefler.

First Input Delay nedir?

First Input Delay (FID) metriği, tarayıcının sayfadaki ilk kullanıcı etkileşimini işlemeye başlaması için geçen süreyi ölçer. Özellikle kullanıcının cihazla etkileşimde bulunduğu zaman ile tarayıcının etkinlik işleyicilerini işlemeye gerçekten başlayabildiği zaman arasındaki farkı ölçer. FID yalnızca dokunma ve tuşlara basma için ölçülür, yani aşağıdaki durumların yalnızca ilki dikkate alınır:

• click
• keydown
• mousedown
• pointerdown (yalnızca ardından pointerup geliyorsa)

Aşağıdaki şema FID'yi göstermektedir:

FID, bu etkinlik işleyicileri çalıştırmak için harcanan süreyi veya tarayıcının daha sonra ekranı güncellemek için yaptığı işleri içermez. Bu değer, bir girişi işleme fırsatı bulmadan önce ana iş parçacığının ne kadar meşgul olduğunu ölçer. Bu engelleme süresi genellikle uzun JavaScript görevlerinden kaynaklanır. Zira bu görevler herhangi bir anda durdurulamaz. Dolayısıyla tarayıcının girişi işlemeye başlayabilmesi için mevcut görevin tamamlanması gerekir.

Neden FID'yi seçtik?

Metrikte yapılan iyileştirmelerin kullanıcılara gerçek faydalar sağlaması için gerçek kullanıcı deneyimini ölçmenin önemli olduğuna inanıyoruz. FID metriği, kullanıcının yeni yüklenen bir siteyle etkileşime geçmeye karar verdiği kullanıcı deneyiminin bir kısmını temsil ettiği için FID'yi ölçmeyi seçtik. FID, kullanıcının bir siteyle etkileşiminden bir yanıt görmek için beklemesi gereken sürenin bir kısmını yakalar. Başka bir deyişle FID, kullanıcının etkileşimde bulunduktan sonra beklediği sürenin alt sınırıdır.

Toplam Engelleme Süresi (TBT) ve Etkileşime Hazır Olma Süresi (TTI) gibi diğer metrikler uzun görevlere dayanır ve FID gibi yükleme sırasında ana iş parçacığı engelleme süresini de ölçer. Bu metrikler hem sahada hem de laboratuvarda ölçülebildiğinden birçok geliştirici neden FID yerine bunlardan birini tercih etmediğimizi sordu.

Bunun birkaç nedeni vardır. Belki de en önemli neden, bu metriklerin kullanıcı deneyimini doğrudan ölçmemesidir. Tüm bu metrikler, sayfada ne kadar JavaScript'in çalıştığını ölçer. JavaScript'in uzun süre çalıştırılması sitelerde sorunlara neden olabilse de kullanıcı sayfayla etkileşimde bulunmazsa bu görevler kullanıcı deneyimini mutlaka etkilemez. Bir sayfanın TBT ve TTI açısından çok iyi bir puanı olabilir, ancak yavaş hissedilebilir veya kullanıcılar açısından hızlı hareket ederken kötü bir puana sahip olabilir. Deneyimlerimize göre, bu dolaylı ölçümler bazı siteler için çok iyi sonuçlar verirken, çoğu sitede iyi sonuç vermemektedir. Kısacası, uzun görevlerin ve TTI'nın kullanıcı odaklı olmaması bu adayları daha zayıf hale getirir.

Laboratuvar ölçümü teşhis için son derece önemli ve paha biçilmez bir araç olsa da asıl önemli olan, kullanıcıların siteleri nasıl deneyimlediğidir. Gerçek kullanıcı koşullarını yansıtan kullanıcı merkezli bir metriğe sahip olduğunuzda, deneyimle ilgili anlamlı bir şeyler yakalamanız garanti edilir. Bu kısmın tüm deneyimi yansıtmadığını bilsek de bu deneyimin küçük bir kısmıyla başlamaya karar verdik. Bu nedenle kullanıcının girişlerinin işlenmesini beklediği sürenin daha büyük bir bölümünü yakalamaya çalışıyoruz.

Ne tür iyileştirmeler yapmayı planlıyoruz?

FID'nin günümüzdeki ölçümlerini genişleten ancak kullanıcı deneyimiyle olan güçlü bağını korumaya devam eden yeni bir metrik geliştirmek istiyoruz.

Yeni metrikle ilgili şunları yapmak istiyoruz:

1. Yalnızca ilkini değil, tüm kullanıcı girişlerinin duyarlılığını göz önünde bulundurun
2. Her etkinliğin tam süresini (yalnızca gecikmeyi değil) yakalayın.
3. Aynı mantıksal kullanıcı etkileşiminin bir parçası olarak gerçekleşen etkinlikleri birlikte gruplandırın ve bu etkileşimin gecikmesini, tüm etkinliklerinin maksimum süresi olarak tanımlayın.
4. Bir sayfada, sayfanın tüm kullanım ömrü boyunca gerçekleşen tüm etkileşimler için toplu puan oluşturun.

Başarılı olmak için, bir sitenin bu yeni metrikteki puanı düşükse, kullanıcı etkileşimlerine hızlı yanıt vermediğini yüksek bir güven düzeyiyle söyleyebilmeliyiz.

Tam etkinlik süresini yakalayın

İlk belirgin iyileştirme, etkinlikteki daha geniş uçtan uca gecikmeyi yakalamaya çalışmaktır. Yukarıda belirtildiği gibi, FID yalnızca giriş etkinliğinin gecikme kısmını yakalar. Tarayıcının etkinlik işleyicilerini gerçekten işlemesi için gereken süreyi hesaba katmaz.

Aşağıdaki şemada gösterildiği gibi, bir olayın yaşam döngüsünde çeşitli aşamalar vardır:

Chrome'un bir girişi işlemek için uyguladığı adımlar şunlardır:

1. Kullanıcı girişi gerçekleşir. Bu işlemin gerçekleştiği saat: timeStamp.
2. Tarayıcı, bir etkinliğin hangi HTML çerçevesine (ana çerçeve veya bir iframe) ait olduğuna karar vermek için isabet testi gerçekleştirir. Daha sonra, tarayıcı etkinliği o HTML çerçevesinden sorumlu uygun oluşturucu işlemine gönderir.
3. Oluşturucu etkinliği alır ve kullanılabilir duruma geldiğinde işleyebilmesi için sıraya alır.
4. Oluşturucu, etkinliği işleyicilerini çalıştırarak işler. Bu işleyiciler, giriş işlemenin parçası olan ek eşzamansız işleri (ör. setTimeout ve getirmeler) sıraya alabilir. Ancak bu noktada eşzamanlı çalışma tamamlanmıştır.
5. Ekrana, etkinlik işleyicilerin çalışmasının sonucunu yansıtan bir çerçeve yazılır. Etkinlik işleyiciler tarafından sıraya alınan eşzamansız görevlerin henüz tamamlanmamış olabileceğini unutmayın.

Yukarıdaki (1) ile (3) numaralı adımlar arasındaki süre, bir etkinliğin gecikmesidir. FID metriği bunu ölçer.

Yukarıdaki (1) ile (5) arasındaki adımlar arasında geçen süre bir etkinliğin süresidir. Yeni metriğimiz bunu ölçecek.

Etkinliğin süresi gecikmeyi içerir ancak aynı zamanda etkinlik işleyicilerde gerçekleşen çalışmayı ve tarayıcının bu işleyiciler çalıştırıldıktan sonra bir sonraki kareyi boyamak için yapması gereken işi içerir. Bir etkinliğin süresi şu anda Event Timing API'de girişin duration özelliği aracılığıyla sunulmaktadır.

Etkinlikleri etkileşimler halinde gruplandırma

Metrik ölçümünün gecikme değerinden süre değerine genişletilmesi iyi bir ilk adım olsa da metrikte önemli bir boşluk bırakır: Sayfayla etkileşim kuran kullanıcı deneyimine değil, bireysel etkinliklere odaklanır.

Tek bir kullanıcı etkileşimi sonucunda birçok farklı etkinlik tetiklenebilir ve her birinin ayrı ayrı ölçülmesi, kullanıcının ne yaşadığına dair net bir fikir vermez. Metriğimizin kullanıcının dokunma, tuşlara basma, kaydırma ve sürükleme sırasında yanıt için beklemesi gereken sürenin tamamını yakaladığından emin olmak istiyoruz. Bu nedenle, her birinin gecikmesini ölçmek için etkileşim kavramını kullanıma sunuyoruz.

Etkileşim türleri

Aşağıdaki tabloda, tanımlamak istediğimiz dört etkileşim ve ilişkilendirildikleri DOM etkinlikleri listelenmektedir. Bunun, bu tür bir kullanıcı etkileşimi gerçekleştiğinde gönderilen tüm etkinlikler grubuyla tam olarak aynı olmadığını unutmayın. Örneğin, kullanıcı görünümü kaydırdığında bir kaydırma etkinliği gönderilir ancak bu, ekran kaydırmayı yansıtacak şekilde güncellendikten sonra gerçekleştiğinden, bunu etkileşim gecikmesinin bir parçası olarak değerlendirmeyiz.

Yukarıda listelenen ilk üç etkileşim (klavye, dokunma ve sürükleme) şu anda FID kapsamındadır. Kaydırma web'de son derece yaygın olduğundan ve bir sayfanın kullanıcılara ne kadar duyarlı olduğunun kritik bir yönü olduğundan yeni duyarlılık metriğimize kaydırmayı da dahil etmek istiyoruz.

Klavye

Klavye etkileşiminin iki bölümü vardır: kullanıcının tuşa basması ve serbest bırakması. Bu kullanıcı etkileşimiyle ilişkilendirilmiş üç etkinlik vardır: keydown, keyup ve keypress. Aşağıdaki şemada, bir klavye etkileşimi için keydown ile keyup gecikmeleri ve süreleri gösterilmektedir:

Yukarıdaki şemada, keydown güncellemelerindeki çerçeve keyup gerçekleşmeden önce sunulduğu için süreler ayrıdır, ancak bunun her zaman geçerli olması gerekmez. Buna ek olarak, çerçeveyi üretmek için gereken son adımlar oluşturucu işleminin dışında yapıldığı için çerçevenin oluşturucu sürecindeki bir görevin ortasında sunulabileceğini unutmayın.

keydown ve keypress kullanıcı tuşa bastığında gerçekleşirken keyup, kullanıcı anahtarı bıraktığında gerçekleşir. Genellikle ana içerik güncellemesi tuşa basıldığında gerçekleşir: Metin ekranda görünür veya değiştirici efekti uygulanır. Bununla birlikte, keyup ürününün ilginç kullanıcı arayüzü güncellemeleri sunacağı daha nadir görülen durumları da yakalamak istiyoruz. Bu nedenle, geçen toplam süreyi incelemek istiyoruz.

Klavye etkileşimi tarafından harcanan toplam süreyi yakalamak için keydown ve keyup etkinliklerinin maksimum süresini hesaplayabiliriz.

Dokunun

Diğer bir önemli kullanıcı etkileşimi, kullanıcının bir web sitesine dokunması veya web sitesini tıklamasıdır. Yukarıdaki şemada gösterildiği gibi, keypress işlemine benzer şekilde bazı etkinlikler kullanıcı parmağını bastırdıkça, diğerleri serbest kaldığında tetiklenir. Dokunmayla ilişkilendirilen etkinliklerin masaüstü ve mobil cihazlarda biraz farklı olduğuna dikkat edin.

Dokunma veya tıklama söz konusu olduğunda ise yayın genellikle tepkilerin çoğunu tetikleyen yayındır. Ancak klavye etkileşimlerinde olduğu gibi, etkileşimin tamamını yakalamak isteriz. Bu durumda, düğmeye basıldığında bazı kullanıcı arayüzü güncellemelerinin olması yaygın bir durum olmadığından, bunu yapmak daha önemlidir.

Tüm bu etkinliklerin sürelerini dahil etmek istiyoruz ancak etkinliklerin çoğu tamamen çakıştığından etkileşimi tam olarak kapsamak için yalnızca pointerdown, pointerup ve click değerlerini ölçmemiz gerekiyor.

Sürüklenim

Sürüklemeyi, benzer ilişkili etkinliklere sahip olması ve genellikle sitelerde önemli kullanıcı arayüzü güncellemelerine neden olması nedeniyle de dahil etmeye karar verdik. Ancak metriğimiz için yalnızca sürükleme başlangıcını ve sürüklemenin ilk ve son kısımlarını, yani sürüklemenin son kısmını dikkate almayı amaçlıyoruz. Bunun amacı, hem akıl yürütmeyi kolaylaştırıp gecikmeleri söz konusu diğer etkileşimlerle karşılaştırılabilir hale getirmektir. Bu, mouseover gibi kesintisiz etkinlikleri hariç tutma kararımızla tutarlıdır.

Ayrıca, yalnızca masaüstünde çalıştıkları için Sürükle ve Bırak API'si aracılığıyla uygulanan sürüklemeleri de kabul etmiyoruz.

Kaydırma

Sitelerle etkileşim kurmanın en yaygın biçimlerinden biri sayfayı kaydırmaktır. Yeni metriğimizde, kullanıcının ilk kaydırma etkileşimindeki gecikmeyi ölçmek istiyoruz. Özellikle, kullanıcının kaydırma isteğinde bulunduğu gerçeğine tarayıcının verdiği ilk tepkiyi önemsiyoruz. Kaydırma deneyiminin tamamını ele almayacağız. Yani kaydırma birçok kare üretir ve dikkatimizi bu parşömene tepki olarak üretilen ilk kareye odaklayacağız.

Neden sadece ilki? Birincisi, sonraki kareler ayrı bir akıcılık teklifi ile yakalanabilir. Yani, kaydırmanın ilk sonucu kullanıcıya gösterildikten sonra, gerisi kaydırma deneyiminin ne kadar sorunsuz olacağına göre ölçülmelidir. Dolayısıyla, sorunsuzluk çabasının bunu daha iyi yakalayabileceğini düşünüyoruz. Bu nedenle, FID'de olduğu gibi ayrık kullanıcı deneyimlerine bağlı kalmayı tercih ederiz. Bu deneyimler, zaman içinde kendileriyle ilişkilendirilmiş net noktalar bulunan ve gecikmelerini kolayca hesaplayabildiğimiz kullanıcı deneyimleridir. Bir bütün olarak kaydırma kesintisiz bir deneyimdir. Bu nedenle, bu metrikte tüm kaydırmaları ölçmeyi düşünmüyoruz.

Peki kaydırmaları neden ölçmek gerekir? Chrome'da topladığımız kaydırma performansı, kaydırmanın genellikle çok hızlı olduğunu göstermektedir. Bununla birlikte, çeşitli nedenlerle ilk kaydırma gecikmelerini yeni metriğimize eklemeye devam etmek istiyoruz. Birincisi, kaydırmanın hızlı olmasının nedeni çok önemli olması çünkü çok fazla optimize edilmiş olmasıdır. Ancak, bir web sitesinin tarayıcının sunduğu performans kazançlarından bazılarını atlamasının yolları hâlâ vardır. Chrome'da en yaygın olarak yapılan, kaydırma işleminin ana iş parçacığında yapılmasına zorlamaktır. Metriğimiz bu durumun ne zaman gerçekleştiğini ve kullanıcılar için kaydırma performansının düşük olmasına neden olduğunu söyleyebilmelidir. İkinci olarak, kaydırma göz ardı edilemeyecek kadar önemlidir. Kaydırmayı hariç tutarsak büyük bir kör noktanın ortaya çıkacağından ve kaydırma performansının zamanla web geliştiricileri bunu fark etmeden düşebileceğinden endişe ediyoruz.

Kullanıcı sayfayı kaydırdığında çeşitli etkinlikler (ör. touchstart, touchmove ve scroll) dağıtılır. Kaydırma etkinliği dışında, bu büyük ölçüde kaydırma için kullanılan cihaza bağlıdır: Mobil cihazlarda kaydırma sırasında dokunma etkinlikleri dağıtılırken, tekerlek etkinlikleri fare tekerleği ile kaydırıldığında gerçekleşir. Kaydırma etkinlikleri, ilk kaydırma tamamlandıktan sonra tetiklenir. Genel olarak, web sitesi pasif olmayan etkinlik işleyiciler kullanmadığı sürece hiçbir DOM etkinliği kaydırmayı engellemez. Kaydırmayı, DOM Etkinlikleri'nden tamamen ayrılmış olarak görüyoruz. Ölçmek istediğimiz şey, kullanıcının bir kaydırma hareketi yapmak için yeterli hareket etmesinden, kaydırmanın gerçekleştiğini gösteren ilk kareye kadar geçen süredir.

Etkileşimin gecikmesi nasıl tanımlanır?

Yukarıda belirttiğimiz gibi, kullanıcının parmağını basılı tutarken harcadığı sürenin ilişkilendirilmemesi için, "aşağı" ve "yukarı" bileşenlerine sahip etkileşimlerin ayrı ayrı değerlendirilmesi gerekir.

Bu tür etkileşimlerde, gecikmenin bunlarla ilişkili tüm etkinliklerin sürelerini kapsamasını isteriz. Etkileşimin her bir "aşağı" ve "yukarı" bölümü için etkinlik süreleri çakışabileceğinden, buna ulaşan etkileşim gecikmesinin en basit tanımı, kendisiyle ilişkili herhangi bir etkinliğin maksimum süresidir. Önceki klavye şemasına dönersek, keyup değerinden uzun olduğu için bu keydown süresidir:

keydown ve keyup süreleri de çakışabilir. Bu durum, örneğin her iki etkinlik için sunulan çerçeve aşağıdaki şemadaki gibi aynı olduğunda ortaya çıkabilir:

Maksimum sınırı kullanmaya dair bu yaklaşımın avantajları ve dezavantajları var ve geri bildirimlerinizi öğrenmek istiyoruz:

• Avantajları: Yalnızca tek bir süre değerini ölçtüğünden kaydırmayı ölçme yöntemimize uygundur.
• Avantajı: keyup'nin genellikle hiçbir şey yapmadığı ve kullanıcının tuşa hızlıca veya yavaşça basıp bırakabileceği durumlarda gürültüyü azaltmayı amaçlar.
• Dezavantajı: Kullanıcının bekleme süresinin tamamını kapsamaz. Örneğin, bir sürüklemenin başlangıcını veya bitişini yakalar, ancak ikisini birden yakalayamaz.

Kaydırma (ilişkilendirilmiş tek bir etkinliği olan) için, tarayıcının kaydırma sonucunda ilk kareyi oluşturması için gereken süre olarak gecikmesini tanımlamak istiyoruz. Yani gecikme, bir kaydırmayı tetikleyecek kadar büyük olan ilk DOM etkinliğinin timeStamp olayı (parmağınızı kullanıyorsanız touchmove gibi) ile kaydırmanın yapıldığı ilk boyama arasındaki deltadır.

Sayfa başına tüm etkileşimleri topla

Bir etkileşimin gecikme süresini tanımladıktan sonra, birçok kullanıcı etkileşimi olabilecek bir sayfa yükleme işlemi için toplam değer hesaplamamız gerekir. Toplu bir değere sahip olmak:

• İş metrikleriyle korelasyonlar oluşturun.
• Diğer performans metrikleriyle korelasyonları değerlendirme İdeal olarak, yeni metriğimiz mevcut metriklere değer katmasından yeterince bağımsız olacaktır.
• Araçlardaki değerleri, anlaşılması kolay yöntemlerle kolayca ortaya çıkarın.

Bu toplama işlemini gerçekleştirmek için iki soruyu çözmemiz gerekir:

1. Hangi sayıları toplamaya çalışıyoruz?
2. Bu sayıları nasıl toplarız?

Çeşitli seçenekleri araştırıp değerlendiriyoruz. Bu veri toplama hakkındaki görüşlerinizi bekliyoruz.

Seçeneklerden biri, etkileşimin gecikmesi için türe (kaydırma, klavye, dokunma veya sürükleme) bağlı olabilecek bir bütçe tanımlamaktır. Örneğin, dokunma işlemleri için bütçe 100 ms ve dokunma gecikmesi 150 ms ise bu etkileşim için bütçeyi aşan miktar 50 ms olur. Daha sonra, sayfadaki herhangi bir kullanıcı etkileşimi için bütçeyi aşan maksimum gecikme miktarını hesaplayabiliriz.

Başka bir seçenek de, sayfa ömrü boyunca gerçekleşen etkileşimlerin ortalama veya medyan gecikme süresini hesaplamaktır. Dolayısıyla, 80 ms., 90 ms. ve 100 ms. gecikmelerimiz varsa sayfa için ortalama gecikme 90 ms. olur. Etkileşimin türüne bağlı olarak, farklı beklentileri hesaba katmak için "bütçenin üzerinde" ortalama veya medyan değerini de göz önünde bulundurabiliriz.

Bu, web performans API'lerinde nasıl görünür?

Etkinlik Zamanlaması'nda hangi eksiklikler vardır?

Ne yazık ki bu yayında sunulan fikirlerin tümü Etkinlik Zamanlaması API'si kullanılarak yakalanamaz. Özellikle, API ile belirli bir kullanıcının etkileşimiyle ilişkili etkinlikleri öğrenmenin basit bir yolu yoktur. Bunu yapmak için API'ye bir interactionID eklemeyi önerdik.

Event Timing API'nin bir diğer eksikliği, kaydırma etkileşimini ölçmenin bir yolu olmamasıdır. Bu nedenle, bu ölçümleri etkinleştirme üzerinde çalışıyoruz (Etkinlik Zamanlaması veya ayrı bir API aracılığıyla).

Şu anda ne deneyebilirsiniz?

Şu anda, dokunma/sürükleme ve klavye etkileşimleri için maksimum gecikmeyi hesaplamak hâlâ mümkün. Aşağıdaki kod snippet'i bu iki metriği oluşturur.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

Geri bildirim

Bu fikirler hakkındaki düşüncelerinizi şu adrese e-posta göndererek bizimle paylaşabilirsiniz: web-vitals-feedback@googlegroups.com!