Praktik terbaik untuk tag dan tag manager

Mengoptimalkan tag dan tag manager untuk Data Web Inti.

Tag adalah cuplikan kode pihak ketiga yang disisipkan ke situs, biasanya melalui tag manager. Tag paling umum digunakan untuk pemasaran dan analisis.

Dampak performa tag dan pengelola tag sangat bervariasi dari satu situs ke situs lainnya. Tag manager dapat dibandingkan dengan amplop: Tag Manager menyediakan wadah, tetapi apa yang Anda isi dan cara Anda menggunakannya, semuanya terserah Anda.

Artikel ini membahas teknik pengoptimalan tag dan tag manager untuk performa dan Data Web. Meskipun artikel ini merujuk ke Google Tag Manager, banyak ide yang dibahas juga berlaku untuk tag manager lainnya.

Dampak pada Data Web Inti

Tag Manager sering kali dapat memengaruhi Data Web Inti Anda secara tidak langsung dengan menggunakan resource yang diperlukan untuk memuat halaman dengan cepat dan menjaganya tetap responsif. Bandwidth dapat digunakan untuk mendownload JavaScript Tag Manager untuk situs Anda, atau panggilan berikutnya yang dilakukan. Waktu CPU di thread utama dapat digunakan untuk mengevaluasi dan menjalankan JavaScript yang terdapat dalam tag manager dan tag.

Largest Contentful Paint (LCP) rentan terhadap pertentangan bandwidth selama waktu pemuatan halaman yang penting. Selain itu, memblokir thread utama dapat menunda waktu render LCP.

Pergeseran Tata Letak Kumulatif (CLS) dapat terpengaruh, baik dengan menunda pemuatan resource penting sebelum render pertama, atau oleh Tag Manager yang memasukkan konten ke halaman.

Interaction to Next Paint (INP) rentan terhadap pertentangan CPU di thread utama, dan kami telah melihat korelasi antara ukuran tag manager dan skor INP yang lebih buruk.

Jenis tag

Dampak tag pada performa bervariasi menurut jenis tag. Secara umum, tag gambar ("piksel") memiliki performa terbaik, diikuti oleh template kustom, dan terakhir, tag HTML kustom. Tag vendor bervariasi bergantung pada fungsi yang diizinkan.

Namun, perlu diingat bahwa cara Anda menggunakan tag sangat memengaruhi dampak performanya. "Piksel" berperforma tinggi terutama karena sifat jenis tag ini menerapkan pembatasan yang ketat terkait cara penggunaannya; tag HTML kustom tidak selalu buruk untuk performa, tetapi karena tingkat kebebasan yang ditawarkan kepada pengguna, tag dapat mudah disalahgunakan dengan cara yang buruk bagi performa.

Saat memikirkan tag, perhatikan skalanya: dampak performa dari setiap tag dapat diabaikan—tetapi dapat menjadi signifikan jika puluhan atau ratusan tag digunakan di halaman yang sama.

Tidak semua skrip harus dimuat menggunakan tag manager

Tag Manager biasanya bukan mekanisme yang baik untuk memuat resource yang menerapkan aspek visual atau fungsional langsung dari pengalaman pengguna, misalnya, pemberitahuan cookie, banner besar, atau fitur situs. Penggunaan tag manager untuk memuat resource ini biasanya menunda pengiriman. Hal ini buruk bagi pengalaman pengguna dan juga dapat meningkatkan metrik seperti LCP dan CLS. Selain itu, perlu diingat bahwa beberapa pengguna memblokir tag manager. Penggunaan tag manager untuk menerapkan fitur UX dapat mengakibatkan situs rusak bagi beberapa pengguna.

Berhati-hatilah dengan tag HTML Kustom

Tag HTML kustom telah ada selama bertahun-tahun dan banyak digunakan di sebagian besar situs. Tag HTML kustom memungkinkan Anda untuk memasukkan kode Anda sendiri dengan sedikit pembatasan karena, meskipun namanya, tujuan utama tag ini adalah untuk menambahkan elemen <script> kustom ke halaman.

Tag HTML kustom dapat digunakan dengan berbagai cara dan dampaknya sangat bervariasi. Saat mengukur performa situs Anda, perhatikan bahwa sebagian besar alat akan mengatribusikan dampak performa tag HTML Kustom ke tag manager yang memasukkannya, bukan tag itu sendiri.

Tag HTML kustom dapat menyisipkan elemen ke halaman sekitarnya. Tindakan menyisipkan elemen ke dalam halaman dapat menjadi sumber masalah performa, dan dalam beberapa kasus, juga dapat menyebabkan pergeseran tata letak.

