שיטות מומלצות לשימוש בתגים ובמנהלי תגים

Katie Hempenius

Barry Pollard

תאריך פרסום: 29 ביולי 2021

תגים הם קטעי קוד של צד שלישי שמוטמעים באתר, בדרך כלל באמצעות מנהל תגים. התגים משמשים בעיקר למטרות שיווק וניתוח נתונים.

ההשפעה של תגים ומנהלי תגים על הביצועים משתנה מאוד בין אתרים שונים. אפשר להשוות בין מנהלי תגים לבין מעטפה: מנהל התגים מספק את הכלי, אבל אתם בעיקר קובעים מה תכניסו אליו ואיך תשתמשו בו.

כאן נסביר על שיטות לאופטימיזציה של תגים ומנהלי תגים לשיפור הביצועים ולשיפור מדדי הליבה לבדיקת חוויית המשתמש באתר. המסמך הזה מתייחס ל-Google Tag Manager, אבל הרבה מהרעיונות שנדונים בו רלוונטיים למערכות ניהול תגים אחרות.

ההשפעה על מדדי הליבה לבדיקת חוויית המשתמש באתר

לעתים קרובות, מערכת ניהול התגים יכולה להשפיע באופן עקיף על המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) על ידי שימוש במשאבים הנדרשים כדי לטעון את הדף במהירות ולשמור על תגובה מהירה שלו. רוחב הפס יכול לשמש להורדת ה-JavaScript של Tag Manager לאתרים שלכם, או לשיחות הבאות שהוא יוצר. את זמן המעבד (CPU) ב-thread הראשי אפשר להשקיע בהערכה ובהפעלה של JavaScript שכלול ב-Tag Manager ובתגים.

מדד Largest Contentful Paint‏ (LCP) חשוף לתחרות על רוחב הפס במהלך זמן הטעינה הקריטי של הדף. בנוסף, חסימה של ה-thread הראשי עלולה לעכב את זמן הרינדור של LCP.

Cumulative Layout Shift (CLS) יכולה להיות מושפעת מעיכוב הטעינה של משאבים קריטיים לפני העיבוד הראשון, או ממנהלי תגים שמחדירים תוכן לדף.

זמן האינטראקציה עד לציור הבא (INP) חשוף לתחרות על המעבד בשרשור הראשי, וראינו קורלציה בין הגודל של מנהלי התגים לבין ציונים נמוכים יותר של INP.

בוחרים את סוג התג המתאים

ההשפעה של התגים על הביצועים משתנה בהתאם לסוג התג. באופן כללי, תגי תמונה ('פיקסלים') הם התגים שמניבים את הביצועים הטובים ביותר, ואחריהם תבניות בהתאמה אישית ולבסוף תגי HTML בהתאמה אישית. תגי הספקים משתנים בהתאם לפונקציונליות שהם מאפשרים.

חשוב לזכור שהאופן שבו משתמשים בתג משפיע מאוד על ההשפעה שלו על הביצועים. ל'פיקסלים' יש ביצועים גבוהים בעיקר מפני שהאופי של סוג התג הזה מגביל מאוד את אופן השימוש בהם. תגי HTML מותאמים אישית לא תמיד פוגעים בביצועים, אבל בגלל רמת החופש שהם מציעים למשתמשים, קל להשתמש בהם לרעה באופן יפגע בביצועים.

כשאתם מחליטים אילו תגים להטמיע, חשוב לזכור את ההיקף: ההשפעה של תג יחיד על הביצועים עשויה להיות זניחה, אבל היא יכולה להיות משמעותית אם משתמשים בעשרות או במאות תגים באותו דף.

לא כל הסקריפטים צריכים להיות נטענים באמצעות מנהל תגים

בדרך כלל, מנהלי תגים הם לא הדרך הטובה ביותר לטעון משאבים שמטמיעים מאפיינים חזותיים או פונקציונליים מיידיים של חוויית המשתמש, כמו הודעות על קובצי cookie, תמונות ראשיות או תכונות של האתר. השימוש במנהל תגים כדי לטעון את המשאבים האלו בדרך כלל מעכב את האספקה שלהם. המצב הזה פוגע בחוויית המשתמש, ויכול גם להגדיל מדדים כמו LCP ו-CLS.

