Kita semua tahu betapa pentingnya membuat kesan pertama yang baik. Hal itu penting saat bertemu orang baru, dan juga penting saat membangun pengalaman di web.
Di web, kesan pertama yang baik dapat membedakan antara seseorang yang menjadi pengguna setia atau mereka yang pergi dan tidak pernah kembali. Pertanyaannya adalah, apa yang membuat kesan yang baik, dan bagaimana cara mengukur jenis kesan yang ingin Anda buat pada pengguna?
Di web, kesan pertama bisa memiliki banyak bentuk—kita memiliki kesan pertama tentang desain dan daya tarik visual situs serta kesan pertama tentang kecepatan dan responsnya.
Meskipun sulit untuk mengukur seberapa besar pengguna menyukai desain situs dengan API web, mengukur kecepatan dan responsivitasnya tidaklah.
Kesan pertama pengguna adalah seberapa cepat pemuatan situs Anda dapat diukur dengan First Contentful Paint (FCP). Namun, seberapa cepat situs Anda dapat menampilkan piksel ke layar hanyalah bagian dari cerita. Hal 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 tentang interaktivitas dan respons situs Anda.
Apa itu FID?
FID mengukur waktu dari saat pengguna pertama kali berinteraksi dengan halaman (yaitu saat pengguna mengklik link, mengetuk tombol, atau menggunakan kontrol kustom 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 berupaya memiliki Penundaan Input Pertama 100 milidetik atau kurang. Guna memastikan Anda mencapai target ini untuk sebagian besar pengguna, batas yang baik untuk diukur adalah persentil ke-75 pemuatan halaman, yang tersegmentasi di seluruh perangkat seluler dan desktop.
FID secara mendetail
Sebagai developer yang menulis kode yang merespons peristiwa, kita sering menganggap kode akan langsung dijalankan—segera setelah peristiwa terjadi. Namun, sebagai pengguna, kita semua sering mengalami hal yang sebaliknya—kita telah memuat halaman web di ponsel, mencoba berinteraksi dengan halaman tersebut, lalu merasa frustrasi ketika tidak ada yang terjadi.
Umumnya, penundaan input (alias latensi input) terjadi karena thread utama browser sedang sibuk melakukan hal lain, sehingga belum dapat (belum) merespons pengguna. Salah satu alasan umum hal ini dapat terjadi adalah browser sibuk mengurai dan mengeksekusi file JavaScript besar yang dimuat oleh aplikasi Anda. Selagi melakukannya, browser tidak dapat menjalankan pemroses peristiwa apa pun karena JavaScript yang dimuatnya mungkin memerintahkannya untuk melakukan hal lain.
Perhatikan linimasa pemuatan halaman web umum berikut:
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 sebentar, 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 beberapa kontennya, tetapi belum interaktif dengan andal. Untuk menggambarkan bagaimana hal ini dapat terjadi, FCP dan TTI telah ditambahkan ke linimasa:
Anda mungkin melihat bahwa ada cukup 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 keterlambatan 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 tersebut. Waktu yang harus ditunggu adalah nilai FID untuk pengguna 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 meskipun jika pemroses peristiwa belum terdaftar. Alasannya karena banyak interaksi pengguna yang tidak memerlukan pemroses peristiwa, tetapi mengharuskan thread utama 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, sebaiknya ukur penundaan input pertama karena beberapa alasan:
- Penundaan input pertama akan menjadi kesan pertama pengguna tentang respons situs Anda, dan kesan pertama sangat penting dalam membentuk kesan keseluruhan 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 fokus awal pada peningkatan interaksi pengguna pertama situs akan memiliki dampak terbesar pada peningkatan interaktivitas web secara keseluruhan.
- Solusi yang direkomendasikan terkait cara situs harus memperbaiki penundaan input pertama yang tinggi (pemisahan kode, pemuatan lebih sedikit JavaScript di awal, dll.) belum tentu merupakan solusi yang sama 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. Dengan demikian, fitur ini hanya berfokus pada peristiwa input dari tindakan terpisah seperti klik, ketukan, dan penekanan tombol.
Interaksi lainnya, seperti men-scroll dan memperbesar/memperkecil, adalah tindakan berkelanjutan dan memiliki batasan performa yang benar-benar berbeda (selain itu, browser sering kali dapat menyembunyikan latensi 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 mengunjunginya. Selain itu, tidak semua interaksi relevan dengan FID (seperti yang disebutkan di bagian sebelumnya). Selain itu, beberapa interaksi pertama pengguna akan terjadi pada saat yang buruk (ketika thread utama sibuk dalam jangka waktu yang lama), dan beberapa interaksi pertama pengguna akan terjadi pada saat yang tepat (saat thread utama benar-benar tidak ada aktivitas).
Artinya, sebagian pengguna tidak akan memiliki nilai FID, sebagian pengguna akan memiliki nilai FID yang rendah, dan sebagian pengguna mungkin akan 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 akan menjelaskan cara terbaik untuk melakukannya.
Mengapa hanya mempertimbangkan penundaan input?
Seperti yang disebutkan di atas, FID hanya mengukur "keterlambatan" dalam pemrosesan peristiwa. Metode ini tidak mengukur waktu pemrosesan peristiwa itu sendiri atau waktu yang diperlukan browser untuk mengupdate UI setelah menjalankan pengendali peristiwa.
Meskipun waktu ini penting bagi pengguna dan mempengaruhi pengalamannya,
waktu tersebut tidak disertakan dalam metrik ini karena dapat mendorong developer
untuk menambahkan solusi yang benar-benar 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" 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 lapangan
- Laporan Pengalaman Pengguna Chrome
- PageSpeed Insights
- Search Console (laporan Data Web Inti)
- 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});
Dalam contoh di atas, nilai penundaan entri first-input diukur dengan mengambil delta di antara stempel waktu startTime dan processingStart entri. Umumnya, ini akan menjadi nilai FID; tetapi, tidak semua entri first-input valid untuk mengukur FID.
Bagian berikut mencantumkan perbedaan antara apa yang dilaporkan oleh API dan cara penghitungan metrik.
Perbedaan antara metrik dan API
- API akan mengirim entri
first-inputuntuk halaman yang dimuat di tab latar belakang, tetapi halaman tersebut harus diabaikan saat menghitung FID. - API juga akan mengirim entri
first-inputjika 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-inputsaat halaman dipulihkan dari back/forward cache, tetapi dalam kasus ini FID harus diukur karena pengguna mengalaminya sebagai kunjungan halaman yang berbeda. - API tidak melaporkan input yang terjadi dalam iframe, tetapi metrik melakukannya karena input tersebut merupakan bagian dari pengalaman pengguna di halaman tersebut. Hal ini dapat menunjukkan 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 digabungkan.
Daripada mengingat semua perbedaan kecil ini, developer dapat menggunakan library JavaScript web-vitals untuk mengukur FID, yang menangani perbedaan ini untuk Anda (jika memungkinkan—perlu diperhatikan bahwa masalah iframe tidak dibahas):
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Anda dapat melihat kode sumber untuk
onFID()
guna mengetahui contoh lengkap cara mengukur FID di JavaScript.
Menganalisis dan melaporkan data FID
Karena varians yang diharapkan dalam nilai FID, sangat penting bagi Anda untuk melihat distribusi nilai dan berfokus pada persentil yang lebih tinggi saat melaporkan FID.
Meskipun pilihan persentil untuk semua batas Data Web Inti adalah 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. Dan itu akan menunjukkan kepada Anda area yang perlu diperbaiki.
Hal ini berlaku meskipun Anda menyegmentasikan laporan berdasarkan kategori atau jenis perangkat. Misalnya, jika Anda menjalankan laporan terpisah untuk desktop dan seluler, nilai FID yang paling penting bagi Anda di desktop haruslah persentil ke-95–99 bagi pengguna desktop, dan nilai FID yang paling penting bagi Anda di perangkat seluler haruslah persentil ke-95–99 pada pengguna seluler.
Cara meningkatkan FID
Panduan lengkap tentang mengoptimalkan FID tersedia untuk memandu Anda melalui teknik untuk meningkatkan metrik ini.
Log perubahan
Terkadang, bug ditemukan di API yang digunakan untuk mengukur metrik, dan terkadang dalam definisi metrik itu sendiri. Oleh karena itu, perubahan terkadang harus dilakukan, dan perubahan ini dapat muncul sebagai peningkatan atau regresi dalam dasbor dan laporan internal Anda.
Untuk membantu Anda mengelola hal ini, 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.