Addy Osmani

Resource pihak ketiga (seperti sematan dan skrip) banyak digunakan di seluruh web saat ini. Mereka menyediakan solusi siap pakai untuk menyematkan media sosial, video, analisis, live chat, iklan, pengujian A/B, personalisasi, dan lainnya. Penyematan pihak ketiga adalah bagian penting dari situs modern yang memungkinkan pemilik situs berfokus pada kompetensi inti mereka, sekaligus mengalihkan fungsi standar tetapi penting kepada penyedia eksternal.

Saat pihak pertama dan pihak ketiga di halaman bekerja secara harmonis, halaman dapat memberikan pengalaman pengguna yang baik. Namun, hal ini memerlukan upaya yang signifikan dari tim teknik dan bisnis serta sering diabaikan, sehingga mengakibatkan halaman web yang berperforma kurang baik dan dampak negatif terhadap metrik yang berfokus pada pengguna seperti Data Web Inti. Hal ini merugikan kedua belah pihak dan menciptakan peluang yang terlewatkan dalam bisnis. Bisakah kita melakukan yang lebih baik di sini?

Kami memiliki visi web masa depan saat skrip dan resource pihak ketiga memberikan nilai bisnis yang diinginkan dengan regresi minimal terhadap performa atau pengalaman pengguna situs yang menggunakannya di browser. Dengan begitu, pengguna akan mendapatkan pemuatan halaman yang lebih cepat.

Selama setahun terakhir, kami telah mempertimbangkan, membahas, dan bereksperimen dengan berbagai kemungkinan yang dapat melindungi pengalaman pengguna dari dampak merugikan skrip pihak ketiga tanpa mengurangi nilai bisnis mereka bagi pemilik situs.

Melalui postingan ini, kami ingin berbagi informasi tentang beberapa eksperimen kami. Kami harap ini adalah awal dari proses yang akan mendorong transparansi dan visibilitas antara agen pengguna, bisnis, dan penyedia pihak ketiga, serta membuka jalan menuju web yang lebih cepat.

Penjelasan lebih mendalam tentang pihak ketiga

Pihak ketiga adalah resource yang ditayangkan oleh penyedia di luar situs. Mereka tidak secara langsung berada dalam kontrol pemilik situs, tetapi hadir dengan persetujuan mereka. Referensi pihak ketiga antara lain:

• Dihosting di origin bersama dan asal yang berbeda dari origin situs utama.
• Tidak ditulis atau dipengaruhi oleh masing-masing pemilik situs.
• Banyak digunakan oleh berbagai situs.

Dari membantu menghasilkan pendapatan (melalui iklan) hingga memberikan peluang pemasaran yang lebih baik (sematan media sosial), pihak ketiga melayani berbagai tujuan bisnis. Kategori umum pihak ketiga meliputi:

Sumber: Pihak ketiga menurut kategori.

Skrip dan library pihak ketiga ini memungkinkan developer web memanfaatkan solusi yang telah teruji dan teruji untuk menerapkan fitur standar, alih-alih menciptakan hal yang tidak penting. Dengan demikian, pihak ketiga mengurangi waktu pengembangan dan membantu bisnis meluncurkan atau mengupgrade produk mereka lebih cepat. Tidak mengherankan jika lebih dari 94% dari semua situs di desktop dan seluler menggunakan pihak ketiga.

Bagaimana pengaruh pihak ketiga terhadap performa?

Idealnya, developer pihak ketiga adalah pakar materi pokok untuk fitur spesifik yang mereka berikan. Pihak ketiga yang paling populer telah mengalami beberapa iterasi, dan diharapkan kode mereka dioptimalkan untuk sasaran bisnis mereka sendiri, yang mungkin menyertakan atau tidak menyertakan performa halaman yang menggunakannya. Namun, kami tahu bahwa pihak ketiga yang paling dioptimalkan pun akan memengaruhi performa. Berikut adalah alasan utama untuk dampak ini:

