Praktik terbaik untuk tag dan tag manager

Katie Hempenius

Barry Pollard

Dipublikasikan: 29 Juli 2021

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

Catatan: Meskipun tag dan skrip pihak ketiga sering kali pada dasarnya sama, terminologi yang terpisah mencerminkan berbagai cara penggunaan skrip ini. Tag biasanya dimiliki oleh departemen pemasaran dan ditambahkan dengan pengelola tag; sedangkan skrip pihak ketiga biasanya merujuk ke resource yang ditambahkan melalui perubahan kode yang dibuat oleh departemen engineering.

Dampak performa tag dan pengelola tag sangat bervariasi di berbagai situs. Pengelola tag dapat diibaratkan seperti amplop: pengelola tag menyediakan wadah, tetapi apa yang Anda isi dan cara menggunakannya sebagian besar terserah Anda.

Di sini, kami membahas teknik untuk mengoptimalkan tag dan pengelola tag untuk performa dan Core Web Vitals. Meskipun dokumen ini merujuk ke Google Tag Manager, banyak ide yang dibahas berlaku untuk pengelola tag lainnya.

Dampak pada Core Web Vitals

Pengelola Tag sering kali dapat memengaruhi Core Web Vitals Anda secara tidak langsung dengan menghabiskan resource yang diperlukan untuk memuat halaman dengan cepat dan membuatnya tetap responsif. Bandwidth dapat digunakan untuk mendownload JavaScript pengelola tag untuk situs Anda, atau panggilan berikutnya yang dilakukan. Waktu CPU di thread utama dapat dihabiskan untuk mengevaluasi dan mengeksekusi JavaScript yang terdapat dalam pengelola tag 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.

Cumulative Layout Shift (CLS) dapat terpengaruh, baik dengan menunda pemuatan resource penting sebelum render pertama, atau dengan pengelola tag yang memasukkan konten ke halaman.

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

Memilih jenis tag yang tepat

Dampak tag terhadap 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.

Perlu diingat bahwa cara Anda menggunakan tag sangat memengaruhi dampak performanya. "Piksel" memiliki performa yang sangat tinggi, terutama karena sifat jenis tag ini memberlakukan batasan ketat terkait cara penggunaannya; tag HTML kustom tidak selalu berdampak buruk bagi performa, tetapi karena tingkat kebebasan yang ditawarkan kepada pengguna, tag ini dapat dengan mudah disalahgunakan sehingga berdampak buruk bagi performa.

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

Tidak semua skrip harus dimuat dengan pengelola tag

Pengelola tag biasanya bukan cara terbaik untuk memuat resource yang menerapkan aspek visual atau fungsional langsung dari pengalaman pengguna, seperti notifikasi cookie, banner besar, atau fitur situs. Menggunakan Tag Manager untuk memuat resource ini biasanya akan menunda pengirimannya. Hal ini berdampak buruk bagi pengalaman pengguna dan juga dapat meningkatkan metrik, seperti LCP dan CLS.

Selain itu, beberapa pengguna memblokir pengelola tag. Menggunakan pengelola tag untuk menerapkan fitur UX dapat menyebabkan situs rusak bagi sebagian pengguna Anda.

Catatan: Resource yang diminta dengan pengelola tag biasanya dimuat lebih lambat daripada resource yang diminta secara langsung. Jika pengelola tag terutama digunakan untuk mengirimkan resource yang tidak penting, penundaan ini dapat digunakan secara konstruktif dengan menyediakan mekanisme untuk menunda permintaan yang tidak penting.

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 memasukkan kode Anda sendiri dengan sedikit batasan karena, terlepas dari namanya, penggunaan utama tag ini adalah untuk menambahkan elemen <script> kustom ke halaman.

Tag HTML kustom dapat digunakan dalam berbagai cara dan dampak performanya sangat bervariasi. Saat mengukur performa situs, perhatikan bahwa sebagian besar alat mengatribusikan dampak performa tag HTML Kustom ke pengelola tag yang memasukkannya, bukan ke tag itu sendiri.

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

• Dalam sebagian besar situasi, jika elemen disisipkan ke dalam halaman, browser harus menghitung ulang ukuran dan posisi setiap item di halaman. Proses ini disebut tata letak. Dampak performa dari satu tata letak sangat kecil, tetapi jika terjadi secara berlebihan, hal ini dapat menjadi sumber masalah performa. Dampak 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 di sekitarnya dirender, hal ini dapat menyebabkan pergeseran tata letak. Fenomena ini tidak hanya terjadi pada pengelola tag—namun, karena tag biasanya dimuat lebih lambat daripada bagian halaman lainnya, tag biasanya disisipkan ke dalam DOM setelah halaman di sekitarnya dirender.