• Umumnya, jika suatu elemen disisipkan ke dalam halaman, browser harus menghitung ulang ukuran dan posisi setiap item di halaman—proses ini dikenal sebagai tata letak. Dampak performa dari satu tata letak bersifat minimal, tetapi jika terjadi secara berlebihan, hal tersebut dapat menjadi sumber masalah performa. Dampak dari fenomena ini lebih besar pada perangkat kelas bawah dan halaman dengan jumlah elemen DOM yang tinggi.
• Jika elemen halaman yang terlihat disisipkan ke dalam DOM setelah area sekitarnya dirender, hal tersebut dapat menyebabkan pergeseran tata letak. Namun, fenomena ini tidak unik bagi Tag Manager. Namun, karena tag biasanya dimuat lebih lambat daripada bagian lain di halaman, biasanya tag tersebut disisipkan ke DOM setelah halaman di sekitarnya selesai dirender.

Pertimbangkan untuk menggunakan Template Kustom

Template kustom mendukung beberapa operasi yang sama seperti tag HTML Kustom, tetapi dibuat berdasarkan versi JavaScript dalam sandbox yang menyediakan API untuk kasus penggunaan umum seperti injeksi skrip dan injeksi piksel. Sesuai dengan namanya, template ini memungkinkan pembuatan template, oleh pengguna super yang dapat membuatnya dengan mempertimbangkan performa. Dengan lebih sedikit pengguna teknis yang dapat menggunakan {i>template<i}. Tindakan ini sering kali lebih aman daripada menyediakan akses penuh HTML Kustom.

Karena pembatasan yang lebih besar yang diberlakukan pada template kustom, tag ini jauh lebih kecil kemungkinannya untuk menunjukkan masalah performa atau keamanan. Namun, untuk alasan yang sama, template kustom tidak akan berfungsi untuk semua kasus penggunaan.

Memasukkan skrip dengan benar

Menggunakan tag manager untuk memasukkan skrip adalah kasus penggunaan yang sangat umum. Cara yang direkomendasikan untuk melakukannya adalah dengan menggunakan Template Kustom dan injectScript API.

Untuk informasi tentang cara menggunakan injectionScript API untuk mengonversi tag HTML Kustom yang ada, lihat Mengonversi tag yang ada.

Jika Anda harus menggunakan tag HTML Kustom, berikut beberapa hal yang perlu diingat:

• Library dan skrip pihak ketiga yang besar harus dimuat melalui tag skrip yang mendownload file eksternal (misalnya, <script src="external-scripts.js">), bukan langsung menyalin konten skrip ke tag. Meskipun penggunaan tag <script> secara terus-menerus menghilangkan perjalanan bolak-balik terpisah untuk mendownload konten skrip, praktik ini meningkatkan ukuran penampung dan mencegah skrip disimpan dalam cache secara terpisah oleh browser.
• Banyak vendor merekomendasikan penempatan tag <script> di bagian atas <head>. Namun, untuk skrip yang dimuat melalui tag manager, rekomendasi ini biasanya tidak diperlukan: biasanya, browser sudah selesai mengurai <head> saat tag manager dijalankan.

Menggunakan piksel

Dalam beberapa situasi, skrip pihak ketiga dapat diganti dengan "piksel" gambar atau iframe. Dibandingkan dengan piksel berbasis skrip, piksel mungkin mendukung lebih sedikit fungsi, sehingga sering dianggap sebagai implementasi yang kurang disukai karena hal tersebut. Namun, jika digunakan di dalam tag manager, piksel dapat menjadi lebih dinamis karena dapat diaktifkan pada pemicu dan meneruskan variabel yang berbeda. Tag ini adalah jenis tag yang paling berperforma dan aman karena tidak ada eksekusi JavaScript setelah diaktifkan. Piksel memiliki ukuran resource yang sangat kecil (kurang dari 1 KB) dan tidak menyebabkan pergeseran tata letak.

Hubungi penyedia pihak ketiga untuk mengetahui informasi selengkapnya tentang dukungan mereka untuk piksel. Selain itu, Anda dapat mencoba memeriksa kodenya untuk menemukan tag <noscript>. Jika vendor mendukung piksel, mereka akan sering menyertakannya dalam tag <noscript>.

Alternatif untuk piksel

