Addy Osmani

Referensi pihak ketiga (seperti penyematan dan skrip) banyak digunakan di seluruh web saat ini. Solusi ini menyediakan solusi siap pakai untuk menyematkan media sosial, video, analisis, live chat, iklan, pengujian A/B, personalisasi, dan lainnya. Penyematan pihak ketiga adalah bagian yang diperlukan dari situs modern yang memungkinkan pemilik situs berfokus pada kompetensi intinya, sekaligus memindahkan fungsi standar, tetapi penting, ke penyedia eksternal.

Jika pihak pertama dan pihak ketiga di halaman web bekerja secara harmonis, halaman dapat memberikan pengalaman pengguna yang luar biasa. Namun, hal ini memerlukan upaya yang signifikan dari tim engineering dan bisnis serta sering kali diabaikan, sehingga menghasilkan halaman web yang kurang berperforma dan dampak negatif pada 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 masa depan tentang web yang menyediakan nilai bisnis yang diinginkan dengan regresi minimal pada performa atau pengalaman pengguna situs yang menggunakannya di browser melalui skrip dan resource pihak ketiga. Hal ini akan memungkinkan pengguna untuk mengalami pemuatan halaman yang lebih cepat.

Selama setahun terakhir, kami telah mempertimbangkan, mendiskusikan, dan bereksperimen dengan banyak kemungkinan yang berpotensi melindungi pengalaman pengguna dari dampak buruk skrip pihak ketiga tanpa mengurangi nilai bisnisnya bagi pemilik situs.

Melalui postingan ini, kami ingin membagikan informasi tentang beberapa eksperimen kami. Kami berharap 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.

Mempelajari lebih lanjut pihak ketiga

Pihak ketiga adalah resource yang ditayangkan oleh penyedia eksternal situs. Iklan tersebut tidak langsung berada dalam kontrol pemilik situs, tetapi ditampilkan dengan persetujuan mereka. Referensi pihak ketiga adalah:

• Dihosting di origin bersama dan publik yang berbeda dengan origin situs utama.
• Tidak ditulis atau dipengaruhi oleh pemilik situs tertentu.
• Banyak digunakan oleh berbagai situs.

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

Sumber: Pihak ketiga menurut kategori.

Skrip dan library pihak ketiga ini memungkinkan developer web memanfaatkan solusi yang telah dicoba dan diuji untuk menerapkan fitur standar, bukan menciptakan kembali roda. Dengan demikian, pihak ketiga mengurangi waktu pengembangan dan membantu bisnis meluncurkan atau mengupgrade produk mereka lebih cepat. Tidak heran 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 pelajaran untuk fitur tertentu yang mereka sediakan. Sebagian besar pihak ketiga populer telah melalui beberapa iterasi, dan kode mereka dapat dioptimalkan untuk sasaran bisnis mereka sendiri, yang mungkin atau mungkin tidak mencakup performa halaman yang menggunakannya. Namun, kami tahu bahwa bahkan pihak ketiga yang paling dioptimalkan memengaruhi performa. Berikut adalah alasan utama dampak ini:

1. Ukuran dan Biaya Eksekusi Skrip: Pihak ketiga sering kali bertujuan untuk memberikan fungsi yang signifikan "hanya" dengan memasukkan elemen <script> atau <iframe> ke halaman Anda. Elemen ini kemudian mengambil skrip dan resource yang berukuran besar dan memerlukan waktu lebih lama untuk didownload dan dieksekusi. JavaScript yang terlalu banyak membuat thread utama sibuk lebih lama, memblokir rendering, dan menunda interaksi pengguna. Beberapa pihak ketiga teratas diketahui memblokir thread utama dari 42 md hingga 1,6 s untuk lebih dari 50% situs yang dianalisis. Thread utama yang diblokir akan menghasilkan Total Blocking Time (TBT) yang tinggi, yang merupakan salah satu metrik yang memengaruhi skor performa situs. Selain itu, hal 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 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, berat halaman, atau penggunaan CPU secara signifikan. Menetapkan proses tata kelola dapat mengatasi situasi tersebut dan memungkinkan developer mengaudit dampak setiap penyedia. Akan lebih baik jika developer memiliki data siap pakai untuk semua pihak ketiga yang menyediakan fungsi tertentu dengan dampak performa, manfaat, dan komprominya untuk perbandingan. Tantangan lain yang dihadapi tim adalah untuk banyak situs, tag pihak ketiga hanya berjalan di produksi, tetapi tidak di lingkungan pengembangan, sehingga mempersulit developer untuk mengujinya.

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

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

