First Input Delay (FID)

Tarayıcı Desteği

  • 76
  • 79
  • 89
  • x

Kaynak

İyi bir ilk izlenim bırakmanın ne kadar önemli olduğunu hepimiz biliyoruz. Yeni insanlarla tanışmak hem web'de deneyim oluştururken de önemlidir.

Web'de iyi bir ilk izlenim, birinin sadık bir kullanıcı olması ile bir kullanıcının ayrılıp bir daha geri dönmemesi arasında fark yaratabilir. Sorulması gereken soru, iyi bir izlenimin neden oluştuğudur ve kullanıcılarınızda olası ne tür bir izlenim oluşturuyorsunuz?

Web'de ilk izlenimler pek çok farklı biçimde gerçekleşebilir. Bir sitenin tasarımı ve görsel çekiciliğiyle ilgili ilk izlenimlerin yanı sıra hızı ve yanıt verme durumuyla ilgili ilk izlenimler burada görülmektedir.

Web API'leriyle kullanıcıların bir sitenin tasarımını ne kadar beğendiğini ölçmek zor olsa da, sitenin hızını ve duyarlılığını ölçmek o kadar kolay değildir!

Sitenizin yükleme hızının İlk Zengin İçerikli Boyama (FCP) ile ölçülebildiğine dair kullanıcıların ilk izlenimi. Ancak, sitenizin pikselleri ekrana boyma hızı sadece işin bir parçasıdır. Aynı derecede önemli olan, kullanıcılar bu piksellerle etkileşimde bulunmaya çalıştığında sitenizin ne kadar duyarlı olduğudur!

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

FID nedir?

FID, bir kullanıcının bir sayfayla ilk kez etkileşimde bulunduğu (yani bir bağlantıyı tıkladığında, bir düğmeye dokunduğu veya özel, JavaScript destekli bir denetim kullandığı an) ile 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 en fazla 100 milisaniye olmalıdır. Kullanıcılarınızın çoğu için bu hedefe ulaştığınızdan emin olmak amacıyla, mobil ve masaüstü cihazlarda segmentlere ayrılmış sayfa yüklemelerinin 75. yüzdelik dilimi iyi bir ölçüm eşiğidir.

İyi FID değerleri 2,5 saniye veya daha kısa, düşük değerler 4,0 saniyeden uzun ve iyileştirme gerektirenler arasındaki tüm değerler

Ayrıntılı olarak FID

Etkinliklere yanıt veren kod yazan geliştiriciler olarak genellikle kodumuzun etkinlik gerçekleştiği anda, yani hemen çalıştırılacağını varsayarız. Ancak kullanıcılar olarak hepimiz telefonumuza bir web sayfası yükledik, onunla etkileşimde bulunmaya çalıştık ve hiçbir şey olmadığında sinirli bir şekilde karşılaştık.

Genel olarak, giriş gecikmesi (diğer adıyla 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 yaygın 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. Yüklediği JavaScript başka bir şey yapmasını istediğinden hiçbir etkinlik işleyiciyi çalıştıramaz.

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

Sayfa yükleme izleme örneği

Yukarıdaki görselleştirme, kaynaklar için birkaç ağ isteği (büyük olasılıkla CSS ve JS dosyaları) yapan bir sayfayı gösterir ve bu kaynakların indirilmesi tamamlandıktan sonra ana iş parçacığında işlenir.

Bunun sonucunda, ana iş parçacığının anlık meşgul olduğu dönemler oluşur. Bu durum, bej renkli görev bloklarıyla gösterilir.

İlk giriş gecikmeleri genellikle İlk Zengin İçerikli Boyama (FCP) ile Etkileşime Hazır Olma Süresi (TTI) arasında meydana gelir. Bunun nedeni, sayfa içeriğinin bir kısmını oluşturmuş olmasına rağmen henüz güvenilir bir şekilde etkileşimli olmamasıdır. Bunun nasıl gerçekleşebileceğini göstermek için zaman çizelgesine FCP ve TTI eklenmiştir:

FCP ve TTI ile sayfa yükleme izlemesi örneği

FCP ve TTI arasında oldukça uzun bir süre olduğunu (üç uzun görev dahil) fark etmiş olabilirsiniz. Bir kullanıcı bu süre içinde sayfayla etkileşimde bulunmaya çalışırsa (örneğin, bir bağlantıyı tıklayarak) tıklamanın alınmasıyla ana iş parçacığının yanıt vermesi arasında bir gecikme olur.

Bir kullanıcı en uzun görevin başında sayfayla etkileşimde bulunmayı denese ne olacağını düşünün:

FCP, TTI ve FID ile sayfa yükleme izleme örneği

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

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

FID, bir giriş etkinliğinin alındığı zaman ile ana iş parçacığının sonraki boşta olduğu 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ı (<a>)

Neden sadece ilk girdiyi dikkate almalısınız?

Herhangi bir girişteki 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 duyarlılığına ilişkin ilk izlenimi olur ve ilk izlenimler, bir sitenin kalitesi ve güvenilirliğine yönelik genel izlenimimizi şekillendirme açısından çok önemlidir.
  • Günümüzde web'de gördüğümüz en büyük etkileşim sorunları sayfa yüklenirken yaşanıyor. 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 sağlayacağına inanıyoruz.
  • Sitelerin yüksek ilk giriş gecikmelerini (kod bölme, daha az JavaScript ön yükleme vb.) nasıl düzeltmesi gerektiğiyle ilgili önerilen çözümler, 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 ayrıntılı performans yönergeleri sağlayabiliriz.

Neler ilk giriş olarak sayılır?

İGG, bir sayfanın yükleme sırasındaki duyarlılığını ö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 gizleyebilir).

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

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