בנוסף, חלק מהמשתמשים חוסמים את מנהלי התגים. שימוש במנהל תגים כדי להטמיע תכונות של חוויית משתמש עלול לגרום לאתר לא תקין אצל חלק מהמשתמשים.

חשוב להיזהר עם תגי HTML בהתאמה אישית

תגי HTML מותאמים אישית קיימים כבר שנים רבות, והם נמצאים בשימוש נרחב ברוב האתרים. תגי HTML מותאמים אישית מאפשרים לכם להזין קוד משלכם, עם מעט הגבלות, כי השימוש העיקרי בתג הזה הוא הוספה של רכיבי <script> מותאמים אישית לדף.

אפשר להשתמש בתגי HTML מותאמים אישית במגוון רחב של דרכים, וההשפעה שלהם על הביצועים משתנה באופן משמעותי. כשמודדים את הביצועים של האתר, חשוב לזכור שרוב הכלים משייכים את ההשפעה של תג HTML מותאם אישית על הביצועים למנהל התגים שהחדיר אותו, ולא לתג עצמו.

תגי HTML מותאמים אישית יכולים להוסיף רכיב לדף שמקיף אותם. הוספת אלמנטים לדף עשויה לגרום לבעיות בביצועים, ובמקרים מסוימים גם לשינויים בפריסה.

• ברוב המצבים, אם מוסיפים רכיב לדף, הדפדפן צריך לחשב מחדש את הגודל והמיקום של כל פריט בדף. התהליך הזה נקרא פריסה. ההשפעה של פריסה אחת על הביצועים היא מינימלית, אבל אם היא מתרחשת באופן מוגזם, היא עלולה לגרום לבעיות בביצועים. ההשפעה של התופעה הזו גדולה יותר במכשירים ברמה נמוכה ובדפים עם מספר רב של רכיבי DOM.
• אם רכיב דף גלוי מוכנס ל-DOM אחרי שהאזור שמסביב כבר עבר עיבוד, הוא עלול לגרום לשינוי הפריסה. התופעה הזו לא ייחודית למנהלי תגים – אבל מכיוון שתגים בדרך כלל נטענים מאוחר יותר מחלקים אחרים בדף, הם לרוב מוכנסים ל-DOM אחרי שהדף שמסביב כבר עבר רינדור.

שימוש בתבניות מותאמות אישית

תבניות בהתאמה אישית תומכות בחלק מהפעולות שתגי HTML בהתאמה אישית תומכים בהן, אבל הן מבוססות על גרסת JavaScript ב-sandbox שמספקת ממשקי API לתרחישים נפוצים של שימוש, כמו הזרקת סקריפט והזרקת פיקסלים. כפי שרואים מהשם, הם מאפשרים ליצור תבנית על ידי משתמש מתקדם שיכול ליצור אותה תוך התמקדות בביצועים. לאחר מכן, משתמשים פחות טכניים יוכלו להשתמש בתבנית. לרוב, זוהי שיטה בטוחה יותר מאשר מתן גישה מלאה ל-HTML בהתאמה אישית.

בגלל ההגבלות המשמעותיות יותר שחלות על תבניות בהתאמה אישית, הסיכוי לבעיות בביצועים או באבטחה בתגים האלה נמוך בהרבה. מהסיבות האלה, תבניות בהתאמה אישית לא מתאימות לכל תרחישי השימוש.

הזרקת סקריפטים בצורה נכונה

שימוש במנהל תגים להחדרת סקריפט הוא תרחיש לדוגמה נפוץ מאוד. הדרך המומלצת לעשות זאת היא להשתמש בתבנית מותאמת אישית וב-API injectScript.

מידע נוסף על השימוש ב-injectScript API כדי להמיר תג HTML מותאם אישית קיים זמין במאמר המרת תג קיים.

אם אתם חייבים להשתמש בתג HTML מותאם אישית, חשוב לזכור:

