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 membuat pengalaman di web.

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

Di web, kesan pertama bisa sangat beragam. Kita mendapatkan kesan pertama tentang desain dan daya tarik situs suatu situs, serta kesan pertama terkait kecepatan dan responsivitasnya.

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

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 Penundaan Input Pertama (FID) membantu mengukur kesan pertama pengguna terhadap interaktivitas dan respons 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, batas yang baik untuk diukur adalah persentil ke-75 dari pemuatan halaman, yang disegmentasikan di seluruh perangkat seluler dan desktop.

FID secara detail

Sebagai developer yang menulis kode yang merespons peristiwa, kita sering menganggap kode akan segera dijalankan—segera setelah peristiwa terjadi. Namun sebagai pengguna, kita semua sering mengalami hal sebaliknya—kita memuat halaman web di ponsel, mencoba berinteraksi dengannya, lalu frustrasi ketika 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 berikut untuk pemuatan halaman web biasa:

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 dengan 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 menggambarkan bagaimana hal ini dapat terjadi, FCP dan TTI telah ditambahkan ke linimasa:

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:

Karena input terjadi saat browser sedang menjalankan tugas, browser harus menunggu hingga tugas selesai agar dapat merespons input. Waktu tunggu 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 saat pemroses peristiwa belum terdaftar. 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 kita 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, fungsi ini 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 scroll 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 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 rendah, dan beberapa pengguna mungkin memiliki nilai FID yang tinggi.

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

Mengapa hanya mempertimbangkan penundaan input?

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

Meskipun penting bagi pengguna dan mempengaruhi pengalaman, waktu ini tidak disertakan dalam metrik ini karena hal tersebut dapat mendorong developer untuk menambahkan solusi yang benar-benar memperburuk pengalaman. Artinya, 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 "keterlambatan" 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 sungguhan untuk berinteraksi dengan halaman Anda. Anda dapat mengukur FID dengan alat berikut.

Alat kolom

• Laporan Pengalaman Pengguna Chrome
• 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. Biasanya, nilai ini adalah nilai FID; tetapi, 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 adanya variasi nilai FID yang diharapkan, saat melaporkan FID, sangat penting untuk melihat distribusi nilai dan berfokus pada persentil yang lebih tinggi.

Meskipun pilihan persentil untuk semua nilai minimum Core Web Vitals adalah persentil ke-75, untuk FID secara khusus, sebaiknya lihat persentil ke-95–99, karena persentil tersebut akan sesuai dengan pengalaman pertama yang sangat buruk yang dialami pengguna dengan situs Anda. Dan akan menunjukkan area yang perlu perbaikan paling banyak.

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 berupa persentil ke-95–99 pengguna desktop, dan nilai FID yang paling penting bagi Anda di perangkat seluler harus berupa persentil ke-95–99 pengguna seluler.

Cara meningkatkan FID

Panduan lengkap tentang mengoptimalkan FID tersedia untuk memandu Anda dalam mempelajari berbagai 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.