Pixel menjadi populer terutama pada suatu waktu karena merupakan salah satu cara termurah dan paling andal untuk membuat permintaan HTTP dalam situasi ketika respons server tidak relevan ( misalnya, saat mengirim data ke penyedia analisis). API navigator.sendBeacon() dan fetch() keepalive dirancang untuk mengatasi kasus penggunaan yang sama ini, tetapi boleh dibilang lebih andal daripada piksel.

Tidak ada yang salah dengan terus menggunakan piksel karena piksel didukung dengan baik dan dampak performa yang minimal. Namun, jika Anda membuat beacon sendiri, sebaiknya pertimbangkan untuk menggunakan salah satu API ini.

sendBeacon()

navigator.sendBeacon() API dirancang untuk mengirim data dalam jumlah kecil ke server web dalam situasi ketika respons server tidak menjadi masalah.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() memiliki API terbatas: hanya mendukung pembuatan permintaan POST dan tidak mendukung penyetelan header kustom. Google Play didukung oleh semua browser modern.

fetch() keepalive

keepalive adalah flag yang memungkinkan Fetch API untuk membuat permintaan non-pemblokiran seperti pelaporan peristiwa dan analisis. API ini digunakan dengan menyertakan keepalive: true dalam parameter yang diteruskan ke fetch().

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

Jika fetch() keepalive dan sendBeacon() tampak sangat mirip, itu karena keduanya. Bahkan, di browser Chromium, sendBeacon() kini dibuat berdasarkan fetch() keepalive.

Saat memilih antara fetch() keepalive dan sendBeacon(), penting untuk mempertimbangkan fitur dan dukungan browser yang Anda butuhkan. Fetch() API jauh lebih fleksibel; tetapi, keepalive memiliki lebih sedikit dukungan browser daripada sendBeacon().

Dapatkan klarifikasi

Tag biasanya dibuat dengan mengikuti panduan yang diberikan oleh vendor pihak ketiga. Jika kode vendor tidak jelas—pertimbangkan untuk bertanya kepada seseorang yang mengetahui. Mendapatkan opini kedua dapat membantu mengidentifikasi apakah tag berpotensi menimbulkan masalah performa atau keamanan.

Memberi label pada tag dengan pemilik di Tag Manager juga direkomendasikan. Jauh terlalu mudah untuk melupakan siapa yang memiliki tag, dan takut untuk menghapusnya untuk berjaga-jaga.

Pemicu

Pada tingkat tinggi, pengoptimalan pemicu tag umumnya adalah memastikan untuk tidak memicu tag lebih dari yang diperlukan, dan memilih pemicu yang menyeimbangkan kebutuhan bisnis dengan biaya performa.

Pemicu itu sendiri adalah kode JavaScript yang akan meningkatkan ukuran—dan biaya eksekusi—tag manager. Meskipun sebagian besar pemicu berukuran kecil, efek kumulatifnya dapat menambah. Memiliki banyak peristiwa klik misalnya, atau pemicu timer dapat secara signifikan meningkatkan beban kerja Tag Manager.

Memilih peristiwa pemicu yang sesuai

Dampak performa tag tidak diperbaiki: secara umum, semakin cepat tag diaktifkan, semakin besar dampaknya terhadap performa. Resource biasanya dibatasi selama pemuatan halaman awal sehingga pemuatan atau eksekusi resource (atau tag) tertentu dapat menghilangkan resource dari resource lainnya.

Meskipun memilih pemicu yang sesuai untuk semua tag penting, hal ini sangat penting untuk tag yang memuat resource besar atau mengeksekusi skrip yang panjang.

Tag dapat dipicu pada Kunjungan Halaman (biasanya Page load, pada DOM Ready, pada Window Loaded), atau berdasarkan peristiwa kustom. Agar tidak memengaruhi pemuatan halaman, sebaiknya aktifkan tag yang tidak penting setelah Window Loaded.

Menggunakan peristiwa kustom

Peristiwa kustom memungkinkan Anda mengaktifkan pemicu sebagai respons terhadap peristiwa halaman yang tidak tercakup oleh pemicu bawaan Google Tag Manager. Misalnya, banyak tag menggunakan pemicu kunjungan halaman; tetapi, jangka waktu antara DOM Ready dan Window Loaded bisa jadi panjang di banyak halaman, dan hal ini dapat menyulitkan penyesuaian saat tag diaktifkan. Peristiwa kustom memberikan solusi untuk masalah ini.

Untuk menggunakan peristiwa kustom, pertama-tama buat pemicu peristiwa kustom dan perbarui tag Anda agar dapat menggunakan pemicu ini.