• כדי לטעון ספריות וסקריפטים גדולים של צד שלישי, צריך להשתמש בתג סקריפט (למשל, <script src="external-scripts.js">) שיוריד קובץ חיצוני, במקום להעתיק את תוכן הסקריפט ולהדביק אותו ישירות בתג. למרות ששימוש מתמשך בתג <script> מונעת הלוך ושוב להורדת תוכן הסקריפט, אבל השיטה הזו מגדילה את הקונטיינר ומונעת את שמירת הסקריפט בנפרד על ידי הדפדפן.
• ספקים רבים ממליצים למקם את תג ה-<script> בחלק העליון של ה-<head>. עם זאת, בדרך כלל אין צורך לעשות זאת עבור סקריפטים שנטענים באמצעות Tag Manager. ברוב המקרים, הדפדפן כבר סיים לנתח את ה-<head> עד שה-Tag Manager מופעל.

שימוש בפיקסלים

לפעמים אפשר להחליף סקריפטים של צד שלישי בתמונות או בפיקסלים של iframe. בהשוואה לקוד המקביל שמבוסס על סקריפט, לפעמים הפיקסלים תומכים בפחות פונקציונליות, ולכן הם נחשבים לרוב להטמעה פחות מועדפת. עם זאת, כשמשתמשים בפיקסלים בתוך מנהלי תגים, הם יכולים להיות דינמיים יותר כי הם יכולים להפעיל טריגרים ולהעביר משתנים שונים.

פיקסלים הם סוג התג עם הביצועים והאבטחה הכי טובים, כי אין ביצוע של JavaScript אחרי שהוא מופעל. לתמונות הפיקסלים יש גודל משאב קטן מאוד (פחות מ-1KB), והן לא גורמות לשינויים בפריסה.

למידע נוסף על התמיכה שלו בפיקסלים, פנו לספק הצד השלישי. בנוסף, אפשר לנסות לבדוק את הקוד שלהם כדי לאתר תג <noscript>. אם הספק תומך בפיקסלים, בדרך כלל הוא כולל את הפיקסל בתג <noscript>.

חלופות לפיקסלים

הפיקסלים הפכו לפופולריים בעיקר כי בעבר הם היו אחת מהדרכים הזולות והמהימנות ביותר לשלוח בקשת HTTP במצבים שבהם התשובה מהשרת לא רלוונטית (לדוגמה, כששולחים נתונים לספקי ניתוח נתונים). ממשקי ה-API של navigator.sendBeacon() ושל fetch() keepalive מיועדים לטפל באותו תרחיש לדוגמה, אבל הם מהימנים יותר מאשר פיקסלים.

אין בעיה להמשיך להשתמש בפיקסלים – יש להם תמיכה רחבה והם משפיעים על הביצועים במידה מינימלית. עם זאת, אם אתם יוצרים משואות משלכם, כדאי לשקול להשתמש באחד מממשקי ה-API האלה.

sendBeacon()

ה-API של navigator.sendBeacon() מיועד לשליחת כמויות קטנות של נתונים לשרתי אינטרנט במצבים שבהם התגובה מהשרת לא חשובה.

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

navigator.sendBeacon(url, data);

ל-sendBeacon() יש ממשק API מוגבל: הוא תומך רק בשליחת בקשות POST ולא תומך בהגדרת כותרות בהתאמה אישית. הוא נתמך בכל הדפדפנים המודרניים.

Fetch API 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(), חשוב להביא בחשבון את התכונות ואת תמיכת הדפדפן הנדרשות. ה-API של fetch() גמיש הרבה יותר, אבל ל-keepalive יש פחות תמיכה בדפדפנים מאשר ל-sendBeacon().

מה התגים עושים

בדרך כלל, התגים נוצרים בהתאם להנחיות של ספק צד שלישי. אם לא ברור מה הקוד של הספק עושה, כדאי לשאול מישהו שמבין בנושא. חוות דעת נוספת יכולה לעזור לכם לזהות אם תג מסוים עלול לגרום לבעיות בביצועים או באבטחה.

מומלץ להוסיף לתגים תווית של בעלים ב-Tag Manager. קל לשכוח מי הבעלים של התג, מה שמוביל לחשוש מהסרה במקרה שמשהו ישבר!

טריגרים

באופן כללי, אופטימיזציה של טריגרים של תגים כוללת הקפדה על כך שלא להפעיל תגים יותר מהנדרש ובחירה בטריגר שמאזן בין הצרכים העסקיים לבין עלויות הביצועים.

