Cara Platform Pengelolaan Izin PubTech mengurangi INP di situs pelanggan mereka hingga 64%, sekaligus meningkatkan visibilitas iklan hingga 1,5%

Cara CMP PubConsent mengurangi INP untuk pelanggan mereka hingga 64% dengan menggunakan strategi yang menghasilkan API Scheduler browser untuk memperbaiki masalah responsivitas yang diidentifikasi menggunakan Chrome DevTools.

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

Platform Pengelolaan Izin (CMP) adalah alat yang membantu situs mematuhi peraturan privasi dengan mendapatkan izin pengguna untuk penggunaan cookie dan teknologi pelacakan. Selain tujuan utama memastikan kepatuhan hukum, CMP, sebagai skrip pihak ketiga, harus memastikan dampak yang minimal terhadap performa dan pengalaman pengguna.

CMP PubConsent adalah produk terbaru dari PubTech. CMP yang dirancang dengan fokus utama pada performa, PubConsent CMP dirancang agar ringan, memastikan pengalaman pengguna yang optimal, dan dampak minimal terhadap performa situs secara keseluruhan.

Dengan diperkenalkannya metrik Interaction to Next Paint (INP), PubTech dapat menemukan masalah terkait responsivitas CMP kami. Dalam studi kasus ini, PubTech menunjukkan cara mereka menyelesaikan masalah terkait responsivitas di platform CMP PubConsent, dan cara mereka meningkatkan INP sebelum menjadi salah satu Core Web Vitals pada Maret 2024, yang menunjukkan komitmen yang teguh untuk memberikan performa terbaik dalam produk CMP.

Mengapa PubTech peduli dengan performa?

CMP PubConsent—seperti sebagian besar CMP—menawarkan fungsi pengelolaan izinnya yang diterapkan sebagai skrip pihak ketiga di halaman situs. Mengurangi dampak performa dari penawaran CMP kami—termasuk terhadap responsivitas—sangat penting untuk menjamin keberhasilan integrasi CMP.

Dengan memprioritaskan performa dan menjaga skrip CMP PubConsent tetap ringan, pemilik situs dapat mencapai keseimbangan yang diperlukan antara menggabungkan fungsi Pengelolaan Izin yang berharga sekaligus menjaga kualitas pengalaman pengguna.

Mengingat pentingnya fungsi yang diberikan CMP—dan dampaknya terhadap performa—PubTech menetapkan sasaran berikut:

  1. Minimalkan dampak produk CMP PubConsent terhadap INP.
  2. Kurangi tugas panjang yang dapat diatribusikan ke produk CMP.
  3. Kurangi Total Blocking Time (TBT), yang dapat memberikan efek negatif pada INP halaman.

Cara pengukuran INP

PubTech menggunakan Chrome DevTools untuk melakukan analisis awal dan interaksi lambat yang didiagnosis secara manual. Alur kerja ini memungkinkan PubTech menemukan masalah tertentu yang memengaruhi responsivitas halaman. Misalnya, interaksi klik dalam produk CMP untuk menerima semua cookie dan kemudian menutup dialog izin cookie menyebabkan tugas panjang yang menunda pembaruan rendering pada antarmuka pengguna. Seperti yang Anda lihat dari gambar berikut, antarmuka pengguna tidak diperbarui untuk menunjukkan bahwa dialog telah ditutup hingga tugas panjang selesai.

Seperti tombol untuk menerima semua cookie, tombol untuk menolak semua cookie atau menyesuaikan preferensi cookie semuanya mengikuti alur kerja yang sama dalam arsitektur CMP PubConsent. Karena itu, peningkatan yang dijelaskan dalam studi kasus ini memengaruhi serangkaian interaksi pengguna dalam produk CMP.

Alur yang menunjukkan bagaimana tugas panjang memblokir antarmuka pengguna agar tidak diupdate setelah pengguna mengklik tombol 'Accept All' di CMP PubConsent. Ada lima langkah yang terdiri dari satu tugas panjang, yang membuat antarmuka pengguna terasa lambat.
Representasi visual dari apa yang terjadi saat pengguna mengklik tombol "Terima Semua".

Penundaan ini menyebabkan persepsi visual panel dalam status terkunci selama tugas. Karena memblokir update rendering untuk jangka waktu yang terasa lama, INP halaman terkena dampak negatif.

Untuk meningkatkan INP, strategi hasil yang berbeda digunakan di CMP PubConsent.

Menghasilkan tugas prioritas tinggi

