Di artikel kali ini, akan dibahas apa itu First Input Delay, manfaatnya, cara optimasi, dan hubungannya dengan metrik Core Web Vitals lainnya. Yuk simak dan baca sampai akhir Pengertian First Input Delay dan Cara Optimasinya

Pengertian First Input Delay (FID)

First Input Delay adalah metrik yang digunakan untuk memantau lamanya delay (penundaan) yang dibutuhkan sampai browser merespons input user, yaitu klik dan ketukan pada layar.

Poin Pentingnya First Input Delay

FID adalah bagian dari metrik Core Web Vitals, bersama dengan Largest Contentful Paint (LCP) dan Cumulative Layout Shift (CSL).

Kalian bisa mengukur performa halaman serta mendapatkan laporan yang akan membantu meningkatkan performa website dengan Core Web Vitals.

Selain itu, metrik-metrik tersebut akan mempengaruhi user experience dan ranking website, yang tentunya berdampak pada Search Engine Optimization (SEO). Sebab, kecepatan halaman merupakan salah satu faktor utama yang menentukan ranking website di Google.

Cara Mengetahui Skor First Input Delay

Tidak seperti Cumulative Layout Shift dan Largest Contentful Paint, First Input Delay hanya bisa dinilai melalui interaksi nyata pengguna dengan halaman kalian.

Berikut tool yang bisa digunakan untuk mengetahui skor First Input Delay:

• Library JavaScript Web Vitals – tool untuk front-end monitoring, membantu untuk menganalisis setiap metrik dalam waktu singkat dan dengan akurasi tinggi. Setiap metrik menentukan satu fungsi, yaitu callback onReport. Setelah mengkonfigurasi library web vitals, tool ini akan melaporkan apakah website sudah mencapai ambang batas yang disarankan atau belum.
• Laporan Chrome User Experience – juga dikenal sebagai CrUX, tool ini membantu developer meningkatkan kegunaan website dengan Core Web Vitals dan metrik diagnostik berdasarkan data pengguna asli. CrUX didukung oleh API platform web standar, artinya bisa juga menggunakan API tersebut untuk mengumpulkan data Real User Monitoring (RUM).
• Laporan Search Console Core Web Vitals – membantu web developer memperbaiki pengalaman pengguna yang buruk. Laporan ini mengevaluasi performa website berdasarkan data lapangan selama 90 hari menurut status URL, grup, dan tipe metrik. Eitss, ingat ya, laporan ini hanya untuk URL yang diindeks dan didasarkan pada Web Core Vitals. Jika tidak memiliki cukup informasi untuk metrik apapun, URL akan dihapus dari laporan.
• Page Speed Insights – mengecek performa website terbaru dengan cepat. Tool ini membagi informasi menurut user desktop dan mobile serta data untuk memperbaiki user experience dan debug masalah.

Jika ingin menggunakan PageSpeed Insights untuk mengetes First Input Delay. Cukup masukkan satu URL ke dalam kolom pencarian.

Setelah itu akan mendapatkan penilaian Core Web Vitals pada halaman serta saran untuk menyempurnakannya. Kalian juga bisa melihat berapa input delay di halaman web kalian.

Nilai FID yang Bagus

User akan merasa bahwa suatu halaman bisa merespons permintaan ‘langsung pada saat itu juga’ adalah ketika respons diberikan kurang dari 0,1 detik.

Maka, untuk mendapatkan nilai FID yang baik dan user input yang cepat, website harus memiliki FID kurang dari 100 ms sebagai batas maksimum. Idealnya, website harus mencapai <100 ms dari 75% loading semua halaman, termasuk perangkat mobile dan desktop.

Grafik di bawah ini menunjukkan pengelompokan nilai First Input Delay yang dianggap bagus, perlu diperbaiki, dan buruk.

Max Potential First Input Delay

Max Potential First Input Delay (MPFID) adalah tugas terlama sebuah halaman. MPFID mengukur waktu respons halaman selama task terlama berjalan. Perlu diperhatikan bahwa pengukuran dimulai hanya setelah First Contentful Paint (FCP) dihitung.

Hasil nilai diambil dari perbandingan waktu max potential FID dengan waktu max potential FID pada website lainnya di internet. Misal, nilai MPFID berwarna hijau, artinya performa halaman lebih baik daripada 90% website lainnya.

Penyebab Nilai FID Rendah

Jika mendapat nilai First Input Delay yang rendah, kalian harus tahu nih bagian mana saja pada halaman kalian yang perlu diperbaiki.

