Pelajari cara mengoptimalkan Interaction to Next Paint situs Anda.
Dipublikasikan: 19 Mei 2023, Terakhir diperbarui: 9 September 2025
Interaction to Next Paint (INP) adalah metrik Data Web Inti yang stabil yang menilai responsivitas keseluruhan halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi yang memenuhi syarat yang terjadi selama masa aktif kunjungan pengguna ke suatu halaman. Nilai INP akhir adalah interaksi terpanjang yang diamati (terkadang mengabaikan pencilan).
Untuk memberikan pengalaman pengguna yang baik, situs harus mengusahakan agar Interaction to Next Paint 200 milidetik atau kurang. Untuk mencapai target ini bagi sebagian besar pengguna Anda, nilai minimum yang baik untuk diukur adalah persentil ke-75 pemuatan halaman, yang disegmentasikan di seluruh perangkat seluler dan desktop.
Bergantung pada situsnya, mungkin ada sedikit atau tidak ada interaksi—seperti halaman yang sebagian besar berisi teks dan gambar dengan sedikit atau tanpa elemen interaktif. Atau, dalam kasus situs seperti editor teks atau game, mungkin ada ratusan—bahkan ribuan—interaksi. Dalam kedua kasus tersebut, jika INP tinggi, pengalaman pengguna akan terganggu.
Meningkatkan INP memerlukan waktu dan upaya, tetapi imbalannya adalah pengalaman pengguna yang lebih baik. Dalam panduan ini, jalur untuk meningkatkan INP akan dijelaskan.
Cari tahu penyebab INP yang buruk
Sebelum dapat memperbaiki interaksi lambat, Anda memerlukan data untuk mengetahui apakah INP situs Anda buruk atau perlu ditingkatkan. Setelah mendapatkan informasi tersebut, Anda dapat masuk ke lab untuk mulai mendiagnosis interaksi yang lambat, dan berupaya menemukan solusi.
Menemukan interaksi lambat di lapangan
Idealnya, perjalanan Anda dalam mengoptimalkan INP akan dimulai dengan data lapangan. Yang terbaik, data lapangan dari penyedia Pemantauan Pengguna Nyata (RUM) tidak hanya akan memberi Anda nilai INP halaman, tetapi juga data kontekstual yang menyoroti interaksi spesifik yang bertanggung jawab atas nilai INP itu sendiri, apakah interaksi terjadi selama atau setelah pemuatan halaman, jenis interaksi (klik, penekanan tombol, atau ketuk), dan informasi berharga lainnya.
Jika Anda tidak mengandalkan penyedia RUM untuk mendapatkan data kolom, panduan data kolom INP menyarankan penggunaan PageSpeed Insights untuk melihat data Laporan Pengalaman Pengguna Chrome (CrUX) guna membantu mengisi kesenjangan. CrUX adalah set data resmi program Core Web Vitals dan memberikan ringkasan tingkat tinggi metrik untuk jutaan situs, termasuk INP. Namun, CrUX sering kali tidak memberikan data kontekstual yang akan Anda dapatkan dari penyedia RUM untuk membantu Anda menganalisis masalah. Oleh karena itu, sebaiknya situs tetap menggunakan penyedia RUM jika memungkinkan, atau menerapkan solusi RUM mereka sendiri untuk melengkapi apa yang tersedia di CrUX.
Mendiagnosis interaksi lambat di lab
Idealnya, Anda harus mulai melakukan pengujian di lab setelah memiliki data lapangan yang menunjukkan bahwa Anda memiliki interaksi yang lambat. Jika tidak ada data lapangan, ada beberapa strategi untuk mengidentifikasi interaksi lambat di lab. Strategi tersebut mencakup mengikuti alur pengguna umum dan menguji interaksi di sepanjang proses, serta berinteraksi dengan halaman selama pemuatan—saat thread utama sering kali paling sibuk—untuk mengidentifikasi interaksi lambat selama bagian penting dari pengalaman pengguna tersebut.
Mengoptimalkan interaksi
Setelah Anda mengidentifikasi interaksi yang lambat dan dapat mereproduksinya secara manual di lab, langkah berikutnya adalah mengoptimalkannya.
Interaksi dapat dibagi menjadi tiga subbagian:
- Penundaan input, yang dimulai saat pengguna memulai interaksi dengan halaman, dan berakhir saat callback peristiwa untuk interaksi mulai berjalan.
- Durasi pemrosesan, yang terdiri dari waktu yang diperlukan agar callback peristiwa berjalan hingga selesai.
- Penundaan presentasi, yaitu waktu yang diperlukan browser untuk menampilkan frame berikutnya yang berisi hasil visual interaksi.
Jumlah ketiga subbagian ini adalah total latensi interaksi. Setiap subbagian interaksi menyumbangkan sejumlah waktu ke latensi interaksi total, jadi penting untuk mengetahui cara mengoptimalkan setiap bagian interaksi agar berjalan sesingkat mungkin.
Mengidentifikasi dan mengurangi penundaan input
Saat pengguna berinteraksi dengan halaman, bagian pertama dari interaksi tersebut adalah penundaan input. Bergantung pada aktivitas lain di halaman, penundaan input dapat berlangsung cukup lama. Hal ini dapat disebabkan oleh aktivitas yang terjadi di thread utama (mungkin karena skrip dimuat, diuraikan, dan dikompilasi), penanganan pengambilan, fungsi timer, atau bahkan dari interaksi lain yang terjadi secara berurutan dengan cepat dan tumpang-tindih satu sama lain.
Apa pun sumber penundaan input interaksi, Anda harus mengurangi penundaan input hingga minimum sehingga interaksi dapat mulai menjalankan callback peristiwa sesegera mungkin.
Hubungan antara evaluasi skrip dan tugas panjang selama startup
Aspek penting interaktivitas dalam siklus proses halaman adalah selama startup. Saat halaman dimuat, halaman akan dirender terlebih dahulu, tetapi penting untuk diingat bahwa hanya karena halaman telah dirender, tidak berarti halaman telah selesai dimuat. Bergantung pada jumlah resource yang diperlukan agar halaman berfungsi sepenuhnya, pengguna mungkin mencoba berinteraksi dengan halaman saat halaman masih dimuat.
Salah satu hal yang dapat memperpanjang penundaan input interaksi saat halaman dimuat adalah evaluasi skrip. Setelah file JavaScript diambil dari jaringan, browser masih harus melakukan beberapa tugas sebelum JavaScript tersebut dapat berjalan; tugas tersebut mencakup mengurai skrip untuk memeriksa apakah sintaksisnya valid, mengompilasinya menjadi bytecode, dan akhirnya mengeksekusinya.
Bergantung pada ukuran skrip, pekerjaan ini dapat memunculkan tugas yang berjalan lama di thread utama, yang akan menunda respons browser terhadap interaksi pengguna lainnya. Agar halaman Anda tetap responsif terhadap input pengguna selama pemuatan halaman, penting untuk memahami apa yang dapat Anda lakukan untuk mengurangi kemungkinan tugas yang panjang selama pemuatan halaman sehingga halaman tetap cepat.
Mengoptimalkan callback peristiwa
Penundaan input hanyalah bagian pertama dari yang diukur INP. Anda juga harus memastikan bahwa callback peristiwa yang berjalan sebagai respons terhadap interaksi pengguna dapat diselesaikan secepat mungkin.
Sering-seringlah mengizinkan thread utama berjalan
Saran umum terbaik dalam mengoptimalkan callback peristiwa adalah melakukan sesedikit mungkin pekerjaan di dalamnya. Namun, logika interaksi Anda mungkin kompleks, dan Anda mungkin hanya dapat mengurangi sedikit pekerjaan yang mereka lakukan.
Jika Anda menemukan hal ini terjadi pada situs Anda, hal berikutnya yang dapat Anda coba adalah memecah pekerjaan dalam callback peristiwa menjadi tugas terpisah. Hal ini mencegah tugas kolektif menjadi tugas panjang yang memblokir thread utama, sehingga memungkinkan interaksi lain yang seharusnya menunggu di thread utama untuk berjalan lebih cepat.
setTimeout adalah salah satu cara untuk memecah tugas, karena callback yang diteruskan ke tugas tersebut berjalan dalam tugas baru. Anda dapat menggunakan setTimeout dengan sendirinya atau mengabstraksi penggunaannya ke dalam fungsi terpisah untuk hasil yang lebih ergonomis.
Menyerahkan secara tidak pandang bulu lebih baik daripada tidak menyerahkan sama sekali—namun, ada cara yang lebih bernuansa untuk menyerahkan ke thread utama, dan hal itu hanya melibatkan penyerahan segera setelah callback peristiwa yang memperbarui antarmuka pengguna sehingga logika rendering dapat berjalan lebih cepat.
Memberikan hasil untuk memungkinkan pekerjaan rendering terjadi lebih cepat
Teknik penyerahan yang lebih canggih melibatkan penataan kode dalam callback peristiwa untuk membatasi apa yang dijalankan hanya pada logika yang diperlukan untuk menerapkan update visual untuk frame berikutnya. Semua hal lainnya dapat ditunda ke tugas berikutnya. Hal ini tidak hanya membuat callback tetap ringan dan cepat, tetapi juga meningkatkan waktu rendering untuk interaksi dengan tidak mengizinkan update visual memblokir kode callback peristiwa.
Misalnya, bayangkan editor teks kaya yang memformat teks saat Anda mengetik, tetapi juga memperbarui aspek lain dari UI sebagai respons terhadap apa yang telah Anda tulis (seperti jumlah kata, menandai kesalahan ejaan, dan masukan visual penting lainnya). Selain itu, aplikasi mungkin juga perlu menyimpan apa yang telah Anda tulis sehingga jika Anda keluar dan kembali, Anda tidak akan kehilangan pekerjaan.
Dalam contoh ini, empat hal berikut harus terjadi sebagai respons terhadap karakter yang diketik oleh pengguna. Namun, hanya item pertama yang perlu diselesaikan sebelum frame berikutnya ditampilkan.
- Perbarui kotak teks dengan apa yang diketik pengguna dan terapkan format yang diperlukan.
- Perbarui bagian UI yang menampilkan jumlah kata saat ini.
- Jalankan logika untuk memeriksa kesalahan ejaan.
- Simpan perubahan terbaru (baik secara lokal maupun ke database jarak jauh).
Kode untuk melakukannya mungkin terlihat seperti berikut:
textBox.addEventListener('input', (inputEvent) => {
// Update the UI immediately, so the changes the user made
// are visible as soon as the next frame is presented.
updateTextBox(inputEvent);
// Use `setTimeout` to defer all other work until at least the next
// frame by queuing a task in a `requestAnimationFrame()` callback.
requestAnimationFrame(() => {
setTimeout(() => {
const text = textBox.textContent;
updateWordCount(text);
checkSpelling(text);
saveChanges(text);
}, 0);
});
});
Visualisasi berikut menunjukkan cara menunda pembaruan tidak penting hingga setelah frame berikutnya dapat mengurangi durasi pemrosesan dan dengan demikian mengurangi latensi interaksi secara keseluruhan.
Meskipun penggunaan setTimeout() di dalam panggilan requestAnimationFrame() dalam contoh kode sebelumnya memang agak esoteris, ini adalah metode efektif yang berfungsi di semua browser untuk mencegah kode non-kritis memblokir frame berikutnya.
Menghindari thrashing tata letak
Pengoptimalan tata letak—terkadang disebut tata letak sinkron paksa—adalah masalah performa rendering yang menyebabkan tata letak terjadi secara sinkron. Hal ini terjadi saat Anda memperbarui gaya visual di JavaScript, lalu membacanya dalam tugas yang sama—dan ada banyak properti di JavaScript yang dapat menyebabkan thrashing tata letak.
Layout thrashing adalah hambatan performa karena dengan memperbarui gaya lalu segera meminta nilai gaya tersebut di JavaScript, browser dipaksa untuk melakukan pekerjaan tata letak sinkron yang seharusnya dapat ditunda untuk dilakukan secara asinkron nanti setelah callback peristiwa selesai berjalan.
Meminimalkan penundaan presentasi
Penundaan presentasi interaksi menandai rentang waktu mulai dari saat callback peristiwa interaksi selesai berjalan, hingga saat browser dapat melukis frame berikutnya yang menunjukkan perubahan visual yang dihasilkan.
Meminimalkan ukuran DOM
Jika DOM halaman kecil, tugas rendering biasanya selesai dengan cepat. Namun, saat DOM menjadi sangat besar, tugas rendering cenderung diskalakan dengan peningkatan ukuran DOM. Hubungan antara pekerjaan rendering dan ukuran DOM tidak bersifat linear, tetapi DOM besar memerlukan lebih banyak pekerjaan untuk dirender daripada DOM kecil. DOM besar bermasalah dalam dua kasus:
- Selama render halaman awal, saat DOM besar memerlukan banyak pekerjaan untuk merender status awal halaman.
- Sebagai respons terhadap interaksi pengguna, DOM yang besar dapat menyebabkan update rendering menjadi sangat mahal, dan oleh karena itu meningkatkan waktu yang diperlukan browser untuk menampilkan frame berikutnya.
Perlu diingat bahwa ada kasus ketika DOM besar tidak dapat dikurangi secara signifikan. Meskipun ada pendekatan yang dapat Anda lakukan untuk mengurangi ukuran DOM, seperti meratakan DOM atau menambahkan ke DOM selama interaksi pengguna untuk menjaga ukuran DOM awal tetap kecil, teknik tersebut mungkin hanya dapat dilakukan hingga batas tertentu.
Menggunakan content-visibility untuk merender elemen di luar layar secara lambat
Salah satu cara untuk membatasi jumlah tugas rendering selama pemuatan halaman dan tugas rendering sebagai respons terhadap interaksi pengguna adalah dengan mengandalkan properti CSS content-visibility, yang secara efektif sama dengan merender elemen secara lambat saat mendekati area tampilan. Meskipun content-visibility memerlukan latihan untuk digunakan secara efektif, ada baiknya Anda menyelidikinya jika hasilnya adalah waktu rendering yang lebih rendah yang dapat meningkatkan INP halaman Anda.
Perhatikan biaya performa saat merender HTML menggunakan JavaScript
Jika ada HTML, ada penguraian HTML, dan setelah browser selesai menguraikan HTML menjadi DOM, browser harus menerapkan gaya, melakukan perhitungan tata letak, dan selanjutnya merender tata letak tersebut. Ini adalah biaya yang tidak dapat dihindari, tetapi cara Anda merender HTML sangat penting.
Saat server mengirimkan HTML, HTML akan tiba di browser sebagai aliran. Streaming berarti respons HTML dari server tiba dalam potongan. Browser mengoptimalkan cara menangani aliran dengan mengurai secara bertahap potongan aliran tersebut saat tiba, dan merendernya sedikit demi sedikit. Ini adalah pengoptimalan performa karena browser secara implisit menghasilkan secara berkala dan otomatis selama pemuatan halaman, dan Anda mendapatkannya secara gratis.
Meskipun kunjungan pertama ke situs mana pun akan selalu melibatkan sejumlah kecil HTML, pendekatan umum dimulai dengan sedikit HTML awal, lalu JavaScript digunakan untuk mengisi area konten. Update berikutnya pada area konten tersebut juga terjadi sebagai hasil interaksi pengguna. Ini biasanya disebut model aplikasi web satu halaman (SPA). Salah satu kekurangan pola ini adalah, dengan merender HTML dengan JavaScript di klien, Anda tidak hanya mendapatkan biaya pemrosesan JavaScript untuk membuat HTML tersebut, tetapi juga browser tidak akan melakukan yield hingga selesai mengurai HTML tersebut, dan merendernya.
Namun, penting untuk diingat bahwa bahkan situs yang bukan SPA mungkin melibatkan sejumlah rendering HTML melalui JavaScript sebagai hasil interaksi. Hal ini umumnya tidak masalah, selama Anda tidak merender HTML dalam jumlah besar di klien, yang dapat menunda presentasi frame berikutnya. Namun, penting untuk memahami implikasi performa dari pendekatan ini untuk merender HTML di browser, dan bagaimana hal ini dapat memengaruhi responsivitas situs Anda terhadap input pengguna jika Anda merender banyak HTML menggunakan JavaScript.
Kesimpulan
Meningkatkan INP situs Anda adalah proses berulang. Saat Anda memperbaiki interaksi lambat di lapangan, kemungkinan besar—terutama jika situs Anda menyediakan banyak interaktivitas—Anda akan mulai menemukan interaksi lambat lainnya, dan Anda juga perlu mengoptimalkannya.
Kunci untuk meningkatkan INP adalah kegigihan. Seiring waktu, Anda dapat membuat halaman responsif sehingga pengguna merasa puas dengan pengalaman yang Anda berikan. Kemungkinan besar, saat Anda mengembangkan fitur baru untuk pengguna, Anda mungkin perlu melalui proses yang sama dalam mengoptimalkan interaksi khusus untuk mereka. Memang akan membutuhkan waktu dan upaya, tetapi waktu dan upaya tersebut akan sangat berharga.
Gambar utama dari Unsplash, oleh David Pisnoy dan dimodifikasi sesuai dengan lisensi Unsplash.