Untuk mengaktifkan pemicu, kirim peristiwa yang sesuai ke lapisan data.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

Menggunakan kondisi pemicu tertentu

Penggunaan kondisi pemicu tertentu membantu menghindari pengaktifan tag yang tidak perlu. Meskipun ada banyak cara untuk menerapkan konsep ini, salah satu hal paling sederhana tetapi paling berguna yang dapat Anda lakukan adalah memastikan bahwa tag hanya diaktifkan di halaman tempat tag tersebut benar-benar digunakan.

Variabel bawaan juga dapat dimasukkan ke dalam kondisi pemicu untuk membatasi pengaktifan tag.

Namun, perhatikan bahwa memiliki kondisi pemicu atau pengecualian yang kompleks memerlukan waktu pemrosesan di dalam dan di luar itu sendiri, jadi jangan membuatnya terlalu rumit.

Memuat tag manager pada waktu yang tepat

Menyesuaikan waktu pemuatan tag manager itu sendiri dapat berdampak signifikan pada performa. Pemicu, terlepas dari cara konfigurasinya, tidak dapat diaktifkan sampai tag manager dimuat. Meskipun memilih pemicu yang baik untuk setiap tag penting (seperti yang dijelaskan di atas), bereksperimen saat Anda memuat tag manager sering kali dapat memiliki dampak yang sama atau lebih besar, mengingat bahwa satu keputusan ini akan memengaruhi semua tag di halaman.

Pemuatan Tag Manager nantinya juga akan menambahkan lapisan kontrol dan dapat menghindari masalah performa di masa mendatang karena akan mencegah pengguna tag manager memuat tag terlalu awal secara tidak sengaja, tanpa menyadari dampaknya.

Variabel

Variabel memungkinkan data untuk dibaca dari halaman. Fungsi ini berguna untuk pemicu, dan dalam tag itu sendiri.

Seperti pemicu, variabel menyebabkan kode JavaScript ditambahkan ke tag manager, sehingga dapat menyebabkan masalah performa. Variabel dapat berupa jenis bawaan yang relatif sederhana dan dapat, misalnya, membaca bagian URL, cookie, lapisan data, atau DOM. Atau bisa berupa JavaScript kustom yang pada dasarnya tidak terbatas kemampuannya.

Buat variabel yang sederhana dan seminimal mungkin, karena variabel harus dievaluasi secara terus-menerus oleh Tag Manager. Hapus variabel lama yang tidak lagi digunakan untuk mengurangi ukuran skrip Tag Manager dan waktu pemrosesan yang digunakan.

Pengelolaan tag

Menggunakan tag secara efisien akan mengurangi risiko masalah performa.

Menggunakan lapisan data

Lapisan data "berisi semua informasi yang ingin Anda teruskan ke Google Tag Manager". Lebih jelasnya, ini adalah array JavaScript untuk objek yang berisi informasi tentang halaman. Ini juga dapat digunakan untuk memicu tag.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Meskipun Google Tag Manager dapat digunakan tanpa lapisan data, penggunaannya sangat direkomendasikan. Lapisan data menyediakan cara untuk menggabungkan data yang diakses oleh skrip pihak ketiga ke dalam satu tempat, sehingga memberikan visibilitas yang lebih baik tentang penggunaannya. Hal ini antara lain dapat membantu mengurangi penghitungan variabel dan eksekusi skrip yang berlebihan. Penggunaan lapisan data juga mengontrol data yang diakses oleh tag, bukan memberikan akses DOM atau variabel JavaScript secara penuh.

Hapus tag duplikat yang tidak digunakan

Tag duplikat dapat terjadi saat tag disertakan dalam markup HTML halaman selain dimasukkan melalui tag manager.

Tag yang tidak digunakan harus dijeda atau dihapus, bukan diblokir melalui penggunaan pengecualian pemicu. Menjeda atau menghapus tag akan menghapus kode dari penampung; pemblokiran tidak akan menghapusnya.

Jika tag yang tidak digunakan dihapus, pemicu dan variabel juga harus ditinjau untuk melihat apakah ada yang dapat dihapus jika hanya digunakan oleh tag tersebut.

Menggunakan daftar izin dan tolak

Daftar izin dan tolak memungkinkan Anda mengonfigurasi pembatasan yang sangat terperinci pada tag, pemicu, dan variabel yang diizinkan di halaman. Tindakan ini dapat digunakan untuk membantu menerapkan praktik terbaik performa dan kebijakan lainnya.

Daftar yang diizinkan dan ditolak dikonfigurasi melalui lapisan data.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

