לפני שתבצעו אופטימיזציה של תגים של צד שלישי, ודאו שהסקריפטים האלה עדיין נדרשים באתר שלכם.
סקריפטים או "תגים" של צד שלישי יכולים להיות מקור לבעיות ביצועים באתר שלך, ולכן כיעד לאופטימיזציה. עם זאת, לפני שתתחילו לבצע אופטימיזציה לתגים שהוספתם, ודאו שאתם לא מבצעים אופטימיזציה לתגים שאתם אפילו לא צריכים. במאמר הזה נסביר איך להעריך בקשות לתגים חדשים, ולנהל ולבדוק תגים קיימים.
כאשר דנים בתגים של צד שלישי, בדרך כלל השיחה עוברת במהירות לבעיות ביצועים, וכבר מתעלמים מהיסודות של תפקיד "הליבה" של התגים. הם מספקים מגוון רחב של פונקציונליות שימושית, שהופכים את האינטרנט לדינמי, אינטראקטיבי יותר ומחובר. עם זאת, צוותים שונים בארגון יכולים להוסיף תגים של צד שלישי, ולרוב שוכחים אותם עם הזמן. אנשים מתקדמים הלאה, התוקף של חוזים פג או שהתוצאות מסתיימות, אבל הצוותים אף פעם לא יוצרים קשר כדי להסיר את הסקריפטים.
לפני שתתחילו לחשוב על ביצוע סקריפטים של תגים של צד שלישי, או על אילו תגים אפשר לדחות, לטעון בהדרגה או לחבר מראש מנקודת מבט טכנית, יש הזדמנות לקבוע אילו תגים יתווספו לאתר או לדף, מנקודת מבט ארגונית. אחד מהנושאים שמקובלים בקרב אתרים שמאט בגלל כמויות עצומות של תגים של צד שלישי: החלק הזה באתר הוא לא בבעלותו של אדם או צוות אחד, ולכן הוא נמצא בין הכיסאות. אין דבר מתסכל יותר מאופטימיזציה של האתר, מרוצים מהביצועים בסביבת ה-Staging, רק בגלל המהירות של חזרה לתהליכי ייצור כתוצאה מהוספה של תגים. הטמעת 'תהליך בדיקה' לתגים של צד שלישי יכולה למנוע זאת על ידי פיתוח תהליך עבודה שיוצר אחריות בפונקציות שונות ואחריות על התגים האלה.
האופן שבו בודקים תגים של צד שלישי תלוי אך ורק בארגון, במבנה שלו ובתהליכים הנוכחיים שלו. הדבר יכול להיות בסיסי כמו ניהול צוות אחד שמנהל את המערכת כשומר הסף לניתוח התגים לפני שמוסיפים אותם. או ברמה מתקדמת ורשמי יותר, למשל על ידי שליחת טופס לצוותים לצורך שליחת בקשות להוספת תג. יכול להיות שתתבקשו לספק הקשר לגבי הסיבה לכך שהוא צריך להופיע באתר, כמה זמן הוא צריך להופיע ומה היתרונות מבחינת העסק.
תהליך ניהול תגים
בכל מקרה, אתם בוחרים לבדוק תגים בארגון שלכם, אבל צריך להביא בחשבון את השלבים הבאים כחלק ממחזור החיים של התג.
תאימות
לפני שמוסיפים תג לדף, חשוב לוודא שהוא נבדק באופן יסודי על ידי צוות משפטי כדי לוודא שהוא עומד בכל דרישות התאימות שיש לעמוד בהן. בין היתר, כדאי לבדוק שהתג עומד בדרישות של General Data Protection Regulation (התקנה הכללית להגנה על מידע (GDPR)) של האיחוד האירופי וחוק הפרטיות לצרכנים בקליפורניה (California Consumer Privacy Act = CCPA).
זה קריטי, אם יש ספק לגבי השלב הזה, צריך לטפל בו לפני שמעריכים את התג מבחינת הביצועים.
חובה
השלב השני הוא לשאול אם יש צורך בתג ספציפי בדף. כדאי להביא בחשבון את נקודות הדיון הבאות:
- האם התג נמצא בשימוש פעיל? אם לא, האם ניתן להסיר אותו?
- אם התג נטען בכל דפי האתר, האם צריך לעשות זאת? לדוגמה, אם אנחנו מנתחים חבילת בדיקות A/B ואתם בודקים כרגע רק ב'דפי נחיתה', האם נוכל לשחרר את התג בדף מסוג זה בלבד?
- האם נוכל להוסיף לוגיקה נוספת, האם נוכל לזהות אם מתבצעת בדיקת A/B בזמן אמת? במקרה כזה, אפשר להוסיף את התג אבל אם לא, צריך לוודא שהוא לא קיים.
בעלות
המשמעות של בעלים או צוות ברורים היא להיות הבעלים של התג, מה שיעזור לכם לעקוב באופן יזום אחרי תגים. בדרך כלל מדובר במי שהוסיף את התג. אם מוסיפים משתמש ליד התג, אפשר לוודא שבעתיד תוכלו לבצע בדיקות ובקרות כדי לבדוק אם צריך את התג.
מטרה
השלב הרביעי מתחיל ביצירת אחריות ואחריות בכל פונקציות שונות, בכך שהוא עוזר לאנשים להבין למה התג נוסף לדף. חשוב שתהיה הבנה של כל פונקציות שונות לגבי מה שכל תג מביא לאתר ולמה נעשה בו שימוש. לדוגמה, אם התג מתעד פעולות של משתמש באתר כדי לאפשר התאמה אישית, האם כל הצוותים יודעים למה זה צריך להיכלל?
בנוסף, האם התקיימו דיונים בנוגע להשפעה על הביצועים, מבחינה מסחרית? אם יש תג שנחשב ל'נדרש' מפני שהוא מניב הכנסות, האם בוצע ניתוח של ההכנסות הפוטנציאליות שאבדו בגלל רגרסיה מהירה?
ביקורת
השלב החמישי, האחרון והחשוב ביותר, הוא לוודא שהתגים נבדקים באופן קבוע. משך הזמן תלוי בגודל האתר, במספר התגים שבאתר ובזמן הביצוע שלהם (למשל: שבועי, חודשי או רבעוני). צריך להתייחס אליהן כמו לאופטימיזציה של נכסי אתר אחרים (JS, CSS, תמונות וכו') ולבדוק באופן יזום באופן קבוע. אם הבדיקה לא תושלם, מנהל התגים 'מנוף' עלול להאט את הדפים. יכול להיות שמשימה מורכבת לחזור לביצועים טובים, אבל לא לבצע רגרסיה של הפונקציונליות הנדרשת בדף
תהליך הבדיקה ישאיר לכם רשימה סופית של תגים שמסווגים כנדרש לדף ספציפי. בשלב הזה אפשר להתעמק בגישות לאופטימיזציה טכנית. כך גם תיפתח ההזדמנות להגדיר את מספר התגים ברשימה הסופית הזו בתקציב ביצועים, שאפשר לעקוב אחריו ב-Lighthouse CI ולשלב אותו בהגדרת יעדים ספציפיים לביצועים. למשל:
אם נצמד <5 תגים בדפי הנחיתה שלנו יחד עם קוד JS שעבר אופטימיזציה, אנחנו בטוחים שזמן החסימה הכולל (TBT) יכול להגיע 'טוב' במדדי הליבה לבדיקת חוויית המשתמש באתר.