First Input Delay (FID)

Philip Walton

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

Di web, kesan pertama yang baik dapat membuat perbedaan antara seseorang menjadi pengguna setia, atau mereka meninggalkan situs dan tidak kembali lagi. Pertanyaannya, apa yang menghasilkan kesan baik, dan bagaimana cara mengukur jenis tayangan yang mungkin Anda hasilkan pada pengguna Anda?

Di web, kesan pertama dapat memiliki berbagai bentuk—kami memiliki kesan pertama dari desain situs dan daya tarik visualnya serta pengalaman kesan tentang kecepatan dan tingkat responsnya.

Meskipun sulit untuk mengukur seberapa banyak pengguna yang menyukai desain situs dengan API web, mengukur kecepatan dan daya responsnya tidak!

Kesan pertama yang dimiliki pengguna tentang seberapa cepat pemuatan situs Anda dapat diukur dengan First Contentful Paint (FCP). Namun, seberapa cepat situs Anda dapat menggambar piksel ke layar hanyalah bagian dari cerita. Hal lain yang tidak kalah penting adalah situs Anda adalah saat pengguna mencoba berinteraksi dengan {i>pixel<i} tersebut!

Metrik Penundaan Input Pertama (FID) membantu mengukur kesan pertama pengguna interaktivitas dan responsivitas situs Anda.

Apa itu FID?

FID mengukur waktu sejak pengguna pertama kali berinteraksi dengan halaman (yaitu, saat mereka mengklik link, mengetuk tombol, atau menggunakan kontrol kustom yang didukung JavaScript) hingga browser benar-benar dapat memulai pemrosesan pengendali peristiwa sebagai respons atas interaksi tersebut.

Berapa skor FID yang baik?

Untuk memberikan pengalaman pengguna yang baik, situs harus berupaya menampilkan Input Pertama Penundaan 100 milidetik atau kurang. Untuk memastikan Anda mencapai target ini, sebagian besar pengguna Anda, batas yang tepat 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 kita akan langsung dijalankan—segera setelah peristiwa terjadi. Tapi sebagai pengguna, kita semua sering mengalami hal sebaliknya—kita telah memuat laman web di ponsel, mencoba berinteraksi dengannya, dan kemudian frustrasi ketika tidak ada terjadi.

Secara umum, penundaan input (alias latensi input) terjadi karena thread utama sedang sibuk melakukan hal lain, sehingga tidak 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. Ketika melakukannya, aplikasi tidak dapat berjalan pemroses peristiwa apa pun karena JavaScript yang dimuat mungkin memerintahkannya untuk melakukan hal lainnya.

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—mereka diproses di thread utama.

Ini menghasilkan periode di mana thread utama sibuk sesaat, yang ditunjukkan dengan warna krem tugas blok.

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

Anda mungkin telah memperhatikan bahwa ada cukup waktu (termasuk tiga video panjang tugas) 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 utas utama dapat merespons.

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

Karena {i>input<i} terjadi saat {i>browser<i} sedang menjalankan tugas, komputer harus menunggu sampai tugas selesai sebelum dapat merespons input. Tujuan 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 peristiwa setelah thread berikutnya tidak ada aktivitas. Ini berarti FID diukur bahkan jika terjadi peristiwa pemroses belum terdaftar. Alasannya adalah karena banyak interaksi pengguna tidak memerlukan pemroses peristiwa, tetapi memang mengharuskan thread utama tidak ada aktivitas di agar dapat dijalankan.

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

• 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 sebaiknya ukur penundaan input pertama karena beberapa alasan:

• Penundaan input pertama akan menjadi tayangan pertama pengguna tentang responsivitas, dan kesan pertama sangat penting dalam membentuk keseluruhan kesan kualitas dan keandalan situs.
• Masalah interaktivitas terbesar yang kami lihat di web saat ini terjadi selama halaman memuat halaman. Oleh karena itu, kami percaya bahwa pada awalnya kami berfokus pada peningkatan interaksi Anda akan memiliki dampak terbesar dalam meningkatkan keseluruhan interaktivitas web.
• Solusi yang direkomendasikan tentang cara situs memperbaiki penundaan input pertama yang tinggi (pemisahan kode, memuat lebih sedikit JavaScript di awal, dll.) belum tentu solusi yang sama untuk memperbaiki penundaan input yang lambat setelah pemuatan halaman. Dengan memisahkan metrik ini, kami dapat memberikan performa yang lebih spesifik pedoman untuk pengembang 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 tombol penekanan.

Interaksi lainnya, seperti menggulir dan memperbesar/memperkecil, adalah tindakan berkelanjutan dan memiliki batasan kinerja yang benar-benar berbeda (juga, {i>browser<i} sering dapat menyembunyikan latensinya dengan menjalankannya di thread terpisah).

