Optimize tags and tag managers for Core Web Vitals.
Tags are snippets of third-party code that are inserted into a site, typically via a tag manager. Tags are most commonly used for marketing and analytics.
The performance impact of tags and tag managers varies wildly from site to site. مدیران برچسب را می توان با یک پاکت مقایسه کرد: مدیر برچسب یک ظرف را فراهم می کند - اما اینکه با چه چیزی آن را پر می کنید و چگونه از آن استفاده می کنید بیشتر به شما بستگی دارد.
This article discusses techniques for optimizing tags and tag managers for performance and Web Vitals. Although this article references Google Tag Manager, many of the ideas discussed are also applicable to other tag managers.
Impact on Core Web Vitals
Tag Managers can often impact your Core Web Vitals indirectly by using up resources needed to load your page quickly and keep it responsive. Bandwidth can be spent downloading the tag manager JavaScript for your sites, or the subsequent calls this makes. CPU time on the main thread can be spent evaluating and executing JavaScript contained within the tag manager and the tags.
Largest Contentful Paint (LCP) is vulnerable to bandwidth contention during the critical page load time. Additionally, blocking the main thread can delay the LCP render time .
تغییر چیدمان تجمعی (CLS) می تواند تحت تأثیر قرار گیرد، یا با به تاخیر انداختن بارگیری منابع مهم قبل از اولین رندر، یا با تزریق محتوا توسط مدیران برچسب به صفحه.
First Input Delay (FID) is susceptible to CPU contention on the main thread. این همچنین میتواند بر متریک جدیدتر Interaction to Next Paint (INP) تأثیر بگذارد و ما همبستگی بین اندازه مدیران برچسب و امتیازات INP ضعیفتر را مشاهده کردهایم.
Tag types
The impact of tags on performance varies by tag type. Generally speaking, image tags ("pixels") are the most performant, followed by custom templates, and lastly, custom HTML tags. Vendor tags vary depending on the functionality they allow.
However, keep in mind that how you use a tag greatly influences its performance impact. "Pixels" are highly performant largely because the nature of this tag type imposes tight restrictions on how they can be used; تگهای HTML سفارشی لزوماً همیشه برای عملکرد بد نیستند، اما به دلیل سطح آزادی که به کاربران ارائه میدهند، میتوان به راحتی از آنها به نحوی سوء استفاده کرد که برای عملکرد بد است.
هنگامی که به برچسب ها فکر می کنید، مقیاس را در نظر داشته باشید: تأثیر عملکرد هر تگ ممکن است ناچیز باشد - اما زمانی که ده ها یا صدها برچسب در همان صفحه استفاده می شود می تواند قابل توجه باشد.
Not all scripts should be loaded using a tag manager
مدیران برچسب معمولاً مکانیسم خوبی برای بارگیری منابعی نیستند که جنبههای بصری یا عملکردی تجربه کاربر را پیادهسازی میکنند - به عنوان مثال، اطلاعیههای کوکی، تصاویر قهرمان یا ویژگیهای سایت. Using a tag manager to load these resources typically delays their delivery. این برای تجربه کاربر بد است و همچنین می تواند معیارهایی مانند LCP و CLS را افزایش دهد. علاوه بر این، به خاطر داشته باشید که برخی از کاربران تگ منیجرها را مسدود می کنند. استفاده از تگ منیجر برای پیاده سازی ویژگی های UX ممکن است منجر به خرابی وب سایت برای برخی از کاربران شما شود.
مراقب تگ های HTML سفارشی باشید
تگهای HTML سفارشی سالهاست که وجود دارند و در اکثر سایتها بهشدت استفاده میشوند. تگهای HTML سفارشی به شما امکان میدهند کد خود را با محدودیتهای کمی وارد کنید، زیرا علیرغم نام، کاربرد اصلی این تگ افزودن عناصر سفارشی <script>
به یک صفحه است.
تگ های HTML سفارشی را می توان به طرق مختلف مورد استفاده قرار داد و تأثیر عملکرد آنها به طور قابل توجهی متفاوت است. هنگام اندازهگیری عملکرد سایت خود، توجه داشته باشید که بیشتر ابزارها تأثیر عملکرد یک تگ HTML سفارشی را به مدیر تگ تزریقکننده آن نسبت میدهند، نه خود تگ.
تگ های سفارشی HTML می توانند یک عنصر را در صفحه اطراف وارد کنند. عمل درج عناصر در صفحه میتواند منشأ مشکلات عملکردی باشد و در برخی موارد باعث تغییر طرحبندی شود.
- در بیشتر مواقع، اگر عنصری در صفحه درج شود، مرورگر باید اندازه و موقعیت هر آیتم را در صفحه دوباره محاسبه کند - این فرآیند به عنوان layout شناخته میشود. تاثیر عملکرد یک چیدمان منفرد حداقل است، اما زمانی که بیش از حد اتفاق می افتد می تواند به منبع مشکلات عملکرد تبدیل شود. تأثیر این پدیده روی دستگاههای پایینتر و صفحات با تعداد عناصر DOM زیاد است.
- اگر یک عنصر صفحه قابل مشاهده پس از رندر شدن منطقه اطراف در DOM وارد شود، می تواند باعث تغییر طرح شود. این پدیده منحصر به مدیران برچسب نیست - با این حال، از آنجا که برچسب ها معمولا دیرتر از سایر قسمت های صفحه بارگیری می شوند، معمولاً پس از ارائه صفحه اطراف در DOM درج می شوند.
استفاده از قالب های سفارشی را در نظر بگیرید
الگوهای سفارشی برخی از عملیات مشابه تگهای HTML سفارشی را پشتیبانی میکنند، اما بر اساس یک نسخه جعبهشنودی جاوا اسکریپت ساخته شدهاند که APIهایی را برای موارد استفاده رایج مانند تزریق اسکریپت و تزریق پیکسل ارائه میکند. همانطور که از نام آن پیداست، آنها اجازه میدهند یک الگو توسط یک کاربر قدرتمند ایجاد شود که میتواند با در نظر گرفتن عملکرد آن را بسازد. سپس کاربران فنی کمتری می توانند از این الگو استفاده کنند. این اغلب ایمن تر از ارائه دسترسی کامل به HTML سفارشی است.
با توجه به محدودیتهای بیشتر اعمال شده بر روی قالبهای سفارشی، این برچسبها بسیار کمتر احتمال دارد که عملکرد یا مسائل امنیتی را نشان دهند. با این حال، به همین دلایل، قالب های سفارشی برای همه موارد استفاده کار نمی کنند.
اسکریپت ها را به درستی تزریق کنید
استفاده از تگ منیجر برای تزریق یک اسکریپت یک مورد استفاده بسیار رایج است. روش پیشنهادی برای انجام این کار استفاده از یک قالب سفارشی و injectScript
API است.
برای اطلاعات در مورد استفاده از injectScript API برای تبدیل یک تگ HTML سفارشی موجود، به تبدیل یک تگ موجود مراجعه کنید.
اگر باید از یک تگ HTML سفارشی استفاده کنید، در اینجا مواردی وجود دارد که باید در نظر داشته باشید:
- کتابخانهها و اسکریپتهای شخص ثالث بزرگ باید از طریق یک تگ اسکریپت بارگیری شوند که یک فایل خارجی را دانلود میکند (برای مثال
<script src="external-scripts.js">
)، به جای کپی کردن مستقیم محتوای اسکریپت در برچسب. اگرچه استفاده نکردن از تگ<script>
یک سفر رفت و برگشت جداگانه برای دانلود محتویات اسکریپت را حذف می کند، این عمل باعث افزایش اندازه ظرف می شود و از ذخیره اسکریپت به طور جداگانه توسط مرورگر جلوگیری می کند. - بسیاری از فروشندگان توصیه می کنند تگ
<script>
خود را در بالای<head>
قرار دهند. با این حال، برای اسکریپتهایی که از طریق مدیر برچسب بارگذاری میشوند، این توصیه معمولاً غیر ضروری است: در بیشتر موقعیتها، مرورگر قبلاً تجزیه<head>
را تا زمانی که مدیر برچسب اجرا میکند به پایان رسانده است.
از پیکسل استفاده کنید
در برخی شرایط، اسکریپت های شخص ثالث را می توان با پیکسل های تصویر یا آی فریم جایگزین کرد. در مقایسه با نمونههای مبتنی بر اسکریپت، پیکسلها ممکن است از عملکرد کمتری پشتیبانی کنند، بنابراین اغلب بهعنوان یک پیادهسازی کمتر ترجیح داده میشوند. با این حال، هنگامی که در داخل تگ منیجرها استفاده میشود، پیکسلها میتوانند پویاتر باشند، زیرا میتوانند روی تریگرها فعال شوند و متغیرهای مختلف را ارسال کنند. آنها کارآمدترین و ایمنترین نوع تگ هستند زیرا پس از اجرا شدن جاوا اسکریپت اجرا نمیشود. پیکسل ها حجم منبع بسیار کمی دارند (کمتر از 1 کیلوبایت) و باعث تغییر چیدمان نمی شوند.
برای اطلاعات بیشتر در مورد پشتیبانی آنها از پیکسل، با ارائه دهنده شخص ثالث خود تماس بگیرید. علاوه بر این، میتوانید کد آنها را برای تگ <noscript>
بررسی کنید. اگر فروشنده ای از پیکسل ها پشتیبانی کند، اغلب آنها را در تگ <noscript>
قرار می دهد.
جایگزین های پیکسل
پیکسلها عمدتاً به این دلیل محبوب شدند که در یک زمان یکی از ارزانترین و مطمئنترین راهها برای درخواست HTTP در شرایطی بودند که پاسخ سرور مرتبط نیست (مثلاً هنگام ارسال دادهها به ارائهدهندگان تجزیه و تحلیل). APIهای navigator.sendBeacon()
و fetch() keepalive
برای رسیدگی به همین مورد استفاده طراحی شده اند، اما مسلماً قابل اعتمادتر از پیکسل ها هستند.
ادامه استفاده از پیکسل ها هیچ اشکالی ندارد - آنها به خوبی پشتیبانی می شوند و کمترین تأثیر را در عملکرد دارند. با این حال، اگر شما در حال ساخت بیکن های خود هستید، ارزش آن را دارد که از یکی از این API ها استفاده کنید.
sendBeacon()
navigator.sendBeacon()
API برای ارسال مقادیر کمی داده به سرورهای وب در شرایطی طراحی شده است که پاسخ سرور اهمیتی ندارد.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon()
یک API محدود دارد: فقط از ایجاد درخواست های POST پشتیبانی می کند و از تنظیم هدرهای سفارشی پشتیبانی نمی کند. توسط تمام مرورگرهای مدرن پشتیبانی می شود.
fetch() keepalive
keepalive
پرچمی است که به Fetch API اجازه میدهد برای درخواستهای غیرمسدود کننده مانند گزارش رویداد و تجزیه و تحلیل استفاده شود. با گنجاندن keepalive: true
در پارامترهای ارسال شده به fetch()
استفاده می شود.
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
اگر fetch() keepalive
و sendBeacon()
بسیار شبیه به هم به نظر می رسند، به این دلیل است که آنها هستند. در واقع، در مرورگرهای Chromium، sendBeacon()
اکنون بر اساس fetch() keepalive
ساخته شده است.
هنگام انتخاب بین fetch() keepalive
و sendBeacon()
، مهم است که ویژگی ها و پشتیبانی مرورگر مورد نیاز خود را در نظر بگیرید. fetch() API به طور قابل توجهی انعطاف پذیرتر است. با این حال، keepalive
از پشتیبانی مرورگر کمتری نسبت به sendBeacon()
برخوردار است.
شفاف سازی دریافت کنید
برچسب ها اغلب با پیروی از راهنمایی های ارائه شده توسط یک فروشنده شخص ثالث ایجاد می شوند. اگر مشخص نیست کد فروشنده چه کاری انجام می دهد - از کسی که می داند بپرسید. گرفتن نظر دوم می تواند به تشخیص اینکه آیا یک برچسب پتانسیل ایجاد مشکلات عملکرد یا امنیتی را دارد کمک کند.
برچسب زدن برچسب ها با مالک در مدیر برچسب نیز توصیه می شود. فراموش کردن مالک یک تگ بسیار آسان است و از حذف آن در هر صورت بترسید!
محرک ها
در سطح بالا، بهینهسازی محرکهای تگ معمولاً شامل اطمینان از عدم راهاندازی برچسبها بیش از حد لازم و انتخاب راهاندازی است که نیازهای تجاری را با هزینههای عملکرد متعادل میکند.
خود تریگرها کد جاوا اسکریپت هستند که اندازه و هزینه اجرای تگ منیجر را افزایش می دهند. در حالی که بیشتر محرک ها کوچک هستند، اثر تجمعی می تواند اضافه شود. برای مثال، داشتن رویدادهای کلیکی زیاد، یا راهاندازهای تایمر میتواند حجم کار مدیر تگ را بهطور چشمگیری افزایش دهد.
یک رویداد محرک مناسب را انتخاب کنید
تأثیر عملکرد یک برچسب ثابت نیست: به طور کلی، هر چه یک برچسب زودتر فعال شود، تأثیر آن بر عملکرد بیشتر است. منابع معمولاً در طول بارگذاری اولیه صفحه محدود می شوند و بنابراین بارگذاری یا اجرای یک منبع (یا برچسب) خاص منابع را از چیز دیگری دور می کند.
اگرچه انتخاب تریگرهای مناسب برای همه تگ ها مهم است، اما به ویژه برای برچسب هایی که منابع بزرگ را بارگیری می کنند یا اسکریپت های طولانی را اجرا می کنند، مهم است.
برچسبها میتوانند در نمایشهای صفحه (معمولاً Page load
، در DOM Ready
، در Window Loaded
)، یا بر اساس یک رویداد سفارشی فعال شوند. برای جلوگیری از تأثیرگذاری بر بارگذاری صفحه، توصیه میشود پس از Window Loaded
برچسبهای غیر ضروری را فعال کنید.
از رویدادهای سفارشی استفاده کنید
رویدادهای سفارشی به شما امکان میدهند در پاسخ به رویدادهای صفحهای که توسط محرکهای داخلی Google Tag Manager پوشش داده نمیشوند، راهاندازها را فعال کنید. برای مثال، بسیاری از تگ ها از محرک های مشاهده صفحه استفاده می کنند. با این حال، دوره زمانی بین DOM Ready
و Window Loaded
میتواند در بسیاری از صفحات طولانی باشد و این میتواند تنظیم دقیق زمانی که یک برچسب فعال میشود، دشوار کند. Custom events provide a solution to this problem.
To use custom events, first create a custom event trigger and update your tags to use this trigger.
To fire the trigger, push the corresponding event to the data layer.
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
Use specific trigger conditions
Using specific trigger conditions helps avoid firing a tag unnecessarily. اگرچه راههای زیادی برای اعمال این مفهوم وجود دارد، یکی از سادهترین و در عین حال مفیدترین کارهایی که میتوانید انجام دهید این است که اطمینان حاصل کنید که یک برچسب فقط در صفحاتی فعال میشود که واقعاً از آن استفاده میشود.
Built-in variables can also be incorporated into trigger conditions to limit tag firing.
However, be aware that having complex trigger conditions or exceptions takes processing time in and off itself, so do not make them too complex.
Load your tag manager at an appropriate time
Adjusting when you tag manager itself loads can have a significant impact on performance. Triggers, regardless of how they are configured, can't fire until after a tag manager loads. اگرچه انتخاب محرکهای خوب برای تگها مهم است (همانطور که در بالا توضیح داده شد)، آزمایش با زمانی که مدیر برچسب خود را بارگیری میکنید، اغلب میتواند تأثیری برابر یا بیشتر داشته باشد، زیرا این تصمیم واحد بر همه برچسبها در یک صفحه تأثیر میگذارد.
بارگیری تگ منیجر بعداً همچنین یک لایه کنترل اضافه میکند و میتواند از مشکلات عملکرد آینده جلوگیری کند، زیرا از بارگیری ناخواسته یک تگ توسط کاربر، بدون اینکه متوجه تأثیر آن باشد، جلوگیری میکند.
متغیرها
Variables allow data to be read from the page. They are useful in triggers, and in tags themselves.
Like triggers, variables result in JavaScript code being added to the tag manager, and so can cause performance issues. Variables can be relatively simple built-in types that can, for example, read parts of the URL, cookies, data layer, or DOM. Or they can be custom JavaScript that is basically unlimited in what it can do.
Keep variables simple and to a minimum, since they will need to be evaluated continually by the tag manager. Remove old variables that are no longer used to reduce both the size of the tag manager script, and the processing time it uses.
مدیریت برچسب
Using the tags efficiently will reduce the risk of performance issues.
از لایه داده استفاده کنید
The data layer "contains all of the information that you want to pass to Google Tag Manager". More concretely, it is a JavaScript array of objects that contain information about the page. It can also be used to trigger tags.
// 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'});
Although Google Tag Manager can be used without the data layer, its use is strongly recommended. لایه داده راهی برای ادغام دادههای قابل دسترسی توسط اسکریپتهای شخص ثالث در یک مکان واحد فراهم میکند و در نتیجه دید بهتری را در استفاده از آن فراهم میکند. Amongst other things, this can help reduce redundant variable calculations and script execution. Using a data layer also controls the data being accessed by the tags, rather than giving full JavaScript variable or DOM access.
Remove duplicate and unused tags
Duplicate tags can occur when a tag is included in a page's HTML markup in addition to being injected through a tag manager.
Unused tags should be paused or removed rather than blocked through use of a trigger exception . Pausing or removing a tag removes the code from the container; مسدود کردن نیست.
هنگامی که برچسبهای استفاده نشده حذف میشوند، محرکها و متغیرها نیز باید بررسی شوند تا ببینیم اگر فقط توسط آن برچسبها استفاده شده باشد، میتوان هر یک از آنها را حذف کرد.
از لیست های مجاز و رد استفاده کنید
Allow and deny lists allow you to configure highly granular restrictions on the tags, triggers, and variables allowed on a page. This can be used to help enforce performance best practices and other policies.
Allow and deny lists are configured through the data layer.
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
For example, it is possible to not allow any Custom HTML tags, JavaScript variables, or direct DOM access. This means only pixels and pre-defined tags can be used, with data from the data layer. While this is certainly restrictive, it can result in a much more performant, and secure, tag manager implementation.
Consider using server-side tagging
جابجایی به برچسبگذاری سمت سرور یک کار بیاهمیت نیست، اما ارزش آن را دارد که در نظر گرفته شود - بهویژه برای سایتهای بزرگتری که میخواهند کنترل بیشتری روی دادههای خود داشته باشند. برچسبگذاری سمت سرور، کد فروشنده را از مشتری حذف میکند و با آن، پردازش را از مشتری به سرور تخلیه میکند.
به عنوان مثال، هنگام استفاده از برچسب گذاری سمت مشتری، ارسال داده به چندین حساب تجزیه و تحلیل مستلزم آن است که مشتری درخواست های جداگانه ای را برای هر نقطه پایانی آغاز کند. در مقابل، با برچسبگذاری سمت سرور، یک درخواست واحد توسط مشتری به کانتینر سمت سرور ارسال میشود و از آنجا، این دادهها به حسابهای تحلیلی مختلف ارسال میشوند.
به خاطر داشته باشید که برچسب گذاری سمت سرور فقط با برخی از برچسب ها کار می کند. tag compatibility varies depending on vendor.
برای اطلاعات بیشتر، به مقدمه ای برای برچسب گذاری سمت سرور مراجعه کنید.
ظروف
مدیران برچسب معمولاً چندین نمونه یا "کانتینر" را در مجموعه خود اجازه می دهند. این اجازه می دهد تا چندین کانتینر در یک حساب مدیر برچسب کنترل شوند.
Use only one container per page
استفاده از چندین کانتینر در یک صفحه می تواند مشکلات عملکردی قابل توجهی ایجاد کند زیرا سربار اضافی و اجرای اسکریپت را معرفی می کند. حداقل خود کد تگ اصلی را کپی میکند که چون به عنوان بخشی از جاوا اسکریپت کانتینر تحویل داده میشود، نمیتوان آن را دوباره بین کانتینرها استفاده کرد.
به ندرت پیش می آید که چندین ظروف به طور موثر استفاده شوند. با این حال، ممکن است مواردی وجود داشته باشد که این می تواند کار کند - اگر به خوبی کنترل شود - از جمله:
- داشتن یک کانتینر سبکتر «بار اولیه» و یک ظرف «بار دیرتر» سنگینتر به جای یک ظرف بزرگ.
- داشتن یک کانتینر محدود که توسط کاربران فنی کمتر مورد استفاده قرار می گیرد، با یک کانتینر با محدودیت کمتر، اما با کنترل دقیق تر، برای برچسب هایی که نمی توانند در کانتینر محدود استفاده شوند.
اگر باید از چندین کانتینر در هر صفحه استفاده کنید، دستورالعملهای مدیر برچسب Google را برای راهاندازی چندین کانتینر دنبال کنید .
Use separate containers if needed
اگر از یک مدیر برچسب برای چندین ویژگی (به عنوان مثال، یک برنامه وب و یک برنامه تلفن همراه) استفاده می کنید، تعداد کانتینرهایی که استفاده می کنید می تواند به بهره وری گردش کار شما کمک کند یا به آن آسیب برساند. It can also impact performance.
به طور کلی، اگر سایتها از نظر کاربری و ساختار مشابه باشند، میتوان از یک کانتینر در چندین سایت استفاده کرد. برای مثال، اگرچه برنامههای موبایل و وب یک برند ممکن است عملکردهای مشابهی داشته باشند، احتمالاً برنامهها ساختار متفاوتی دارند و بنابراین به طور مؤثرتری از طریق کانتینرهای جداگانه مدیریت میشوند.
تلاش برای استفاده مجدد از یک کانتینر به طور گسترده معمولاً به طور غیرضروری پیچیدگی و اندازه کانتینر را با اجبار به پذیرش منطق پیچیده برای مدیریت برچسب ها و محرک ها افزایش می دهد.
Keep an eye on container size
اندازه کانتینر توسط برچسب ها، محرک ها و متغیرهای آن تعیین می شود. اگرچه یک کانتینر کوچک هنوز هم ممکن است بر عملکرد صفحه تأثیر منفی بگذارد، یک کانتینر بزرگ تقریباً مطمئناً تأثیر منفی خواهد گذاشت.
هنگام بهینه سازی استفاده از برچسب، اندازه کانتینر نباید معیار ستاره شمالی شما باشد. با این حال، اندازه ظروف بزرگ اغلب یک علامت هشدار دهنده است که یک ظرف به خوبی نگهداری نمی شود و احتمالاً مورد سوء استفاده قرار می گیرد.
Google Tag Manager اندازه کانتینر را به 200 کیلوبایت محدود می کند و در مورد اندازه ظرف از 140 کیلوبایت هشدار می دهد. با این حال، بیشتر سایت ها باید سعی کنند کانتینرهای خود را بسیار کوچکتر از این نگه دارند. برای چشم انداز، کانتینر سایت میانه حدود 50 کیلوبایت است.
برای تعیین اندازه ظرف خود، به اندازه پاسخی که توسط https://www.googletagmanager.com/gtag/js?id=YOUR_ID
برگردانده شده است نگاه کنید. این پاسخ شامل کتابخانه Google Tag Manager به اضافه محتویات ظرف است. به خودی خود، کتابخانه Google Tag Manager حدود 33 کیلوبایت فشرده است.
Name your container versions
نسخه کانتینر یک عکس فوری از محتوای یک ظرف در یک زمان خاص است. استفاده از یک نام معنی دار و همراه با توضیح کوتاهی از تغییرات معنی دار در داخل می تواند کمک زیادی به رفع اشکالات عملکرد آینده کند.
برچسب گذاری گردش کار
مدیریت تغییرات در برچسب های شما برای اطمینان از اینکه آنها تأثیر منفی بر عملکرد صفحه ندارند مهم است.
Test tags before deploying
آزمایش تگها قبل از استقرار میتواند به رفع مشکلات (عملکرد و موارد دیگر) قبل از ارسال کمک کند.
Things to consider when testing a tag include:
- Is the tag working correctly?
- Does the tag cause any layout shifts?
- Does the tag load any resources? How large are these resources?
- Does the tag trigger a long-running script?
حالت پیش نمایش
حالت پیشنمایش به شما امکان میدهد تغییرات تگها را در سایت واقعی خود بدون نیاز به نصب آنها برای عموم آزمایش کنید. حالت پیش نمایش شامل یک کنسول اشکال زدایی است که اطلاعات مربوط به برچسب ها را ارائه می دهد.
زمان اجرای Google Tag Manager زمانی که در حالت پیشنمایش اجرا میشود، به دلیل سربار اضافی مورد نیاز برای افشای اطلاعات در کنسول اشکالزدایی، متفاوت خواهد بود (کمی کندتر). بنابراین، مقایسه اندازهگیریهای Web Vitals جمعآوریشده در حالت پیشنمایش با اندازهگیریهای جمعآوریشده در تولید توصیه نمیشود. با این حال، این اختلاف نباید بر رفتار اجرای خود برچسب ها تأثیر بگذارد.
تست مستقل
یک روش جایگزین برای آزمایش تگ ها، راه اندازی یک صفحه خالی حاوی یک محفظه با یک تگ است - برچسبی که در حال آزمایش آن هستید. این تنظیم آزمایشی کمتر واقع بینانه است و برخی از مشکلات را حل نمی کند (مثلاً اینکه آیا یک برچسب باعث تغییر طرح بندی می شود) - با این حال می تواند جداسازی و اندازه گیری تأثیر برچسب بر مواردی مانند اجرای اسکریپت را آسان تر کند. بررسی کنید که چگونه تلگراف از این رویکرد جداسازی برای بهبود عملکرد کد شخص ثالث استفاده می کند .
نظارت بر عملکرد تگ
Google Tag Manager Monitoring API می تواند برای جمع آوری اطلاعات در مورد زمان اجرای یک برچسب خاص استفاده شود. این اطلاعات به نقطه پایانی مورد نظر شما گزارش می شود.
برای اطلاعات بیشتر، نحوه ساخت مانیتور Google Tag Manager را ببینید.
نیاز به تایید برای تغییرات کانتینر
کد شخص اول معمولاً قبل از استقرار از طریق بررسی و آزمایش انجام می شود - با برچسب های خود نیز به همین ترتیب رفتار کنید. یکی از راههای انجام این کار، افزودن تأیید دو مرحلهای ، که به تأیید سرپرست برای تغییرات کانتینر نیاز دارد. از طرف دیگر، اگر نمیخواهید به تأیید دو مرحلهای نیاز داشته باشید، اما همچنان میخواهید تغییرات را زیر نظر داشته باشید، میتوانید اعلانهای کانتینر را برای دریافت هشدارهای ایمیل درباره رویدادهای کانتینر انتخابی خود تنظیم کنید.
به طور دوره ای استفاده از برچسب را بررسی کنید
یکی از چالش های کار با برچسب ها این است که آنها در طول زمان انباشته می شوند: برچسب ها اضافه می شوند اما به ندرت حذف می شوند. بررسی دوره ای برچسب ها یکی از راه های معکوس کردن این روند است. فرکانس ایده آل برای انجام این کار به تعداد دفعات به روز رسانی برچسب های سایت شما بستگی دارد.
برچسب زدن به هر تگ به طوری که مالک مشخص باشد، امکان شناسایی آسانتر اینکه چه کسی برای آن برچسب پاسخگو است و میتواند بگوید که آیا هنوز به آن نیاز است یا خیر، میدهد.
هنگام ممیزی تگ ها، پاک کردن محرک ها و متغیرها را نیز فراموش نکنید. آنها به راحتی می توانند علت مشکلات عملکرد نیز باشند.
برای اطلاعات بیشتر، به نگهداری اسکریپت های شخص ثالث تحت کنترل مراجعه کنید.