Pelajari cara mengoptimalkan Interaction to Next Paint situs Anda.
Dipublikasikan: 19 Mei 2023, Terakhir diperbarui: 2 September 2025
Interaction to Next Paint (INP) adalah metrik Core Web Vital yang stabil yang menilai responsivitas keseluruhan halaman terhadap interaksi pengguna dengan mengamati latensi semua interaksi yang memenuhi syarat yang terjadi selama kunjungan pengguna ke suatu halaman. Nilai INP akhir adalah interaksi terpanjang yang diamati (terkadang mengabaikan pencilan).
Untuk memberikan pengalaman pengguna yang baik, situs harus berupaya memiliki Interaction to Next Paint sebesar 200 milidetik atau kurang. Agar Anda mencapai target ini bagi sebagian besar pengguna Anda, batas yang tepat untuk diukur adalah persentil ke-75 dari pemuatan halaman, yang dikelompokkan berdasarkan 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 berisiko.
Meningkatkan INP memerlukan waktu dan upaya, tetapi hasilnya adalah pengalaman pengguna yang lebih baik. Dalam panduan ini, jalur untuk meningkatkan INP akan dibahas.
Mencari tahu penyebab INP buruk
Sebelum dapat memperbaiki interaksi yang lambat, Anda memerlukan data untuk mengetahui apakah INP situs Anda buruk atau perlu ditingkatkan. Setelah memiliki informasi tersebut, Anda dapat beralih ke lab untuk mulai mendiagnosis interaksi yang lambat, dan berupaya menemukan solusinya.
Menemukan interaksi lambat di lapangan
Idealnya, perjalanan Anda dalam mengoptimalkan INP akan dimulai dengan data lapangan. Idealnya, 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 ketukan), dan informasi berharga lainnya.
Jika Anda tidak mengandalkan penyedia RUM untuk mendapatkan data lapangan, panduan data lapangan INP menyarankan penggunaan PageSpeed Insights untuk melihat data Chrome User Experience Report (CrUX) guna membantu mengisi kesenjangan. CrUX adalah set data Google untuk program Core Web Vitals dan memberikan ringkasan metrik tingkat tinggi 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 sendiri untuk melengkapi apa yang tersedia di CrUX.
Mendiagnosis interaksi lambat di lab
Idealnya, Anda akan memulai 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 penggunaan umum dan menguji interaksi di sepanjang prosesnya, serta berinteraksi dengan halaman selama pemuatan—saat thread utama sering kali paling sibuk—untuk mengidentifikasi interaksi yang 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 callback peristiwa untuk berjalan hingga selesai.
- Penundaan presentasi, yaitu waktu yang diperlukan browser untuk menampilkan frame berikutnya yang berisi hasil visual interaksi.
Jumlah dari ketiga subbagian ini adalah total latensi interaksi. Setiap subbagian interaksi berkontribusi pada jumlah waktu latensi interaksi total, jadi penting untuk mengetahui cara mengoptimalkan setiap bagian interaksi agar berjalan secepat 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 pemuatan, penguraian, dan kompilasi skrip), penanganan pengambilan, fungsi timer, atau bahkan dari interaksi lain yang terjadi secara berurutan dan tumpang-tindih satu sama lain.
Apa pun sumber penundaan input interaksi, Anda harus mengurangi penundaan input seminimal mungkin agar interaksi dapat mulai menjalankan callback peristiwa sesegera mungkin.
Hubungan antara evaluasi skrip dan tugas berdurasi lama selama startup
Aspek penting interaktivitas dalam siklus proses halaman adalah selama startup. Saat dimuat, halaman akan dirender terlebih dahulu, tetapi penting untuk diingat bahwa meskipun halaman telah dirender, bukan berarti pemuatan halaman selesai dimuat. Bergantung pada jumlah resource yang diperlukan halaman agar berfungsi sepenuhnya, pengguna mungkin mencoba berinteraksi dengan halaman saat halaman masih dimuat.
Satu hal yang dapat memperpanjang penundaan input interaksi saat halaman dimuat adalah evaluasi skrip. Setelah file JavaScript diambil dari jaringan, browser masih memiliki pekerjaan yang harus dilakukan sebelum JavaScript tersebut dapat berjalan; pekerjaan tersebut mencakup penguraian skrip untuk memeriksa apakah sintaksisnya valid, mengompilasinya menjadi bytecode, dan akhirnya mengeksekusinya.
Bergantung pada ukuran skrip, pekerjaan ini dapat menyebabkan tugas berdurasi lama di thread utama, yang akan menunda browser merespons interaksi pengguna lainnya. Agar halaman Anda tetap responsif terhadap input pengguna selama pemuatan halaman, penting untuk memahami hal yang dapat Anda lakukan untuk mengurangi kemungkinan tugas yang lama selama pemuatan halaman agar halaman tetap cepat.
Mengoptimalkan callback peristiwa
Penundaan input hanyalah bagian pertama dari apa yang diukur INP. Anda juga harus memastikan bahwa callback peristiwa yang berjalan sebagai respons terhadap interaksi pengguna dapat diselesaikan secepat mungkin.
Sering-seringlah mengalah pada thread utama
Saran umum terbaik dalam mengoptimalkan callback peristiwa adalah melakukan pekerjaan sesedikit mungkin di dalamnya. Namun, logika interaksi Anda mungkin kompleks, dan Anda mungkin hanya dapat mengurangi sedikit pekerjaan yang dilakukan.
Jika Anda mendapati hal ini terjadi di situs Anda, hal berikutnya yang dapat Anda coba adalah membagi pekerjaan dalam callback peristiwa menjadi tugas-tugas terpisah. Hal ini mencegah pekerjaan kolektif menjadi tugas berdurasi lama yang memblokir thread utama, sehingga memungkinkan interaksi lain yang seharusnya menunggu di thread utama berjalan lebih cepat.
setTimeout adalah salah satu cara untuk memecah tugas, karena callback yang diteruskan ke dalamnya berjalan dalam tugas baru. Anda dapat menggunakan setTimeout sendiri atau mengabstraksi penggunaannya ke dalam fungsi terpisah untuk menghasilkan hasil yang lebih ergonomis.
Menyerahkan secara sembarangan lebih baik daripada tidak menyerahkan sama sekali—namun, ada cara yang lebih bernuansa untuk menyerahkan ke thread utama, dan itu hanya melibatkan penyerahan segera setelah callback peristiwa yang memperbarui antarmuka pengguna sehingga logika rendering dapat berjalan lebih cepat.
Menyerahkan 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. 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 rich text yang memformat teks saat Anda mengetik, tetapi juga memperbarui aspek lain UI sebagai respons terhadap apa yang telah Anda tulis (seperti jumlah kata, penyorotan 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 kehilangan pekerjaan apa pun.
Dalam contoh ini, empat hal berikut harus terjadi sebagai respons terhadap karakter yang diketik oleh pengguna. Namun, hanya item pertama yang perlu dilakukan sebelum frame berikutnya ditampilkan.
- Perbarui kotak teks dengan apa yang diketik pengguna dan terapkan pemformatan yang diperlukan.
- Perbarui bagian UI yang menampilkan jumlah kata saat ini.
- Menjalankan logika untuk memeriksa kesalahan ejaan.
- Menyimpan 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 update yang tidak penting hingga setelah frame berikutnya dapat mengurangi durasi pemrosesan, sehingga mengurangi latensi interaksi secara keseluruhan.
Meskipun penggunaan setTimeout() di dalam panggilan requestAnimationFrame() dalam contoh kode sebelumnya memang agak rumit, ini adalah metode efektif yang berfungsi di semua browser untuk mencegah kode yang tidak penting memblokir frame berikutnya.
Menghindari thrashing tata letak
Layout thrashing—terkadang disebut tata letak sinkron paksa—adalah masalah performa rendering saat tata letak terjadi secara sinkron. Hal ini terjadi saat Anda memperbarui gaya di JavaScript, lalu membacanya dalam tugas yang sama—dan ada banyak properti di JavaScript yang dapat menyebabkan thrashing tata letak.
Layout thrashing adalah bottleneck performa karena dengan memperbarui gaya, lalu segera meminta nilai gaya tersebut di JavaScript, browser dipaksa untuk melakukan pekerjaan tata letak sinkron yang seharusnya dapat ditunggu untuk dilakukan secara asinkron nanti setelah callback peristiwa selesai berjalan.
Meminimalkan penundaan presentasi
Penundaan presentasi dari tanda interaksi mencakup dari saat callback peristiwa interaksi selesai berjalan, hingga titik saat browser dapat menggambar frame berikutnya yang menampilkan perubahan visual yang dihasilkan.
Minimalkan ukuran DOM
Jika DOM halaman berukuran kecil, pekerjaan rendering biasanya selesai dengan cepat. Namun, saat DOM menjadi sangat besar, pekerjaan rendering cenderung diskalakan seiring dengan bertambahnya ukuran DOM. Hubungan antara pekerjaan rendering dan ukuran DOM tidak bersifat linear, tetapi DOM yang besar memerlukan lebih banyak pekerjaan untuk dirender daripada DOM yang kecil. DOM yang besar menimbulkan masalah dalam dua kasus:
- Selama render halaman awal, saat DOM yang besar memerlukan banyak pekerjaan untuk merender status awal halaman.
- Sebagai respons terhadap interaksi pengguna, DOM yang besar dapat menyebabkan update rendering menjadi sangat mahal, sehingga meningkatkan waktu yang diperlukan browser untuk menampilkan frame berikutnya.
Perlu diingat bahwa ada beberapa kasus saat 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 akan berhasil sampai batas tertentu.
Menggunakan content-visibility untuk merender elemen di luar layar secara lambat
Salah satu cara untuk membatasi jumlah pekerjaan rendering selama pemuatan halaman dan pekerjaan rendering sebagai respons terhadap interaksi pengguna adalah dengan mengandalkan properti content-visibility CSS, yang secara efektif menghasilkan rendering lambat elemen saat mendekati area pandang. Meskipun content-visibility memerlukan latihan agar dapat digunakan secara efektif, sebaiknya selidiki apakah 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 mengurai HTML menjadi DOM, browser harus menerapkan gaya ke DOM, melakukan penghitungan tata letak, dan kemudian merender tata letak tersebut. Biaya ini tidak dapat dihindari, tetapi cara Anda merender HTML sangatlah penting.
Saat server mengirimkan HTML, HTML tersebut akan tiba di browser sebagai streaming. Streaming berarti respons HTML dari server tiba dalam bentuk potongan. Browser mengoptimalkan cara menangani streaming dengan mengurai potongan streaming tersebut secara bertahap 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 HTML, pendekatan umum dimulai dengan sedikit HTML awal, lalu JavaScript digunakan untuk mengisi area konten. Pembaruan berikutnya pada area konten tersebut juga terjadi sebagai hasil dari interaksi pengguna. Hal ini biasanya disebut model aplikasi web satu halaman (SPA). Salah satu kelemahan pola ini adalah, dengan merender HTML dengan JavaScript di klien, Anda tidak hanya mendapatkan biaya pemrosesan JavaScript untuk membuat HTML tersebut, tetapi browser juga tidak akan menghasilkan apa pun hingga selesai mengurai HTML tersebut, dan merendernya.
Namun, penting untuk diingat bahwa situs yang bukan SPA pun mungkin akan melibatkan sejumlah rendering HTML melalui JavaScript sebagai hasil dari interaksi. Hal ini umumnya tidak masalah, asalkan Anda tidak merender HTML dalam jumlah besar di klien, yang dapat menunda presentasi frame berikutnya. Namun, penting untuk memahami implikasi performa dari pendekatan ini terhadap rendering HTML di browser, dan pengaruhnya terhadap responsivitas situs Anda terhadap input pengguna jika Anda merender banyak HTML menggunakan JavaScript.
Kesimpulan
Meningkatkan INP situs Anda adalah proses yang berulang. Saat Anda memperbaiki interaksi yang 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 persistensi. Seiring waktu, Anda dapat meningkatkan responsivitas halaman ke tingkat yang membuat pengguna puas dengan pengalaman yang Anda berikan kepada mereka. Kemungkinan besar, saat mengembangkan fitur baru untuk pengguna, Anda mungkin perlu melalui proses yang sama dalam mengoptimalkan interaksi khusus untuk mereka. Hal ini akan membutuhkan waktu dan upaya, tetapi waktu dan upaya tersebut akan sepadan.