Dengan menurunkan TBT 30 kali lipat dan bermigrasi ke Next.js, The Ecomonic Times mengurangi INP hampir empat kali lipat, sehingga menghasilkan penurunan rasio pantulan sebesar 50% dan peningkatan pageview sebesar 43%.
Interaction to Next Paint (INP) adalah metrik yang menilai responsivitas situs terhadap input pengguna. Respons yang baik berarti halaman merespons interaksi pengguna dengan cepat. Makin rendah INP halaman, makin baik responsnya terhadap interaksi pengguna.
Awal yang tidak jelas
Saat Google awalnya memperkenalkan INP sebagai metrik eksperimental dengan potensi untuk berkembang menjadi salah satu metrik Core Web Vitals, tim Economic Times mengambil tantangan untuk memperbaikinya sebelum lulus menjadi salah satu, karena menyediakan pengalaman pengguna kelas dunia sangat penting bagi nilai bisnis inti kami.
INP telah menjadi salah satu metrik yang paling sulit untuk dipecahkan sejauh ini. Pada awalnya, kami tidak memahami cara mengukur INP secara efektif. Yang membuatnya semakin sulit adalah kurangnya dukungan komunitas—termasuk sebagian besar penyedia Real User Monitoring (RUM) yang belum mendukungnya. Namun, kami memiliki alat RUM Google seperti Laporan Pengalaman Pengguna Chrome (CrUX), library JavaScript web-vitals, dan alat lainnya yang mendukungnya, yang memberi kami gambaran tentang posisi kami saat kami mengevaluasi jalur ke depan. INP kami mendekati 1.000 milidetik pada tingkat asal saat kami memulai.
Satu hal yang muncul saat memperbaiki INP di bidang adalah salah satu metrik lab yang harus ditargetkan adalah Total Blocking Time (TBT). TBT sudah didokumentasikan dengan baik dan didukung oleh komunitas. Meskipun sudah memenuhi nilai minimum untuk Data Web Inti, kami belum mencapai performa yang baik di bagian depan TBT, karena waktu yang diperlukan lebih dari 3 detik saat kami memulai.
Apa yang dimaksud dengan TBT, dan langkah apa yang kita ambil untuk meningkatkannya?
TBT adalah metrik lab yang mengukur responsivitas halaman web terhadap input pengguna selama pemuatan halaman. Setiap tugas yang membutuhkan waktu lebih dari 50 milidetik untuk dijalankan dianggap sebagai tugas yang panjang, dan waktu setelah ambang batas 50 milidetik dikenal sebagai waktu pemblokiran.
TBT dihitung dengan menjumlahkan waktu pemblokiran semua tugas panjang selama pemuatan halaman. Misalnya, jika ada dua tugas panjang selama pemuatan, waktu pemblokiran ditentukan sebagai berikut:
- Tugas A membutuhkan waktu 80 milidetik (30 milidetik lebih dari 50 milidetik).
- Tugas B membutuhkan waktu 100 milidetik (50 milidetik lebih dari 50 milidetik).
TBT halaman akan menjadi: 80 milidetik (30 + 50). Makin rendah TBT, makin baik, dan TBT juga berhubungan baik dengan INP.
Berikut adalah perbandingan lab singkat tentang TBT kami sebelum dan sesudah mengambil langkah-langkah untuk meningkatkannya:
Meminimalkan pekerjaan thread utama
Thread utama browser menangani semuanya mulai dari mengurai HTML, membangun DOM, hingga mengurai CSS dan menerapkan gaya, serta mengevaluasi dan mengeksekusi JavaScript. Thread utama juga menangani interaksi pengguna—yaitu, klik, ketuk, dan penekanan tombol. Jika thread utama sibuk melakukan pekerjaan lain, thread tersebut mungkin tidak merespons input pengguna secara efisien, dan dapat menyebabkan pengalaman pengguna yang tersendat.
Ini adalah tugas yang paling sulit bagi kami, karena kami memiliki algoritma sendiri guna mendeteksi identitas pengguna untuk menayangkan iklan berdasarkan status langganan dan skrip pihak ketiga untuk pengujian A/B, analisis, dan lainnya.
Pada awalnya, kami mengambil langkah-langkah kecil, seperti tidak memprioritaskan pemuatan aset bisnis yang kurang penting. Kedua, kami menggunakan requestIdleCallback untuk pekerjaan nonkritis, yang dapat membantu mengurangi TBT.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
Menentukan waktu tunggu direkomendasikan saat menggunakan requestIdleCallback, karena memastikan bahwa jika waktu yang diberikan telah berlalu dan callback belum dipanggil, callback akan segera dieksekusi setelah waktu tunggu habis.
Meminimalkan waktu evaluasi skrip
Kami juga memuat library pihak ketiga secara lambat menggunakan Komponen yang dapat dimuat. Kami juga menghapus JavaScript dan CSS yang tidak digunakan dengan membuat profil halaman menggunakan alat cakupan di Chrome DevTools. Hal ini membantu kami mengidentifikasi area yang memerlukan tree shaking untuk mengirimkan lebih sedikit kode selama pemuatan halaman, sehingga mengurangi ukuran paket awal aplikasi.
Kurangi ukuran DOM
Per Lighthouse, ukuran DOM yang besar meningkatkan penggunaan memori, menyebabkan rekalkulasi gaya yang lebih lama, dan menghasilkan perubahan posisi/geometri tata letak yang mahal.
Kami mengurangi jumlah simpul DOM dengan dua cara:
- Pertama, kami merender item menu kami atas permintaan pengguna (saat diklik). Ini mengurangi ukuran DOM sekitar 1.200 node.
- Kedua, kita lambat memuat widget yang kurang penting.
Karena semua upaya ini, kami menurunkan TBT secara signifikan, dan INP kami juga berkurang hampir 50%:
Pada tahap ini, kami hampir kehabisan kemenangan mudah untuk lebih mengurangi TBT (dan INP melalui proxy), tetapi kami tahu bahwa masih ada banyak hal yang perlu ditingkatkan. Inilah saatnya kami memutuskan untuk mengupgrade boilerplate UI kustom kami ke React versi terbaru bersama dengan Next.js untuk memanfaatkan hook dengan lebih baik guna menghindari rendering ulang komponen yang tidak perlu.
Karena pembaruan yang lebih sering dan traffic yang relatif lebih rendah dibandingkan dengan bagian lain di situs, kami mulai memigrasikan halaman topik kami ke Next.js. Kami juga menggunakan PartyTown untuk memindahkan pekerjaan thread utama yang berat ke pekerja web, beserta teknik seperti requestIdleCallBack untuk menunda tugas yang tidak penting.
Bagaimana peningkatan INP membantu The Economic Times?
TBT dan INP saat ini di asal
Pada saat artikel ini dipublikasikan, TBT untuk origin kami adalah 120 milidetik, turun dari 3.260 milidetik saat kami memulai upaya pengoptimalan. Demikian pula, INP untuk asal kami adalah 257 milidetik setelah upaya pengoptimalan kami, turun dari lebih dari 1.000 milidetik.
Tren INP CrUX
Traffic yang diterima pada halaman topik mewakili sebagian kecil dari keseluruhan traffic. Oleh karena itu, ini adalah tempat yang ideal untuk eksperimen. Hasil CrUX beserta hasil bisnis sangat menggembirakan, dan membuat kami memperluas upaya kami di seluruh situs untuk memperoleh manfaat lebih lanjut.
Analisis TBT Akamai mPulse
Kami menggunakan Akamai mPulse sebagai solusi RUM, yang mengukur TBT di lapangan. Kami mengamati penurunan TBT yang konsisten, yang secara jelas menunjukkan hasil dari upaya kami untuk mengurangi INP. Seperti yang terlihat pada screenshot di bawah, nilai TBT akhirnya turun dari sekitar 5 detik menjadi sekitar 200 milidetik di lapangan.
Hasil bisnis
Secara keseluruhan, upaya kami untuk menurunkan TBT 30 kali lipat, bersama dengan migrasi ke Next.js membantu kami mengurangi INP hampir 4 kali lipat, yang pada akhirnya menghasilkan penurunan rasio pantulan sebesar 50% dan peningkatan pageview sebesar 43% di halaman topik.
Kesimpulan
Ringkasnya, INP secara ekstensif membantu menentukan masalah performa runtime di bagian-bagian situs Economic Times. Hal ini telah terbukti menjadi salah satu metrik paling efektif untuk memberi dampak positif terhadap hasil bisnis. Karena angka yang sangat menggembirakan yang kami lihat sebagai hasil dari upaya ini, kami termotivasi untuk memperluas skala upaya pengoptimalan ke area lain dalam situs web kami dan menuai keuntungan tambahan.