First Input Delay (FID)

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Philip Walton

İlk izlenimin ne kadar önemli olduğunu hepimiz biliyoruz. Yeni insanlarla tanışırken ve web'de deneyimler oluştururken bu durum önemlidir.

Web'de, iyi bir ilk izlenim, kullanıcıların sadık bir kullanıcı olup olmayacağını veya siteyi terk edip bir daha geri gelip gelmeyeceğini belirleyebilir. Peki, iyi bir izlenim nasıl oluşturulur ve kullanıcılarınız üzerinde nasıl bir izlenim bıraktığınızı nasıl ölçersiniz?

Web'de ilk izlenimler birçok farklı biçimde olabilir. Bir sitenin tasarımı ve görsel çekiciliği ile hız ve duyarlılığı hakkında ilk izlenimler vardır.

Kullanıcıların bir sitenin tasarımını ne kadar beğendiğini web API'leriyle ölçmek zor olsa da hızını ve duyarlılığını ölçmek zor değildir.

Kullanıcıların sitenizin ne kadar hızlı yüklendiğini değerlendirdiği ilk izlenim, ilk zengin içerikli boyama (FCP) ile ölçülebilir. Ancak sitenizin ekrana piksel çizme hızı, hikayenin yalnızca bir parçasıdır. Kullanıcılar bu piksellerle etkileşime geçmeye çalışırken sitenizin ne kadar duyarlı olduğu da aynı derecede önemlidir.

First Input Delay (FID) metriği, kullanıcınızın sitenizin etkileşimi ve yanıt vermesiyle ilgili ilk izlenimini ölçmenize yardımcı olur.

FID nedir?

FID, kullanıcının bir sayfayla ilk kez etkileşime girmesinden (yani bir bağlantıyı tıkladığında, bir düğmeye dokunduğunda ya da JavaScript'le çalıştırılan özel bir denetimi kullandığında) tarayıcının bu etkileşime yanıt olarak etkinlik işleyicileri işlemeye gerçekten başlayabildiği zamana kadar geçen süreyi ölçer.

İyi bir FID puanı nedir?

İyi bir kullanıcı deneyimi sağlamak için sitelerde ilk giriş gecikmesinin 100 milisaniye veya daha kısa olması gerekir. Kullanıcılarınızın çoğu için bu hedefe ulaştığınızdan emin olmak amacıyla, mobil ve masaüstü cihazlara göre segmentlere ayrılmış sayfa yüklemelerinin yüzde 75'lik dilimi iyi bir eşiktir.

FID hakkında ayrıntılı bilgi

Etkinliklere yanıt veren kod yazan geliştiriciler olarak, genellikle kodumuzun etkinliğin gerçekleştiği anda hemen çalışacağını varsayıyoruz. Ancak kullanıcılar olarak hepimiz sık sık bunun tam tersini deneyimledik. Telefonumuza bir web sayfası yükledik, sayfayla etkileşim kurmaya çalıştık ve hiçbir şey olmadığında hayal kırıklığına uğradık.

Genel olarak giriş gecikmesi (diğer adıyla giriş gecikmesi), tarayıcının ana iş parçacığı başka bir şeyle meşgul olduğu için kullanıcıya (henüz) yanıt verememesinden kaynaklanır. Bunun en yaygın nedenlerinden biri, tarayıcının uygulamanız tarafından yüklenen büyük bir JavaScript dosyasını ayrıştırıp yürütmekte olmasıdır. Bu işlem sırasında, yüklediği JavaScript başka bir şey yapmasını söyleyebileceğinden hiçbir etkinlik dinleyicisini çalıştıramaz.

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

Yukarıdaki görselde, kaynaklar (muhtemelen CSS ve JS dosyaları) için birkaç ağ isteği gönderen bir sayfa gösterilmektedir. Bu kaynaklar indirildikten sonra ana iş parçacığında işlenir.

Bu durum, ana iş parçacığının kısa süreliğine meşgul olduğu dönemlere neden olur. Bu dönemler, bej renkli görev bloklarıyla gösterilir.

Uzun ilk giriş gecikmeleri genellikle ilk zengin içerikli boyama (FCP) ile etkileşime hazır olma süresi (TTI) arasında gerçekleşir. Bunun nedeni, sayfanın içeriğinin bir kısmının oluşturulmuş ancak henüz güvenilir bir şekilde etkileşime açık olmamasıdır. Bunun nasıl olabileceğini göstermek için zaman çizelgesine FCP ve TTI eklenmiştir:

FCP ile TTI arasında oldukça uzun bir süre (üç uzun görev dahil) olduğunu fark etmiş olabilirsiniz. Kullanıcı bu süre zarfında sayfayla etkileşime geçmeye çalışırsa (ör. bir bağlantıyı tıklayarak) tıklamanın alınması ile ana iş parçacığının yanıt verebilmesi arasında bir gecikme olur.

Kullanıcı en uzun görevin başlangıcına yakın bir yerde sayfayla etkileşim kurmaya çalışırsa ne olur?

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

Bir etkileşimin etkinlik dinleyicisi yoksa ne olur?

FID, bir giriş etkinliğinin alındığı zaman ile ana iş parçacığının bir sonraki boş zaman aralığı arasındaki farkı ölçer. Bu, bir etkinlik işleyicinin kaydedilmediği durumlarda bile FID'nin ölçüldüğü anlamına gelir. Bunun nedeni, birçok kullanıcı etkileşiminin etkinlik dinleyici gerektirmemesi ancak ana iş parçacığının çalışabilmesi için boşta olmasını gerektirdiğidir.

Örneğin, aşağıdaki HTML öğelerinin tümü, kullanıcı etkileşimlerine yanıt vermeden önce ana iş parçacığındaki 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ılar (<a>)

Neden yalnızca ilk giriş dikkate alınır?

Herhangi bir girişin gecikmesi kötü bir kullanıcı deneyimine yol açabilir ancak birkaç nedenden dolayı öncelikle ilk giriş gecikmesini ölçmenizi öneririz:

• İlk giriş gecikmesi, kullanıcının sitenizin duyarlılığıyla ilgili ilk izlenimi olacaktır. İlk izlenimler, bir 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ükleme sırasında ortaya çıkıyor. Bu nedenle, başlangıçta sitenin ilk kullanıcı etkileşimini iyileştirmeye odaklanmanın, web'in genel etkileşimini iyileştirme konusunda en büyük etkiye sahip olacağına inanıyoruz.
• Sitelerin yüksek ilk giriş gecikmelerini düzeltmesi için önerilen çözümler (kod bölme, önceden daha az JavaScript yükleme vb.), sayfa yüklendikten sonra yavaş giriş gecikmelerini düzeltmek için önerilen çözümlerle aynı olmayabilir. Bu metrikleri ayırarak web geliştiricilere daha spesifik performans yönergeleri sunabileceğiz.

İlk giriş olarak ne kabul edilir?

FID, bir sayfanın yüklenmesi sırasındaki duyarlılığını ölçen bir metriktir. Bu nedenle, yalnızca tıklama, dokunma ve tuşa 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 genellikle ayrı bir iş parçacığında çalıştırarak gecikmeleri gizleyebilir).

