מומלץ להשתמש בבדיקות A/B כדי להעריך את ההשפעה של מהירות האתר על המדדים העסקיים.
בשנים האחרונות ידוע שהביצועים של מהירות האתר הם חלק משמעותי מחוויית המשתמש, וששיפור המהירות תורם למדדים עסקיים שונים, כמו שיעורי המרות ושיעורי העזיבה. כדי לגבות את הטענה הזו פורסמו מספר מאמרים ומקרים לדוגמה, כולל: How Website Performance Affects Conversion Rates (איך ביצועי אתר משפיעים על שיעורי ההמרה) של Deloitte, מיליוניות השנייה של Deloitte ו-Shopping for Speed ב-eBay.com.
למרות שהמקרה של המהירות הוא ברור, חברות רבות עדיין נאבקות בתעדוף העבודה שתשפר את מהירות האתר שלהן, כי הן לא יודעות בדיוק איך זה משפיע שלהן על המשתמשים וכתוצאה מכך על העסק שלהם.
אם אין נתונים, אפשר לעכב את העבודה במהירות האתר ולהתמקד במשימות אחרות. תרחיש נפוץ הוא לגרום לכמה אנשים בחברה להכיר בחשיבות של מהירות האתר, אבל לא ליצור תרחיש למטרה הזו ולשכנע כמה בעלי עניין להשקיע בהתאם.
במאמר הזה נסביר באופן כללי איך להשתמש בבדיקות A/B כדי להעריך את ההשפעה של מהירות האתר על המדדים העסקיים, וכך לקבל החלטות יעילות יותר בנושא.
שלב 1: בחירת דף לבדיקת A/B
המטרה היא לבדוק את ההשערה שמהירות הדף קשורה למדדים העסקיים שלכם. לשם הפשטות, תוכלו בהתחלה להגביל את עצמכם לזיהוי דף אחד לניתוח. העבודה העתידית יכולה להתרחב למספר דפים מאותו סוג כדי לאמת את הממצאים, ואז לחלקים אחרים באתר. בחלק התחתון של השלב הזה מופיעות כמה הצעות שיעזרו לכם להתחיל. מספר דרישות מניעות את תהליך בחירת הדף:
- יש להריץ בדיקת A/B רק במכשירים של משתמשים בנייד. ברחבי העולם, אתרי השותפים שאנחנו עוזרים להם לראות ממוצע של יותר מ-50% (ואף עלייה!) מהתנועה שלהם מגיעים מניידים, אבל הם יכולים לגדול באופן משמעותי בהתאם לאזור ולתעשייה מסוימת. מכשירים ניידים רגישים יותר לאתרים איטיים יותר, בגלל אילוצי עיבוד וזיכרון, ורשתות פחות יציבות. בנוסף, דפוסי השימוש בדרכים מצביעות על כך שהציפיות למהירות גבוהות יותר.
הדף שבוחרים לבדיקה צריך להיות חלק חשוב במשפך ההמרות. לכל אתר יש מטרה שונה, לכן כל אתר עוקב אחר מדדי הצלחה שונים. המדדים האלה קשורים בדרך כלל למסע של המשתמש, שמנותח באמצעות משפך. לדוגמה, משתמשים באתר מסחר אלקטרוני יצטרכו לנווט דרך דף הבית, דפי קטגוריות, דפי מוצרים ודף תשלום כדי להשלים רכישה. אם אתם מבצעים אופטימיזציה תוך התמקדות בהמרות, אחד מהדפים האלה מומלץ.
לדף צריכה להיות מטרה יחידה. עדיף להימנע משימוש בדף הבית לבדיקה, אלא אם יש לאתר שלכם מטרה ספציפית מאוד. דפי הבית של אתרים מסחריים רבים מהווים פורטלים למגוון רחב של פונקציונליות, שהופכים את הניתוח לרעש. לדוגמה, במקרה שאתם מבצעים אופטימיזציה לצפיות בדף בכל סשן באתר חדשות, ייתכן שעדיף להחריג את החלקים באתר שאינם לשימוש מסחרי ולהתמקד בקטעים ומאמרים שמכילים מונטיזציה.
הדף שנבחר אמור לקבל מספיק תנועה, כך שלא צריך להמתין זמן רב לפני קבלת תוצאה בעלת מובהקות סטטיסטית.
הדף שנבחר צריך להיות איטי יחסית. למעשה, כדאי לאט יותר. המשמעות היא שלא רק שיהיה לכם קל יותר לשפר את הדף, אלא גם שהנתונים יהיו ברורים הרבה יותר. ניתן לך לבצע סריקה מהירה בדוח המהירות של Google Analytics או בדוח מדדי הליבה לבדיקת חוויית המשתמש באתר של מסוף החיפוש כדי לבדוק אילו מהדפים שלך הם האיטיים ביותר.
הדף צריך להיות יציב יחסית. אל תעדכנו את הדפים (כל דבר שישפיע על המדדים העסקיים) עד שהבדיקה תסתיים. ככל שיש פחות גורמים חיצוניים שצריך להביא בחשבון, כך הניתוח יהיה נקי יותר.
על סמך ההוראות שלמעלה, צריך להיות קצת יותר ברור אילו דפים מתאימים לבדיקה. מומלץ להשתמש גם בדפי נחיתה של מודעות, כי סביר להניח שעומדים לרשותכם מדדים עסקיים, בדיקות A/B וניתוחים. אם אתם עדיין לא בטוחים, הנה כמה רעיונות לכל ענף בתעשייה:
- אתרי תוכן: מדורים, מאמרים
- חנויות: דפי קטגוריות, דפי מוצרים
- נגני מדיה: דפי גילוי/חיפוש סרטונים, דף הפעלת סרטון
- שירותים וגילוי (נסיעות, השכרת רכב, רישום שירות וכו'): דף הזנת טופס ראשוני
שלב 2: מדידת הביצועים
יש שתי דרכים כלליות למדידת מדדים: בשיעור Lab ובשדה. באופן אישי, מדידת מדדים בשדה (שנקרא גם Real User Monitoring (RUM) מועילה יותר כי היא משקפת את החוויה של משתמשים אמיתיים. דוגמאות לספריות ולשירותים שיכולים לעזור לכם לדווח על נתוני RUM כוללות בשמים, מעקב אחר ביצועים ב-Firebase ואירועים של Google Analytics.
יש הרבה מדדים לבחירה כי המטרה שלהם היא לתעד היבטים שונים של חוויית המשתמש. חשוב לזכור שהמטרה היא לקבוע בסופו של דבר אם יש קשר ישיר בין המהירות לבין המדדים העסקיים, ולכן כדאי לעקוב אחרי כמה מדדי מהירות כדי לקבוע לאיזה מהם יש את ההתאמה הטובה ביותר להצלחה העסקית. באופן כללי, מומלץ להתחיל עם Core WebVitals. בעזרת הספרייה web-vitals.js אפשר למדוד חלק מהמדדים הבסיסיים של חוויית המשתמש בתחום, אבל חשוב לזכור שהתמיכה בדפדפנים לא עומדת ב-100%. מעבר למדדי הליבה לבדיקת חוויית המשתמש באתר, כדאי לבדוק גם את מדדי הליבה הנוספים לבדיקת חוויית המשתמש באתר. אפשר גם להגדיר מדדים מותאמים אישית, כמו "הזמן שחלף מהקליק הראשון על המודעה".
שלב 3: יוצרים וריאנטים של ביצועי המהירות
בשלב הזה תטמיעו את השינויים כדי ליצור גרסה מהירה יותר של הדף שתיבדק בהשוואה לגרסה הנוכחית.
כמה דברים שחשוב לזכור:
- אין לבצע שינויים כלשהם בממשק המשתמש או בחוויית המשתמש. מלבד העובדה שדף אחד מהיר יותר מהדף השני, המשתמשים לא יוכלו לראות את השינויים.
- גם המדידה היא היבט מרכזי בשלב זה. במהלך הפיתוח, כדאי להשתמש בכלים לבדיקות מעבדה כמו Lighthouse כדי לציין את ההשפעה של השינויים על הביצועים. חשוב לזכור ששינויים במדד אחד יכולים להשפיע לעיתים קרובות על מדד אחר. אחרי שהדפים יתפרסמו, הצמדו ל-RUM כדי לבצע הערכה מדויקת יותר.
יש כמה דרכים ליצור וריאנטים של ביצועים. למטרת הבדיקה, כדאי לעשות זאת בצורה פשוטה ככל האפשר. בהמשך מופיעות כמה אפשרויות.
יצירת דף מהיר יותר
- השתמשו בכלי כמו Squoosh כדי לבצע אופטימיזציה ידנית של התמונות בדף הבדיקה
- שימוש כיסוי הקוד של כלי הפיתוח כדי להסיר באופן ידני JavaScript או CSS שאינם בשימוש רק עבור הדף הזה
- טעינה יעילה של סקריפטים של צד שלישי
- השתמשו בכלי כמו Critical כדי לפצל ולהטמיע CSS קריטי
- הסירו קוד JavaScript לא קריטי שאינו משפיע על חוויית המשתמש, ושניתן לעשות זאת בלעדיו לצורך הבדיקה (לדוגמה, ספריות מסוימות של צד שלישי)
- הטמעה של טעינה מדורגת ברמת הדפדפן שלא נתמכת בכל הדפדפנים, אבל עדיין עשויה לשפר את הביצועים באופן משמעותי במקרים שבהם התכונה נתמכת
- יש להסיר תגים שאינם קריטיים של ניתוח נתונים או לטעון אותם באופן אסינכרוני
תוכלו למצוא אפשרויות נוספות לאופטימיזציה בזמני טעינה מהירים וברשימת המשימות של ביצועי הקצה. אפשר גם להשתמש ב-PageSpeed Insights כדי להפעיל את Lighthouse, שמזהה הזדמנויות לשיפור הביצועים.
האטת הדף
זו עשויה להיות הדרך הקלה ביותר ליצור וריאנטים, וניתן להשיג אותה על ידי הוספת סקריפט פשוט, האטה של זמני התגובה של השרת, טעינת תמונות גדולות יותר ועוד. ה-Financial Times בחר באפשרות הזו כדי לבדוק את ההשפעה של הביצועים על המדדים העסקיים שלהם: ראה A דוח מהיר יותר של FT.com.
האצה של טעינת דפים
במקרים שבהם דף הבדיקה (למשל דף פרטי מוצר) מקושר בעיקר מדף אחר (למשל, דף הבית), שליפה מראש או עיבוד מראש של דף המוצר ישירות מדף הבית של קבוצת הבדיקה יזרזו את הטעינה הבאה של הדף. שימו לב שבמקרה הזה החלוקה של בדיקת ה-A/B (שלב 4) מתבצעת בדף הבית. בנוסף, כל הפעולות האלה עלולות להאט את הטעינה של הדף הראשון, לכן חשוב למדוד זאת ולקחת את זה בחשבון כשמנתחים את תוצאות הבדיקה (שלב 5).
שלב 4: יצירה של בדיקת A/B
אחרי שיוצרים שתי גרסאות של אותו דף, שבה האחת מהירה יותר מהשנייה, השלב הבא הוא פיצול התנועה כדי למדוד את ההשפעה. באופן כללי יש הרבה שיטות וכלים לביצוע בדיקות A/B, אבל חשוב לזכור שלא כל השיטות מתאימות למדידת ההשפעה על ביצועי המהירות.
אם אתם משתמשים בכלי לבדיקת A/B כמו Optimizely או Optimize, מומלץ מאוד להגדיר בדיקה בצד השרת במקום בדיקה בצד הלקוח, כי בדיקות A/B בצד הלקוח בדרך כלל מסתירות את תוכן הדף עד שהניסוי נטען, מה שעלול להטות את המדדים שרוצים למדוד. אם אפשר לבצע רק בדיקה בצד הלקוח, כדאי להגדיר את הניסוי בדף אחר ולשנות את הקישורים לדף הבדיקה כדי לפצל את התנועה. כך דף הבדיקה עצמו לא ייגרר למטה בבדיקה בצד הלקוח.
דוגמה לשינויים בביצועים של בדיקת AB בדף פרטי מוצר נתון (PDP) באמצעות בדיקה בצד השרת:
הבקשה עוברת לקצה העורפי, שמחלקת את המשתמשים לשתי הגרסאות השונות של הדף. באופן כללי זו הגדרה טובה, אבל לעיתים קרובות נדרשים משאבי IT כדי להגדיר את הפיצול בצד השרת.
הנה דוגמה להגדרת בדיקה בצד הלקוח, באמצעות הדף הקודם (דף הבית בתרשים שבהמשך) כדי להריץ את ה-JavaScript לבדיקה:
קוד ה-JavaScript לבדיקה מבצע מניפולציה על הקישור היוצא כדי לספק לשתי קבוצות הבדיקה של המשתמשים קישורים לשתי הגרסאות של דף תיאור המוצר המדובר. קל להגדיר ולתחזק את התכונה הזו באמצעות כלים נפוצים לבדיקות A/B כמו Optimizely או Optimize, והיא לא משפיעה על בדיקת הביצועים כי קוד ה-JavaScript לבדיקה פועל בדף אחר.
לחלופין, אפשר לבחור שני דפים עם התנהגות דומה מאוד וביצועים דומים (לדוגמה, לשני מוצרים דומים מאוד). תוכלו להחיל את השינויים על אחד מהם ולהשוות את ההבדלים בין המדדים לאורך זמן. המשמעות היא שאתם לא עורכים בדיקת A/B מתאימה, אבל היא עדיין יכולה לספק תובנות מועילות.
אם דף הבדיקה משמש כדף נחיתה לקמפיינים פרסומיים, כדאי להשתמש בכלים המובנים לבדיקת A/B של רשת המודעות, כמו בדיקת פיצול של מודעות ב-Facebook או טיוטות וניסויים ב-Google Ads. אם זה לא אפשרי, אפשר להשתמש בשני קמפיינים עם אותה הגדרה ולהגדיר דפי נחיתה שונים כיעדים.
שלב 5: ניתוח של בדיקת A/B
אחרי הרצת הבדיקה מספיק זמן ויש מספיק נתונים כדי להיות בטוחים לגבי התוצאות, הגיע הזמן להרכיב את כל הנתונים ולבצע ניתוח. הדרך לעשות זאת תלויה באופן ההרצה של הבדיקה, לכן נבחן את האפשרויות.
אם הבדיקה בוצעה בדפי נחיתה של מודעות באמצעות הכלים שצוינו למעלה, הניתוח צריך להיות פשוט כמו קריאת התוצאה. אם אתם משתמשים בטיוטות ובניסויים של Google, מומלץ לקרוא את ההשוואה באמצעות ScoreCard.
פלטפורמות כמו Optimizely או Optimize מציעות גם דרכים פשוטות לפרש את התוצאות ולקבוע את מידת ההשפעה של מהירות הפעולה על הדפים שלכם.
אם אתם משתמשים ב-Google Analytics או בכלי דומה, תצטרכו לרכז את הדוח בעצמכם. למרבה המזל, Google Analytics מאפשר ליצור דוחות מותאמים אישית בקלות, וזה השלב שבו כדאי להתחיל. אם שלחתם נתוני מהירות ל-Google Analytics באמצעות מאפיין מותאם אישית, מומלץ לעיין במדריך לדיווח כדי ללמוד כיצד להגדיר את הנתונים האלה ולכלול אותם בדוחות המותאמים אישית. חשוב לוודא שהדוח כולל את התאריך של הניסוי ושהוא מוגדר להציג את שתי הווריאנטים. מה צריך לכלול בדוח הזה?
- בעיקר, עליך לכלול את הערכים העסקיים החשובים לך ביותר: המרות, צפיות בדף, מודעות שנצפו, שיעור המרות, מדדים של מסחר אלקטרוני, שיעור קליקים וכו'.
- בנוסף, מדדים סטנדרטיים אחרים של דפים, שיכולים להתאים גם לשיפור מהירות האתר, הם שיעור העזיבה, משך הביקור הממוצע ואחוז היציאה.
ייתכן שתצטרכו גם לסנן לפי מכשיר נייד ולהקפיד להחריג בוטים ותנועה אחרת שאינה של משתמשים. בניתוח מתקדם יותר יתבצע גם סינון לפי אזור, רשתות, מכשירים, מקור תנועה ופרופילים וסוגים של משתמשים, למשל משתמשים חדשים לעומת מבקרים חוזרים. כל קבוצת משתמשים עשויה להיות רגישה יותר או פחות למהירויות נמוכות יותר, וגם לזהות אותן.
בעזרת Looker Studio (לשעבר Data Studio) או כלים אחרים להצגה חזותית של נתונים, אפשר לשלב בקלות מקורות נתונים שונים, כולל Google Analytics. כך אפשר לבצע בקלות ניתוח נתונים וליצור מרכזי בקרה שאפשר לשתף עם בעלי העניין הרבים שמעורבים בהפעלת אתר מודרני כדי לבצע רכישות נוספות. לדוגמה, האפוטרופוס יצר מערכת התראה אוטומטית שהזהירה את צוות העריכה כאשר תוכן שפורסם לאחרונה חרג מגודל הדף או מסף המהירות שלו, וככל הנראה הוביל למשתמשים לא מרוצים.
שלב 6: הסקת מסקנות והחלטה על השלבים הבאים
אחרי שיהיו לכם נתונים שמקשרים בין ביצועים למדדים עסקיים, תוכלו לבחון את התוצאות ולהתחיל להסיק מסקנות.
אם אפשר לראות בבירור קשר בין שיפור הביצועים לבין שיפור המדדים העסקיים, סכמו את התוצאות ודווחו עליהן לחברה. עכשיו, כשאתם מדברים על ביצועי מהירות ב"שפה עסקית", יש לכם יותר סיכוי למשוך את תשומת הלב של בעלי עניין שונים ולבחון את מהירות האתר של כולם. השלב הבא הוא להגדיר תקציבי ביצועים על סמך התוצאות, ולתכנן עבודה כדי לעמוד בתקציבים האלה. מכיוון שאתם יודעים מה הערך שתפיקו מהעבודה הזו, תוכלו לתעדף בהתאם.
אם לא הצלחת לזהות קורלציה, כדאי לעיין באזהרות הבאות ולבדוק אם צריך להריץ בדיקות דומות במקומות אחרים באתר (למשל, לאורך כל משפך הרכישה או בדף מסוג אחר).
נקודות שיש לשים לב אליהן:
יכולות להיות כמה סיבות לכך שאתם לא מוצאים קשר משמעותי בין מדדי מהירות האתר לבין המדדים העסקיים:
- לדף שנבחר אין מספיק השפעה על המדדים העסקיים שבוחנים. לדוגמה, אם דף התשלום מאוד איטי או לא ידידותי, לדף מוצר מהיר יותר לא תהיה השפעה משמעותית על שיעורי ההמרות. כדאי לבחון מדדים רלוונטיים יותר, כמו שיעורי העזיבה, שיעורי ההוספה לעגלת הקניות או כל מדד אחר שקשור באופן ישיר יותר לדף שבודקים.
- ההבדל במהירות אינו משמעותי מספיק בין שתי הגרסאות. יש להעריך זאת בהתאם למדדי RUM שאתם מודדים.
- קיימת תקלה במנגנון בדיקת ה-A/B. ייתכן שתנועת הגולשים לא מופצת כראוי או שניתוח הנתונים לא מדווח כראוי. כדי לשלול זאת, כדאי להריץ בדיקת A/A שבה בודקים את אותה גרסה של דף באמצעות אותו מנגנון בדיקה, כדי לוודא שאין הבדל בתוצאות.
- מהירות האתר לא משפיעה באמת על המדדים העסקיים. זה מקרה נדיר, אבל יכול לקרות במקרים שבהם שוק היעד שלך פחות רגיש למהירות (למשל, הגישה לאתר מתבצעת בעיקר ממכשירים חזקים ברשת חזקה), או שהביקוש מצד המשתמשים גבוה מאוד והבחירה מוגבלת (למשל, שירות מכירת כרטיסים שמוכר רק כרטיסים למופעים עם ביקוש גבוה). שימו לב: זה לא אומר שאתר מהיר יותר לא ישפר את חוויית המשתמש, אלא משפיע על המוניטין של המותג.
סיכום
אמנם מפתה להשיק אופטימיזציות של מהירות בכל האתר, אבל בטווח הארוך בדרך כלל כדאי יותר להבין קודם מה המשמעות של אתר מהיר יותר למשתמשים ולחברה שלכם. זה ההבדל בין אמירה של "שיפרנו את ה-FCP ב-1.5 שניות" לבין "שיפרנו את ה-FCP ב-1.5 שניות ושיפרנו את שיעורי ההמרות שלנו ב-5%". כך תוכלו לתעדף עבודה נוספת, לשכנע בעלי עניין שונים להפוך את הביצועים של מהירות האתר למאמץ ברמת החברה.