1. Biaya Eksekusi Skrip dan Ukuran: Pihak ketiga sering kali berupaya memberikan fungsi signifikan "hanya" dengan memasukkan elemen <script> atau <iframe> ke halaman Anda. Elemen-elemen ini kemudian akan menarik skrip dan resource yang ukurannya signifikan serta memerlukan waktu lebih lama untuk didownload dan dieksekusi. Terlalu banyak JavaScript membuat thread utama tetap sibuk lebih lama, memblokir rendering, dan menunda interaksi pengguna. Beberapa pihak ketiga teratas diketahui memblokir thread utama dari 42 milidetik hingga 1,6 detik untuk lebih dari 50% situs yang dianalisis. Thread utama yang diblokir menghasilkan Total Waktu Pemblokiran (TBT) yang tinggi, yang merupakan salah satu metrik yang memengaruhi skor performa untuk situs. Selain itu, tindakan ini juga menunda respons terhadap interaksi pengguna dan menurunkan metrik Interaction to Next Paint (INP) yang digunakan untuk mengukur responsivitas situs. Dengan demikian, biaya eksekusi skrip memiliki dampak yang signifikan terhadap performa.

2. Jumlah: Rata-rata, situs menggunakan sekitar 21 pihak ketiga yang berbeda di perangkat seluler dan web. Sering kali, tag pihak ketiga ditambahkan oleh alat pengelolaan tag yang tidak dikontrol secara langsung oleh tim teknis/pengembangan. Tag yang tidak diperlukan dapat ditambahkan oleh tim lain tanpa proses peninjauan dan tidak akan pernah dihapus. Hal ini dapat memengaruhi pengalaman pengguna, bobot halaman, atau penggunaan CPU secara signifikan. Menetapkan proses tata kelola dapat mengatasi situasi tersebut dan memungkinkan developer mengaudit dampak setiap penyedia. Akan sangat membantu jika developer telah menyiapkan data untuk semua pihak ketiga yang memberikan fungsi tertentu beserta dampak performa, manfaat, dan komprominya sebagai perbandingan. Tantangan lain yang dihadapi tim adalah bahwa bagi banyak situs, tag pihak ketiga hanya berjalan di lingkungan produksi, tetapi tidak di lingkungan pengembangan. Hal ini membuat developer lebih sulit mengujinya.

3. Jaringan: Karena pihak ketiga dihosting di origin yang berbeda, browser harus membuat jumlah koneksi yang lebih besar untuk mendownload konten dari mereka. Koneksi yang berbeda tidak dapat mengoordinasikan download berdasarkan prioritas, sehingga menyebabkan pertentangan jaringan. Hal ini dapat menunda pemuatan halaman lebih lanjut jika pengoptimalan yang tepat tidak dipertimbangkan.

4. Pengurutan: Pihak ketiga dapat memblokir thread utama dan bersaing dengan bandwidth untuk mendapatkan resource yang lebih penting. Meskipun demikian, dalam beberapa kasus, pihak ketiga adalah resource penting yang diperlukan untuk merender halaman. Pengurutan yang optimal untuk sumber daya pihak pertama dan ketiga menjadi diperlukan ketika situs web menggunakan beberapa pihak ketiga. Developer web harus mengetahui berbagai opsi yang tersedia untuk mengoptimalkan pengurutan.

Akibatnya, pihak ketiga dapat memengaruhi salah satu atau semua komponen Data Web Inti. Sebagian besar pihak ketiga berdampak negatif terhadap Largest Contentful Paint (LCP) dan Penundaan Input Pertama (FID). Sematan YouTube memblokir rangkaian pesan utama selama 4,5 detik untuk 10% situs di perangkat seluler, dan setidaknya 1,6 detik untuk 50% situs yang diteliti. Bayangkan kekesalan pengguna jika mereka menemukan halaman dengan 20 skrip semacam itu di koneksi lambat. Visualisasi berikut dari thirdpartyweb.today menunjukkan pihak ketiga dengan dampak performa terbesar saat ini.

"Di antara ~4 juta situs teratas, ~2.700 asal menyumbang ~57% dari semua waktu eksekusi skrip dengan 50 entitas teratas sudah menyumbang ~47%". - web pihak ketiga

Halaman yang dirender dengan cepat dan menjadi interaktif dalam jangka waktu yang wajar sangat penting untuk pengalaman pengguna yang baik seperti yang diukur oleh Data Web Inti. UX yang baik sering kali berarti bisnis yang baik untuk situs, yang berarti bisnis yang baik untuk pihak ketiga yang digunakan. Bekerja sama untuk mengurangi dampak pihak ketiga dapat menjadi kemenangan bagi semua pihak dalam rantai.

