נתוני שטח מול מעבדה: למה תוצאות PageSpeed שונות

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

ציון Lighthouse ירוק אינו מוכיח שהמבקרים עומדים ב-Core Web Vitals. בדיקה סינתטית איטית אינה מבטלת תוצאות שטח טובות. קודם הגדירו מה כל מספר מייצג. המדריך למתחילים מסביר את המדדים; כאן נסביר מדוע המדידות שונות.

להתחיל באוכלוסייה ובשאלה

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

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

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

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

לא להפוך אחוזון לממוצע

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

הספים הטובים הם LCP עד 2.5 שניות, INP עד 200 אלפיות שנייה ו-CLS עד 0.1. בדקו נייד ומחשב בנפרד. מחשב טוב אינו מפצה על בעיה בנייד; הספים עצמם זהים.

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

ההשוואה של Google בין שטח למעבדה מספקת את ההקשר. צרפו תמיד למדד את האחוזון ואת האוכלוסייה.

לבדוק אם הנתונים שייכים לכתובת המדויקת

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

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

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

אם חסרה מדידה ל-URL, הציגו את המגבלה ואת ההקשר הכללי בנפרד. מדריך דוח PageSpeed Insights מסביר היכן בודקים את ההבחנה.

להבין מה ההאטה מדמה ומה לא

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

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

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

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

לחקור את המדד שמסביר את הפער

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

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

ב-INP בדקו פעולות. ניווט רגיל של Lighthouse אינו מספק את התפלגות INP האמיתית של CrUX. TBT יכול להצביע על עומס בשרשור הראשי בזמן טעינה, אבל אינו תחליף. כלים אינטראקטיביים מבוקרים כן יכולים למדוד השהיית תגובה; המגבלה היא התרחיש והכיסוי.

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

להתחשב בחלון המתגלגל לאחר פרסום

CrUX ב-PSI מכסה את 28 הימים הקודמים ומתעדכן מדי יום. מיד אחרי תיקון, חלק ניכר מהחלון עדיין מתאר את הגרסה הישנה. המעבדה העדכנית והשטח ההיסטורי עונים לשאלות זמן שונות.

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

גם הרכב הקהל משתנה. קמפיין שמביא רשתות איטיות יותר יכול לשנות את ההתפלגות למרות שיפור בקוד. השוו קבוצות כשהניטור מאפשר זאת והכירו באי-הוודאות כשאין פירוט.

להוסיף RUM כשהנתונים המצטברים אינם מגלים את הסיבה

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

הספרייה הרשמית web-vitals מטפלת בפרטים חשובים של מחזור החיים. בפרויקט שמתקין ואורז אותה, המודול הבא רושם מדדים נתמכים מקומית, ללא שליחה לשרת.

import {onCLS, onINP, onLCP} from 'web-vitals';

function reportMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    rating: metric.rating,
    navigationType: metric.navigationType
  });
}

onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);

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

RUM לא חייב להיות זהה ל-CrUX. כיסוי דפדפנים, דגימה, הסכמה, הגדרות ניווט ו-iframes יכולים להיות שונים. השתמשו בגרסת attribution כשנדרש פירוט נוסף, ובדקו מה היא כוללת לפני העברה.

להשתמש בכל תוצאה להחלטה שהיא מאפשרת

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

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