טריגרים הם קוד JavaScript שמגדיל את הגודל ואת עלות הביצוע של מנהל התגים. רוב הטריגרים הם קטנים, אבל ההשפעה המצטברת שלהם יכולה להיות משמעותית. לדוגמה, אם מפעילים כמה אירועי קליקים או טריגרים של טיימר, צריך להגדיל באופן משמעותי את עומס העבודה ב-Tag Manager.

בחירת גורם מפעיל מתאים לאירוע

ההשפעה על הביצועים של התג יכולה להשתנות. באופן כללי, ככל שהתג מופעל מוקדם יותר, כך ההשפעה שלו על הביצועים גדולה יותר. המשאבים בדרך כלל מוגבלים בזמן הטעינה הראשונית של הדף, ולכן טעינה או הפעלה של משאב מסוים (או תג) חוסכות משאבים ממשהו אחר.

למרות שחשוב לבחור טריגרים מתאימים לכל התגים, חשוב במיוחד לתגים שטוענים משאבים גדולים או מריצים סקריפטים ארוכים.

אפשר להפעיל תגים בצפיות בדפים (בדרך כלל Page load, ב-DOM Ready, ב-Window Loaded) או על סמך אירוע מותאם אישית. כדי למנוע השפעה על טעינת הדף, כדאי להפעיל תגים לא חיוניים אחרי Window Loaded.

שימוש באירועים מותאמים אישית

משתמשים באירועים בהתאמה אישית כדי להפעיל טריגרים בתגובה לאירועים בדף שלא מכוסים על ידי הטריגרים המובנים של Google Tag Manager. לדוגמה, תגים רבים משתמשים בטריגרים של צפיות בדפים. עם זאת, הזמן שחולף בין DOM Ready לבין Window Loaded יכול להיות ארוך, ולכן קשה לשפר את התזמון של הפעלת התג. אירועים מותאמים אישית יכולים להיות פתרון לבעיה הזו.

קודם כול, יוצרים טריגר אירוע בהתאמה אישית ומעדכנים את התגים כך שישתמשו בטריגר הזה.

כדי להפעיל את הטריגר, דוחפים את האירוע המתאים לשכבת הנתונים.

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

שימוש בתנאים ספציפיים לטריגר

מגדירים תנאי טריגר ספציפיים כדי להימנע מהפעלה של תגים כשאין צורך בכך. אחת הדרכים הפשוטות והיעילות לעשות זאת היא לוודא שתג מופעל רק בדפים שבהם משתמשים בו בפועל.

אפשר לשלב משתנים מובְנים בתנאים להפעלה כדי להגביל את הפעלת התגים.

טעינת מנהל התגים בזמן המתאים

כדי לשפר את הביצועים, אפשר לשנות את מועד הטעינה של מנהל התגים עצמו. טריגרים, ללא קשר לאופן הגדרתם, לא יכולים לפעול עד לאחר טעינת ה-Tag Manager. כדאי לנסות לטעון את מנהל התגים, כי ההשפעה יכולה להיות שווה או גדולה יותר. ההחלטה הזו משפיעה על כל התגים בדף.

טעינת מנהל התגים בשלב מאוחר יותר מונעת טעינת תג מוקדם מדי בטעות, וכך מונעת בעיות בביצועים בעתיד.

משתנים

שימוש במשתנים כדי לקרוא נתונים מהדף. הם שימושיים בטריגרים ובתגים עצמם.

בדומה לטריגרים, משתנים מוסיפים קוד JavaScript למנהל התגים, ולכן הם עלולים לגרום לבעיות בביצועים. המשתנים יכולים להיות קטנים יחסית, כמו קוד לקריאת חלקים מכתובת ה-URL, מקובצי cookie, משכבת הנתונים או מ-DOM. הן יכולות לכלול גם קוד JavaScript בהתאמה אישית עם יכולות (וגודל) בלתי מוגבלות.

השימוש במשתנים צריך להיות מינימלי, כי מנהל התגים מעריך אותם באופן קבוע. כדי לצמצם את גודל הסקריפט של Tag Manager ואת זמן העיבוד שלו, כדאי להסיר משתנים ישנים שלא בשימוש.

