First Input Delay (FID)

İyi bir ilk izlenim yaratmanın ne kadar önemli olduğunu hepimiz biliriz. Hem yeni insanlarla tanışmak hem de web'de deneyim oluşturmak açısından çok önemlidir.

Web'de iyi bir ilk izlenim, birinin sadık bir kullanıcı olması veya ayrılıp bir daha geri dönmemesi arasında fark yaratabilir. Soru şudur: İyi bir izlenim neden oluşur ve kullanıcılarınızda yaratmış olabileceğiniz gösterimi nasıl ölçersiniz?

Web'de ilk izlenimler pek çok farklı biçimde görülebilir. Bir sitenin tasarımı ve görsel çekiciliğiyle ilgili ilk izlenimlerin yanı sıra hızı ve yanıt verebilirliğiyle ilgili ilk izlenimleri de ediniriz.

Web API'leriyle kullanıcıların bir sitenin tasarımını ne kadar beğendiğini ölçmek zor olsa da hızını ve yanıt verebilirliğini ölçmek doğru değildir.

Kullanıcıların sitenizin ne kadar hızlı yüklendiğine dair ilk izlenimleri First Contentful Paint (FCP) ile ölçülebilir. Ancak, sitenizin pikselleri ekrana ne kadar hızlı boyayabileceği, hikayenin sadece bir parçasıdır. Aynı derecede önemli olan ise, kullanıcılar bu piksellerle etkileşim kurmaya çalıştığında sitenizin ne kadar duyarlı olduğudur!

First Input Delay (FID) metriği, sitenizin etkileşim ve yanıt verme düzeyiyle ilgili kullanıcınızın ilk izlenimini ölçmeye yardımcı olur.

FID nedir?

FID, kullanıcının bir sayfayla ilk kez etkileşimde bulunmasından (yani bir bağlantıyı tıkladığında, bir düğmeye dokunduğunda veya özel, JavaScript destekli bir denetim kullandığı andan itibaren) tarayıcının bu etkileşime yanıt olarak etkinlik işleyicileri işlemeye gerçekten başlayabileceği ana kadar geçen süreyi ölçer.

İyi bir FID puanı nedir?

İyi bir kullanıcı deneyimi sağlamak için sitelerde İlk Giriş Gecikmesi, 100 milisaniye veya daha az olmalıdır. Kullanıcılarınızın çoğu için bu hedefe ulaştığınızdan emin olmak amacıyla, ölçmek için iyi bir eşik, mobil ve masaüstü cihazlar arasında segmentlere ayrılmış sayfa yüklemelerinin 75. yüzdelik dilimidir.

başlıklı makaleyi inceleyin.

Ayrıntılı FID

Etkinliklere yanıt veren kod yazan geliştiriciler olarak genellikle kodumuzun etkinlik gerçekleşir gerçekleşmez, hemen çalıştırılacağını varsayıyoruz. Ancak kullanıcılar olarak her zaman bunun tersini yaşadık. Telefonumuza bir web sayfası yükledik, onunla etkileşim kurmaya çalıştık ve hiçbir şey olmazsa hüsrana uğradık.

Genel olarak, giriş gecikmesi (giriş gecikmesi) tarayıcının ana iş parçacığı başka bir şey yapmakla meşgul olduğundan (henüz) kullanıcıya yanıt verememesinden kaynaklanır. Bunun sık karşılaşılan nedenlerinden biri, tarayıcının, uygulamanız tarafından yüklenen büyük bir JavaScript dosyasını ayrıştırmak ve çalıştırmakla meşgul olmasıdır. Bu sırada, yüklediği JavaScript başka bir şey yapmasını söylediğinden hiçbir etkinlik işleyiciyi çalıştıramaz.

Tipik bir web sayfası yüklemesinin aşağıdaki zaman çizelgesini göz önünde bulundurun:

Yukarıdaki görselleştirmede, kaynaklar (büyük olasılıkla CSS ve JS dosyaları) için birkaç ağ isteğinde bulunan bir sayfa gösterilmektedir. Bu kaynakların indirilmesi tamamlandıktan sonra da ana iş parçacığında işlenir.

