קראו דוח PageSpeed Insights בשלושה מעברים: זהו את היקף נתוני השטח ואת המדד הבעייתי, בחנו את בדיקת המעבדה ובחרו אבחון שמסביר את הבעיה. הערכת השטח וציון Lighthouse עונים לשאלות שונות. עיגול ירוק בחלק אחד אינו מבטל בעיה בחלק אחר.
התחילו בכתובת ציבורית שמייצגת את הדף שתרצו לשפר. ודאו לאן היא מופנית ובחרו נייד או מחשב. שמרו את תנאי הבדיקה לפני שינוי, כדי להשוות בהמשך אותו דף ואותה אסטרטגיה.
לוודא קודם את הדף ואת תנאי הבדיקה
בדיקה שהושלמה יכולה עדיין לתאר את החוויה הלא נכונה. בדקו הפניות, תוכן מוחזר, הגבלות גישה, הגנת בוטים ודפי שגיאה. דף אימות מהיר אינו הוכחה שמאמר נטען מהר.
בחרו תבניות מייצגות ולא רק דף בית. מאמר, קטגוריה, מוצר וחיפוש יכולים להשתמש במשאבים שונים. התחילו בבעיה ידועה ובדקו עוד דוגמאות לפני שסוגרים תיקון משותף.
רשמו תאריך, מכשיר וכתובת סופית; שמרו גם גרסת Lighthouse וסביבה. שמות וקבוצות הבדיקות יכולים להשתנות, ולכן עדיף להבין את מטרת החלק ולא להסתמך על צילום ממדריך ישן.
הסקירה הרשמית של PageSpeed Insights מסבירה את השילוב בין שטח למעבדה. הדוח הוא התחלת אבחון, לא הוראה ליישם כל המלצה בלי שיקול דעת.
לקרוא את המשתמשים האמיתיים לפני ציון המעבדה
CrUX מתאר ביקורי Chrome שעומדים בתנאי ההכללה לאורך 28 הימים הקודמים ומתעדכן מדי יום. בדקו אם מוצגת הכתובת המדויקת או ה-origin כולו.
origin מורכב מפרוטוקול, שם מארח ופורט ויכול לכלול תבניות רבות. הנתון שלו אינו מוכיח שאותו מאמר מציג אותה התפלגות. שמרו את תווית ההיקף כשמשתפים צילום או מעתיקים מדד.
LCP עוסק בטעינה, INP בתגובתיות ו-CLS ביציבות. באחוזון 75, טוב פירושו LCP עד 2.5 שניות, INP עד 200 אלפיות שנייה ו-CLS עד 0.1. CLS אינו זמן. אל תחברו או תמצעו יחידות שונות.
כשיש די נתונים לשלושתם, כולם צריכים להיות טובים כדי לעבור. PSI מאפשר הערכה על בסיס LCP ו-CLS כאשר INP חסר. כשאין די נתונים ל-LCP או ל-CLS, אי אפשר להעריך. INP חסר אינו אפס ואינו תוצאה טובה שנמדדה.
להבין פסי התפלגות ומדדים נוספים
הפסים מייצגים שיעור חוויות טובות, טעונות שיפור וגרועות. הם אינם אחוז המשאבים שעברו בדיקה. p75 הוא אחוזון של ביקורים, לא ממוצע חשבוני.
דף היפותטי יכול להציג p75 טוב ועדיין זנב איטי ברור. ייתכן שכדאי לחקור אזור, מכשיר או תבנית בניטור שלכם. הפס הציבורי עצמו אינו מגלה את הסיבה.
FCP ו-TTFB יכולים להופיע כמדדי טעינה נוספים, אך אינם עוד Core Web Vitals. בית ראשון מאוחר יכול לעכב את ההמשך, אבל אינו מוכיח שצריך שרת גדול יותר. חקרו הפניות, חיבורים, עבודת יישום ומטמון.
שמרו יחידות בהעברה לגיליון או למשימה. ערבוב אלפיות שנייה ושניות יכול להיראות כמו נסיגה עצומה שאינה קיימת. אל תוסיפו ״ms״ ל-CLS.
להפריד בין נייד למחשב
המתג משנה את אסטרטגיית המעבדה ואת סוג המכשיר בנתוני השטח. מכשיר אמיתי שונה מהסימולציה, אך שניהם יכולים לחשוף בעיה שמחשב חזק מסתיר. אל תמצעו ציונים לציון אתר כללי.
גם הפריסה משנה: תמונת פתיחה אחרת, כותרת גבוהה, תפריט מוסתר או רכיב שונה. כשה-LCP משתנה, זהו את האלמנט הגדול בכל גרסה לפני החלטה על תמונה או שרת.
בדקו מסלולים חשובים בכל סוג. פריסה שמתאימה למסך יכולה עדיין להכיל תפריט איטי או מודעה קופצת. רספונסיביות של CSS ותגובתיות של INP אינן אותו דבר.
מדריך Core Web Vitals למתחילים מחבר את המדדים לחוויה. שמרו נקודות התחלה נפרדות כדי ששיפור בצד אחד לא יסתיר נסיגה בשני.
לקרוא Lighthouse כסיכום מעבדה
החלק האבחוני מריץ Lighthouse בתנאים מוגדרים. הציון נע בין 0 ל-100: 90 ומעלה טוב, 50 עד 89 דורש שיפור ומתחת ל-50 גרוע. אלה אינם הספים של מדדי השטח.
הציון משקלל ציוני מדדים. המלצות מסייעות באבחון, אבל תיקון בדיקה אינו מעניק מספר נקודות קבוע. השוו גרסה, תנאים וזמנים בודדים לצד העיגול.
שינוי זמן קטן יכול להזיז ציון, ותיקון מועיל יכול להשאיר את המספר המעוגל ללא שינוי. בדקו אם המדד השתפר באופן עקבי ואם האתר עדיין פועל נכון.
קטגוריות נגישות, שיטות עבודה ו-SEO כוללות בדיקות מוגבלות אחרות. SEO גבוה אינו הבטחת דירוג, וציון נגישות אוטומטי אינו ביקורת מלאה. הסבירו את ההיקף לבעל אתר שאינו מפתח.
לחבר מדד לשאלת האבחון
הרצת ניווט מודדת טעינה ו-CLS בתקופת התצפית. היא עלולה לפספס תזוזות מאוחרות ואינה מספקת התפלגות INP בשטח. פעולות צריכות בדיקה אינטראקטיבית מתאימה.
הטבלה מסייעת לבחור חקירה בלי להחליף בין מדדים.
| מדידה | במה היא מסייעת | מה אינה מוכיחה |
|---|---|---|
| LCP | אספקה וציור של התוכן הגדול | תגובתיות של פעולות מאוחרות |
| CLS | תזוזות שנצפו בבדיקה | יציבות לאחר סיום הבדיקה |
| FCP | מועד הצגת תוכן ראשון | שהתוכן המרכזי מוכן |
| TBT | חסימת השרשור הראשי בזמן הטעינה | את ערך INP בשטח |
| Speed Index | התקדמות השלמת התצוגה | מעבר עצמאי של Core Web Vitals |
עם TBT גבוה, בחנו משימות ארוכות והרצת סקריפטים. עם INP גרוע, שחזרו הקלדה, תפריטים ושינוי אפשרויות. TBT יכול לתת רמז, אבל אסור לתייג אותו INP.
כש-CLS בשטח ובמעבדה שונים, האריכו את ההקלטה ובדקו תוכן מאוחר. מדריך שטח מול מעבדה מסביר את הפער לפני שמחליטים שאחד הדוחות שגוי.
לתעדף אבחונים לפי המדד שהם מסבירים
פתחו את התובנות הרלוונטיות למדד הבעייתי. השמות יכולים להשתנות, אך השאלות נשארות: מה עיכב גילוי, העברה או ציור, מה חסם את השרשור ומה שינה את הפריסה?
ב-LCP עקבו אחר האלמנט במפל הבקשות. תמונה יכולה להתגלות מאוחר, להמתין לעדיפות אחרת או לסיים הורדה לפני שהדפדפן פנוי להציגה. תקנו את השלב הדומיננטי ולא רק את מספר הבתים.
במשאבים חוסמי ציור, הבחינו בין מה שנדרש בתחילה למה שאפשר לדחות. דחייה גורפת יכולה לשבור תלות או להציג תוכן בלי עיצוב. מדריך משאבים חוסמי רינדור מסביר את הבחירה.
חיסכון משוער הוא תוצאת מודל לתרחיש הזה, לא הבטחה לכל משתמש. המלצות חופפות יכולות לטפל באותו צוואר בקבוק; אל תחברו אותן להבטחת חיסכון כולל. בצעו שינוי מוצדק ובדקו מחדש.
להפוך ממצא למשימה שניתן לשחזר
משימה טובה כוללת דף, מכשיר, מדד, ראיה ורכיב לשינוי. צרפו בקשה או סקריפט רלוונטיים במקום דוח שלם עם ״להפוך לירוק״. הוסיפו בדיקה תפקודית כדי שלא יאשרו תיקון באמצעות הסרת תכונה חיונית.
למשל, משימת תמונה יכולה לבקש גילוי ב-HTML הראשוני ובדיקת המשאב הרספונסיבי שנבחר. הקבלה תכלול LCP ותצוגה תקינה בכמה רוחבים. זו דוגמת תהליך, לא אבחון של האתר שלכם.
תעדפו רכיבים משותפים כשהראיות תומכות בכך. סקריפט כותרת רחב יכול להיות חשוב מקישוט יחיד, אך צבעים דומים אינם מוכיחים אותה סיבה. שמרו אפשרות חזרה לשינויי רינדור ויישום.
להבחין בין הסיבות לחוסר נתונים
כתובת חדשה, מעט תצפיות או היעדר גילוי ציבורי יכולים להשאיר דף ללא שטח. origin נותן הקשר ואינו משלים את המדידה החסרה. יישום פרטי דורש גישה אחרת.
גם אינטגרציית API עלולה לא לספק שטח בגלל שינוי תגובה, תצורה או שגיאה. הפרידו בין ״אין רשומת CrUX״, ״הבקשה נכשלה״ ו״האינטגרציה אינה מחזירה שטח״. אלה אינם אותו מצב אדום.
המשיכו בבדיקות מתאימות ושקלו RUM שמכבד פרטיות. אל תמציאו אחוזון מהרצה אחת ואל תהפכו ערך חסר למעבר.
להשתמש ב-API עם אסטרטגיה וטיפול בשגיאות
API v5 מספק ניתוח Lighthouse תכנותי. הפקודה מבקשת את קטגוריית הביצועים לכתובת ציבורית לדוגמה ושומרת JSON. נדרש curl; גישה לשירות, מכסות והגדרות פרויקט עדיין חלות.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.jsonלאוטומציה הגדירו מפתח ומכסות לפי Google. אל תחשפו מפתחות לא מוגבלים בקוד דפדפן. בדקו HTTP ושגיאות JSON לפני קריאת lighthouseResult; שמרו מועד, כתובת סופית, גרסה והגדרות.
Google מודיעה על כוונה להפסיק לכלול CrUX ב-API הזה וממליצה על CrUX API או CrUX History API. אל תבנו מערכת חדשה בהנחה שהשדות loadingExperience ו-originLoadingExperience יישארו תמיד. הפרידו איסוף מעבדה ושטח וטפלו במפורש בשדות חסרים.
תוצאת API אינה מעניקה רשות לבדוק כתובות פרטיות. הימנעו מכתובות עם אסימונים או מידע אישי. שירות ציבורי צריך לאמת יעדים ולהגן מפני שימוש לרעה בשרת.
לבדוק שוב אחרי שינוי משמעותי ולעקוב אחר המגמה
חזרו על בדיקות תואמות אחרי שינוי ממוקד ושמרו מדדים בודדים. בדקו גם את הפעולה שהושפעה. הרצות תכופות ללא שינוי מראות בעיקר שונות, ואינן יוצרות ביקורים בחלון השטח.
בחנו מדידות חדשות ואת המגמה הציבורית כשביקורים נכנסים לחלון 28 הימים. רשמו גרסאות ושינויים בקהל. עקביות בכמה תרחישים מועילה יותר מהרצה מוצלחת במיוחד.
פתחו את מנתח PageSpeed כשהוא פעיל, והמשיכו למדריכי מהירות דפים לפי הסיבה. סיימו בפעולה מדידה, אחראי ותנאי לבדיקה חוזרת, ולא ברשימת אזהרות בלתי מוסברות.