Sebagai konsekuensi dari hal di atas, pihak ketiga dapat memengaruhi salah satu atau semua komponen Core Web Vitals. Sebagian besar pihak ketiga berdampak negatif pada Largest Contentful Paint (LCP) dan First Input Delay (FID). Penyematan YouTube memblokir thread utama selama 4,5 detik untuk 10% situs di perangkat seluler, dan setidaknya 1,6 detik untuk 50% situs yang dipelajari. Bayangkan rasa frustrasi pengguna jika mereka menemukan halaman dengan 20 skrip tersebut pada koneksi yang lambat. Visualisasi berikut dari thirdpartyweb.today menunjukkan pihak ketiga dengan dampak performa terbesar saat ini.

"Di ~4 juta situs teratas, ~2.700 origin menyumbang ~57% dari semua waktu eksekusi skrip dengan 50 entitas teratas sudah menyumbang ~47%". - third-party-web

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 dapat berarti bisnis yang baik untuk pihak ketiga yang digunakan. Bekerja sama untuk mengurangi dampak pihak ketiga dapat menjadi keuntungan bagi semua orang dalam rantai.

Kami memahami bahwa Google menjual sejumlah skrip pihak ketiga yang umum digunakan, termasuk Google Tag Manager, penyematan YouTube, dan ReCaptcha. Kami menyadari bahwa sejumlah skrip kami dapat memiliki dampak performa yang lebih ringan pada Data Web Inti, dan kami berkomitmen untuk mencari cara untuk meningkatkan dampak ini jika memungkinkan.

Bagaimana Chrome dapat membantu?

Resource pihak ketiga yang memiliki performa buruk biasanya menjadi tantangan bagi developer, yang memerlukan perubahan bertahap dalam dinamika ekosistem yang mendasarinya. Chrome ingin menjelajahi ruang ini untuk mencapai hasil berikut:

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

   Kami tahu bahwa kami tidak dapat melakukan upaya ini dengan baik jika tidak berkolaborasi dengan partner, bisnis, pihak ketiga, dan developer. Kami ingin menciptakan ruang terbuka untuk membahas 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 mereka dalam alat dan di lapangan, jalur yang jelas dan baik untuk penggunaannya, serta insentif yang lebih baik selama waktu penulisan untuk memastikannya 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 terkait setiap skrip yang disematkan, termasuk alternatif yang lebih cepat jika berlaku.

Pendekatan yang Diusulkan

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

1. **Memberikan atribusi yang lebih mendalam kepada developer untuk setiap dampak pihak ketiga melalui RUM dan di alat developer Chrome.**

   RUM mengacu pada data metrik pengguna sebenarnya (juga dikenal sebagai data lapangan) yang tersedia melalui API pemantauan performa web. Alat developer Chrome mencakup Lighthouse, Chrome DevTools, dan Laporan Pengalaman Pengguna Chrome. Kami mengusulkan untuk meningkatkan API dan alat yang tersedia agar developer situs memahami dampak dari setiap pihak ketiga yang telah mereka gunakan di setiap halaman. Alat ini juga akan mengedukasi mereka tentang tindakan yang dapat mereka lakukan untuk mengurangi dampaknya (misalnya, menundanya atau menggunakan facade) dan mempelajari potensi solusi lainnya (pihak ketiga lain atau DIY) dengan kompromi. Untuk API pemantauan performa web, kami sedang mempelajari cara memperluas cakupan resource lintas origin tanpa mengorbankan privasi dan keamanan pengguna kami.

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

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

   Kami juga ingin mengatasi masalah tersebut di framework JavaScript dan Sistem Pengelolaan Konten (CMS) jika lebih sesuai. Project seperti Aurora dan WordPress Performance Team telah mengajarkan kepada kita pentingnya setelan default bawaan yang menyelesaikan masalah pemuatan yang diketahui. Setelan default yang disertakan dalam framework dan CMS memandu bisnis di sepanjang jalur yang jelas. Hal 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 kapan dan bagaimana pihak ketiga tertentu harus dimuat dalam siklus proses halaman. (Misalnya, komponen skrip Next.js memiliki default bawaan untuk memuat skrip pihak ketiga setelah halaman menjadi interaktif.)

3. **Berikan 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 menguranginya di hulu. Kami harus memanggil semua pihak ketiga, termasuk yang ditulis oleh Google, agar berhasil.

Tantangan

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

• Pihak ketiga adalah masalah lintas-sektor yang melibatkan iklan, analisis, pengelolaan tag, utilitas, dan banyak lagi. Setiap area memerlukan pertimbangan serangkaian persyaratan dan kompromi yang unik. Misalnya:
  • Keputusan untuk mengoptimalkan pemuatan iklan bergantung pada kompromi antara pendapatan dan pengalaman pengguna. Terlalu awal, iklan akan memblokir konten yang berharga; terlalu terlambat, pengguna akan melewatkan konten tersebut.
  • Skrip Analytics menambah beban halaman, tetapi memberikan data berharga tentang tindakan pengguna kepada bisnis.