Kami memahami bahwa Google menjual beberapa skrip pihak ketiga yang umum digunakan, termasuk di antaranya adalah Google Tag Manager, sematan YouTube, dan ReCaptcha. Kami menyadari bahwa sejumlah skrip kami dapat memberikan dampak performa yang lebih ringan pada Data Web Inti, dan kami berkomitmen untuk mengeksplorasi cara untuk meningkatkan dampak ini jika memungkinkan.

Bagaimana Chrome dapat membantu?

Resource pihak ketiga yang berperforma buruk sering kali menjadi tantangan bagi developer, sehingga diperlukan perubahan langkah dalam dinamika ekosistem yang mendasarinya. Chrome ingin menjelajahi bidang ini untuk mencapai hasil berikut:

1. Temukan cara yang lebih baik untuk memuat resource pihak ketiga di web tanpa mengurangi kualitas pengalaman pengguna atau hasil bisnis.

   Kami memahami bahwa kami tidak dapat melanjutkan upaya ini jika tidak berkolaborasi dengan partner, bisnis, pihak ketiga, dan developer. Kami ingin menciptakan tempat terbuka untuk mendiskusikan kemungkinan dan bertukar ide melalui penjelasan dan spesifikasi publik. Developer akan memiliki waktu untuk memberikan masukan dan menguji dampak dari banyak proposal ini.

2. Memungkinkan pengguna skrip pihak ketiga memiliki atribusi yang lebih baik untuk biaya alat dan di lapangan, jalur yang jelas dan beraspal untuk penggunaan mereka, serta insentif yang lebih baik selama waktu pembuatan untuk memastikan biaya mereka optimal secara default.

   Kami ingin meningkatkan semua lapisan, seperti agen pengguna, framework, dan skrip pihak ketiga untuk mengurangi dampak performa pihak ketiga. Kami juga ingin memberikan insight yang memadai untuk membantu pemilik situs menerapkan praktik terbaik pada setiap skrip yang disematkan, termasuk alternatif yang lebih cepat jika memungkinkan.

Pendekatan yang Diusulkan

Kami mengusulkan pendekatan tiga cabang untuk mencapai hasil ini...

1. **Berikan atribusi yang lebih mendalam kepada developer tentang dampak pihak ketiga melalui RUM dan di alat developer Chrome.**

   RUM mengacu pada data metrik pengguna nyata (juga dikenal sebagai data kolom) yang tersedia melalui API pemantauan performa web. Alat developer Chrome meliputi Lighthouse, Chrome DevTools, dan Laporan Pengalaman Pengguna Chrome. Kami mengusulkan untuk meningkatkan API dan alat yang tersedia sehingga developer situs memahami dampak dari setiap pihak ketiga yang mereka gunakan di setiap halaman. Alat ini juga akan mengedukasi mereka tentang tindakan yang dapat mereka ambil untuk mengurangi dampak (misalnya, menunda atau menggunakan fasad) dan mengeksplorasi potensi solusi lainnya (pihak ketiga atau DIY lainnya) dengan kompromi. Untuk API pemantauan performa web, kami sedang mempelajari cara untuk memperluas cakupan resource lintas asalnya tanpa mengorbankan privasi dan keamanan pengguna kami.

2. **Berikan jalur yang terang kepada bisnis untuk memuat resource pihak ketiga secara efisien.**

   Kami ingin mengusulkan standar baru yang mendorong browser untuk secara lebih cerdas melakukan kompromi antara cara pemuatan sumber daya pihak pertama dan pihak ketiga demi memberikan pengalaman pemuatan yang lebih baik bagi pengguna. Nantinya, kita akan menyoroti beberapa proposal ini, seperti penyematan pihak ketiga yang memuat lambat secara default, atau menerapkan prioritas resource berbeda ke resource pihak ketiga yang mungkin tidak terlalu penting bagi konten awal yang mungkin paling diminati pengguna. Ini hanyalah sebagian kecil ide yang kami evaluasi dalam ruang ini dan kami ingin berkolaborasi dengan pakar performa web dan komunitas yang lebih luas untuk membentuk karya ini.

   Kami juga ingin mengatasi masalah tersebut dalam kerangka kerja JavaScript dan Sistem Pengelolaan Konten (CMS) jika lebih tepat. Project seperti Aurora dan WordPress Performance Team telah mengajari kami pentingnya default bawaan yang menyelesaikan masalah pemuatan umum. Default yang ada ke dalam framework dan CMS akan memandu bisnis di sepanjang jalur yang memadai. Parameter ini juga dapat membantu agen pengguna (misalnya, Chrome) sebagai petunjuk yang memungkinkannya menerapkan heuristik untuk mengoptimalkan pemuatan halaman dan CWV. Petunjuk tersebut dapat membantu agen pengguna memutuskan waktu dan cara pemuatan pihak ketiga tertentu dalam siklus proses halaman. (Misalnya, komponen skrip Next.js memiliki default bawaan untuk memuat skrip pihak ketiga setelah halaman menjadi interaktif.)