ניהול תגים

שימוש יעיל בתגים מפחית את הסיכון לבעיות בביצועים.

שימוש בשכבת הנתונים

שכבת הנתונים היא מערך של אובייקטים ב-JavaScript שמכילים מידע על הדף. האובייקטים האלה מכילים את כל המידע שרוצים להעביר אל Google Tag Manager.

אפשר גם להשתמש בשכבת הנתונים כדי להפעיל תגים.

// 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'});

אפשר להשתמש ב-Google Tag Manager בלי שכבת הנתונים, אבל מומלץ מאוד להשתמש בה. שכבת הנתונים מרכזת את הנתונים שסקריפטים של צד שלישי יכולים לגשת אליהם במקום אחד, וכך מספקת שקיפות טובה יותר לגבי השימוש בהם. בין היתר, כך תוכלו לצמצם את מספר החישובים העודפים של המשתנים ואת מספר פעולות ההפעלה של הסקריפט.

שימוש בשכבת נתונים מאפשר לכם לקבוע לאילו נתונים התגים יקבלו גישה, במקום לתת גישה מלאה למשתנה JavaScript או ל-DOM.

יכול להיות שהיתרונות של שכבת הנתונים מבחינת הביצועים לא יהיו אינטואיטיביים, מכיוון שעדכון שכבת הנתונים גורם ל-Google Tag Manager להעריך מחדש את כל משתני הקונטיינר, ויכול להיות שהוא יגרום להפעלת תגים, שכוללת ביצוע של JavaScript. אפשר להשתמש בשכבת הנתונים בצורה שגויה, אבל באופן כללי, אם שכבת הנתונים נראית כמקור לבעיות בביצועים, סביר להניח שיש בעיות בביצועים של המאגר עצמו. שכבת הנתונים מאפשרת לראות את הבעיות האלה בבירור.

הסרת תגים כפולים ותגים שלא בשימוש

תגים כפולים יכולים להופיע כשתג כלשהו נכלל בסימון ה-HTML של הדף, בנוסף להחדרת התג דרך מנהל תגים.

תגים שלא בשימוש צריך להשהות או להסיר, ולא לחסום באמצעות החרגת טריגר. השהיה או הסרה של תג מסירים את הקוד מהמאגר, אבל חסימה לא מסירה אותו.

כשמסירים תגים שלא בשימוש, כדאי לבדוק את הטריגרים והמשתנים כדי לקבוע אם אפשר להסיר אותם גם כן.

תגים מושהים משפיעים על גודל המאגר, אבל המטען הייעודי (payload) הכולל קטן יותר מאשר כשהתגים פעילים.

שימוש ברשימות היתרים ודחייה

אפשר להשתמש ברשימות הרשאה ודחייה כדי להגדיר הגבלות מפורטות מאוד על התגים, הטריגרים והמשתנים שמותר להשתמש בהם בדף. אפשר להשתמש בנתונים האלה כדי לאכוף שיטות מומלצות לשיפור הביצועים וכללי מדיניות אחרים.

רשימות ההרשאות והדחייה מוגדרות דרך שכבת הנתונים.

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

לדוגמה, אפשר למנוע שימוש בתגי HTML בהתאמה אישית, במשתני JavaScript או בגישה ישירה ל-DOM. המשמעות היא שניתן להשתמש רק בפיקסלים ובתגים מוגדרים מראש, עם נתונים משכבת הנתונים. אמנם מדובר בהגבלה, אבל היא יכולה להוביל להטמעה מאובטחת וביצועים טובים יותר של Tag Manager.

כדאי להשתמש בתיוג בצד השרת

כדאי לשקול לעבור לתיוג בצד השרת, במיוחד באתרים גדולים יותר שרוצים יותר שליטה בנתונים שלהם. תיוג בצד השרת מסיר את קוד הספק מהלקוח, וכך מעביר את העיבוד מהלקוח לשרת.

לדוגמה, כשמשתמשים בתיוג בצד הלקוח, שליחת נתונים לכמה חשבונות Analytics מחייבת את הלקוח להתחיל בקשות נפרדות לכל נקודת קצה. כשמשתמשים בתיוג בצד השרת, הלקוח שולח בקשה אחת למאגר התגים בצד השרת, ומשם הנתונים מועברים לחשבונות ניתוח נתונים שונים.