Bu, ana iş parçacığının anlık olarak meşgul olduğu, bej renkli görev bloklarıyla belirtilen dönemlerle sonuçlanır.

Sayfa, içeriğinin bir kısmını oluşturduğu ancak henüz güvenilir bir şekilde etkileşimli olmadığı için genellikle İlk Zengin İçerikli Boyama (FCP) ve Etkileşime Hazır Olma Süresi (TTI) arasında uzun ilk giriş gecikmeleri meydana gelir. Bunun nasıl gerçekleşebileceğini göstermek için zaman çizelgesine FCP ve TTI eklendi:

FCP ve TTI arasında oldukça uzun bir süre (üç uzun görev dahil) olduğunu fark etmiş olabilirsiniz. Bu süre içinde bir kullanıcı sayfayla etkileşim kurmaya çalışırsa (örneğin, bir bağlantıyı tıklayarak) tıklamanın alınması ile ana iş parçacığının yanıt verebileceği zaman arasında bir gecikme olacaktır.

Bir kullanıcı en uzun görevin başlangıcında sayfayla etkileşimde bulunmaya çalışsaydı ne olacağını düşünün:

Giriş, tarayıcı bir görevin ortasındayken gerçekleştiğinden, girişe yanıt verebilmek için görevin tamamlanmasını beklemesi gerekir. Beklemesi gereken süre, bu sayfada ilgili kullanıcının FID değeridir.

Bir etkileşimin etkinlik işleyicisi yoksa ne olur?

FID, bir giriş etkinliğinin alınması ile ana iş parçacığının bir sonraki boşta kalma zamanı arasındaki deltayı ölçer. Yani FID, bir etkinlik işleyicinin kaydedilmediği durumlarda bile ölçülür. Bunun nedeni, birçok kullanıcı etkileşiminin etkinlik işleyici gerektirmemesi ancak ana iş parçacığının çalışması için boşta olmasını gerektirmemesidir.

Örneğin, aşağıdaki HTML öğelerinin tümü, kullanıcı etkileşimlerine yanıt vermeden önce ana iş parçacığında devam eden görevlerin tamamlanmasını beklemelidir:

• Metin alanları, onay kutuları ve radyo düğmeleri (<input>, <textarea>)
• Açılır listeleri seçin (<select>)
• bağlantı sayısı (<a>)

Neden yalnızca ilk girdiyi dikkate almalısınız?

Herhangi bir girişten kaynaklanan gecikme kötü bir kullanıcı deneyimine yol açabilir, ancak öncelikle birkaç nedene bağlı olarak ilk giriş gecikmesini ölçmenizi öneririz:

• İlk giriş gecikmesi, kullanıcının sitenizin yanıt verme düzeyine ilişkin ilk izlenimi olur. İlk izlenimler, sitenin kalitesi ve güvenilirliğiyle ilgili genel izlenimimizi şekillendirmede kritik öneme sahiptir.
• Günümüzde web'de gördüğümüz en büyük etkileşim sorunları, sayfa yüklenirken ortaya çıkmaktadır. Bu nedenle, başlangıçta sitenin ilk kullanıcı etkileşimini iyileştirmeye odaklanmanın, web'in genel etkileşimini iyileştirmede en büyük etkiyi yaratacağına inanıyoruz.
• Sitelerin yüksek ilk giriş gecikmelerini nasıl düzeltmesi gerektiğiyle ilgili önerilen çözümler (kod bölme, daha az JavaScript ön yükleme vb.), sayfa yüklendikten sonra yavaş giriş gecikmelerini düzeltmek için her zaman aynı çözümler değildir. Bu metrikleri ayırarak web geliştiricilerine daha spesifik performans kuralları sunabileceğiz.

Neler ilk giriş olarak sayılır?

FID, bir sayfanın yükleme sırasında yanıt verme düzeyini ölçen bir metriktir. Bu nedenle, yalnızca tıklama, dokunma ve tuşlara basma gibi ayrı işlemlerden gelen giriş etkinliklerine odaklanır.