3. **Memberikan insentif kepada pihak ketiga untuk mengurangi dampak performa mereka melalui upaya transparansi yang lebih baik.**

   Developer pihak ketiga saat ini tidak memiliki visibilitas yang diperlukan untuk memahami dampak skrip mereka pada situs secara keseluruhan. Kami berencana untuk mengatasi masalah ini dan membekali penyedia ini dengan alat untuk menganalisis dampaknya dan membandingkannya dengan produk lain di pasar yang memberikan nilai yang sama. Kami juga ingin membantu mereka menggunakan data untuk mendiagnosis penyebab dampaknya, sehingga mereka dapat memitigasinya ke upstream. Kami harus meminta semua pihak ketiga, termasuk yang ditulis oleh Google, agar berhasil.

Tantangan

Upaya sebesar ini bukan tanpa tantangan. Beberapa tantangan utama yang harus kita pertimbangkan adalah.

• Pihak ketiga memiliki masalah lintas sektor yang berkaitan dengan iklan, analisis, pengelolaan tag, utilitas, dan banyak lainnya. Setiap area memerlukan pertimbangan dan serangkaian persyaratan yang unik. Misalnya:
  • Keputusan untuk mengoptimalkan pemuatan iklan bergantung pada kompromi antara pendapatan dan pengalaman pengguna. Mereka memblokir konten yang berharga terlalu cepat, dan jika terlambat, pengguna tidak bisa melihatnya.
  • Skrip Analytics ditambahkan ke bobot halaman, tetapi memberikan data yang berharga tentang tindakan pengguna kepada bisnis.

Kami berharap dapat bermitra dengan berbagai kategori pihak ketiga, memahami perbedaan yang ada, menyelesaikan kompromi, dan mengembangkan insentif yang sesuai untuk semua orang. Kami menyadari bahwa kami harus bekerja sama dengan entitas di setiap area agar strategi kami dapat efektif. Ini termasuk partner internal kami seperti Google Tag Manager, Google Ads, dan YouTube.

1. Kami ingin memberikan atribusi yang lebih mendalam kepada developer situs dan developer pihak ketiga. Hal ini memerlukan upaya cermat di mana kami mengidentifikasi data yang paling relevan dalam mengukur dampak, mengatribusikannya secara akurat dan terperinci, serta menyediakan jalur yang benar ke depan. Pada akhirnya, penghitungan tentang performa pihak ketiga tertentu terhadap pesaingnya harus transparan bagi semua pihak.

2. Kami mengusulkan untuk meningkatkan Chrome agar dapat menerapkan pengoptimalan yang membantu mencapai keseimbangan yang tepat untuk memprioritaskan pemuatan resource pihak pertama vs. ketiga. Perubahan yang bernilai akan tersedia sebagai standar di semua browser, tetapi hal ini memerlukan waktu. Misalnya, atribut loading untuk elemen <img> dan <iframe> telah tersedia di Chrome/Edge sejak tahun 2019, tetapi hanya tersedia di Safari pada tahun 2022. Hingga fitur distandardisasi, pengguna sumber daya pihak ketiga harus memastikan bahwa mereka juga telah mengoptimalkan untuk browser lain. Kami akan membantu dengan menyoroti hal ini dalam panduan kami jika relevan.

