Menurunkan TBT sebanyak 30 kali dan bermigrasi ke Next.js membantu The Ecomonic Times mengurangi INP hampir empat kali lipat, yang menghasilkan penurunan rasio pantulan sebesar 50% dan peningkatan kunjungan halaman sebesar 43%.
Interaction to Next Paint (INP) adalah metrik yang menilai daya respons situs terhadap input pengguna. Responsivitas yang baik berarti halaman cepat merespons interaksi pengguna. Semakin rendah INP halaman, semakin baik kemampuannya dalam merespons interaksi pengguna.
Awal yang kaku
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 satu, karena memberikan pengalaman pengguna kelas dunia sangat penting bagi nilai bisnis inti kami.
INP telah menjadi salah satu metrik yang paling sulit untuk diselesaikan sejauh ini. Pada awalnya, kami tidak memahami cara mengukur INP secara efektif. Kesulitannya adalah kurangnya dukungan komunitas—termasuk sebagian besar penyedia Real User Monitoring (RUM) yang belum mendukungnya. Namun, kami memiliki alat RUM Google seperti Chrome User Experience Report (CrUX), library JavaScript web-vitals, dan alat lain yang mendukungnya, yang memberi kami gambaran tentang posisi kami saat mengevaluasi jalur ke depan. INP kami mendekati 1.000 milidetik pada tingkat origin saat kami memulai.
Satu hal yang muncul saat memperbaiki INP di kolom adalah salah satu metrik lab yang ditargetkan adalah Total Blocking Time (TBT). TBT telah terdokumentasi dengan baik dan didukung oleh komunitas. Namun, meskipun sudah memenuhi nilai minimum untuk Core Web Vitals, kami tidak berperforma sebaik mungkin dalam hal TBT, karena kami sudah memulai lebih dari 3 detik.
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 dieksekusi dianggap sebagai tugas yang lama, dan waktu setelah batas 50 milidetik dikenal sebagai waktu pemblokiran.
TBT dihitung dengan menjumlahkan waktu pemblokiran semua tugas yang berlangsung lama selama pemuatan halaman. Misalnya, jika ada dua tugas panjang selama pemuatan, waktu pemblokiran ditentukan sebagai berikut:
- Tugas A memerlukan waktu 80 milidetik (30 milidetik lebih dari 50 milidetik).
- Tugas B memerlukan waktu 100 milidetik (50 milidetik lebih dari 50 milidetik).
TBT halaman akan menjadi: 80 milidetik (30 + 50). Semakin rendah TBT, semakin baik, dan TBT juga berkaitan baik dengan INP.
Berikut adalah perbandingan lab singkat dari TBT kami sebelum dan sesudah melakukan langkah-langkah untuk memperbaikinya:
Meminimalkan pekerjaan thread utama
Thread utama browser menangani semuanya mulai dari penguraian 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 mengerjakan 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.
Awalnya, kami melakukan langkah kecil, seperti tidak memprioritaskan pemuatan aset bisnis yang kurang penting. Kedua, kami menggunakan requestIdleCallback untuk pekerjaan non-kritis, 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 akan memastikan bahwa jika waktu yang diberikan telah berlalu dan callback belum dipanggil, callback akan dijalankan segera setelah waktu tunggu.
Minimalkan waktu evaluasi skrip
Kami juga memuat library pihak ketiga dengan 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. Solusi ini membantu kami mengidentifikasi area yang memerlukan tree shaking untuk mengirimkan lebih sedikit kode selama pemuatan halaman, sehingga mengurangi ukuran paket awal aplikasi.
Mengurangi ukuran DOM
Per Lighthouse, ukuran DOM yang besar meningkatkan penggunaan memori, menyebabkan penghitungan ulang gaya yang lebih lama, dan menghasilkan penyesuaian tata letak yang mahal.
Kami mengurangi jumlah node DOM dengan dua cara:
- Pertama, kami merender item menu atas permintaan pengguna (saat diklik). Tindakan ini mengurangi ukuran DOM sekitar 1.200 node.
- Kedua, kita memuat widget yang kurang penting dengan lambat.
Berkat semua upaya ini, kami mengurangi TBT secara signifikan, dan INP kami juga berkurang hampir sebesar 50%:
Pada tahap ini, kami hampir kehabisan solusi mudah untuk lebih mengurangi TBT (dan INP melalui proxy), tetapi kami tahu bahwa kami memiliki banyak peluang untuk peningkatan. Ini adalah saat kami memutuskan untuk mengupgrade boilerplate UI yang dibuat khusus 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 mengalihkan pekerjaan thread utama yang berat lainnya ke pekerja web, bersama dengan teknik seperti requestIdleCallBack untuk menunda tugas yang tidak penting.
Bagaimana peningkatan INP telah membantu The Economic Times?
TBT dan INP saat ini di origin
Pada saat memublikasikan postingan ini, TBT untuk origin kami adalah 120 milidetik, turun dari 3.260 milidetik saat kami memulai upaya pengoptimalan. Demikian pula, INP untuk origin kami adalah 257 milidetik setelah upaya pengoptimalan kami, turun dari lebih dari 1.000 milidetik.
Tren CrUX INP
Traffic yang diterima di halaman topik menunjukkan bagian yang jauh lebih kecil dari keseluruhan traffic. Oleh karena itu, Google Ads adalah tempat yang ideal untuk bereksperimen. Hasil CrUX bersama dengan hasil bisnisnya sangat menggembirakan, dan mengarahkan kami untuk memperluas upaya ke seluruh situs guna 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, memetakan dengan jelas hasil upaya kami dalam mengurangi INP. Seperti yang dapat dilihat 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 sebanyak 30 kali, bersama dengan migrasi ke Next.js, membantu kami mengurangi INP hampir 4 kali lipat, yang akhirnya menghasilkan penurunan rasio pantulan sebesar 50% dan peningkatan kunjungan halaman sebesar 43% di halaman topik.
Kesimpulan
Ringkasnya, INP sangat membantu dalam menentukan masalah performa runtime di bagian-bagian situs Economic Times. Data tersebut telah terbukti menjadi salah satu metrik paling efektif untuk memberikan dampak positif terhadap hasil bisnis. Berkat jumlah yang sangat menggembirakan yang telah kami amati sebagai hasil dari upaya ini, kami termotivasi untuk meningkatkan upaya pengoptimalan kami pada area lainnya di situs web kami dan menuai manfaat tambahan.