Kaydırma ve yakınlaştırma gibi diğer etkileşimler, sürekli işlemlerdir ve tamamen farklı performans kısıtlamalarına sahiptir (ayrıca, tarayıcılar gecikmelerini genellikle ayrı bir iş parçacığında çalıştırarak bunları gizleyebilir).

Başka bir deyişle, FID, RAIL performans modelinde R'ye (duyarlılık) odaklanır. Kaydırma ve yakınlaştırma ise A (animasyon) ile daha çok ilişkilidir ve performans nitelikleri ayrı olarak değerlendirilmelidir.

Bir kullanıcı sitenizle hiç etkileşimde bulunmazsa ne olur?

Tüm kullanıcılar, her ziyaretlerinde sitenizle etkileşime girmeyebilir. Ayrıca tüm etkileşimler FID ile ilgili değildir (bir önceki bölümde belirtildiği gibi). Buna ek olarak, bazı kullanıcıların ilk etkileşimleri kötü zamanlarda (ana iş parçacığı uzun süre meşgul olduğunda) ve bazı kullanıcıların ilk etkileşimleri iyi zamanlarda olur (ana iş parçacığı tamamen boşta olduğunda).

Bu, bazı kullanıcıların hiç FID değerine sahip olmayacağı, bazı kullanıcıların düşük FID değerlerine ve bazı kullanıcıların ise yüksek FID değerlerine sahip olacağı anlamına gelir.

FID'yi izleme, raporlama ve analiz etme yönteminiz muhtemelen alışık olduğunuz diğer metriklerden biraz farklı olacaktır. Bir sonraki bölümde bunu en iyi şekilde nasıl yapacağınız açıklanmaktadır.

Neden yalnızca giriş gecikmesini dikkate almalısınız?

Yukarıda belirtildiği gibi, FID yalnızca etkinlik işlemedeki "gecikmeyi" ölçer. Etkinlik işleme süresinin kendisini veya tarayıcının etkinlik işleyicileri çalıştırdıktan sonra kullanıcı arayüzünü güncellemek için harcadığı süreyi ölçmez.

Bu süre kullanıcı için önemli olmasına ve deneyimi etkilemesine rağmen, geliştiricileri gerçekten deneyimi daha da kötüleştirecek geçici çözümler eklemeye teşvik edebileceğinden bu süre, bu metriğe dahil edilmez. Yani, etkinlik işleyici mantığını, etkinlikle ilişkili görevden ayırmak için eşzamansız bir geri çağırmayla (setTimeout() veya requestAnimationFrame() aracılığıyla) sarmalayabilirler. Sonuç olarak, metrik puanında iyileşme görülürken kullanıcı tarafından algılanan yavaş bir yanıt elde edilir.

Bununla birlikte, FID yalnızca etkinlik gecikmesinin "gecikme" kısmını ölçse de etkinlik yaşam döngüsünün daha büyük bir kısmını izlemek isteyen geliştiriciler bunu Event Timing API'yi kullanarak yapabilir. Daha fazla ayrıntı için özel metrikler ile ilgili kılavuza bakın.

FID metriği nasıl ölçülür?

FID, gerçek bir kullanıcının sayfanızla etkileşim kurmasını gerektirdiği için yalnızca alanda ölçülebilen bir metriktir. FID metriğini aşağıdaki araçları kullanarak ölçebilirsiniz.

Saha araçları

• Chrome Kullanıcı Deneyimi Raporu
• PageSpeed Insights
• Search Console (Önemli Web Verileri raporu)
• web-vitals JavaScript kitaplığı

JavaScript'te FID'yi ölçme

JavaScript'te FID'yi ölçmek için Event Timing API'yi kullanabilirsiniz. Aşağıdaki örnekte, first-input girişlerini dinleyen ve konsola kaydeden bir PerformanceObserver'in nasıl oluşturulacağı gösterilmektedir:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

Yukarıdaki örnekte first-input girişinin gecikme değeri, girişin startTime ile processingStart zaman damgaları arasındaki delta alınarak ölçülür. Çoğu durumda bu FID değeri olur. Ancak first-input girişlerinin tümü FID'yi ölçmek için geçerli değildir.