Metode yieldToMainUiBlocking yang ditampilkan dalam cuplikan kode berikut dirancang untuk mengoptimalkan tugas JavaScript prioritas tinggi dengan menghasilkan scheduler.yield jika tersedia, tetapi kembali ke postTask dengan prioritas user-blocking (tinggi) jika postTask tersedia, yang akhirnya kembali ke tidak ada.

setTimeout dihindari di sini karena metode yieldToMainUiBlocking dirancang untuk menangani operasi setelan CMP internal dan pekerjaan prioritas tinggi yang harus mempertahankan prioritas tersebut selama menghasilkan. Artinya, hanya browser yang menerapkan API penjadwalan ini—yang saat ini hanya tersedia di browser berbasis Chromium pada saat artikel ini ditulis—yang mendapatkan manfaat dari peningkatan yang dijelaskan dalam studi kasus ini. Meskipun demikian, pendekatan ini dianggap sebagai {i>progressive enhancement<i} yang dapat diterima untuk tugas prioritas tinggi tersebut.

function yieldToMainUiBlocking () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
      }
    }

    resolve(false);
  });
};

Hasil pada tugas sedang dan latar belakang

Metode yieldToMainBackground yang ditampilkan dalam cuplikan kode berikut digunakan untuk memecah tugas panjang yang memiliki prioritas user-visible (sedang) atau background. Logika ini akan mengimplementasikan scheduler.yield() jika tersedia, tetapi berbeda saat menggunakan postTask dengan prioritas sedang, dan terakhir, kembali ke setTimeout di Browser non-Chromium.

function yieldToMainBackground () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
      }
    }

    setTimeout(() => { resolve(true) }, 0);
  });
};
Alur yang menunjukkan berapa lama tugas panjang yang memblokir update antarmuka pengguna setelah pengguna mengklik tombol &#39;Terima Semua&#39; di CMP PubConsent telah dioptimalkan. Kelima langkah tersebut sekarang akan menghasilkan jika memungkinkan, yang memungkinkan antarmuka pengguna memperbarui renderingnya lebih cepat.
Representasi visual tentang bagaimana hasil menggunakan yieldToMainBackground memungkinkan browser merender paint berikutnya (dalam hal ini menutup UI CMP) lebih cepat.

Cara PubTech semakin mengurangi TBT dengan pengoptimalan tata letak rendering

Setelah menerapkan strategi hasil, kami mendapati bahwa INP meningkat secara signifikan untuk CMP. Bahkan, setelah mengurangi durasi pemrosesan pengendali peristiwa secara signifikan, ditemukan peluang untuk melakukan peningkatan rendering lebih lanjut untuk paint berikutnya untuk tindakan Tutup UI. Tindakan ini awalnya didesain untuk menghapus elemen dari DOM. Hal ini menimbulkan tantangan, terutama di situs dengan jumlah node DOM yang substansial, yang mengakibatkan peningkatan yang tidak terduga dalam pekerjaan rendering.

Screenshot panel Performance di Chrome DevTools, yang menampilkan bagian rekaman aktivitas dengan stack panggilan aktivitas untuk menutup dialog UI di CMP PubConsent. Tugas untuk menutup dialog UI itu sendiri memicu penghapusan node DOM yang menambah penundaan presentasi interaksi.

Guna mengatasi peningkatan jumlah pekerjaan rendering yang diperlukan untuk menghapus elemen dari DOM, sebuah solusi diperkenalkan bahwa tim bernama "de-rendering lambat". Pendekatan ini pertama-tama menerapkan aturan CSS display: none ke dialog izin CMP setelah pengguna memberikan izin untuk menyembunyikannya. Kemudian, penghapusan node DOM yang terkait dengan dialog CMP akan dialihkan ke waktu berikutnya saat browser tidak ada aktivitas menggunakan requestIdleCallback. Pendekatan ini terbukti jauh lebih cepat daripada menghapus node DOM pada saat pengguna menutup dialog izin.

Screenshot panel Performance di Chrome DevTools, yang menunjukkan pelacakan yang sama seperti sebelumnya, tetapi telah dioptimalkan. Saat dialog CMP PubConsent ditutup, tindakan awalnya adalah menyembunyikannya menggunakan tampilan CSS: none rule. Kemudian, saat browser nanti tidak ada aktivitas, penghapusan node DOM akan dilakukan.
Screenshot DevTools menyoroti peningkatan INP dengan menggeser tugas penghapusan DOM.

Cara PubTech semakin mengurangi INP dengan meningkatkan library TCF IAB