Misalnya, Anda dapat tidak mengizinkan tag HTML Kustom, variabel JavaScript, atau akses DOM langsung. Artinya, hanya piksel dan tag standar yang dapat digunakan, dengan data dari lapisan data. Meskipun tentu saja terbatas, cara ini dapat menghasilkan penerapan tag manager yang jauh lebih berperforma dan aman.

Pertimbangkan untuk menggunakan pemberian tag sisi server

Beralih ke pemberian tag sisi server bukanlah tugas yang mudah, tetapi perlu dipertimbangkan, terutama untuk situs yang lebih besar yang menginginkan kontrol lebih besar atas datanya. Pemberian tag sisi server menghapus kode vendor dari klien, dan dengannya, mengalihkan pemrosesan dari klien ke server.

Misalnya, saat menggunakan pemberian tag sisi klien, pengiriman data ke beberapa akun analisis berarti klien memulai permintaan terpisah untuk setiap endpoint. Sebaliknya, dengan pemberian tag sisi server, satu permintaan dibuat oleh klien ke penampung sisi server, dan dari sana, data ini diteruskan ke akun analisis yang berbeda.

Perlu diingat bahwa pemberian tag sisi server hanya berfungsi dengan beberapa tag; kompatibilitas tag bervariasi bergantung pada vendor.

Untuk informasi selengkapnya, lihat Pengantar pemberian tag sisi server.

Container

Tag manager biasanya mengizinkan beberapa instance atau "penampung" dalam penyiapannya. Dengan demikian, beberapa penampung dapat dikontrol dalam satu akun tag manager.

Hanya gunakan satu penampung per halaman

Menggunakan beberapa containers di satu halaman dapat menimbulkan masalah performa yang signifikan karena menimbulkan overhead tambahan dan eksekusi skrip. Setidaknya, penampung ini menduplikasi kode tag inti itu sendiri, yang, karena dikirim sebagai bagian dari JavaScript penampung, tidak dapat digunakan kembali di antara penampung.

Beberapa container jarang digunakan secara efektif. Namun, ada kemungkinan contoh saat hal ini dapat berfungsi—jika dikontrol dengan baik—termasuk:

• Memiliki container "pemuatan awal" yang lebih ringan dan container "pemuatan lebih lambat" yang lebih berat, daripada satu container besar.
• Memiliki penampung yang dibatasi yang digunakan oleh pengguna yang tidak terlalu teknis, dengan penampung yang tidak dibatasi, tetapi lebih terkontrol, untuk tag yang tidak dapat digunakan di penampung yang dibatasi.

Jika Anda harus menggunakan beberapa penampung per halaman, ikuti panduan Google Tag Manager untuk menyiapkan beberapa penampung.

Gunakan container terpisah jika diperlukan

Jika Anda menggunakan tag manager untuk beberapa properti (misalnya, aplikasi web dan aplikasi seluler), jumlah penampung yang Anda gunakan dapat membantu atau mengganggu produktivitas alur kerja Anda. Hal ini juga dapat memengaruhi performa.

Secara umum, satu penampung dapat secara efektif digunakan di beberapa situs jika situs tersebut memiliki penggunaan dan struktur yang serupa. Misalnya, meskipun aplikasi seluler dan web merek mungkin menyajikan fungsi yang serupa, kemungkinan aplikasi akan disusun secara berbeda, sehingga dikelola lebih efektif melalui penampung terpisah.

Mencoba menggunakan kembali satu penampung terlalu luas biasanya akan meningkatkan kompleksitas dan ukuran penampung dengan memaksakan penerapan logika yang kompleks untuk mengelola tag dan pemicu.

Memantau ukuran container

Ukuran penampung ditentukan oleh tag, pemicu, dan variabelnya. Meskipun penampung kecil mungkin masih berdampak negatif terhadap performa halaman, penampung besar kemungkinan besar akan berdampak negatif.

Ukuran penampung tidak boleh menjadi metrik bintang utara saat mengoptimalkan penggunaan tag. Namun, ukuran penampung yang besar sering kali menjadi tanda peringatan bahwa penampung tidak dipelihara dengan baik dan mungkin disalahgunakan.

Google Tag Manager membatasi ukuran penampung hingga 200 KB dan akan memperingatkan tentang ukuran penampung mulai dari 140 KB. Namun, sebagian besar situs harus memastikan penampungnya jauh lebih kecil dari ini. Secara perspektif, penampung situs median berukuran sekitar 50 KB.