Salah satu penyebab utama yang membuat browser tidak bisa merespons interaksi user dengan cepat adalah input user yang terblokir. Hal ini terjadi saat main thread browser sibuk mengerjakan task lain.

Task ini biasanya termasuk menangani HTML, CSS, dan Javascript sehingga pekerjaan browser mejadi terlalu berat. Task panjang JavaScript adalah error umum yang menyebabkan penundaaan pada main thread bahkan event listener menjadi tidak bisa berjalan.

Untuk menemukan masalah ini, gunakan PageSpeed ​​Insights dan cari bagian audit Avoid long main-thread tasks.

Cara Optimasi First Input Delay (FID)

Biasanya, JavaScript memiliki dampak yang paling signifikan pada nilai FID sehingga direkomendasikan untuk mengoptimasi kode JavaScript.

Ikuti langkah di bawah ini untuk melakukannya:

1. Pecah Task Panjang Menjadi Bagian Kecil

Tingkat kesulitan: mudah

Dampak: tinggi

Saat main thread browser sibuk dan terblokir, permintaan user pun tidak bisa diproses sehingga halaman menjadi tidak responsif. Tingkat respons yang tidak mencukupi tersebut disebabkan oleh task yang berjalan lebih lama dari 50 ms.

Task JavaScript menggunakan banyak resource yang bisa mempengaruhi performa kecepatan halaman. Untuk mengatasinya, hapus task tersebut atau pecah task panjang menjadi bagian yang lebih kecil dan asinkron. Paling tidak, satu task menjadi tidak lebih lama dari 50 ms.

Oia, bisa menggunakan fungsi setTimeout untuk memecah task panjang menjadi beberapa task kecil agar main thread bisa merespons input user tanpa delay.

2. Terapkan Progressive Loading

Tingkat kesulitan: menengah

Dampak: tinggi

Website dengan loading yang cepat bisa meningkatkan pengalaman penggunanya. Ada banyak komponen seperti gambar atau task JavaScript besar yang bisa membuat web browser menjadi lambat.

Untuk mengatasi masalah ini, silakan buat kode progressive loading dengan memasukkan semua file JavaScript ke dalam bundling bundle.js. Untuk melakukannya, bisa menggunakan webpack.

Bundling juga membantu untuk meminimalkan ukuran halaman dan menghapus kode yang tidak terpakai atau memperkecilnya (minify) dengan mudah. Selain itu, bundling membuat browser hanya memuat komponen UI saat dibutuhkan saja.

3. Pindah Logic ke Server-Side

Tingkat kesulitan: sulit

Dampak: tinggi

Server-side rendering (SSR/Rendering sisi server) adalah proses untuk menampilkan halaman web pada server.

Dengan server-side render, halaman akan ditampilkan dengan cepat tanpa harus menunggu resource tersedia. Solusi ini bisa mengatasi masalah halaman yang diindeks dan crawl budget, yang tentunya bermanfaat untuk memaksimalkan SEO.

Selain itu, server-side rendering bisa meningkatkan kecepatan First Contentful Paint dan Time to Interactive (TTI) dengan mencegah pengiriman file JavaScript besar ke client. Hasilnya, loading halaman web akan menjadi lebih cepat.

Kalian bisa merender versi server-side menggunakan framework front-end, seperti Vue, React, atau Svelte. Sebelum menggunakan aplikasi ini, pastikan sudah menginstal Node.js untuk menjalankan JavaScript di server, ya.

4. Hasilkan Konten Secara Statis

Tingkat kesulitan: menengah

Dampak: tinggi

Tidak seperti server rendering, static rendering menghasilkan (generate) satu halaman HTML yang disiapkan satu kali saat build time. Cara ini memungkinkan user mengakses halaman lebih awal.

Nah, kalian bisa menggunakan static site generator, seperti Gatsby, untuk menghasilkan halaman HTML statis dari data, konten, dan template. Lalu, generator ini akan menghasilkan tampilan halaman yang bisa disajikan kepada pengguna.

Ingat ya, static rendering tidak sesuai untuk website besar yang memiliki banyak halaman atau butuh perubahan respons pada setiap permintaan. Sebab, solusi ini mengharuskan website diluncurkan dan dites, yang akan turut mempengaruhi update real-time.

5. Tinjau Eksekusi Script Pihak Ketiga

Tingkat kesulitan: sulit

Dampak: tinggi

Lamanya waktu loading bisa disebabkan oleh script pihak ketiga yang menambah fungsionalitas website, seperti live chat, iklan, dan analitik.