Kami berharap dapat berpartner dengan berbagai kategori pihak ketiga, memahami nuansa yang terlibat, menyelesaikan kompromi, dan mengembangkan insentif yang cocok untuk semua orang. Kami menyadari bahwa kami harus bekerja secara terpisah dengan entitas di setiap area agar strategi kami efektif. Hal ini mencakup 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 yang cermat, yaitu mengidentifikasi data yang paling relevan dalam mengukur dampak, mengatribusinya secara akurat dan terperinci, serta memberikan jalur yang tepat untuk ke depannya. Pada akhirnya, penghitungan performa pihak ketiga tertentu terhadap pesaingnya harus transparan bagi semua orang.

2. Kami mengusulkan untuk meningkatkan Chrome agar dapat menerapkan pengoptimalan yang membantu mencapai keseimbangan yang tepat untuk memprioritaskan pemuatan resource pihak pertama vs. pihak ketiga. Perubahan yang berharga akan tersedia sebagai standar di semua browser, tetapi perlu waktu. Misalnya, atribut loading untuk elemen <img> dan <iframe> telah tersedia di Chrome/Edge sejak 2019, tetapi hanya tersedia di Safari pada tahun 2022. Hingga fitur distandarisasi, pengguna resource 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 menjalankan project ini, kami harus berinteraksi dengan partner dan developer, tidak hanya untuk membantu kami memahami persyaratan tertentu, tetapi juga untuk menguji solusi eksperimental dalam skala besar, memberikan masukan, melakukan iterasi, dan berimprovisasi sesuai kebutuhan. Perubahan harus direncanakan, dengan mempertimbangkan jangka waktu yang wajar untuk pengujian dan evaluasi.

Proposal Standar Awal

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

LazyEmbeds

Sebelumnya, Chrome akan memuat lambat elemen <img> dan <iframe> di luar layar untuk pengguna Mode Ringan. Fitur ini dapat diperluas ke semua pengguna untuk menunda pemuatan elemen <iframe> yang ditentukan sebagai penyematan pihak ketiga hingga pengguna men-scroll di dekatnya. Hal ini dapat mempercepat pemuatan bagian lain halaman, meningkatkan Data Web Inti, mengurangi penggunaan memori, dan menghemat data.

Berikut adalah demo yang menggunakan LazyEmbeds untuk memuat lambat video YouTube di halaman. Satu sematan video YouTube biasanya menambahkan JavaScript sebesar 500-600 KB ke halaman. Kami mencoba mengoptimalkan postingan blog dengan 14 penyematan video tersebut menggunakan LazyEmbeds. Hasilnya menjanjikan dalam hal waktu pemuatan halaman dan penghematan data.

Untuk mempelajari lebih lanjut pekerjaan ini, lihat penjelasan kami dan thread intent-to-experiment serta ekstensi eksperimen blink-dev.

Throttling pihak ketiga yang ditargetkan

Skrip pihak ketiga sering kali ditambahkan oleh berbagai tim tanpa proses pengawasan menyeluruh. Tim engineer di The Telegraph menyatakan 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 membatasi jenis pihak ketiga yang sangat spesifik untuk mengurangi dampaknya. Hal ini akan memungkinkan browser memuat konten utama + pihak ketiga penting lebih awal, sedangkan konten yang aman untuk dimuat nanti akan dibatasi.

Meningkatkan RUM API

Kami juga mempertimbangkan untuk meningkatkan RUM API agar menyertakan informasi yang akan relevan dalam menilai performa pihak ketiga. Peningkatan ini mencakup:

1. Pelaporan <iframe>: Kami sedang mengerjakan solusi yang dapat memanfaatkan Performance Timeline API untuk pelaporan lintas frame. Hal ini akan memungkinkan penulis halaman tingkat atas memeriksa data performa untuk iframe pihak ketiga yang bekerja sama dan 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 lainnya

Kami masih bereksperimen dengan banyak ide tersebut dan berharap dapat memublikasikan penjelasan GitHub dan draf spesifikasi untuk perubahan seiring berjalannya waktu. Pihak ketiga dan pemilik situs yang ingin berpartner dengan kami atau memberikan masukan dapat berkontribusi dalam diskusi melalui forum ini. Pihak ketiga juga dapat mulai berfokus untuk mengoptimalkan metrik Core Web Vitals dan INP untuk memastikan bahwa data Core Web Vitals/INP yang buruk tidak diatribusikan kepada mereka. Untuk saat ini, pengguna yang secara aktif mencari info terbaru dapat melihat postingan di grup blink-dev.

Kami berharap dapat mempelajari ruang masalah ini lebih lanjut dan berinteraksi dengan komunitas terkait 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.