Setelah berhasil menyelesaikan sebagian besar masalah responsivitas CMP, peluang peningkatan lebih lanjut untuk peningkatan teridentifikasi dalam salah satu dependensi utamanya: library Transparency and Consent Framework (TCF) IAB.

Komponen yang paling mahal secara komputasi pada library ini adalah "build strings" dan "dispatch consent". Komponen ini merupakan bagian integral dari library TCF IAB. Pengoptimalan berikut untuk komponen ini diterapkan dalam fork terpisah khusus untuk kebutuhan PubTech:

  1. Menggunakan kembali hasil yang dihitung untuk proses decoding, yang dijalankan untuk setiap callback pihak ketiga yang perlu membaca izin pengguna.
  2. Menghindari dan mengurangi loop yang tidak perlu dalam proses encoding pembatasan penayang, yang dijalankan saat pengguna memberikan izin.

Pengoptimalan pertama ini mengurangi waktu yang dihabiskan oleh CMP pada setiap callback pihak ketiga yang terhubung ke library TCF IAB. Pengoptimalan kedua mengurangi durasi pemrosesan yang dikeluarkan oleh komponen "string build". Bahkan, pengoptimalan ini memungkinkan pengurangan loop hingga 60% yang dijalankan setiap kali pengguna memberikan izin.

Hasil

Dengan menerapkan strategi yang sebelumnya berperforma baik dan pengoptimalan tata letak rendering baru, INP CMP meningkat hingga 65%. Hasilnya, responsivitas pengalaman pengguna CMP PubConsent meningkat secara signifikan, dan untuk beberapa iklan, visibilitas bahkan meningkat sebesar 1,5% dengan mengoptimalkan waktu iklan diminta.

Selain peningkatan ini, pada library TCF IAB, kami mengamati bahwa INP meningkat hingga 77% di perangkat seluler untuk pelanggan yang terpengaruh sebagai hasil dari pengurangan tugas panjang yang disebabkan TCF hingga 85%. Hal ini membantu mengurangi secara signifikan overhead setiap callback pihak ketiga yang dieksekusi selama seluruh siklus proses halaman.

Jumlah origin yang lulus INP saat menggunakan CMP PubConsent meningkat lebih dari 400%, naik dari 13% menjadi 55% di perangkat seluler. Untuk beberapa pelanggan, INP halaman berkurang lebih dari setengahnya—dari 470 milidetik menjadi 230 milidetik—karena pengoptimalan PubTech SDK yang dilakukan.

Screenshot rasio kartu INP asal untuk situs yang menggunakan CMP PubTech. Di desktop, tingkat kelulusan meningkat menjadi 99,12% dari sekitar 84%. Pada seluler, tingkat kelulusan meningkat menjadi 55,46% dari sekitar 22%.
Rasio kelulusan INP asal untuk situs yang menggunakan CMP PubTech seperti yang dilaporkan oleh Arsip HTTP dan Laporan Pengalaman Pengguna Chrome (CrUX).
Screenshot dasbor yang menampilkan INP dari data RUM pada persentil ke-75. Dari Juli/Agustus 2023, INP hanya di bawah 500 milidetik, tetapi pada pertengahan Februari 2024, INP hanya di bawah 200 milidetik, yang menempatkannya di ambang batas &#39;Baik&#39;.
Tren peningkatan data INP seluler pelanggan PubConsent, yang berkorelasi dengan perubahan SDK yang dijelaskan dalam studi kasus ini.

Kesimpulan

Pelanggan PubTech dengan cepat menyadari performa INP positif dan hasil metrik bisnis yang dihasilkan dari upaya pengoptimalan kami. Peningkatan performa lebih lanjut untuk CMP PubConsent sedang dipertimbangkan, dengan memanfaatkan data Real User Monitoring (RUM) yang sangat berharga dari pelanggan mereka. Data ini melacak dengan cermat regresi dan kemajuan, yang mendorong upaya peningkatan berkelanjutan PubTech.

Sebagai pihak ketiga, PubTech juga menyadari bahwa mereka memiliki peluang untuk meningkatkan performa web dalam skala besar dan memberikan respons yang lebih baik, sekaligus menghindari dampak negatif pada KPI bisnis. Tak ada kata terlambat untuk mulai menerapkan peningkatan semacam ini.

Terima kasih banyak kepada Luca Coppola, PubTech CTO yang telah mendukung upaya inovasi ini, serta kepada Jeremy Wagner, Michal Mocny, dan Rick Viscomi dari Google.