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

Katie Hempenius
Katie Hempenius
X
Barry Pollard

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

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

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

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

ההשפעה על Core Web Vitals

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

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

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

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

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

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

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

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

לא צריך לטעון את כל הסקריפטים באמצעות Tag Manager

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

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

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

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

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

יצירת תג בהתאמה אישית ב-Google Tag Manager

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

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

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

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

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

תבנית מותאמת אישית ב-Google Tag Manager

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

שימוש ב-Tag Manager כדי להוסיף סקריפט הוא תרחיש נפוץ מאוד. הדרך המומלצת לעשות את זה היא להשתמש בתבנית בהתאמה אישית וב-API‏ injectScript.

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

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

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

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

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

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

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

תג של תמונה מותאמת אישית ב-Google Tag Manager

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

פיקסלים הפכו לפופולריים בעיקר כי בעבר הם היו אחת מהדרכים הזולות והאמינות ביותר לשלוח בקשת 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. רוב הטריגרים קטנים, אבל ההשפעה המצטברת שלהם יכולה להיות משמעותית. לדוגמה, אם יש כמה אירועים מסוג קליק או טריגרים של טיימר, זה יכול להגדיל באופן משמעותי את עומס העבודה של Tag Manager.

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

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

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

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

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

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

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

טריגר של אירוע בהתאמה אישית ב-Google Tag Manager

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

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

שימוש בתנאים ספציפיים להפעלת הכלל

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

תנאי טריגר ב-Google Tag Manager

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

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

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

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

משתנים

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

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

מומלץ להשתמש במשתנים כמה שפחות, כי Tag Manager מבצע בהם הערכה מתמשכת. כדי להקטין את הגודל של הסקריפט של 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 בדף, בנוסף להזרקה שלו דרך Tag Manager.

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

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

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

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

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

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

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

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

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

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

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

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

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

קונטיינרים

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

משתמשים רק במאגר תגים אחד בכל דף

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

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

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

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

אם צריך, השתמשו במאגרים נפרדים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקה עצמאית

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

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

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

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

דרישת אישור לשינויים במאגר התגים

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

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

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

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

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

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

מידע נוסף זמין במאמר Keeping third-party scripts under control.