Dengan kata lain, FID berfokus pada R (responsivitas) dalam RAIL performa model, sedangkan scroll, dan zoom lebih terkait dengan A (animasi), dan performanya kualitas 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. Dan tidak semua interaksi Anda relevan dengan FID (seperti yang disebutkan di bagian sebelumnya). Di beberapa Selain itu, interaksi pertama beberapa pengguna akan berada di saat yang buruk (ketika yang utama thread sibuk untuk waktu yang lama), dan beberapa interaksi akan berada pada saat yang tepat (saat thread utama benar-benar tidak ada aktivitas).

Artinya, beberapa pengguna tidak akan memiliki nilai FID, beberapa pengguna akan memiliki FID 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 Anda gunakan. Bagian selanjutnya menjelaskan cara terbaik untuk melakukan ini.

Mengapa hanya mempertimbangkan penundaan input?

Seperti disebutkan di atas, FID hanya mengukur "keterlambatan" dalam pemrosesan peristiwa. Ya tidak mengukur total durasi pemrosesan peristiwa, maupun waktu yang diperlukan browser memperbarui UI setelah menjalankan pengendali peristiwa.

Meskipun waktu ini penting bagi pengguna dan mempengaruhi pengalaman, hal tersebut tidak disertakan dalam metrik ini karena hal tersebut dapat memberikan insentif kepada developer untuk menambahkan solusi yang benar-benar memperburuk pengalaman—yaitu, dapat menggabungkan logika pengendali peristiwa dalam callback asinkron (melalui setTimeout() atau requestAnimationFrame()) untuk memisahkannya dari yang terkait dengan peristiwa tersebut. Hasilnya adalah peningkatan pada metrik tetapi respons yang lebih lambat seperti yang dirasakan oleh pengguna.

Namun, sementara FID hanya mengukur "keterlambatan" latensi peristiwa, developer yang ingin melacak lebih banyak siklus proses peristiwa dapat melakukannya menggunakan kolom Waktu Peristiwa Google Cloud Platform. Lihat panduan tentang kustom metrik untuk mengetahui detail selengkapnya.

Cara mengukur FID

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

Alat kolom

• Pengalaman Pengguna Chrome Laporkan
• PageSpeed Insights
• Search Console (Data Web Inti) laporan)
• Library JavaScript web-vitals

Mengukur FID di JavaScript

Untuk mengukur FID di JavaScript, Anda dapat menggunakan Waktu Peristiwa Google Cloud Platform. Contoh berikut menunjukkan cara buat PerformanceObserver yang mendengarkan first-input entri 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 startTime dan processingStart entri stempel waktu. Dalam kebanyakan kasus, ini adalah nilai FID; Namun, tidak semua first-input entri valid untuk mengukur FID.

Bagian berikut mencantumkan perbedaan antara hal yang dilaporkan API dan caranya metrik tersebut dihitung.

Perbedaan antara metrik dan API

• API akan mengirimkan first-input entri 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 dalam kasus ini karena pengguna melihatnya sebagai halaman yang berbeda kunjungan.
• API tidak melaporkan input yang terjadi dalam iframe, tetapi metrik melakukannya karena merupakan bagian dari pengalaman pengguna di laman tersebut. 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 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—perhatikan bahwa masalah iframe tidak tercakup):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Anda dapat merujuk ke kode sumber untuk onFID() untuk contoh lengkap cara mengukur FID di JavaScript.

Menganalisis dan melaporkan data FID

Karena adanya perbedaan yang diharapkan dalam nilai FID, sangat penting untuk melaporkan FID Anda melihat distribusi nilai dan fokus pada persentil yang lebih tinggi.

Meskipun pilihan persentil untuk semua Nilai minimum Data Web Inti adalah yang ke-75, khususnya untuk FID, kami masih sarankan untuk melihat persentil ke-95-99, karena itu akan sesuai dengan pengalaman pertama yang buruk yang dialami pengguna di situs Anda. Dan itu akan menunjukkan area yang paling perlu diperbaiki.

Hal ini berlaku meskipun Anda menyegmentasikan laporan menurut kategori atau jenis perangkat. Sebagai Misalnya, jika Anda menjalankan laporan terpisah untuk desktop dan seluler, nilai FID yang Anda yang paling diperhatikan di desktop adalah persentil ke-95–99 pengguna desktop, dan nilai FID yang paling penting bagi Anda di perangkat seluler harus yang ke-95–99 persentil 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 dalam API yang digunakan untuk mengukur metrik, dan terkadang dalam definisi metrik itu sendiri. Akibatnya, perubahan terkadang harus dilakukan, dan perubahan ini dapat muncul sebagai peningkatan atau regresi dalam laporan internal dan dasbor 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 untuk masukan web-vitals-feedback.