Lebih dari 90% halaman memuat setidaknya satu pihak ketiga, dan 1,000 situs teratas sekarang memiliki rata-rata 106 permintaan pihak ketiga di perangkat seluler — 15 lebih banyak daripada tahun sebelumnya — menurut HTTP Archive. Almanak Web 2025Skrip merupakan bagian terbesar dari permintaan tersebut, yaitu sebesar 24.8%.
Hampir tidak ada satupun yang terjadi karena keputusan. Itu terjadi satu per satu melalui proses penandaan, dan tidak ada yang memiliki totalnya. Biayanya dapat diukur: perpustakaan studi kasus Google mencatat peningkatan LCP oleh Vodafone Italia sebesar 31% dan mengambil langkah-langkah tertentu. Penjualan 8% lebih banyak.
Panduan ini ditujukan untuk orang yang diminta memperbaiki Core Web Vitals yang tidak dapat menghapus tag pemasaran secara sepihak. Pada akhirnya, Anda akan memiliki skor lima kriteria untuk setiap pihak ketiga di situs Anda, aturan perutean yang mengubah setiap skor menjadi satu tindakan spesifik, dan angka yang dapat dipertahankan untuk rapat di mana seseorang membela tag yang memakan waktu 380ms tersebut.
Bangun persediaan sebelum Anda mendapatkan apa pun.
Anda membutuhkan dua daftar; tidak satu pun yang lengkap jika berdiri sendiri.
Daftar kontainer. Ekspor kontainer Google Tag Manager Anda: tag, pemicu, dan variabel beserta pemilik dan kondisi pemicunya. Inilah tujuannya.
Daftar jaringan. Muat halaman di Chrome DevTools dengan cache dinonaktifkan, lalu jalankan Lighthouse dan baca audit "Kurangi dampak kode pihak ketiga". Inilah yang sebenarnya dieksekusi, termasuk tag yang disuntikkan oleh tag lain, yang tidak pernah muncul dalam ekspor kontainer.
Untuk setiap pihak ketiga dalam salah satu daftar, catat tujuh kolom berikut:
- Vendor dan apa yang diklaimnya
- Pemilik bisnis yang disebutkan namanya (orang, bukan departemen)
- Ukuran transfer skrip
- Waktu pemblokiran thread utama yang disebabkan oleh hal tersebut
- Apakah hal itu berada pada jalur kritis menuju elemen LCP?
- Template halaman mana yang akan diaktifkan
- Terakhir kali seseorang membuat keputusan menggunakan datanya
Kolom terakhir itulah yang sering dilewati orang, dan yang paling sering mengakhiri perdebatan. Skor terhadap data kolom: Core Web Vitals dinilai pada Persentil ke-75 dari pemuatan halaman sebenarnya, dan pengujian di laboratorium dengan koneksi cepat akan meningkatkan performa perangkat Anda.
Lima kriteria penilaian
Berikan skor 0–3 untuk setiap pihak ketiga pada kelima poin tersebut. Total skor yang lebih tinggi berarti alasan yang lebih kuat untuk pencopotan.
| Kriterium | 0 poin | Titik 1 | 2 poin | 3 poin |
|---|---|---|---|---|
| Biaya thread utama | Di bawah 50 ms | 50–150 md | 150–350 md | Lebih dari 350 ms |
| Posisi jalur kritis | Api muncul setelah pemuatan, di luar jalur. | Asinkron, tidak berpengaruh pada LCP | Menunda elemen LCP | Pemblokiran rendering di <head> |
| Penggunaan yang telah dibuktikan | Mengambil keputusan setiap minggu | Pelaporan bulanan saja | Seseorang membukanya setiap tiga bulan sekali. | Tidak ada penggunaan yang disebutkan dalam 90 hari |
| Ketergantian | Tidak ada pengganti yang tersedia. | Vendor SDK adalah satu-satunya pilihan. | Fasad atau lazy-load dimungkinkan. | Tersedia solusi asli, sisi server, atau yang setara dari pihak pertama. |
| Ketergantungan persetujuan | Sangat diperlukan, tanpa persetujuan. | Persetujuan diperlukan, banyak hal setelah pemberian hibah. | Persetujuan diperlukan, banyak yang ditolak secara default. | Persetujuan diperlukan dan gerbang serta tag lainnya. |
Terdapat dua penggantian di atas total:
- Nilai 3 pada rute penggunaan yang terbukti untuk membunuh terlepas dari totalnya. Tidak ada biaya yang sepadan untuk sebuah label yang tidak digunakan siapa pun.
- Nilai 3 pada jalur posisi jalur kritis mengarah setidaknya ke band 3. Skrip yang menghambat rendering di bagian head bersifat struktural, betapapun berharganya vendor tersebut.
Tabel perutean
| Total | Tindakan | Persetujuan diperlukan |
|---|---|---|
| 0-3 | Simpan. Lakukan penilaian ulang dalam enam bulan. | None |
| 4-6 | Tunda atau muat secara bertahap | Teknik |
| 7-9 | Ganti dengan fasad, atau muat secara kondisional berdasarkan rute, geografi, atau status persetujuan. | Pemilik tag Engineering Plus |
| 10-12 | Pindahkan ke sisi server, atau ganti dengan alternatif pihak pertama. | Pemilik analitik |
| 13-15 | Bunuh. Sajikan skornya, bukan opini. | Manajer pemilik tag |
Dalam sebuah band, skor Replaceability menentukan taktik yang digunakan: skor 3 berarti ada alternatif dari pihak pertama atau sisi server, jadi gunakan jalur tersebut daripada opsi default band.
Kolom penutup penting karena setiap band menyebutkan satu orang. "Situs ini lambat karena tag" adalah sebuah keluhan. "Tag ini mendapat skor 11, berikut adalah orang yang menandatanganinya" adalah sebuah tiket.
Contoh soal yang sudah dikerjakan
Contoh tampilan proses pembayaran e-commerce kelas menengah. Bukan data klien; angka-angka tersebut hanya ilustrasi.
| label | Biaya | Posisi | penggunaan | menggantikan | Persetujuan | Total | Rute |
|---|---|---|---|---|---|---|---|
| Widget obrolan langsung | 3 | 2 | 0 | 2 | 1 | 8 | Fasad: dimuat saat diklik |
| Alat peta panas lama | 2 | 1 | 3 | 3 | 2 | 11 | Bunuh (Gunakan penggantian) |
| Tag konversi iklan | 1 | 1 | 0 | 3 | 2 | 7 | Pindahkan ke sisi server (Kemampuan Penggantian 3) |
| Platform manajemen persetujuan | 1 | 3 | 0 | 1 | 0 | 5 | Band 3 (Penggantian posisi): audit perilaku pemblokirannya |
| Penyedia font | 1 | 2 | 0 | 3 | 0 | 6 | Hosting sendiri dan subset (Kemampuan Penggantian 3) |
Widget obrolan adalah baris yang informatif. Widget ini benar-benar digunakan dan tidak dapat digantikan, dan masih mengarah ke fasad, karena kriteria tersebut memisahkan "apakah kita membutuhkan ini" dari "apakah kita membutuhkannya dalam 2.5 detik pertama".
[INTERNAL DATA NEEDED: replace this composite table with a real anonymised inventory from a Switas engagement — vendor category, measured blocking time, post-change field metric.]
Tiga solusi tersebut, diurutkan berdasarkan seberapa sering solusi tersebut benar-benar berhasil.
Fasad. Ganti elemen yang disematkan dengan placeholder statis yang memuat widget sebenarnya saat terjadi interaksi. Widget obrolan, video, peta, dan ulasan biasanya menjadi contoh yang berhasil. Ini adalah perbaikan yang paling efektif dalam sebagian besar audit karena menghilangkan biaya tanpa menghilangkan fitur, itulah sebabnya solusi ini lolos dari rapat.
Menunda. Berguna, dengan beberapa catatan. Chrome menurunkan prioritas jaringan of async ke defer sumber daya, sehingga dimuat lebih lambat dari yang Anda harapkan — tidak masalah untuk piksel, tetapi tidak untuk apa pun yang dirender. web.dev juga mencatat bahwa embed "dapat memblokir window.onload jika server mereka merespons lambat, bahkan jika embed menggunakan async atau defer." Penundaan hanya memindahkan biaya; tidak selalu menghilangkannya.
Penandaan sisi server. Ini perlu dikoreksi, karena dijual sebagai produk peningkat kecepatan halaman padahal bukan. Ini adalah produk milik Google sendiri. pengantar penandaan sisi server menjelaskan kepemilikan data, pembentukan, dan perutean — "hanya Anda yang memiliki akses ke data di server sampai Anda memilih untuk mengirimkannya ke tempat lain" — dan tidak membuat klaim kinerja apa pun. Browser masih menjalankan kode pengukuran dan masih mengirimkan peristiwa, melalui piksel gambar, fetch, XHR atau petugas layanan yang dilayani dari Anda domain kontainer server.
Yang dibeli adalah konteks pihak pertama dan kendali atas apa yang keluar dari infrastruktur Anda. Peningkatan kecepatan apa pun adalah efek samping dari skrip vendor yang Anda hapus saat migrasi. Jika vendor menjanjikan peningkatan INP hanya dari penandaan sisi server, tanyakan skrip mana yang berhenti dimuat di browser; jika jawabannya tidak ada, tidak ada peningkatan. INP terdiri dari penundaan input, durasi pemrosesan, dan penundaan presentasi., dan skrip memperbesar dua hal pertama dengan menduduki thread utama. Mengubah lokasi permintaan mengirim tidak mempengaruhi keduanya.
Di mana lapisan persetujuan mengubah perhitungan aritmatika
Platform manajemen persetujuan Anda biasanya merupakan item dengan skor tertinggi dalam inventaris: platform ini berada di bagian head, secara desain menghambat rendering, dan setiap tag lainnya menunggunya. Beri skor seperti hal lainnya.
Kemudian tentukan mode persetujuan mana yang ingin Anda jalankan, karena keduanya memiliki profil kinerja yang berbeda. Menurut ketentuan Google, mode persetujuan dasar artinya tag "diblokir hingga pengguna berinteraksi dengan banner persetujuan", sedangkan mode lanjutan "dimuat dengan pengaturan default yang telah ditetapkan denied" dan mengirimkan pengukuran tanpa cookie sebelum persetujuan. Versi Basic lebih cepat pada pemuatan awal. Namun, versi ini juga menghabiskan data Anda: Google Panduan EEA memperingatkan bahwa jika Anda mencegah tag dimuat hingga interaksi banner, "Google tidak akan dapat memverifikasi pilihan persetujuan pengguna dan ini dapat menyebabkan kehilangan data."
Di sini, detail regional menjadi penting. Turki bukan anggota EEA, jadi persyaratan persetujuan EEA Google tidak berlaku untuk lalu lintas dari Turki — tetapi hukum Turki berlaku. Panduan KVKK tentang praktik cookie memperlakukan cookie analitik sebagai memerlukan persetujuan eksplisit, bukan hanya wajib, mewajibkan kategori persetujuan tidak dicentang secara default dan "Tolak Semua" sama menonjolnya dengan "Terima Semua", dan melarang dinding cookie.
Konsekuensi praktis bagi pengecer Turki atau multi-pasar: jalankan mode persetujuan dasar pada lalu lintas Turki dan mode lanjutan pada lalu lintas EEA, dan Anda tidak akan kehilangan apa pun yang menjadi hak Anda di kedua pasar tersebut. Sebagian besar CMP tidak akan melakukan ini secara otomatis. Ini adalah keputusan konfigurasi yang dibatasi secara geografis, bukan plugin.
Apa yang tidak tercakup dalam rubrik ini
- Sistem ini memberi skor pada tag, bukan halaman. Sebuah tag yang tidak berbahaya di halaman beranda dapat menjadi masalah besar di halaman daftar produk karena memuat hingga empat puluh tag tersebut.
- Biaya thread utama tidak bersifat aditif. Menghapus lima tag 100ms jarang menghasilkan nilai 500ms. Ukur setelah setiap perubahan.
- Ini mengabaikan kode Anda sendiri. Tugas-tugas panjang dari hidrasi kerangka kerja seringkali merupakan bagian terbesar dari INP yang buruk, dan tidak ada audit pihak ketiga yang akan menemukannya.
- Ini hanya memberikan Anda informasi dari sisi biaya. Tag berdurasi 380ms yang menghasilkan pendapatan nyata yang dapat diatribusikan mungkin layak untuk dipertahankan.
- Pihak tersebut tidak memiliki pendapat mengenai keamanan atau residensi data., terkadang alasan sebenarnya mengapa seorang vendor harus pergi.
- Tag yang diselipkan tersembunyi dari ekspor kontainer. Jika kedua daftar tersebut berbeda, percayalah pada daftar jaringan.
FAQ (Pertanyaan Umum)
Bagaimana cara saya mengukur biaya thread utama untuk satu pihak ketiga tertentu? Gunakan panel Kinerja Chrome DevTools untuk mengaitkan tugas-tugas yang memakan waktu lama dengan asal skrip, dan periksa silang dengan audit Lighthouse "Kurangi dampak kode pihak ketiga". Konfirmasikan dengan data lapangan, karena uji coba di laboratorium meremehkan biaya sebenarnya.
Apakah penandaan sisi server meningkatkan Core Web Vitals? Tidak dengan sendirinya. Dokumentasi Google untuk penandaan sisi server menjelaskan kontrol dan perutean data, bukan kecepatan halaman, dan browser masih memuat kode pengukuran dan mengirimkan peristiwa. Peningkatan apa pun berasal dari skrip vendor yang Anda hapus dari halaman sebagai bagian dari migrasi.
Core Web Vital mana yang paling sering dirusak oleh pihak ketiga? Biasanya INP, karena skrip menempati thread utama dan meningkatkan penundaan input serta durasi pemrosesan. Tag yang memblokir rendering di bagian head malah mengenai LCP, dan banner atau widget yang disuntikkan terlambat mengenai CLS.
Apakah saya harus menghosting sendiri skrip pihak ketiga? Terkadang, tetapi ini adalah sebuah transaksi. Salinan yang dihosting sendiri berhenti menerima perubahan API vendor dan perbaikan keamanan sampai Anda memperbaruinya secara manual, yang oleh web.dev dianggap sebagai risiko pendapatan dan keamanan.
Apa yang seharusnya menjadi tujuan saya? Pada persentil ke-75 dari waktu pemuatan halaman sebenarnya: LCP pada atau di bawah 2.5 detik, INP pada atau di bawah 200 milidetik, CLS pada atau di bawah 0.1.
Apakah saya memerlukan mode persetujuan Google jika sebagian besar lalu lintas saya berasal dari Turki? Persyaratan persetujuan EEA Google tidak berlaku untuk lalu lintas Turki, tetapi aturan cookie KVKK berlaku, jadi Anda tetap memerlukan mekanisme persetujuan yang berfungsi. Yang berubah adalah Anda lebih bebas memilih implementasi dasar yang lebih cepat untuk segmen tersebut.
Seberapa sering ini harus dinilai ulang? Setiap kuartal untuk seluruh inventaris, dan pada setiap rilis yang menambahkan vendor. Tumpukan tag tumbuh kembali: angka tahunan Web Almanac menunjukkan jumlah permintaan pihak ketiga meningkat.
Apa yang harus saya lakukan jika pemilik tag menolak? Kirimkan skor dan nama band, bukan perdebatannya. Rubrik tersebut ada agar percakapan berfokus pada angka dan tindakan yang ditentukan, bukan pada prioritas siapa yang menang.
Jika halaman pembayaran atau daftar produk Anda gagal dalam pengujian Core Web Vitals dan Anda tidak dapat menentukan vendor mana yang bertanggung jawab, jalankan rubrik ini pada tumpukan teknologi Anda sendiri — atau minta kami menjalankannya, dengan data lapangan dan daftar tugas yang diprioritaskan, melalui Layanan kinerja web Switas.
sumber
- Pihak Ketiga — Almanak Web 2025, Arsip HTTP
- Informasi Penting Web — web.dev
- Interaksi ke Next Paint (INP) — web.dev
- Memuat JavaScript pihak ketiga — web.dev
- Dampak bisnis dari Core Web Vitals — studi kasus web.dev
- Pengenalan penandaan sisi server — Google Tag Platform
- Mengirim data ke kontainer server — Google Tag Platform
- Konsep mode persetujuan — Google Tag Platform
- Pembaruan pada mode persetujuan untuk lalu lintas EEA — Bantuan Google Ads
- Peta jalan kepatuhan KVKK Çerez Rehberi — Mondaq (analisis panduan Otoritas setebal 61 halaman; kvkk.gov.tr tidak dapat diakses pada saat penulisan)
