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

לבצע אופטימיזציה של תגים ומנהלי תגים לבדיקת Core Web Vitals.

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

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

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

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

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

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

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

ל-Interaction to Next Paint (INP) ייתכנו התנגשויות בין מעבדי (CPU) ב-thread הראשי, וראינו מתאם בין הגודל של מנהלי התגים לבין ציוני INP נמוכים יותר.

סוגי תגים

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

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

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

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

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

כדאי להיזהר בתגי HTML בהתאמה אישית

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

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

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

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

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

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

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

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

השימוש ב-Tag Manager להחדרת סקריפט הוא תרחיש לדוגמה נפוץ מאוד. ומומלץ להשתמש בתבנית מותאמת אישית injectScript API.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לטעון את Tag Manager בזמן המתאים

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

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

משתנים

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

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

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

ניהול תגים

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

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

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

// 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קונטיינרים

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

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

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

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

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

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

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

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

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

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

חשוב לשים לב לגודל המכל

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

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

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

כדי לדעת מה גודל המאגר, צריך לבדוק את גודל התגובה הוחזרו על ידי https://www.googletagmanager.com/gtag/js?id=YOUR_ID. הזה מכילה את ספריית Google Tag Manager ואת התוכן של מאגר תגים. גודל הספרייה של Google Tag Manager כשלעצמה הוא כ-33KB דחוסה.

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

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

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

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

בדיקת תגים לפני פריסה

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

נקודות למחשבה לגבי בדיקת תג כוללות:

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

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

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

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

בדיקה עצמאית

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

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

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

למידע נוסף, אפשר לעיין במאמר איך יוצרים Google Tag Manager. מעקב.

נדרש אישור לביצוע שינויים במאגרים

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

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

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

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

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

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