מה עליך למדוד כדי לשפר את הביצועים?

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

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

במדריך הזה נסביר איך ניתן למדוד את השלבים השונים. לכן מומלץ לעיין בנתוני שיעור ה-Lab והשטח.

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

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

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

קמפיינים מסוג Discovery

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

מבחינת המשתמש, המדדים החשובים ביותר הם:

• הצגת תוכן ראשוני (FCP): המצב שבו המשתמש מסתכל על מסך ריק. במצב כזה, רוב המשתמשים יוצאים מדף הכניסה, כי הם לא רואים את ההתקדמות.
• הצגת התוכן העיקרי (FMP): כשהמשתמש מתחיל לראות את התוכן העיקרי שעבורו הוא הגיע. לרוב זוהי התמונה הראשית (Hero), אבל אם מדובר בדף נחיתה, זו יכולה להיות גם קריאה לפעולה, כמו לחצן Buy (קנייה), כי ייתכן שהמשתמש הגיע עם כוונה ברורה (לדוגמה, דרך קמפיין פרסום ממוקד).
• השהיה לאחר קלט ראשוני (FID): המועד שבו האתר צריך להגיב לקלט הראשון של המשתמש. יותר מדי בעיות של JavaScript ובעיות אחרות בטעינת נכסים יכולות לחסום את הבעיה, ולגרום להקשות או לקליקים שנכשלו, לקלט שגוי ולנטישת דף.

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

מעורבות והמרה

לאחר הטעינה הראשונה של דף נחיתה, משתמש ימשיך לבקר באתר, בתקווה להמרה מוצלחת.

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

יש שתי דרכים נוחות לעשות זאת:

WebPageTest

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

• מבקשים מ-WebPageTest לעבור בין הדפים בתהליך העבודה באמצעות הפקודה navigate.
• במקרה הצורך, תוכלו לכתוב סקריפט על ידי לחיצה על הלחצנים באמצעות clickAndWait פקודות ומילוי שדות טקסט דרך setValue. כדי לבדוק אפליקציות בדף יחיד צריך להשתמש בפקודות clickAndWait במקום בפקודות navigate לכל השלבים שאחרי הראשון, כי navigate יבצע טעינה מלאה במקום טעינת דף וירטואלית קלה.
• הקפידו לשלב בניתוח את השלבים השונים של התהליך דרך combineSteps, כדי להפיק דוח תוצאה כולל אחד עבור התהליך המלא.

סקריפט כזה יכול להיראות כך:

combineSteps
navigate    https://www.store.google.com/landingpage
navigate    https://www.store.google.com/productpage
clickAndWait    innerText=Buy Now
navigate    https://www.store.google.com/basket
navigate    https://www.store.google.com/checkout

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

בובנית

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

כמדד, ניתן למדוד ישירות את משך הזרימה, אבל אפשר גם לסכם את ערכי ה-FCP, FMP או TTI של הטעינות הנפרדות של הזרימה. בדיקת ביצועי האתר באמצעות Puppeteer – סקירה כללית של קבלת מדדי ביצועים דרך Puppeteer. דוגמה פשוטה מאוד לסקריפט צומת יכולה להיראות כך:

const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  const start = performance.now();
  await page.goto('https://www.store.google.com/landingpage');
  await page.goto('https://www.store.google.com/productpage');
  // click the buy button, which triggers overlay basket
  await page.click('#buy_btn');
  // wait until basket overlay is shown
  await page.waitFor('#close_btn');
  await page.goto('https://www.store.google.com/basket');
  await page.goto('https://www.store.google.com/checkout');
  console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
  await browser.close();
})();

אפשר לבצע את הסקריפט הזה בקלות, ואפילו להפוך אותו לחלק מתהליך ה-build או מתקציבים לביצוע, ולעקוב אחריו באופן קבוע.

מעורבות חוזרת

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

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

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

Recap

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