Aşağıdaki bölümde, API'nin raporlarıyla metriğin hesaplanma şekli arasındaki farklar listelenmiştir.

Metrik ve API arasındaki farklar

• API, arka plan sekmesinde yüklenen sayfalar için first-input girişlerini gönderir ancak FID hesaplanırken bu sayfalar yoksayılmalıdır.
• Sayfa, ilk giriş gerçekleşmeden önce arka plana alındıysa API de first-input girişlerini gönderir ancak FID hesaplanırken bu sayfalar da göz ardı edilmelidir (girişler yalnızca sayfa tüm süre boyunca ön plandaysa dikkate alınır).
• Sayfa geri-ileri önbellekten geri yüklendiğinde API, first-input girişlerini bildirmez ancak kullanıcılar bunları farklı sayfa ziyaretleri olarak deneyimledikleri için bu durumlarda FID ölçülmelidir.
• API, iframe'ler içinde gerçekleşen girişleri raporlamaz ancak metrik, sayfanın kullanıcı deneyiminin bir parçası olduğundan bunları raporlar. Bu, CrUX ve RUM arasındaki bir fark olarak gösterilebilir. FID metriğinin doğru bir şekilde ölçülmesi için bu metrikleri göz önünde bulundurmalısınız. Alt çerçeveler, first-input girişlerini toplama için üst çerçeveye bildirmek için API'yi kullanabilir.

Geliştiriciler tüm bu ince farkları ezberlemek yerine FID'yi ölçmek için web-vitals JavaScript kitaplığını kullanabilir. FID metriği bu farkları sizin yerinize ele alır (mümkünse iframe sorunu dahil değildir):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

JavaScript'te FID metriğinin nasıl ölçüleceğine dair eksiksiz bir örnek için onFID() kaynak koduna bakabilirsiniz.

FID verilerini analiz etme ve raporlama

FID değerlerindeki beklenen sapmalardan dolayı, FID değerleriyle ilgili rapor oluştururken değerlerin dağılımına bakmanız ve daha yüksek yüzdelik dilimlere odaklanmanız çok önemlidir.

Tüm Önemli Web Verileri eşikleri için yüzdelik seçimi 75. sırada olsa da özellikle FID için yine de 95.-99. yüzdelik dilimlere bakmanızı kesinlikle öneririz. Bu yüzdeler, kullanıcıların sitenizde yaşadığı ilk kötü deneyimlere karşılık gelir. En çok iyileştirilmesi gereken alanları gösterir.

Raporlarınızı cihaz kategorisine veya türüne göre segmentlere ayırsanız bile bu durum geçerlidir. Örneğin, masaüstü ve mobil için ayrı raporlar çalıştırırsanız masaüstünde en çok önem verdiğiniz FID değeri, masaüstü kullanıcılarının 95-99. yüzdelik dilimi olmalıdır. Mobil cihazlarda en çok önemsediğiniz FID değeri, mobil kullanıcıların 95.-99. yüzdelik dilimi olmalıdır.

FID'yi iyileştirme

Bu metriği iyileştirme teknikleri konusunda size yol göstermesi için FID'yi optimize etme ile ilgili eksiksiz bir kılavuz mevcuttur.

DEĞİŞİKLİK GÜNLÜĞÜ

Zaman zaman metrikleri ölçmek için kullanılan API'lerde, bazen de metriklerin tanımlarında hatalar bulunur. Bu nedenle, değişikliklerin bazen yapılması gerekir. Bu değişiklikler, dahili raporlarınızda ve kontrol panellerinizde iyileştirmeler ya da regresyonlar olarak gösterilebilir.

Bu durumu yönetmenize yardımcı olmak için, söz konusu metriklerin uygulanmasında veya tanımında yapılan tüm değişiklikler bu CHANGELOG'da gösterilir.

Bu metriklerle ilgili geri bildiriminiz varsa web-vitals-feedback Google grubunda geri bildirimde bulunabilirsiniz.