בדיקת מהירות אתר אמינה מתחילה ב-PageSpeed Insights של גוגל, ובדבר אחד שרוב האנשים מפספסים: בדוח יש שני סוגי נתונים. החלק העליון מציג נתוני שטח, כלומר איך משתמשים אמיתיים חוו את העמוד. החלק התחתון מציג נתוני מעבדה, בדיקה אחת בסביבה מדומה. הציון הצבעוני שכולם מסתכלים עליו שייך לחלק של המעבדה.
לכן, לפני שנבהלים מציון אדום, כדאי לבדוק מה המשתמשים שלך חווים בפועל. אחר כך עוברים מדד אחרי מדד, מבינים מה תקוע ומתקנים. ובסוף מודדים שוב, באותו כלי ובאותו עמוד, כדי לדעת אם התיקון עבד.
במאמר הזה ריכזתי סדר עבודה לקריאת הדוח: מה כל מדד אומר, איך מגלים את הבעיה שמאחוריו ואיך מתקנים אותה באתר וורדפרס.
בדיקת מהירות אתר גוגל ב-PageSpeed Insights: נתוני שטח מול נתוני מעבדה
נכנסים ל-PageSpeed Insights, מדביקים כתובת של עמוד ספציפי ומריצים. יש תוצאה נפרדת למובייל ולדסקטופ, וכדאי להתחיל מהמובייל, כי שם התנאים קשים יותר. וכשאתה כבר בודק במובייל, שווה לוודא גם שהעמוד עצמו מוצג שם נכון ולא רק מהר, ועל זה כתבתי במדריך אתר רספונסיבי.
לפי התיעוד של PageSpeed Insights, נתוני השטח מגיעים מ-Chrome User Experience Report (CrUX), והם מסכמים חוויות של משתמשים אמיתיים לאורך 28 הימים האחרונים. נתוני המעבדה מגיעים מ-Lighthouse, שבודק את העמוד בסביבה מדומה: במובייל על מכשיר בינוני ורשת סלולרית, ובדסקטופ על מחשב עם חיבור קווי.
בפועל זה אומר שנתוני השטח לא יזוזו מחר בבוקר אחרי שתתקן משהו, כי הם ממוצע מתגלגל של ארבעה שבועות. נתוני המעבדה כן יזוזו מיד, ולכן בהם בודקים אם תיקון עשה משהו.
- נתוני שטח: מה קרה אצל המבקרים שלך. זה מה שחשוב.
- נתוני מעבדה: ריצה אחת בתנאים קבועים, שמשמשת לאבחון ולהשוואה לפני ואחרי.
התיעוד של web.dev אומר את זה במפורש: כשיש פער, נותנים עדיפות לנתוני השטח, ומשתמשים בנתוני המעבדה כדי למצוא מה לשפר.
עובר או לא עובר את Core Web Vitals
בראש הדוח תראה אם העמוד עובר את הערכת Core Web Vitals. אלה שלושה מדדים, וכל אחד מודד משהו אחר:
| מדד | מה הוא מודד | טוב | גרוע |
|---|---|---|---|
| LCP | כמה זמן עד שהתוכן הגדול ביותר במסך מופיע | עד 2.5 שניות | מעל 4 שניות |
| INP | כמה מהר העמוד מגיב ללחיצה או להקשה | עד 200 מילישניות | מעל 500 מילישניות |
| CLS | כמה התוכן קופץ בזמן הטעינה | עד 0.1 | מעל 0.25 |
לפי ההגדרה ב-web.dev, הערכים נמדדים באחוזון ה-75. במילים פשוטות, כדי שהעמוד ייחשב טוב, לפחות שלושה רבעים מהביקורים צריכים לעמוד ביעד, בנפרד במובייל ובדסקטופ.
לפעמים כתוב בדוח שאין מספיק נתונים. זה קורה באתרים עם מעט תנועה. גוגל מסבירה שכשאין מספיק נתונים לכתובת הספציפית, הכלי עובר לנתונים של כל האתר (origin), ואם גם אלה לא קיימים, נשארים עם נתוני המעבדה בלבד. זה לא אומר שהאתר שבור, רק שאין מספיק ביקורים של משתמשי כרום כדי לבנות תמונה.
LCP איטי, התוכן הראשי מופיע מאוחר
כאן ה-LCP מופיע בכתום או באדום. האלמנט הגדול יכול להיות תמונת הבאנר העליונה, תמונה ראשית או בלוק טקסט גדול. בחלק של האבחון Lighthouse מראה איזה אלמנט נבחר כ-LCP, וכך אתה יודע בדיוק על מה לעבוד.
web.dev מפרק את ה-LCP לארבעה חלקים: זמן עד הבייט הראשון מהשרת (TTFB), העיכוב עד שהדפדפן מתחיל להוריד את התמונה, זמן ההורדה עצמו, והעיכוב עד שהאלמנט מצויר.
לכל חלק יש סיבה ותיקון משלו:
- שרת איטי: בוורדפרס, לפי התיעוד הרשמי, מטמון עמודים הוא הצעד שנותן הכי הרבה תמורה. תוסף מטמון שומר את העמודים כקבצים סטטיים, והשרת לא בונה אותם מחדש בכל ביקור. לא כל תוסף מתאים לכל אתר, ובמדריך תוסף שיפור מהירות יש השוואה בין האפשרויות הנפוצות.
- התמונה הראשית בטעינה עצלה: אם לתמונה העליונה יש
loading="lazy", הדפדפן מחכה איתה. web.dev ממליץ לא להחיל טעינה עצלה על אלמנט ה-LCP, ולתת לוfetchpriority="high". - תמונה כבדה: כאן עוזרות דחיסה ופורמט מודרני. התיעוד של וורדפרס ממליץ על WebP כשאפשר.
- CSS ו-JavaScript שחוסמים את הציור: סקריפטים שלא נחוצים לחלק העליון של העמוד אפשר לדחות.
CLS גבוה, העמוד קופץ
את זה מרגישים גם בלי כלים: אתה מתחיל לקרוא ופתאום הטקסט יורד, או שאתה לוחץ על כפתור ובדיוק אז הוא זז. ב-Lighthouse תראה אילו אלמנטים גרמו לתזוזה.
לפי web.dev, אלה הגורמים הנפוצים והתיקון שלהם:
| הגורם | מה עושים |
|---|---|
| תמונות בלי מידות | מוסיפים width ו-height לתגית התמונה, או aspect-ratio ב-CSS, כדי שהדפדפן ישמור מקום מראש. |
| באנרים, פרסומות והטמעות שנטענות מאוחר | שומרים להם מקום עם min-height. |
| תוכן שמוזרק מעל תוכן קיים | למשל פס הודעה או באנר עוגיות שדוחף את העמוד למטה. |
| גופנים | החלפה בין גופן גיבוי לגופן האתר יכולה להזיז טקסט. אפשר לטעון מראש את הגופן הקריטי ולבחור גופן גיבוי קרוב בגודלו. |
| אנימציות | מנפישים עם transform ולא עם top או left. |
INP גבוה, האתר מגיב לאט ללחיצות
INP מופיע רק בנתוני השטח, כי הוא תלוי באינטראקציה אמיתית של משתמש. בפועל זה נראה כמו תפריט מובייל שנפתח באיחור או כפתור הוספה לסל שלא מגיב מיד.
לפי web.dev, הסיבה העיקרית היא משימות ארוכות שתוקעות את ה-main thread של הדפדפן. בוורדפרס זה בדרך כלל עודף JavaScript מתוספים, מבוני עמודים ומסקריפטים חיצוניים כמו צ'אטים ופיקסלים. ומה שאפשר לעשות:
- לעבור על רשימת התוספים ולהסיר את מה שלא בשימוש. זה גם הצעד הראשון ברשימת האופטימיזציה של וורדפרס.
- לדחות סקריפטים של צד שלישי עד אחרי האינטראקציה הראשונה.
- להקטין את מספר האלמנטים בעמוד (DOM גדול), למשל בעמודים שנבנו בשכבות על גבי שכבות.
ציון הביצועים, ומה הוא לא אומר לך
הציון מ-0 עד 100 הוא ציון מעבדה. לפי גוגל, 90 ומעלה נחשב טוב, 50 עד 89 טעון שיפור, ומתחת ל-50 גרוע.
אבל גוגל לא משתמשת בציון הזה לדירוג. במסמך של גוגל על חוויית עמוד, גוגל כותבת שאין סיגנל יחיד של חוויית עמוד, ושתוצאות טובות בדוח Core Web Vitals או בכלים אחרים לא מבטיחות שהעמוד יופיע בראש התוצאות. היא גם כותבת שהיא תמיד מנסה להציג את התוכן הרלוונטי ביותר, גם אם חוויית העמוד לא מושלמת.
לכן המטרה היא לא 100, אלא ששלושת המדדים יהיו בירוק אצל משתמשים אמיתיים. אם העמוד עובר את Core Web Vitals בנתוני השטח וציון המעבדה 75, לא שווה לשרוף שבוע על עוד כמה נקודות. ואם מעניין אותך איפה מהירות נכנסת לתמונה הרחבה, כתבתי על זה במאמר איך לשפר דירוג בגוגל מהר.
מודדים לפני ואחרי
בדיקת מהירות אתר שווה משהו רק אם יש לה נקודת השוואה. זה הסדר:
- לפני שנוגעים במשהו, מריצים PageSpeed Insights על אותם עמודים (בית, עמוד שירות, עמוד מוצר) ושומרים צילום מסך של נתוני השטח ושל נתוני המעבדה.
- משנים דבר אחד בכל פעם. אם הפעלת חמש הגדרות ביחד והאתר נשבר, לא תדע מה שבר אותו.
- מנקים את המטמון של התוסף ושל ה-CDN, ומריצים שוב. נתוני המעבדה ישתנו מיד. כדאי להריץ כמה פעמים, כי תוצאות מעבדה משתנות מעט בין ריצה לריצה.
- נתוני השטח יתעדכנו בהדרגה לאורך חלון של 28 ימים.
במקביל כדאי לפתוח את דוח Core Web Vitals ב-Search Console. הוא מבוסס על אותם נתונים של משתמשים אמיתיים, מקבץ כתובות דומות לקבוצות ומציג אותן לפי טוב, טעון שיפור וגרוע. אחרי תיקון אפשר לבקש מהדוח לאמת אותו, ותהליך המעקב נמשך 28 ימים.
מתי לעצור ולקרוא למומחה
- ה-TTFB גבוה גם אחרי שהפעלת מטמון עמודים. זה בדרך כלל עניין של שרת, אחסון או קוד בצד השרת. לפעמים הפתרון האמיתי הוא לא עוד תוסף אלא שדרוג של האחסון עצמו, ועל זה כתבתי במדריך שרת בענן.
- הפעלת אופטימיזציה של CSS או JavaScript וחלק מהאתר נשבר, למשל תפריט שלא נפתח, טופס שלא נשלח או סליידר ריק.
- INP גרוע באתר שנבנה עם הרבה תוספים, ואתה לא יודע איזה מהם אחראי.
- האתר הוא חנות, וכל שינוי בעמוד המוצר או בקופה עלול לפגוע בהזמנות.
בכל המקרים האלה, לפני שמשנים משהו באתר חי, עושים גיבוי מלא.
שאלות נפוצות
באיזה כלי לעשות בדיקת מהירות אתר?
PageSpeed Insights של גוגל, כי הוא מציג באותו מסך גם נתוני שטח של משתמשים אמיתיים וגם נתוני מעבדה מ-Lighthouse. בשביל התמונה של כל האתר לאורך זמן, תשתמש בדוח Core Web Vitals ב-Search Console.
למה הציון שלי משתנה בכל פעם שאני בודק?
הציון מבוסס על ריצת מעבדה אחת, ותנאי הרשת והשרת משתנים מעט בין ריצות. גם אצלי מדד Speed Index, שמודד כמה מהר העמוד מתמלא בתוכן, קופץ בין ריצות בלי ששיניתי שום דבר באתר. לכן מריצים כמה פעמים ומסתכלים על המגמה, ולא על ריצה בודדת.
אם עשית בדיקת מהירות אתר, עברת על השלבים והמדדים עדיין לא זזים, או שתיקון שבר משהו באתר, אני יכול לטפל בזה בשבילך.