Field vs Lab Data: למה רוב הוויכוחים על Core Web Vitals נכשלים
רוב הוויכוחים על ביצועים מתרחשים בגלל שאנשים משתמשים במאגרי נתונים לא נכונים.
אדם אחד מסתכל על תוצאות של משתמשים אמיתיים. אחר מסתכל על סימולציה במעבדה. שניהם צודקים. שניהם עונים על שאלות שונות.
אם אינכם יכולים להגדיר מהו מאגר הנתונים שלכם, אתם לא מבצעים אבחון. אתם פשוט מתווכחים.
הבינו את ההבדל:
- נתונים מהשטח (Field data) אומרים לכם אם משתמשים אמיתיים נתקלים בבעיות בקנה מידה רחב. הם כוללים טלפונים איטיים וקליטה סלולרית גרועה.
- נתונים במעבדה (Lab data) אומרים לכם למה הם נתקלים בבעיות. הם מספקים traces מבוקרים ובדיקות שניתן לשחזר.
מדדי Core Web Vitals כמו LCP, INP ו-CLS הם מדדי תוצאה. הם אומרים לכם מה קרה, לא למה.
הפסיקו להשתמש בממוצעים. השתמשו באחוזון ה-75. אתר יכול להרגיש מהיר עבורכם אך עדיין להיכשל, כיוון שאחוזון ה-75 לוקח בחשבון רשתות איטיות ומכשירים חלשים.
השתמשו ברצף הזה כדי לפתור בעיות ביצועים:
- נתונים מהשטח: אישור קיומו של הבעיה ומציאת ההיקף שלה.
- נתונים במעבדה: בידוד סיבה שניתן לבדוק.
- נתונים מהשטח: אימות התיקון מול הראיות המקוריות שלכם.
התאימו את הטענות שלכם לראיות:
- אם משתמשים נתקלים בבעיות: בדקו מגמות ב-Search Console.
- אם התבנית (template) היא הגורם: חפשו כשלים בכתובות URL דומות.
- אם LCP איטי בגלל השרת: השתמשו ב-lab traces כדי למצוא תגובות מסמך מאוחרות.
- אם INP נכשל: השתמשו ב-DevTools כדי למצוא משימות ארוכות (long tasks).
- אם גרסה חדשה גרמה לנסיגה (regression): קשרו בין הזמנים לבין ה-deploy logs שלכם.
אל תסתמכו על הרצה בודדת של Lighthouse. אל תשתמשו בבדיקות דסקטופ כדי להסביר כשלים בנייד. אל תשתמשו ב-"זה מרגיש מהיר יותר" כהוכחה.
פעלו לפי הצעדים הבאים:
- הגדירו את מאגר הנתונים שלכם במשפט אחד.
- אשרו את ההיקף. הניחו שמדובר בבעיית תבנית עד שתפריכו זאת.
- זהו את המגבלה. האם זה השרת, נתיב הרינדור (render path), או צד שלישי?
- הריצו את הבדיקה הקטנה ביותר האפשרית כדי להפריך את התיאוריה שלכם.
השתמשו בנתונים במעבדה כדי למצוא את צוואר הבקבוק. השתמשו בנתונים מהשטח כדי להוכיח שצוואר הבקבוק נעלם.