מעקב אחר ביצועים

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

מדידת הביצועים של הדף

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

כדי להתחיל למדוד את הביצועים, מומלץ לשלב בין הגישות הבאות:

  • מעקב סינתטי
    אתם יכולים להשתמש בכלים כמו Lighthouse ו-Publisher Ads Audits for Lighthouse כדי למדוד את ביצועי הדף בסביבת מעבדה. סוג המדידה הזה לא מחייב אינטראקציה של משתמש קצה, ולכן הוא מתאים לשימוש בבדיקות אוטומטיות, וניתן להשתמש בו כדי לאמת את הביצועים של השינויים לפני שמפיצים אותם למשתמשים.
  • מעקב אחר משתמשים אמיתיים (RUM)
    אתם יכולים להשתמש בכלים כמו Google Analytics ו-PageSpeed Insights כדי לאסוף נתוני ביצועים מהעולם האמיתי ישירות מהמשתמשים. סוג המדידה הזה מבוסס על אינטראקציות של משתמשי קצה, ולכן הוא שימושי לזיהוי בעיות בביצועים בשלב האחרון של התהליך, שלא ניתן לגלות בקלות באמצעות בדיקות סינתטיות.

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

בחירת המדדים

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

אזור הביצועים
מהירות הטעינה שחושבים שהיא מדדים

המהירות שבה הדף יכול לטעון ולעבד את כל רכיבי ממשק המשתמש.


מדדים מוצעים

הצגת תוכן ראשוני (FCP)
הצגת חלק התוכן הגדול ביותר (LCP)
הזמן להצגת המודעה הראשונה

מהירות טעינת הדף מדדים

המהירות שבה דף הופך לרספונסיבי אחרי הטעינה הראשונית.


מדדים מוצעים

השהיה לאחר קלט ראשוני (FID)
זמן לפעולה אינטראקטיבית (TTI)
זמן החסימה הכולל (TBT)

יציבות חזותית מדדים

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


מדדים מוצעים

תזוזת מודעות מצטברת
Cumulative Layout Shift ‏ (CLS)

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

בדיקת השינויים

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

בדיקה אוטומטית

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

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

בדיקת A/B

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

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

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

כלים כמו Optimizely ו-Google Optimize יכולים לעזור בהגדרה ובהפעלה של בדיקות A/B. עם זאת, חשוב לזכור שבדיקה מבוססת-תגים של A/B (הגדרת ברירת המחדל של הכלים האלה) עשויה להשפיע לרעה על הביצועים ולהניב תוצאות מטעות. לכן מומלץ מאוד לבצע שילוב בצד השרת:

תוצאות של בדיקות A/B

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

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

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

// On control group (A) pages, set page-level targeting to:
googletag
.pubads().setTargeting('your-test-id', 'a');

// On experimental group (B) pages, set page-level targeting to:
googletag
.pubads().setTargeting('your-test-id', 'b');

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