Pencarian Economic Times untuk memperbaiki INP

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%.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

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.

Nilai INP yang baik adalah 200 milidetik atau kurang, nilai yang buruk lebih besar dari 500 milidetik, dan apa pun di antaranya perlu ditingkatkan.

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:

Gambar gabungan tugas yang berjalan lama selama startup seperti yang ditampilkan di panel performa Chrome DevTools, dan laporan metrik halaman. Thread utama diblokir selama pemuatan halaman selama 3.260 milidetik.
Thread utama selama startup sebelum mengoptimalkan TBT. TBT-nya adalah 3.260 milidetik.
Gambar gabungan tugas yang berjalan lama selama startup seperti yang ditampilkan di panel performa Chrome DevTools, dan laporan metrik halaman. Thread utama diblokir selama pemuatan halaman selama 120 milidetik.
Thread utama selama startup setelah mengoptimalkan TBT. TBT adalah 120 milidetik.

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.

Screenshot alat cakupan di Chrome DevTools. Di sini, alat ini menampilkan bagian file JavaScript dan CSS yang tidak digunakan selama pemuatan halaman.

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.

Screenshot audit ukuran DOM di Lighthouse. Jumlah elemen DOM yang dilaporkan adalah 2.706 elemen.

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%:

Screenshot audit INP di CrUX. INP untuk halaman adalah 539 milidetik, yang melebihi batas 'buruk' nilai minimum.

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.

Screenshot audit INP di CrUX. INP untuk halaman adalah 257 milidetik, yang berada dalam kategori 'perlu ditingkatkan' minimum.

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.

Screenshot distribusi INP seperti yang divisualisasikan di CrUX selama empat bulan, mulai Juli 2022 dan berakhir pada Oktober 2022. Nilai dalam filter 'buruk' dan 'perlu peningkatan' nilai minimum menurun, sedangkan nilai dalam kategori 'baik' nilai minimum meningkat.

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.

Screenshot diagram di Akamai mPulse, yang menunjukkan penurunan TBT selama sekitar sebulan.

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.

Screenshot Google Analytics yang membandingkan kunjungan halaman versus rasio pantulan. Karena pengoptimalan yang dilakukan pada INP di situs The Economic Times, tercapainya penurunan rasio pantulan sebesar 50% dan peningkatan pageview sebesar 43%.

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.