Tüm kullanıcılar, sitenizi her ziyaret ettiklerinde etkileşimde bulunmaz. 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ştayken).

Bu nedenle, bazı kullanıcılar hiç FID değerlerine sahip olmayacak, bazı kullanıcılar düşük FID değerlerine ve bazı kullanıcılar büyük olasılıkla yüksek FID değerlerine sahip olacaktır.

FID'yi izleme, raporlama ve analiz etme yönteminiz, alışkın olduğunuz diğer metriklerden büyük olasılıkla biraz farklı olacaktır. Sonraki bölümde bunun en iyi şekilde nasıl yapılacağı 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çekte deneyimi daha da kötüleştiren geçici çözümler eklemeye teşvik edebileceğinden, bu süre bu metriğe dahil edilmez. Diğer bir deyişle, 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 daha 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 Etkinlik Zamanlaması API'sini 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ı

JavaScript'te FID'yi ölçün

JavaScript'te FID'yi ölçmek için Etkinlik Zamanlaması API'sini kullanabilirsiniz. Aşağıdaki örnekte, first-input girişlerini dinleyen ve bunları 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 ve processingStart zaman damgaları arasındaki delta alınarak ölçülür. Bu, çoğu durumda FID değeri olur. Ancak tüm first-input girişleri FID'yi ölçmek için geçerli değildir.

Aşağıdaki bölümde, API'nin bildirdikleri ile 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.
  • API, sayfa ilk giriş gerçekleşmeden önce arka plana alındıysa first-input girişlerini de gönderir, ancak FID hesaplanırken bu sayfaların da yoksayılması gerekir (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 raporlamaz 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 rapor etmez, ancak sayfanın kullanıcı deneyiminin bir parçası oldukları için metrik rapor eder. Bu durum, CrUX ve RUM arasındaki bir fark olarak gösterilebilir. FID'yi doğru şekilde ölçmek için bunları göz önünde bulundurmalısınız. Alt çerçeveler, first-input girişlerini toplama için üst çerçeveye bildirmek üzere API'yi kullanabilir.

Geliştiriciler tüm bu ince farkları ezberlemek yerine, bu farklılıkları sizin yerinize işleyen FID'yi ölçmek için web-vitals JavaScript kitaplığını kullanabilir (mümkünse iframe sorununun ele alınmadığını unutmayın):

import {onFID} from 'web-vitals';

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

JavaScript'te FID'nin nasıl ölçüleceğine ilişkin eksiksiz bir örnek için onFID() kaynak koduna bakabilirsiniz.

FID verilerini analiz etme ve raporlama

FID değerlerindeki beklenen sapma nedeniyle, FID hakkında 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 95.-99. yüzdelik dilimlere bakmanızı kesinlikle öneririz. Bu yüzdelik dilimler, kullanıcıların sitenizde yaşadığı özellikle kötü olan ilk deneyimlere karşılık gelir. En çok iyileştirilmesi gereken bölgeleri gösterir.

Raporlarınızı cihaz kategorisine veya türe 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 ise en çok önem verdiğiniz FID değeri, mobil cihaz kullanıcıları için 95.-99. yüzdelik dilim 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ğişiklik günlüğü

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

Bu durumu yönetmenize yardımcı olmak amacıyla, metriklerin uygulanmasında veya tanımında yapılan tüm değişiklikler bu Değişiklik günlüğünde gösterilir.

Bu metriklerle ilgili geri bildirimlerinizi web-önemli geri bildirim Google grubunda paylaşabilirsiniz.