3. Untuk melaksanakan project ini, kami harus bekerja sama dengan partner dan developer untuk tidak hanya membantu kami memahami persyaratan tertentu, tetapi juga menguji solusi eksperimental dalam skala besar, memberikan masukan, melakukan iterasi, dan berimprovisasi sesuai kebutuhan. Perubahan ini harus direncanakan, memberikan kerangka waktu yang wajar untuk pengujian dan evaluasi.

Proposal Standar Awal

Kami telah melakukan beberapa eksperimen awal untuk mengembangkan fitur yang dapat diaktifkan untuk mengoptimalkan proses pemuatan pihak ketiga. Kami puas dengan hasil yang diamati dan saat ini dapat mendiskusikan dua fitur tersebut.

LazyEmbeds

Chrome sebelumnya akan memuat dengan lambat di luar layar elemen <img> dan <iframe> untuk pengguna Mode Ringan. Fitur ini dapat diperluas ke semua pengguna untuk menunda pemuatan elemen <iframe> yang dianggap sebagai sematan pihak ketiga hingga pengguna men-scroll di dekatnya. Tindakan ini dapat mempercepat pemuatan bagian lain di halaman, meningkatkan Core Web Vitals, mengurangi penggunaan memori, dan menghemat data.

Berikut adalah demo penggunaan LazyEmbeds untuk memuat video YouTube secara lambat di halaman. Satu video YouTube tersemat biasanya menambahkan 500-600 KB JavaScript ke halaman. Kami mencoba mengoptimalkan postingan blog dengan 14 sematan video tersebut menggunakan LazyEmbeds. Hasilnya menjanjikan untuk menghemat waktu pemuatan halaman dan menghemat data.

Untuk mempelajari cara ini lebih lanjut, lihat penjelasan dan rangkaian pesan intent-untuk-eksperimen serta ekstensi eksperimen blink-dev kami.

Throttling pihak ketiga yang ditargetkan

Skrip pihak ketiga sering ditambahkan oleh berbagai tim tanpa proses pengawasan menyeluruh. Tim engineer di The Telegraph mengatakan bahwa "semua orang menginginkan 'tag tersebut' di halaman yang akan menghasilkan uang bagi organisasi". Hal ini dapat terus meningkatkan beban pengelolaan dampak performa.

Throttling skrip pihak ketiga yang ditargetkan mengusulkan untuk men-throttle jenis pihak ketiga yang sangat spesifik untuk mengurangi dampaknya. Tindakan ini akan memungkinkan browser memuat konten utama + pihak ketiga yang penting lebih awal, sementara konten yang aman untuk dimuat nanti dibatasi.

Meningkatkan API RUM

Kami juga mempertimbangkan untuk meningkatkan API RUM guna menyertakan informasi yang akan relevan dalam menilai performa pihak ketiga. Peningkatan tersebut meliputi:

1. Pelaporan <iframe>: Kami sedang mengupayakan solusi yang dapat memanfaatkan Performance Timeline API untuk pelaporan lintas-frame. Dengan demikian, penulis halaman tingkat atas dapat memeriksa data performa untuk iframe pihak ketiga yang bekerja sama yang disematkan di halaman.

2. Atribusi Tugas Panjang: Long Tasks API di RUM akan membantu pemilik situs mengidentifikasi tugas panjang yang mengikat thread utama untuk waktu yang lama dan menunda interaksi.

Info terbaru lebih lanjut

Kami masih bereksperimen dengan banyak ide semacam itu dan berharap dapat memublikasikan draf penjelasan dan spesifikasi GitHub untuk perubahan saat kita melanjutkan. Pihak ketiga dan pemilik situs yang ingin bermitra dengan kami atau memberikan masukan dapat berkontribusi pada diskusi melaluinya. Pihak ketiga juga dapat mulai berfokus pada pengoptimalan Data Web Inti dan metrik INP untuk memastikan bahwa data Core Web Vitals/INP yang buruk tidak diatribusikan ke data tersebut. Untuk saat ini, bagi pengguna yang aktif mencari info terbaru dapat merujuk ke postingan di grup blink-dev.

Kami berharap dapat mengeksplorasi masalah ini lebih lanjut dan berinteraksi dengan komunitas berdasarkan pembelajaran kami.

Dengan ucapan terima kasih khusus kepada Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. Jose, Melissa Mitchell, Yoav Weiss, Shunya Shishido, dan Minoru Chikamune atas masukan dan kontribusi mereka.