Tips: Jika Anda menambahkan atau mengubah konten yang terlihat di halaman, perlu diingat bahwa mesin telusur harus dapat mengambil dan memproses JavaScript yang digunakan. Untuk Google, Anda dapat memverifikasi rendering halaman untuk Penelusuran. Mesin telusur lain mungkin memiliki alat pengujian serupa.

Menggunakan template kustom

Template kustom mendukung beberapa operasi yang sama seperti tag HTML Kustom, tetapi dibuat berdasarkan JavaScript dengan sandbox yang menyediakan API untuk kasus penggunaan umum seperti injeksi skrip dan injeksi piksel. Seperti namanya, template ini memungkinkan pembuatan template oleh pengguna super yang dapat membuatnya dengan mempertimbangkan performa. Pengguna yang kurang memahami teknis kemudian dapat menggunakan template tersebut. Hal ini sering kali lebih aman daripada memberikan akses HTML Kustom penuh.

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

Memasukkan skrip dengan benar

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

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

Jika Anda harus menggunakan tag HTML Kustom, ingat:

• Library dan skrip pihak ketiga yang besar harus dimuat dengan tag skrip (misalnya, <script src="external-scripts.js">) yang mendownload file eksternal, bukan langsung menyalin dan menempelkan konten skrip ke dalam tag. Meskipun tidak menggunakan tag <script> menghilangkan perjalanan bolak-balik terpisah untuk mendownload konten skrip, praktik ini meningkatkan ukuran penampung dan mencegah skrip di-cache secara terpisah oleh browser.
• Banyak vendor merekomendasikan untuk menempatkan tag <script> mereka di bagian atas <head>. Namun, untuk skrip yang dimuat dengan pengelola tag, hal ini sering kali tidak diperlukan. Dalam sebagian besar situasi, browser telah selesai mengurai <head> pada saat pengelola tag dijalankan.

Menggunakan piksel

Terkadang, skrip pihak ketiga dapat diganti dengan piksel gambar atau iframe. Dibandingkan dengan tag berbasis skrip, piksel mungkin mendukung lebih sedikit fungsi, sehingga sering dianggap sebagai penerapan yang kurang disukai. Namun, jika digunakan di dalam pengelola tag, piksel dapat menjadi lebih dinamis karena dapat diaktifkan pada pemicu dan meneruskan berbagai variabel.

Piksel 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 Anda untuk mengetahui informasi selengkapnya tentang dukungan mereka untuk piksel. Selain itu, Anda dapat mencoba memeriksa kode mereka untuk menemukan tag <noscript>. Jika vendor mendukung piksel, mereka sering menyertakan piksel dalam tag <noscript>.

Alternatif untuk piksel

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

Catatan: API sendBeacon() dan fetch() keepalive masih berfungsi saat browser menghapus muatan halaman. Misalnya, kedua API ini dapat digunakan untuk melacak klik link keluar. Sebaliknya, teknik seperti piksel dan XMLHttpRequest kemungkinan akan gagal dalam kasus tersebut.

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

sendBeacon()

API navigator.sendBeacon() dirancang untuk mengirimkan sejumlah kecil data 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 penetapan header kustom. Fitur ini didukung oleh semua browser modern.

Fetch API keepalive

keepalive adalah flag yang memungkinkan Fetch API digunakan untuk membuat permintaan non-pemblokiran seperti pelaporan peristiwa dan analisis. Fungsi 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 memang mirip. 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. API fetch() jauh lebih fleksibel; namun, keepalive memiliki dukungan browser yang lebih sedikit daripada sendBeacon().

Memahami fungsi tag

Tag sering kali dibuat dengan mengikuti panduan yang diberikan oleh vendor pihak ketiga. Jika tidak jelas apa yang dilakukan kode vendor, pertimbangkan untuk bertanya kepada seseorang yang mengetahuinya. Mendapatkan pendapat kedua dapat membantu mengidentifikasi apakah tag berpotensi menimbulkan masalah performa atau keamanan.

Sebaiknya beri label pada tag dengan pemilik di pengelola tag. Sangat mudah untuk melupakan siapa yang memiliki tag, sehingga menimbulkan kekhawatiran akan penghapusan jika tag tersebut merusak sesuatu.

Pemicu

Secara umum, pengoptimalan pemicu tag biasanya terdiri dari memastikan untuk tidak memicu tag lebih dari yang diperlukan dan memilih pemicu yang menyeimbangkan kebutuhan bisnis dengan biaya performa.

Pemicu adalah kode JavaScript yang meningkatkan ukuran dan biaya eksekusi Tag Manager. Meskipun sebagian besar pemicu berukuran kecil, efek kumulatifnya dapat bertambah. Misalnya, memiliki beberapa peristiwa klik atau pemicu timer dapat meningkatkan beban kerja pengelola tag secara signifikan.

Memilih peristiwa pemicu yang sesuai

