Pencarian Economic Times untuk memperbaiki INP

Dengan mengurangi TBT sebanyak 30 kali dan bermigrasi ke Next.js, The Ecomonic Times berhasil mengurangi INP hampir empat kali lipat, sehingga 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 responsivitas situs terhadap input pengguna. Responsivitas yang baik berarti halaman cepat merespons interaksi pengguna. Makin rendah INP halaman, makin baik kemampuannya untuk merespons interaksi pengguna.

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

Awal yang tidak jelas

Saat Google pertama kali memperkenalkan INP sebagai metrik eksperimental yang berpotensi berkembang menjadi salah satu metrik Data Web Inti, tim Economic Times menerima tantangan untuk memperbaikinya sebelum menjadi salah satu metrik tersebut, karena memberikan pengalaman pengguna kelas dunia sangat penting bagi nilai bisnis inti kami.

INP adalah salah satu metrik yang paling sulit dipecahkan sejauh ini. Awalnya, kami tidak tahu cara mengukur INP secara efektif. Hal yang mempersulitnya adalah kurangnya dukungan komunitas—termasuk sebagian besar penyedia Pemantauan Pengguna Nyata (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 mengevaluasi jalur ke depan. INP kami mendekati 1.000 milidetik di tingkat origin saat kami memulai.

Salah satu hal yang muncul saat memperbaiki INP di lapangan adalah salah satu metrik lab yang akan ditargetkan adalah Total Blocking Time (TBT). TBT sudah didokumentasikan dengan baik dan didukung oleh komunitas. Meskipun sudah memenuhi nilai minimum untuk Core Web Vitals, kami tidak terlalu baik dalam hal TBT, karena waktunya lebih dari 3 detik saat kami memulai.

Apa yang dimaksud dengan TBT, dan langkah apa yang kami lakukan untuk meningkatkannya?

TBT adalah metrik lab yang mengukur responsivitas halaman web terhadap input pengguna selama pemuatan halaman. Setiap tugas yang memerlukan waktu lebih dari 50 milidetik untuk dieksekusi dianggap sebagai tugas yang lama, dan waktu setelah nilai minimum 50 milidetik dikenal sebagai waktu pemblokiran.

TBT dihitung dengan mengambil jumlah waktu pemblokiran dari semua tugas yang lama selama pemuatan halaman. Misalnya, jika ada dua tugas yang lama 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). Makin rendah TBT, makin baik, dan TBT juga berkorelasi baik dengan INP.

Berikut adalah perbandingan lab singkat TBT kami sebelum dan sesudah melakukan langkah-langkah untuk meningkatkannya:

Gambar gabungan tugas yang 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 adalah 3.260 milidetik.
Gambar gabungan tugas yang 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 mengurai HTML, mem-build 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 tidak lancar.

Ini adalah tugas tersulit bagi kami, karena kami memiliki algoritma sendiri untuk mendeteksi identitas pengguna guna menayangkan iklan berdasarkan status langganan dan skrip pihak ketiga untuk pengujian A/B, analisis, dan lainnya.

Pada awalnya, kami melakukan langkah-langkah kecil, seperti menurunkan prioritas 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 memastikan bahwa jika waktu yang ditentukan telah berlalu dan callback belum dipanggil, callback akan segera dieksekusi setelah waktu tunggu habis.

Meminimalkan waktu evaluasi skrip

Kami juga memuat lambat library pihak ketiga 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 tempat tree shaking diperlukan 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

Menurut 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, kita merender item menu berdasarkan permintaan pengguna (saat diklik). Hal ini mengurangi ukuran DOM sekitar 1.200 node.
  • Kedua, kami memuat lambat widget yang kurang penting.

Berkat semua upaya ini, kami berhasil mengurangi TBT secara signifikan, dan INP kami berkurang hampir 50%:

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

Pada tahap ini, kami hampir kehabisan cara mudah untuk mengurangi TBT (dan INP melalui proxy) lebih lanjut, tetapi kami tahu bahwa kami memiliki banyak ruang untuk peningkatan. Pada saat itulah kami memutuskan untuk mengupgrade boilerplate UI buatan kustom ke React versi terbaru beserta 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 sedikit dibandingkan dengan bagian lain situs, kami mulai memigrasikan halaman topik ke Next.js. Kami juga menggunakan PartyTown untuk memindahkan pekerjaan thread utama berat tambahan ke pekerja web, bersama dengan teknik seperti requestIdleCallBack untuk menunda tugas yang tidak penting.

Bagaimana peningkatan INP membantu The Economic Times?

TBT dan INP saat ini di origin

Pada saat memposting 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 tersebut adalah 257 milidetik, yang berada dalam nilai minimum 'perlu peningkatan'.

Tren CrUX INP

Traffic yang diterima di halaman topik mewakili sebagian kecil dari keseluruhan traffic. Oleh karena itu, tempat ini ideal untuk eksperimen. Hasil CrUX beserta hasil bisnisnya sangat menggembirakan, dan mendorong kami untuk memperluas upaya di 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 batas 'buruk' dan 'perlu ditingkatkan' sedikit menurun, sedangkan nilai dalam batas 'baik' meningkat.

Analisis TBT mPulse Akamai

Kami menggunakan Akamai mPulse sebagai solusi RUM kami, yang mengukur TBT di lapangan. Kami mengamati penurunan TBT yang konsisten, yang jelas sesuai dengan hasil upaya kami untuk 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 mengurangi TBT sebanyak 30 kali, 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 kunjungan halaman sebesar 43% di halaman topik.

Screenshot Google Analytics yang membandingkan kunjungan halaman dengan rasio pantulan. Berkat pengoptimalan yang dilakukan pada INP di situs The Economic Times, rasio pantulan menurun sebesar 50% dan kunjungan halaman meningkat sebesar 43%.

Kesimpulan

Singkatnya, INP secara ekstensif membantu menentukan masalah performa runtime di bagian situs Economic Times. Metrik ini telah terbukti menjadi salah satu metrik paling efektif untuk memengaruhi hasil bisnis secara positif. Karena angka yang sangat menggembirakan yang kami amati sebagai hasil dari upaya ini, kami termotivasi untuk menskalakan upaya pengoptimalan ke area lain di situs kami dan memperoleh manfaat tambahan.