First Input Delay (FID)

Dukungan Browser

  • Chrome: 76.
  • Edge: 79.
  • Firefox: 89.
  • Safari: tidak didukung.

Sumber

Kita semua tahu betapa pentingnya memberikan kesan pertama yang baik. Hal ini penting saat bertemu orang baru, dan juga penting saat membuat pengalaman di web.

Di web, kesan pertama yang baik dapat menentukan apakah seseorang akan menjadi pengguna setia atau meninggalkan situs dan tidak pernah kembali. Pertanyaannya adalah, apa yang membuat kesan yang baik, dan bagaimana Anda mengukur jenis kesan yang mungkin Anda berikan kepada pengguna?

Di web, kesan pertama dapat muncul dalam berbagai bentuk—kita memiliki kesan pertama tentang desain dan daya tarik visual situs serta kesan pertama tentang kecepatan dan responsivitasnya.

Meskipun sulit untuk mengukur seberapa banyak pengguna menyukai desain situs dengan API web, mengukur kecepatan dan responsivitasnya tidaklah sulit.

Kesan pertama pengguna tentang seberapa cepat situs Anda dimuat dapat diukur dengan First Contentful Paint (FCP). Namun, seberapa cepat situs Anda dapat menampilkan piksel ke layar hanyalah sebagian dari cerita. Yang sama pentingnya adalah seberapa responsif situs Anda saat pengguna mencoba berinteraksi dengan piksel tersebut.

Metrik First Input Delay (FID) membantu mengukur kesan pertama pengguna tentang interaktifitas dan responsivitas situs Anda.

Apa yang dimaksud dengan FID?

FID mengukur waktu dari saat pengguna pertama kali berinteraksi dengan halaman (yaitu, saat mereka mengklik link, mengetuk tombol, atau menggunakan kontrol khusus JavaScript) hingga saat browser benar-benar dapat mulai memproses pengendali peristiwa sebagai respons terhadap interaksi tersebut.

Berapa skor FID yang baik?

Untuk memberikan pengalaman pengguna yang baik, situs harus mengusahakan agar Penundaan Input Pertama 100 milidetik atau kurang. Untuk memastikan Anda mencapai target ini bagi sebagian besar pengguna, nilai minimum yang baik untuk diukur adalah persentil ke-75 muat halaman, yang disegmentasikan di seluruh perangkat seluler dan desktop.

Nilai FID yang baik adalah 2,5 detik atau kurang, nilai yang buruk lebih besar dari 4,0 detik, dan nilai di antara keduanya perlu ditingkatkan

FID secara mendetail

Sebagai developer yang menulis kode yang merespons peristiwa, kita sering berasumsi bahwa kode kita akan segera dijalankan—segera setelah peristiwa terjadi. Namun, sebagai pengguna, kita sering mengalami hal sebaliknya—kita telah memuat halaman web di ponsel, mencoba berinteraksi dengannya, lalu merasa frustrasi saat tidak ada yang terjadi.

Secara umum, penundaan input (alias latensi input) terjadi karena thread utama browser sibuk melakukan hal lain, sehingga belum dapat merespons pengguna. Salah satu alasan umum yang mungkin terjadi adalah browser sedang sibuk mengurai dan mengeksekusi file JavaScript besar yang dimuat oleh aplikasi Anda. Saat melakukannya, browser tidak dapat menjalankan pemroses peristiwa apa pun karena JavaScript yang dimuatnya mungkin memintanya untuk melakukan hal lain.

Pertimbangkan linimasa pemuatan halaman web standar berikut:

Contoh trace pemuatan halaman

Visualisasi di atas menunjukkan halaman yang membuat beberapa permintaan jaringan untuk resource (kemungkinan besar file CSS dan JS), dan—setelah resource tersebut selesai didownload—resource tersebut diproses di thread utama.

Hal ini menghasilkan periode saat thread utama sibuk untuk sementara, yang ditunjukkan oleh blok tugas berwarna krem.

Penundaan input pertama yang lama biasanya terjadi antara First Contentful Paint (FCP) dan Time to Interactive (TTI) karena halaman telah merender sebagian kontennya, tetapi belum interaktif secara andal. Untuk mengilustrasikan bagaimana hal ini dapat terjadi, FCP dan TTI telah ditambahkan ke linimasa:

Contoh rekaman aktivitas pemuatan halaman dengan FCP dan TTI

Anda mungkin telah memperhatikan bahwa ada cukup banyak waktu (termasuk tiga tugas lama) antara FCP dan TTI. Jika pengguna mencoba berinteraksi dengan halaman selama waktu tersebut (misalnya, dengan mengklik link), akan ada penundaan antara saat klik diterima dan saat thread utama dapat merespons.