Untuk menentukan ukuran penampung, lihat ukuran respons yang ditampilkan oleh https://www.googletagmanager.com/gtag/js?id=YOUR_ID. Respons ini berisi library Google Tag Manager dan konten penampung. Dengan sendirinya, library Google Tag Manager berukuran sekitar 33 KB yang dikompresi.

Beri nama versi penampung Anda

Versi penampung adalah snapshot konten penampung pada titik waktu tertentu. Menggunakan nama yang bermakna dan menyertakan deskripsi singkat tentang perubahan yang berarti di dalamnya dapat sangat membantu untuk memudahkan debug masalah performa di masa mendatang.

Alur kerja pemberian tag

Anda harus mengelola perubahan pada tag untuk memastikan tag tersebut tidak berdampak negatif terhadap performa halaman.

Menguji tag sebelum men-deploy

Menguji tag Anda sebelum deployment dapat membantu mendeteksi masalah (performa dan lainnya) sebelum dikirimkan.

Hal-hal yang perlu dipertimbangkan saat menguji tag meliputi:

• Apakah tag berfungsi dengan benar?
• Apakah tag menyebabkan pergeseran tata letak?
• Apakah tag memuat resource? Seberapa besarkah sumber daya ini?
• Apakah tag memicu skrip yang berjalan lama?

Mode pratinjau

Mode pratinjau memungkinkan Anda menguji perubahan tag di situs yang sebenarnya tanpa harus men-deploy perubahan tersebut ke publik terlebih dahulu. Mode pratinjau menyertakan konsol proses debug yang memberikan informasi tentang tag.

Waktu eksekusi Google Tag Manager akan berbeda (sedikit lebih lambat) saat dijalankan dalam mode Pratinjau karena overhead tambahan yang diperlukan untuk menampilkan informasi di konsol proses debug. Oleh karena itu, membandingkan pengukuran Data Web yang dikumpulkan dalam mode pratinjau dengan yang dikumpulkan dalam produksi tidak direkomendasikan. Namun, perbedaan ini seharusnya tidak memengaruhi perilaku eksekusi tag itu sendiri.

Pengujian mandiri

Pendekatan alternatif untuk menguji tag adalah dengan menyiapkan halaman kosong yang berisi penampung dengan satu tag—tag yang Anda uji. Penyiapan pengujian ini kurang realistis dan tidak akan mendeteksi beberapa masalah (misalnya, apakah tag menyebabkan pergeseran tata letak)—tetapi hal tersebut dapat mempermudah isolasi dan pengukuran dampak tag tersebut pada hal-hal seperti eksekusi skrip. Lihat cara Telegraph menggunakan pendekatan isolasi ini untuk meningkatkan performa kode pihak ketiga.

Memantau performa tag

Monitoring API Google Tag Manager dapat digunakan untuk mengumpulkan informasi tentang waktu eksekusi tag tertentu. Informasi ini dilaporkan ke endpoint yang Anda pilih.

Untuk informasi selengkapnya, lihat Cara membuat Monitor Google Tag Manager.

Wajibkan persetujuan untuk perubahan penampung

Kode pihak pertama biasanya menjalani peninjauan dan pengujian sebelum deployment - perlakukan tag Anda dengan cara yang sama. Menambahkan verifikasi dua langkah, yang memerlukan persetujuan administrator untuk perubahan penampung, adalah salah satu cara untuk melakukannya. Atau, jika tidak ingin mewajibkan verifikasi dua langkah, tetapi masih ingin memantau perubahan, Anda dapat menyiapkan notifikasi penampung untuk menerima peringatan email tentang peristiwa penampung yang Anda pilih.

Audit penggunaan tag secara berkala

Salah satu tantangan dalam menggunakan tag adalah tag tersebut cenderung terakumulasi seiring waktu: tag ditambahkan, tetapi jarang dihapus. Mengaudit tag secara berkala adalah salah satu cara untuk membalikkan tren ini. Frekuensi yang ideal untuk melakukannya akan bergantung pada seberapa sering tag situs Anda diperbarui.

Memberi label pada setiap tag agar pemiliknya jelas memudahkan identifikasi siapa yang responsif untuk tag tersebut dan dapat mengetahui apakah tag tersebut masih diperlukan atau tidak.

Saat mengaudit tag, jangan lupa untuk membersihkan pemicu dan variabel. Masalah performa juga dapat disebabkan oleh masalah performa.

Untuk mengetahui informasi selengkapnya, lihat Menjaga skrip pihak ketiga tetap terkendali.