חשוב לזכור שתיוג בצד השרת פועל רק עם תגים מסוימים. תאימות התגים משתנה בהתאם לספק.

מידע נוסף זמין במאמר מבוא לתיוג בצד השרת.

קונטיינרים

בדרך כלל, מערכת ניהול התגים מאפשרת להגדיר כמה מופעים, שנקראים לרוב מאגרים. אפשר לשלוט במספר מאגרים בחשבון Tag Manager אחד.

שימוש רק בקונטיינר אחד בכל דף

מספר קונטיינרים בדף אחד יכולים לגרום לבעיות משמעותיות בביצועים, כי הם כוללים תקורה נוספת וביצוע של סקריפט. לכל הפחות, הוא מכפיל את קוד התג של הליבה, שאי אפשר לעשות בו שימוש חוזר בין הקונטיינרים כי הוא מועבר כחלק מ-JavaScript של הקונטיינר.

רק במקרים נדירים אפשר להשתמש ביעילות בכמה מאגרים. עם זאת, יש מקרים שבהם אפשר להשתמש באפשרות הזו, אם שולטים בה היטב. לדוגמה:

• כולל מאגר קל יותר לטעינה מוקדמת ומאגר כבד יותר לטעינה מאוחרת, במקום מאגר אחד גדול.
• שימוש במאגר מוגבל למשתמשים פחות טכניים, ובמאגר תגים פחות מוגבל, אבל עם בקרה קפדנית יותר, לתגים מורכבים יותר.

אם אתם חייבים להשתמש בכמה מאגרי תגים בכל דף, עליכם לפעול לפי ההנחיות של Google Tag Manager להגדרת כמה מאגרי תגים.

שימוש בקונטיינרים נפרדים במקרה הצורך

אם אתם משתמשים במנהל תגים למספר נכסים, כמו אפליקציית אינטרנט ואפליקציה לנייד, מספר הקונטיינרים שבהם אתם משתמשים יכול לעזור או לפגוע בפרודוקטיביות של תהליך העבודה. הוא גם יכול להשפיע על הביצועים.

אפשר להשתמש בקונטיינר אחד בכמה אתרים אם האתרים דומים במבנה ובשימוש. לדוגמה, יכול להיות שאפליקציות האינטרנט והאפליקציות לנייד של המותג יפעלו בצורה דומה, אבל סביר להניח שהמבנה שלהן יהיה שונה, ולכן קל יותר לנהל אותן באמצעות קונטיינרים נפרדים.

שימוש חוזר בקונטיינר אחד באופן רחב מדי יכול להגדיל את המורכבות והגודל של הקונטיינר, על ידי אילוץ לוגיקה מורכבת לניהול תגים וטריגרים.

מעקב אחר גודל הקונטיינר

הגודל של מאגר נקבע על סמך התגים, הטריגרים והמשתנים שלו. אמנם קונטיינר קטן עדיין עלול להשפיע לרעה על ביצועי הדף, אבל קונטיינר גדול כמעט בוודאות ישפיע לרעה על הביצועים.

כשמבצעים אופטימיזציה של השימוש בתג, גודל הקונטיינר לא צריך להיות המדד הכי חשוב. עם זאת, לרוב נפח גדול של מאגר הוא סימן אזהרה לכך שהמאגר לא מתוחזק כראוי וייתכן שנעשה בו שימוש לרעה.

מערכת Google Tag Manager מגבילה את גודל המאגר ל-300KB, ומזהירה על גודל המאגר אחרי שהוא מגיע ל-70% ממגבלת הגודל.

ברוב האתרים כדאי לשמור על קונטיינרים קטנים יותר מהמגבלה. לשם השוואה, קובץ האימג' הממוצע באתר הוא כ-50KB. ספריית Google Tag Manager בפני עצמה היא כ-33KB דחוסה.

מתן שם לגרסאות של מאגר התגים

