First Input Delay (FID)

Philip Walton

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

Di web, kesan pertama yang baik dapat membuat perbedaan antara seseorang menjadi pengguna setia atau pergi dan tidak pernah kembali. Pertanyaannya adalah, apa yang membuat kesan yang baik, dan bagaimana cara mengukur jenis kesan yang mungkin Anda berikan kepada pengguna?

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

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

Kesan pertama pengguna tentang seberapa cepat situs Anda dimuat dapat diukur dengan First Contentful Paint (FCP). Namun, seberapa cepat situs Anda dapat merender 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 terhadap interaktivitas dan responsivitas situs Anda.

Apa itu FID?

FID mengukur waktu dari saat pengguna pertama kali berinteraksi dengan halaman (yaitu, saat mereka mengklik link, mengetuk tombol, atau menggunakan kontrol khusus yang didukung 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. Agar Anda mencapai target ini untuk sebagian besar pengguna, batas yang tepat untuk diukur adalah persentil ke-75 dari pemuatan halaman, yang dikelompokkan berdasarkan perangkat seluler dan desktop.

FID secara mendetail

Sebagai developer yang menulis kode yang merespons peristiwa, kita sering mengasumsikan bahwa kode kita akan segera dijalankan—segera setelah peristiwa terjadi. Namun, sebagai pengguna, kita semua 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 sedang sibuk melakukan hal lain, sehingga tidak dapat (belum) merespons pengguna. Salah satu alasan umum hal ini dapat terjadi adalah browser sedang memproses 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 berikut untuk pemuatan halaman web umum:

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 menyebabkan periode saat thread utama sibuk sesaat, 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 beberapa kontennya, tetapi belum dapat diandalkan untuk berinteraksi. Untuk mengilustrasikan bagaimana hal ini dapat terjadi, FCP dan TTI telah ditambahkan ke linimasa:

Anda mungkin memperhatikan bahwa ada banyak waktu (termasuk tiga tugas panjang) 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:

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

Bagaimana jika interaksi tidak memiliki pemroses peristiwa?

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

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

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

Mengapa hanya input pertama yang dipertimbangkan?

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

• Penundaan input pertama akan menjadi kesan pertama pengguna terhadap responsivitas situs Anda, dan kesan pertama sangat penting dalam membentuk kesan keseluruhan kita terhadap kualitas dan keandalan situs.
• Masalah interaktivitas terbesar yang kami lihat di web saat ini terjadi selama pemuatan halaman. Oleh karena itu, kami yakin bahwa berfokus pada peningkatan interaksi pengguna pertama di situs pada awalnya akan memberikan dampak terbesar dalam meningkatkan interaktivitas web secara keseluruhan.
• Solusi yang direkomendasikan untuk cara situs harus memperbaiki penundaan input pertama yang tinggi (pemisahan kode, memuat lebih sedikit JavaScript di awal, dll.) tidak selalu sama dengan solusi untuk memperbaiki penundaan 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. Oleh karena itu, hanya berfokus pada peristiwa input dari tindakan terpisah seperti klik, ketukan, dan penekanan tombol.

Interaksi lain, seperti men-scroll dan melakukan zoom, adalah tindakan berkelanjutan dan memiliki batasan performa yang sama sekali berbeda (juga, browser sering kali dapat menyembunyikan latensinya dengan menjalankannya di thread terpisah).

Dengan kata lain, FID berfokus pada R (responsivitas) dalam model performa RAIL, sedangkan scrolling dan zoom 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 buruk (saat thread utama sibuk dalam jangka waktu yang lama), dan beberapa interaksi pertama pengguna akan terjadi pada waktu yang baik (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 sangat 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. Metrik ini tidak mengukur durasi pemrosesan peristiwa total itu sendiri, atau waktu yang dibutuhkan 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 melakukannya dapat mendorong developer untuk menambahkan solusi yang justru memperburuk pengalaman—yaitu, mereka dapat membungkus 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 interaksi pengguna nyata dengan halaman Anda. Anda dapat mengukur FID dengan alat berikut.

Alat lapangan

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (laporan Core Web Vitals)
• Library JavaScript web-vitals

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. Dalam sebagian besar kasus, nilai ini adalah nilai FID; namun, tidak semua entri first-input valid untuk mengukur FID.

Bagian berikut mencantumkan perbedaan antara yang dilaporkan 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 back-forward cache, 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 tersebut melaporkannya karena merupakan bagian dari pengalaman pengguna di 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 ke frame induk untuk penggabungan.

Menganalisis dan melaporkan data FID

Karena varians yang diharapkan dalam nilai FID, saat melaporkan FID, Anda harus melihat distribusi nilai dan berfokus pada persentil yang lebih tinggi.

Meskipun pilihan persentil untuk semua Core Web Vitals adalah persentil ke-75, khususnya untuk FID, kami tetap sangat menyarankan untuk melihat persentil ke-95–99, karena persentil tersebut akan sesuai dengan pengalaman pertama yang sangat buruk yang dialami pengguna di situs Anda. Selain itu, alat ini akan menunjukkan area yang paling perlu ditingkatkan.

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 Anda perhatikan di desktop haruslah persentil ke-95–99 pengguna desktop, dan nilai FID yang paling Anda perhatikan di seluler haruslah persentil ke-95–99 pengguna seluler.

Cara meningkatkan FID

Panduan lengkap tentang mengoptimalkan FID tersedia untuk memandu Anda mempelajari teknik-teknik untuk meningkatkan metrik ini.

Log perubahan

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

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

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