Pertimbangkan apa yang akan terjadi jika pengguna mencoba berinteraksi dengan halaman di dekat awal tugas terpanjang:

Contoh rekaman aktivitas pemuatan halaman dengan FCP, TTI, dan FID

Karena input terjadi saat browser sedang menjalankan tugas, browser harus menunggu hingga tugas selesai sebelum dapat merespons input. Waktu yang harus ditunggu adalah nilai FID untuk pengguna ini di halaman ini.

Bagaimana jika interaksi tidak memiliki pemroses peristiwa?

FID mengukur delta antara saat peristiwa input diterima dan saat thread utama tidak ada aktivitas berikutnya. Artinya, FID diukur bahkan jika pemroses peristiwa belum didaftarkan. Alasannya adalah karena banyak interaksi pengguna tidak memerlukan pemroses peristiwa, tetapi memerlukan thread utama untuk tidak ada aktivitas agar dapat berjalan.

Misalnya, semua elemen HTML berikut harus menunggu tugas yang sedang berlangsung di thread utama selesai sebelum merespons interaksi pengguna:

  • Kolom teks, kotak centang, dan tombol pilihan (<input>, <textarea>)
  • Pilih dropdown (<select>)
  • link (<a>)

Mengapa hanya mempertimbangkan input pertama?

Meskipun penundaan dari input apa pun dapat menyebabkan pengalaman pengguna yang buruk, kami terutama menyarankan untuk mengukur penundaan input pertama karena beberapa alasan:

  • Penundaan input pertama akan menjadi kesan pertama pengguna tentang responsivitas situs Anda, dan kesan pertama sangat penting dalam membentuk kesan keseluruhan kami tentang kualitas dan keandalan situs.
  • Masalah interaktivitas terbesar yang kami lihat di web saat ini terjadi selama pemuatan halaman. Oleh karena itu, kami yakin bahwa pada awalnya berfokus pada peningkatan interaksi pengguna pertama situs akan memiliki dampak terbesar dalam meningkatkan interaktivitas web secara keseluruhan.
  • Solusi yang direkomendasikan untuk cara situs memperbaiki latensi input pertama yang tinggi (pemisahan kode, memuat lebih sedikit JavaScript di awal, dll.) tidak selalu merupakan solusi yang sama untuk memperbaiki latensi input yang lambat setelah pemuatan halaman. Dengan memisahkan metrik ini, kami dapat memberikan panduan performa yang lebih spesifik kepada developer web.

Apa yang dianggap sebagai input pertama?

FID adalah metrik yang mengukur responsivitas halaman selama pemuatan. Dengan demikian, hanya berfokus pada peristiwa input dari tindakan terpisah seperti klik, ketukan, dan penekanan tombol.

Interaksi lainnya, seperti men-scroll dan memperbesar, adalah tindakan berkelanjutan dan memiliki batasan performa yang sama sekali berbeda (selain itu, browser sering kali dapat menyembunyikan latensinya dengan menjalankannya di thread terpisah).

Dengan kata lain, FID berfokus pada R (responsivitas) dalam model performa RAIL, sedangkan men-scroll dan memperbesar lebih terkait dengan A (animasi), dan kualitas performanya harus dievaluasi secara terpisah.

Bagaimana jika pengguna tidak pernah berinteraksi dengan situs Anda?

Tidak semua pengguna akan berinteraksi dengan situs Anda setiap kali mereka berkunjung. Selain itu, tidak semua interaksi relevan dengan FID (seperti yang disebutkan di bagian sebelumnya). Selain itu, beberapa interaksi pertama pengguna akan terjadi pada waktu yang tidak tepat (saat thread utama sibuk selama jangka waktu yang lama), dan beberapa interaksi pertama pengguna akan terjadi pada waktu yang tepat (saat thread utama benar-benar tidak ada aktivitas).

Artinya, beberapa pengguna tidak akan memiliki nilai FID, beberapa pengguna akan memiliki nilai FID yang rendah, dan beberapa pengguna mungkin akan memiliki nilai FID yang tinggi.

Cara Anda melacak, melaporkan, dan menganalisis FID mungkin akan sedikit berbeda dari metrik lain yang mungkin biasa Anda gunakan. Bagian berikutnya menjelaskan cara terbaik untuk melakukannya.

Mengapa hanya mempertimbangkan penundaan input?

Seperti yang disebutkan di atas, FID hanya mengukur "penundaan" dalam pemrosesan peristiwa. Pengukuran ini tidak mengukur total durasi pemrosesan peristiwa itu sendiri, atau waktu yang diperlukan browser untuk mengupdate UI setelah menjalankan pengendali peristiwa.