Dampak performa tag dapat bervariasi. Secara umum, makin awal tag diaktifkan, makin besar dampaknya terhadap performa. Resource biasanya dibatasi selama pemuatan halaman awal, sehingga pemuatan atau eksekusi resource (atau tag) tertentu akan mengalihkan resource dari hal lain.

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

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

Menggunakan peristiwa kustom

Gunakan peristiwa kustom untuk mengaktifkan pemicu sebagai respons terhadap peristiwa halaman yang tidak tercakup oleh pemicu bawaan Google Tag Manager. Misalnya, banyak tag menggunakan pemicu kunjungan halaman. Namun, waktu antara DOM Ready dan Window Loaded bisa lama, sehingga sulit untuk menyesuaikan waktu pengaktifan tag. Peristiwa kustom dapat menjadi solusi untuk masalah ini.

Pertama, buat pemicu peristiwa kustom dan perbarui tag Anda untuk 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

Tentukan kondisi pemicu tertentu untuk menghindari pengaktifan tag saat tidak diperlukan. Salah satu cara paling sederhana dan efektif untuk melakukannya adalah dengan memastikan bahwa tag hanya diaktifkan di halaman tempat tag tersebut benar-benar digunakan.

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

Perhatian: Kondisi pemicu atau pengecualian yang kompleks juga dapat memerlukan waktu pemrosesan. Hindari terlalu banyak kondisi dan kondisi yang kompleks.

Memuat pengelola tag pada waktu yang tepat

Anda dapat meningkatkan performa dengan menyesuaikan waktu pemuatan pengelola tag itu sendiri. Pemicu, terlepas dari cara konfigurasinya, tidak dapat diaktifkan hingga setelah pengelola tag dimuat. Bereksperimenlah dengan waktu pemuatan pengelola tag, karena hal ini dapat memberikan dampak yang sama atau lebih besar. Keputusan ini memengaruhi semua tag di halaman.

Dengan memuat pengelola tag nanti, Anda dapat menghindari masalah performa di masa mendatang, karena hal ini mencegah pemuatan tag yang terlalu dini secara tidak sengaja.

Variabel

Menggunakan variabel untuk membaca data dari halaman. Variabel berguna dalam pemicu dan dalam tag itu sendiri.

Seperti pemicu, variabel menambahkan kode JavaScript ke pengelola tag, sehingga dapat menyebabkan masalah performa. Variabel dapat berukuran relatif kecil, seperti kode untuk membaca bagian URL, cookie, lapisan data, atau DOM. Tag ini juga dapat menyertakan JavaScript kustom yang memiliki kemampuan (dan ukuran) tak terbatas.

Gunakan variabel seminimal mungkin, karena variabel terus dievaluasi oleh pengelola tag. Hapus variabel lama yang tidak lagi digunakan untuk mengurangi ukuran skrip tag manager dan waktu pemrosesan yang digunakan.

Pengelolaan tag

Penggunaan tag secara efisien akan mengurangi risiko masalah performa.

Menggunakan lapisan data

Lapisan data adalah array objek JavaScript yang berisi informasi tentang halaman. Objek ini berisi semua informasi yang ingin Anda teruskan ke Google Tag Manager.

Lapisan data 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, sebaiknya gunakan lapisan data. Lapisan data menggabungkan data yang dapat diakses oleh skrip pihak ketiga ke dalam satu tempat, sehingga memberikan visibilitas yang lebih baik terkait penggunaannya. Di antaranya, hal ini dapat membantu mengurangi penghitungan variabel dan eksekusi skrip yang redundan.

Dengan menggunakan lapisan data, Anda dapat mengontrol data yang diakses oleh tag, bukan memberikan akses variabel JavaScript atau DOM penuh.

Manfaat performa lapisan data mungkin tidak intuitif, mengingat bahwa memperbarui lapisan data menyebabkan Google Tag Manager mengevaluasi ulang semua variabel penampung dan berpotensi memicu tag, yang memerlukan eksekusi JavaScript. Meskipun lapisan data dapat disalahgunakan, secara umum, jika lapisan data tampaknya menjadi sumber masalah performa, penampung itu sendiri kemungkinan memiliki masalah performa. Lapisan data membuat masalah ini lebih terlihat.

Menghapus tag duplikat dan tidak digunakan

Tag duplikat dapat terjadi jika tag disertakan dalam markup HTML halaman selain dimasukkan melalui pengelola tag.

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.

Setelah tag yang tidak digunakan dihapus, tinjau pemicu dan variabel untuk menentukan apakah pemicu dan variabel tersebut juga dapat dihapus.

Tag yang dijeda memengaruhi ukuran penampung, tetapi total payload-nya lebih kecil daripada saat tag aktif.

Menggunakan daftar izinkan dan tolak