גרסת קונטיינר היא קובץ snapshot של תוכן הקונטיינר בנקודת זמן מסוימת. שימוש בשם משמעותי וגם הוספת תיאור קצר של השינויים המשמעותיים בתוך השם יכולים לעזור מאוד בניפוי באגים של בעיות ביצועים עתידיות.

תהליכי עבודה של תגים

חשוב לנהל את השינויים בתגים כדי שלא תהיה להם השפעה שלילית על ביצועי הדפים.

בדיקה לפני הפריסה

כדאי לבדוק את התגים לפני הפריסה כדי לזהות בעיות שקשורות לביצועים ובעיות אחרות לפני שהם נשלחים.

כשבודקים תג, חשוב להביא בחשבון את הדברים הבאים:

• האם התג פועל בצורה תקינה?
• האם התג גורם לשינויים בפריסה?
• האם התג טוען משאבים? מה גודל המשאבים האלה?
• האם התג מפעיל סקריפט ממושך?

מצב תצוגה מקדימה

מצב תצוגה מקדימה מאפשר לבדוק שינויים בתגים באתר בפועל בלי שתצטרכו לפרוס אותם קודם לקהל הרחב. מצב התצוגה המקדימה כולל מסוף לניפוי באגים שמספק מידע על התגים.

זמן הביצוע של Google Tag Manager שונה (קצת איטי יותר) כשמריצים אותו במצב תצוגה מקדימה, בגלל העלויות הנוספות הנדרשות כדי לחשוף מידע במסוף ניפוי הבאגים. לכן, לא מומלץ להשוות בין מדידות של מדדי Web Vitals שנאספו במצב תצוגה מקדימה לבין מדידות שנאספו בסביבת הייצור. עם זאת, אי ההתאמה הזו לא אמורה להשפיע על התנהגות הביצוע של התגים עצמם.

בדיקה עצמאית

גישה חלופית לבדיקת תגים היא להגדיר דף ריק שמכיל מאגר עם תג אחד – התג שאתם בודקים. הגדרת הבדיקה הזו פחות מציאותית ולא תזהה בעיות מסוימות (למשל, אם תג גורם לשינויים בפריסה) – אבל קל יותר לבודד ולמדוד את ההשפעה של התג על פעולות כמו הפעלת הסקריפט. כדאי לקרוא איך ב-Telegraph משתמשים בגישה הזו לבידוד כדי לשפר את הביצועים של קוד של צד שלישי.

מעקב אחר ביצועי התג

אפשר להשתמש ב-Monitoring API של Google Tag Manager כדי לאסוף מידע על זמן הביצוע של תג מסוים. המידע הזה מדווח לנקודת הקצה של הבחירה.

מידע נוסף זמין במאמר איך יוצרים ניטור ב-Google Tag Manager.

דרישה לאישור לשינויים בקונטיינרים

בדרך כלל, קוד של צד ראשון עובר בדיקה ובדיקה לפני הפריסה. יש להתייחס לתגים באותו אופן.

אחת מהדרכים לעשות זאת היא להוסיף אימות דו-שלבי, שמחייב אישור של אדמין לשינויים בקונטיינרים. לחלופין, אם אתם לא רוצים לדרוש אימות דו-שלבי אבל עדיין רוצים לעקוב אחרי שינויים, תוכלו להגדיר התראות לגבי קונטיינרים כדי לקבל התראות באימייל על אירועים בקונטיינרים שבחרתם.

בדיקה תקופתית של השימוש בתגים

אחד האתגרים בעבודה עם תגים הוא שהם נוטים לצבור לאורך זמן: מוסיפים תגים, אבל הם נשלפים לעיתים רחוקות. בדיקת התגים מדי פעם היא אחת הדרכים לשנות את המגמה הזו. התדירות האידיאלית לביצוע הפעולה הזו תלויה בתדירות העדכון של התגים באתר.

תוויות על כל תג שמציינות את הבעלים שלו מאפשרות לזהות בקלות את הגורם האחראי לתג הזה, ולדעת אם הוא עדיין נדרש.

כשבודקים את התגים, חשוב לנקות את הטריגרים והמשתנים. לעתים קרובות הן גם יכולות לגרום לבעיות בביצועים.

מידע נוסף זמין במאמר שליטה בסקריפטים של צד שלישי.