SpeedCurve משלב ניטור משתמשים אמיתיים עם בדיקות סינתטיות שניתן לחזור עליהן, כדי לזהות אילו מבקרים חווים עמודים איטיים ולבדוק מה השתנה. הוא מתאים לאתרים שצריכים לאבחן ביצועים באופן שוטף בין גרסאות, תבניות עמוד ומכשירים. תפקידו לספק בסיס להחלטות: התקנת סקריפט ניטור אינה משפרת כשלעצמה את מדדי Core Web Vitals.
מה SpeedCurve מוסיף לתהליך בדיקת הביצועים
בדיקת מעבדה מתארת עמוד בתנאים שנבחרו מראש. ניטור משתמשים אמיתיים, המכונה RUM, מודד ביקורים בזמן שאנשים משתמשים באתר בפועל. SpeedCurve מציע את שתי הגישות. התיעוד שלו מתאר לוח Vitals שמשלב תוצאות סינתטיות עם נתוני RUM כאשר האיסוף פעיל, לצד תצוגות מפורטות יותר לחקירת הביצועים.
פלטפורמת ניטור הביצועים של SpeedCurve רלוונטית כאשר כתובת בדיקה אחת כבר אינה מייצגת היטב את האתר. אתר תוכן עשוי להזדקק להפרדה בין תבניות כתבה לעמודי קטגוריה. חנות עשויה להזדקק להפרדה בין איתור מוצרים לתהליך הרכישה. אלה חוויות שונות, גם כשהן חולקות דומיין ומערכת עיצוב.
התיעוד של SpeedCurve מתאר גם תוויות עמודים, תקציבי ביצועים ותצוגות של פריסות גרסה. יחד הם יכולים לתמוך בתהליך שבו הצוות מזהה קבוצת עמודים שנפגעה, בודק גרסה ומתעד את הטיפול הנדרש. הם אינם מוכיחים שהפריסה האחרונה גרמה לכל תנועה בגרף. עדיין צריך לבדוק שינויים בהרכב המבקרים ובאיסוף הנתונים.
הגדירו קבוצות עמודים שימושיות לפני איסוף נתוני הבסיס
התחילו בשאלות שהצוות יכול לפעול לפיהן. באתר תוכן אפשר לבדוק אם תבנית הכתבה טוענת את התמונה הראשית בזמן ואם התפריט בנייד מגיב באופן אמין. תוכנית הניטור הראשונית צריכה לזהות את התבניות, המכשירים והאינטראקציות החשובות. אוסף גדול של מדדים מועיל פחות כשאין אחראי למשימות שעולות ממנו.
SpeedCurve משתמש כברירת מחדל בכותרת המסמך כתווית העמוד ב-RUM. הדבר עלול ליצור פירוט רב מדי: כל כותרת כתבה יכולה להפוך לקבוצה נפרדת. השירות מתעד כללי כתובות ו-API של JavaScript להקצאת תוויות. בחרו תוויות תבנית יציבות כאשר המטרה היא להשוות התנהגות של עמודים דומים רבים.
התאימו בין התוויות של הבדיקות הסינתטיות לבין תוויות RUM. SpeedCurve מציין במפורש שהתאמה זו נדרשת לחיבור בין מערכי הנתונים בלוחות הרלוונטיים. בדקו כתובות מייצגות לפני הרחבת ההטמעה. עמוד מוצר שסווג בטעות עם תוצאות חיפוש יכול ליצור גרף שנראה סביר, אך השוואה שאינה מועילה.
תעדו את כללי התיוג יחד עם ההטמעה. לפי SpeedCurve, שינוי תוויות אינו מסווג מחדש צפיות שכבר נאספו. אם משנים את הקבוצות באמצע בדיקה, יש להתייחס לכך כשינוי במדידה. רשמו מתי התרחש השינוי ואל תציגו את המגמה שנוצרה כהשוואה רציפה של אותה אוכלוסייה.
קראו את מדדי Core Web Vitals יחד עם הגדרת האוכלוסייה
Google מגדירה מדדי Core Web Vitals טובים כ-LCP של 2.5 שניות או פחות, INP של 200 מילישניות או פחות ו-CLS של 0.1 או פחות, לפי האחוזון ה-75. LCP עוסק בטעינה, INP בתגובתיות ו-CLS ביציבות חזותית. הספים מסייעים לסווג את החוויה, אך אינם אומרים איזה שינוי בהטמעה יפתור את הבעיה.
לכן דוח ניטור שימושי מציין איזו אוכלוסייה נמדדה. כללו את קבוצת העמודים, סוג המכשירים, תקופת הדיווח וגודל המדגם הזמין. אחוזון של עמודי מוצר בנייד ואחוזון של האתר כולו בכל המכשירים עונים על שאלות שונות. השוואתם כאילו היו שקולים עלולה להסתיר דווקא את הבעיה שמנסים למצוא.
היעזרו במדריך הספים של Core Web Vitals לפירוש הערכים, ואז חזרו לפלח שנפגע. בדקו את ההתפלגות לצד האחוזון. שינוי בהרכב הביקורים יכול לשנות תוצאה מצרפית גם בלי שינוי בתבנית עצמה.
נתון חסר דורש הסבר
היעדר מדידה אינו מעיד על עמידה בדרישה. לפני הסקת מסקנה, ודאו שהאיסוף פעל ושהדפדפן, מחזור חיי העמוד והתנהגות המבקר אפשרו לדווח על המדד.
השתמשו בבדיקות סינתטיות לחקירת בעיה שנמצאה בשטח
נתוני שטח מזהים חוויה שכדאי לבדוק. בדיקה מבוקרת מקלה לבחון הסבר מוצע. ההבחנה חשובה כאשר האיטיות מופיעה רק במכשירים מסוימים, לאחר אינטראקציה מסוימת או במצב עמוד שבדיקת ניווט בסיסית אינה מגיעה אליו.
המדריך לנתוני שטח ולנתוני מעבדה מסביר מדוע המדידות עשויות להיות שונות. התיעוד של SpeedCurve מציע תצוגות נפרדות לחקירת נתונים סינתטיים ו-RUM. השתמשו בהן כראיות משלימות. אל תחשבו ממוצע משותף ואל תתארו הרצה סינתטית אחת כחוויה של כלל המבקרים.
לפני שינוי באתר, כתבו השערה קצרה. השערה להמחשה יכולה להיות שתבנית כתבה חדשה גורמת לדפדפן לגלות את התמונה הראשית מאוחר יותר. זהו הסבר מוצע, לא ממצא. בחרו עמוד מייצג ובדקו את טעינת המשאבים בתנאים קבועים לפני שינוי ממוקד ואחריו.
לאחר מכן חזרו ל-RUM. השוו את אותה קבוצת עמודים ואותו פלח מכשירים לאורך תקופת תצפית מתאימה, תוך בדיקה אם הרכב המבקרים השתנה. אם הבדיקה המבוקרת השתפרה אך ההתפלגות המקבילה בשטח לא השתנתה, חקרו את הפער. ייתכן שהעמוד שנבדק, הגרסה שהוגשה, מצב ההסכמה או פלח התנועה אינם מייצגים את הביקורים שעדיין דורשים טיפול.
הפכו תקציב ביצועים למשימה עם אחראי
SpeedCurve מתעד תקציבי ביצועים ותצוגות שמקשרות בין פריסות מתועדות לשינויים בביצועים. הם מועילים רק כאשר הצוות מסכים מה יקרה בהמשך. הגדירו מי מקבל ממצא, אילו ראיות דרושות לו וכיצד יבחין בין נסיגה בעקבות גרסה לבין תנודות רגילות.
רישום הבדיקה יכול להישאר קצר. כללו את התבנית שנפגעה, המדד, פלח המכשירים, הפריסה הרלוונטית, תנאי ההשוואה והאחראי לבדיקת ההשערה. לאחר הבדיקה הוסיפו החלטה: לתקן, לחזור לגרסה קודמת, להמשיך לחקור או לסגור עם הסבר. אל תתייחסו להתראה כהוכחה לסיבה.
בבעיות תגובתיות, זהו את האינטראקציה עצמה. דוח שאומר רק "INP איטי" משאיר לאדם הבא לחזור על עבודת האיתור. ציינו אם העיכוב קשור לפתיחת ניווט, לסינון רשימה או לשליחת טופס. המדריך לשיפור INP יכול לסייע להפוך את התצפית לבדיקה של העבודה בתהליכון הראשי ושל הרינדור.
בחרו תקופת תצפית שמתאימה לתנועה הזמינה בפלח. תבנית עם מעט ביקורים עשויה להזדקק לזמן נוסף לפני שההתפלגות שלה תאפשר השוואה שימושית. אל תיצרו ודאות מלאכותית באמצעות מספר מדויק יותר או גרף ממוקד יותר. ציינו כשהראיות עדיין דלות והשאירו את הבדיקה פתוחה לאיסוף נוסף.
העריכו את האיסוף, את העבודה השוטפת ואת המגבלות
לפני אימוץ SpeedCurve, ודאו שיש מי שיכול להתקין ולתחזק את שילוב RUM, לנהל הרשאות ולחקור ממצאים. בדקו את התנאים המסחריים העדכניים לנפח האיסוף המתוכנן, לצורכי הבדיקות הסינתטיות ולתקופות השמירה. השאלה היא אם השירות תומך בהחלטות שהצוות צריך לקבל בעלות שוטפת סבירה.
בדקו אילו נתונים ההטמעה שולחת בפועל. SpeedCurve מתעד את סוגי הנתונים שהוא אוסף ותומך בנתונים מותאמים. בדקו כתובות, תוויות עמודים וערכים מותאמים לפני ההרחבה, כדי שלא תישלח בטעות אינפורמציה שלא התכוונתם להעביר. התאימו את האיסוף למנגנוני הפרטיות וההסכמה באתר, בלי להניח שתיאור כללי של הספק פותר כל שאלה בהטמעה מסוימת.
הטמעת RUM מוסיפה גם תלות לעמוד. בדקו שהיא נטענת כמתוכנן, שאינה מופיעה פעמיים דרך שילובים שונים ושהיא נשארת לאחר שינוי תבניות. אם האיסוף מתחיל רק לאחר הסכמה, זכרו שהביקורים הנצפים מייצגים את תנאי האיסוף הזה. תעדו זאת לצד הדוחות המשמשים להשוואת גרסאות.
SpeedCurve אינו יכול לשכתב יישום איטי, לתקן אסטרטגיית טעינת תמונות או להבטיח דירוגים בחיפוש. הנתונים שלו אינם חייבים להיות זהים ל-Chrome User Experience Report של Google, משום שאוכלוסיות האיסוף ושיטות הדיווח שונות. התייחסו לפערים כשאלות לבדיקה, ולא כהוכחה שאחד המקורות תקול.
בצעו פיילוט שמסתיים בהחלטה
בחרו תבנית חשובה אחת, בדיקה סינתטית מייצגת וקבוצת RUM עם תיוג ברור. קבעו נתוני בסיס, חקרו בעיה מוגדרת ותעדו אם הראיות הובילו לשינוי מועיל. השתמשו ברשימת הבדיקות לביצועי אתר כדי לשמור על מעקב אחר הבדיקות הטכניות ומשימות ההמשך.
בסיום הפיילוט בחנו את תהליך העבודה לצד הגרפים. האם הצוות יכול לזהות מי נפגע, לשחזר סיבה סבירה ולוודא מה קרה לאחר שינוי? אם התשובה עדיין אינה ברורה, שפרו את הקבוצות או את תהליך החקירה לפני הרחבת האיסוף לכל האתר.
תוכן שותפים. מאמר זה עוסק ב-SpeedCurve ומתפרסם בנפרד מהסיקור המערכתי של WebVitalsDev.