Kode pihak ketiga bisa menimbulkan masalah, seperti pemrosesan permintaan jaringan yang terlalu banyak ke berbagai server yang mengirimkan task JavaScript atau file gambar besar yang memblokir main thread.

Untuk meninjau script pihak ketiga, silakan menguji website di PageSpeed ​​Insights. Tool ini akan menunjukkan daftar resource pihak ketiga yang dimuat serta ukuran transfer dan waktu blokir thread utama.

Gunakan async atau defer attribute untuk mempersingkat waktu loading dalam script pihak ketiga. Maka, kalian bisa menyingkirkan masalah blocking rendering dan memicu proses loading yang lebih cepat.

Script penting yang sekiranya vital untuk loading halaman tidak akan menggunakan async atau defer attribute karena ini hanya diperuntukkan bagi script eksternal.

6. Manfaatkan Web Worker

Tingkat kesulitan: sulit

Dampak: tinggi

Web worker membantu mengurangi waktu blokir thread utama dan memperbaiki nilai FID website. Web worker memungkinkan untuk memindahkan task panjang ke background thread tanpa mengganggu user interface sehingga website menjadi lebih responsif.

Gunakan kode Worker(“path/to/worker/script”) untuk membuat worker. Kode ini bisa mengirim pesan ke kode JavaScript dengan memposting pesan ke event handler yang ditentukan oleh kode tersebut dan sebaliknya.

Selain itu, web worker bisa mengerjakan task input atau output menggunakan XMLHttpRequest atau fetch.

Untuk mempelajari cara menggunakan web worker, silakan kunjungi library berikut:

• Comlink – library kecil yang menyederhanakan penggunaan postMessage/.
• Workway – web worker exporter.
• Workerize – webpack loader yang memindahkan modul ke dalam web worker.

7. Optimalkan JavaScript yang Tidak Dibutuhkan

Tingkat kesulitan: sulit

Dampak: tinggi

Task JavaScript yang terlalu banyak butuh waktu lama untuk diuraikan dan dieksekusi. Akibatnya adalah waktu respons browser pun tertunda. Browser akan berhenti apabila menemukan tag script yang terkait dengan kode JavaScript eksternal. Makanya, jalankan kode yang dibutuhkan saja.

Ada beberapa cara optimasi JavaScript, misalnya code-split dan defer JavaScript yang kurang penting. Sebelum mulai, bisa menggunakan tab Coverage di Chrome DevTools untuk mengecek seberapa banyak JavaScript yang tidak terpakai di halaman web.

Code-split memungkinkan untuk memisahkan bundle JavaScript menjadi bagian-bagian kecil dan memuat halaman saat dibutuhkan saja. Langkah ini juga dikenal sebagai lazy loading.

Sementara itu, untuk melakukan defer task Javascript apapun yang bersifat kurang penting, selalu gunakan async atau defer untuk script yang tidak diperlukan bagi critical rendering path atau above the fold.

8. Perbaiki Penggunaan Polyfill

Tingkat kesulitan: sulit

Dampak: rendah

Polyfill adalah kode yang digunakan untuk menyediakan fitur modern pada browser lama yang tidak mendukungnya secara native.

Contohnya saat menggunakan sintaksis JavaScript modern dan API browser untuk menulis kode, perlu melakukan transpile dan menyediakan polyfill agar fitur modern tersebut bisa berjalan di browser versi lama.

Penggunaan polyfill bisa menciptakan lebih banyak bundle yang membutuhkan waktu lebih lama untuk dimuat pada browser. Penting untuk meminimalkan polyfill yang tidak digunakan.

Untuk mempersingkat waktu loading halaman web, silakan gunakan compiler JavaScript seperti Babel, dan gunakan @babel/preset-env untuk menyertakan polyfill yang dibutuhkan bagi browser versi lama.

Kalian juga bisa mengurangi penggunaan polyfill yang tidak digunakan dengan mengaktifkan opsi bugfix pada versi Babel 7.9.

Alternatifnya, deliver dua bundle yang terpisah dengan menggunakan module/nomodule untuk mengoptimalkan polyfill.

Nah, bisa disimpulkan bahwa website yang responsif dapat memberi dampak signifikan pada user experience situs. Oleh karena itu, penting untuk melakukan tes dan analisis Core Web Vitals, termasuk First Input Delay (FID) agar kalian juga bisa ikut serta meningkatkan performa halaman website.

Selamat mencoba dan tunggu info-info menarik lainnya dari kami, ya 🙂