Başka bir deyişle, FID, RAIL performans modelindeki R'ye (duyarlılığa) odaklanır. Kaydırma ve yakınlaştırma ise daha çok A ile (animasyon) ilgilidir ve performans özellikleri ayrı ayrı değerlendirilmelidir.

Kullanıcı sitenizle hiç etkileşime geçmezse ne olur?

Tüm kullanıcılar sitenizi her ziyaret ettiğinde sitenizle etkileşimde bulunmaz. Ayrıca, etkileşimlerin tümü FID ile alakalı değildir (önceki bölümde belirtildiği gibi). Ayrıca, bazı kullanıcıların ilk etkileşimleri kötü zamanlarda (ana iş parçacığı uzun süre meşgul olduğunda) gerçekleşirken bazı kullanıcıların ilk etkileşimleri iyi zamanlarda (ana iş parçacığı tamamen boşta olduğunda) gerçekleşir.

Bu, bazı kullanıcıların FID değerinin olmaması, bazı kullanıcıların FID değerinin düşük olması ve bazı kullanıcıların FID değerinin muhtemelen yüksek olması anlamına gelir.

FID'yi izleme, raporlama ve analiz etme şekliniz, alışkın olabileceğiniz diğer metriklerden muhtemelen oldukça farklı olacaktır. Bunu en iyi şekilde nasıl yapacağınız sonraki bölümde açıklanmıştır.

Neden yalnızca giriş gecikmesi dikkate alınır?

Yukarıda da belirtildiği gibi, FID yalnızca etkinlik işlenmesinde yaşanan "gecikmeyi" ölçer. Toplam etkinlik işleme süresini veya etkinlik işleyicileri çalıştırdıktan sonra tarayıcının kullanıcı arayüzünü güncellemesi için geçen süreyi ölçmez.