Gunakan daftar izinkan dan tolak untuk mengonfigurasi batasan yang sangat terperinci pada tag, pemicu, dan variabel yang diizinkan di halaman. Hal 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 mencegah penggunaan tag HTML kustom, variabel JavaScript, atau akses DOM langsung. Artinya, hanya piksel dan tag yang telah ditentukan yang dapat digunakan, dengan data dari lapisan data. Meskipun bersifat membatasi, hal ini dapat menghasilkan penerapan pengelola tag yang lebih berperforma tinggi dan aman.

Pertimbangkan untuk menggunakan pemberian tag sisi server

Sebaiknya pertimbangkan untuk beralih ke pemberian tag sisi server, terutama untuk situs yang lebih besar yang menginginkan kontrol lebih besar atas datanya. Pemberian tag sisi server menghapus kode vendor dari klien, dan dengan demikian, mengalihkan pemrosesan dari klien ke server.

Misalnya, saat menggunakan pemberian tag sisi klien, pengiriman data ke beberapa akun analisis mengharuskan klien memulai permintaan terpisah untuk setiap endpoint. Dengan pemberian tag sisi server, satu permintaan dibuat oleh klien ke penampung sisi server, dan dari sana, data ini diteruskan ke berbagai akun analisis.

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

Pengelola tag biasanya mengizinkan beberapa instance, yang sering disebut sebagai penampung, dalam penyiapannya. Beberapa penampung dapat dikontrol dalam satu akun Tag Manager.

Hanya gunakan satu penampung per halaman

Beberapa penampung di satu halaman dapat menyebabkan masalah performa yang signifikan, karena menimbulkan overhead dan eksekusi skrip tambahan. Setidaknya, tindakan ini akan menduplikasi kode tag inti itu sendiri yang, karena dikirimkan sebagai bagian dari JavaScript penampung, tidak dapat digunakan kembali di antara penampung.

Jarang ada beberapa penampung yang digunakan secara efektif. Namun, ada situasi ketika hal ini dapat berhasil, jika dikontrol dengan baik. Contoh:

• Termasuk penampung "pemuatan awal" yang lebih ringan dan penampung "pemuatan nanti" yang lebih berat, bukan satu penampung besar.
• Menggunakan penampung yang dibatasi untuk pengguna yang kurang teknis dan penampung yang kurang dibatasi, tetapi dikontrol lebih ketat, untuk tag yang lebih kompleks.

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

Menggunakan container terpisah jika diperlukan

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

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

Menggunakan kembali satu penampung secara terlalu luas dapat meningkatkan kompleksitas dan ukuran penampung dengan memaksa logika yang kompleks untuk mengelola tag dan pemicu.

Perhatikan ukuran penampung

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

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

Google Tag Manager membatasi ukuran penampung hingga 300 KB dan memperingatkan tentang ukuran penampung setelah mencapai 70% dari batas ukuran.

Sebagian besar situs harus berupaya menjaga ukuran penampungnya lebih kecil dari batasan. Sebagai perbandingan, penampung situs median berukuran sekitar 50 KB. Library Google Tag Manager sendiri berukuran sekitar 33 KB setelah dikompresi.

Memberi 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 bermakna di dalamnya dapat sangat membantu dalam mempermudah proses debug masalah performa di masa mendatang.

Memberi tag pada alur kerja

Penting untuk mengelola perubahan pada tag Anda agar tidak berdampak negatif pada performa halaman.

Melakukan pengujian sebelum men-deploy

Uji tag Anda sebelum deployment untuk mendeteksi masalah, performa, dan hal lainnya, sebelum tag dikirim.

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 besar resource 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-nya ke publik terlebih dahulu. Mode pratinjau menyertakan konsol debug yang memberikan informasi tentang tag.

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

Pengujian mandiri

Pendekatan alternatif untuk menguji tag adalah 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 dapat mempermudah mengisolasi dan mengukur dampak tag 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 mengetahui informasi selengkapnya, lihat Cara membuat Monitor Google Tag Manager.

Memerlukan persetujuan untuk perubahan penampung

Kode pihak pertama biasanya melalui 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 Anda tidak ingin mewajibkan verifikasi dua langkah, tetapi tetap ingin memantau perubahan, Anda dapat menyiapkan notifikasi penampung untuk menerima pemberitahuan email tentang peristiwa penampung pilihan Anda.

Mengaudit penggunaan tag secara berkala

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

Memberi label pada setiap tag sehingga pemiliknya terlihat jelas akan memudahkan identifikasi siapa yang bertanggung jawab atas tag tersebut dan dapat menyatakan apakah tag tersebut masih diperlukan.

Saat mengaudit tag, jangan lupa untuk membersihkan pemicu dan variabel. Hal ini juga sering kali dapat menjadi penyebab masalah performa.

Untuk mengetahui informasi selengkapnya, lihat Mengontrol skrip pihak ketiga.