Meskipun waktu ini penting bagi pengguna dan memengaruhi pengalaman, waktu ini tidak disertakan dalam metrik ini karena dapat mendorong developer untuk menambahkan solusi yang sebenarnya memperburuk pengalaman—yaitu, mereka dapat menggabungkan logika pengendali peristiwa dalam callback asinkron (melalui setTimeout() atau requestAnimationFrame()) untuk memisahkannya dari tugas yang terkait dengan peristiwa. Hasilnya adalah peningkatan skor metrik, tetapi respons yang lebih lambat seperti yang dirasakan oleh pengguna.

Namun, meskipun FID hanya mengukur bagian "penundaan" dari latensi peristiwa, developer yang ingin melacak lebih banyak siklus proses peristiwa dapat melakukannya menggunakan Event Timing API. Lihat panduan tentang metrik kustom untuk mengetahui detail selengkapnya.

Cara mengukur FID

FID adalah metrik yang hanya dapat diukur di lapangan, karena memerlukan pengguna sebenarnya untuk berinteraksi dengan halaman Anda. Anda dapat mengukur FID dengan alat berikut.

Alat kolom

Mengukur FID di JavaScript

Untuk mengukur FID di JavaScript, Anda dapat menggunakan Event Timing API. Contoh berikut menunjukkan cara membuat PerformanceObserver yang memproses entri first-input dan mencatatnya ke konsol:

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});

Pada contoh di atas, nilai penundaan entri first-input diukur dengan mengambil delta antara stempel waktu startTime dan processingStart entri. Pada umumnya, ini akan menjadi nilai FID; namun, tidak semua entri first-input valid untuk mengukur FID.

Bagian berikut mencantumkan perbedaan antara laporan API dan cara metrik dihitung.

Perbedaan antara metrik dan API

  • API akan mengirimkan entri first-input untuk halaman yang dimuat di tab latar belakang, tetapi halaman tersebut harus diabaikan saat menghitung FID.
  • API juga akan mengirimkan entri first-input jika halaman berada di latar belakang sebelum input pertama terjadi, tetapi halaman tersebut juga harus diabaikan saat menghitung FID (input hanya dipertimbangkan jika halaman berada di latar depan sepanjang waktu).
  • API tidak melaporkan entri first-input saat halaman dipulihkan dari cache kembali/maju, tetapi FID harus diukur dalam kasus ini karena pengguna mengalaminya sebagai kunjungan halaman yang berbeda.
  • API tidak melaporkan input yang terjadi dalam iframe, tetapi metrik melaporkannya karena merupakan bagian dari pengalaman pengguna halaman. Hal ini dapat ditampilkan sebagai perbedaan antara CrUX dan RUM. Untuk mengukur FID dengan benar, Anda harus mempertimbangkannya. Sub-frame dapat menggunakan API untuk melaporkan entri first-input-nya ke frame induk untuk agregasi.

Menganalisis dan melaporkan data FID

Karena variasi yang diharapkan dalam nilai FID, sangat penting untuk melihat distribusi nilai dan berfokus pada persentil yang lebih tinggi saat melaporkan FID.

Meskipun pilihan persentil untuk semua nilai minimum Core Web Vitals adalah persentil ke-75, untuk FID secara khusus, sebaiknya Anda tetap melihat persentil ke-95–99, karena persentil tersebut akan sesuai dengan pengalaman pertama yang sangat buruk yang dialami pengguna dengan situs Anda. Selain itu, alat ini akan menunjukkan area yang paling memerlukan peningkatan.

Hal ini berlaku meskipun Anda menyegmentasikan laporan menurut kategori atau jenis perangkat. Misalnya, jika Anda menjalankan laporan terpisah untuk desktop dan seluler, nilai FID yang paling penting bagi Anda di desktop harus berada di persentil ke-95–99 pengguna desktop, dan nilai FID yang paling penting bagi Anda di perangkat seluler harus berada di persentil ke-95–99 pengguna seluler.

Cara meningkatkan FID

Panduan lengkap tentang mengoptimalkan FID tersedia untuk memandu Anda dalam menerapkan teknik untuk meningkatkan metrik ini.

Log perubahan

Terkadang, bug ditemukan di API yang digunakan untuk mengukur metrik, dan terkadang di definisi metrik itu sendiri. Oleh karena itu, terkadang perubahan harus dilakukan, dan perubahan ini dapat muncul sebagai peningkatan atau regresi dalam laporan dan dasbor internal Anda.

Untuk membantu Anda mengelolanya, semua perubahan pada penerapan atau definisi metrik ini akan ditampilkan di Log Perubahan ini.

Jika memiliki masukan untuk metrik ini, Anda dapat memberikannya di grup Google web-vitals-feedback.