Bu süre kullanıcı için önemli olsa ve deneyimi etkilese de, geliştiricileri deneyimi daha da kötüleştiren geçici çözümler eklemeye teşvik edebileceği için bu metriğe dahil edilmez. Yani geliştiriciler, etkinlik işleyici mantıklarını etkinlikle ilişkili görevden ayırmak için setTimeout() veya requestAnimationFrame() aracılığıyla ayarsız geri çağırma işlevine sarmalayabilirler. Sonuç olarak, metrik puanında bir iyileşme olur ancak kullanıcı tarafından algılanan yanıt hızı yavaşlar.

Ancak FID yalnızca etkinlik gecikmesinin "gecikme" kısmını ölçerken etkinlik yaşam döngüsünün daha fazlasını izlemek isteyen geliştiriciler Event Timing API'yi kullanabilir. Daha ayrıntılı bilgi için özel metrikler kılavuzuna bakın.

FID'yi ölçme

FID, gerçek bir kullanıcının sayfanızla etkileşime geçmesini gerektirdiğinden yalnızca sahada ölçülebilen bir metriktir. FID'yi aşağıdaki araçlarla ölçebilirsiniz.

Saha araçları

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

JavaScript'de 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 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ının farkı alınarak ölçülür. Çoğu durumda bu, FID değeri olacaktır. 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 raporladığı değerler ile metriğin hesaplanma şekli arasındaki farklar listelenmiştir.

Metrik ile API arasındaki farklar

• API, arka plan sekmesinde yüklenen sayfalar için first-input girişleri gönderir ancak bu sayfalar FID hesaplanırken yoksayılmalıdır.
• API, ilk giriş gerçekleşmeden önce sayfa arka plandaysa first-input girişleri de gönderir ancak bu sayfalar FID hesaplanırken de yoksayılmalıdır (Girişler yalnızca sayfa tüm süre boyunca ön plandaysa dikkate alınır).
• API, sayfa geri/ileri önbellekten geri yüklendiğinde first-input girişlerini bildirmez ancak kullanıcılar bunları farklı sayfa ziyaretleri olarak deneyimlediğinden bu durumlarda FID ölçülmelidir.
• API, iframe'lerde gerçekleşen girişleri bildirmez ancak sayfanın kullanıcı deneyiminin bir parçası oldukları için metrik bu girişleri bildirir. Bu durum CrUX ile RUM arasında bir fark olarak gösterilebilir. FID'yi doğru şekilde ölçmek için bunları göz önünde bulundurmanız gerekir. Alt çerçeveler, toplama için first-input girişlerini ebeveyn çerçeveye bildirmek üzere API'yi kullanabilir.

FID verilerini analiz etme ve raporlama

FID değerlerinde beklenen varyans nedeniyle, FID hakkında rapor oluştururken değerlerin dağılımına bakmanız ve daha yüksek yüzdelik dilimlere odaklanmanız önemlidir.

Tüm Core Web Vitals eşiklerinde yüzdelik dilim seçimi 75. yüzdelik dilim olsa da özellikle İGG için 95. ve 99. yüzdelik dilimleri incelemenizi önemle tavsiye ederiz. Bu yüzdelik dilimler, kullanıcıların sitenizle ilgili yaşadığı özellikle kötü ilk deneyimlere karşılık gelir. Ayrıca, en çok iyileştirilmesi gereken alanları da 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 yayınlarsanız masaüstünde en çok önemsediğiniz FID değeri, masaüstü kullanıcılarının yüzde 95-99'uncu yüzdelik dilimi, mobilde en çok önemsediğiniz FID değeri ise mobil kullanıcıların yüzde 95-99'uncu yüzdelik dilimi olmalıdır.

FID'yi iyileştirme

Bu metriği iyileştirme teknikleri konusunda size yol gösterecek FID'yi optimize etme konulu tam bir kılavuz mevcuttur.

Değişiklik günlüğü

Metrikleri ölçmek için kullanılan API'lerde ve bazen de metriklerin tanımlarında zaman zaman hatalar keşfedilir. Bu nedenle, bazen değişiklikler yapılması gerekir ve bu değişiklikler dahili raporlarınızda ve kontrol panellerinizde iyileştirme veya gerileme olarak görünebilir.

Bu metrikleri yönetmenize yardımcı olmak için bu metriklerin uygulanmasında veya tanımında yapılan tüm değişiklikler bu değişiklik günlüğünde gösterilir.

Bu metrikler hakkında geri bildiriminiz varsa web-vitals-feedback Google grubunda paylaşabilirsiniz.