אתר מהיר לפי מדדי גוגל נדרש להציג את התוכן המרכזי שלו תוך 2.5 שניות, להגיב ללחיצה תוך 200 מילישניות, ולשמור על יציבות עיצובית עם ציון שלא עולה על 0.1. המספרים האלה אינם המלצה תאורטית אלא תנאי מעבר מדויקים שנמדדים באחוזון ה-75 של כלל הגולשים שלכם, בהפרדה בין מכשירי מובייל ומחשבים. אם עשרים ושבעה אחוזים מהמבקרים שלכם מחכים יותר מ-2.5 שניות לתמונה הראשית, הדף נכשל בהערכה.
בדיקות מעבדה משקרות לעיתים קרובות.
כשאתם מריצים בדיקה בכלי כמו PageSpeed Insights, מקבלים שני סוגי נתונים שונים בתכלית. החלק התחתון של הדוח מציג נתוני מעבדה באמצעות כלי Lighthouse בסביבה מבוקרת וסינתטית. הציון הכללי מ-0 עד 100 נשען על המעבדה הזו בלבד, שבה ציון 90 ומעלה נחשב טוב, 50 עד 89 דורש שיפור, ומתחת ל-50 נחשב גרוע. גוגל קובע מעבר לפי נתוני שטח אמיתיים שנאספים מתוך Chrome User Experience Report לאורך עשרים ושמונה ימים. דף שמקבל ציון 95 במעבדה יכול להציג חוויה כושלת אצל גולשים עם מכשירים חלשים או גלישה סלולרית איטית.
שלושת מדדי הליבה של גוגל
שלושת המדדים שמגדירים את חוויית הליבה נקראים Core Web Vitals, וכל אחד מהם בוחן פן נפרד במפגש של הגולש עם הדף. המדד הראשון הוא LCP, שמודד את משך הזמן מרגע תחילת הטעינה ועד שאלמנט הטקסט או התמונה הגדול ביותר בתוך המסך מוצג במלואו. המדד השני הוא INP, שבודק את מהירות התגובה של הדף לכל פעולת לחיצה, הקשה במסך או הקלדה שמתרחשת לאורך כל זמן השהות באתר. המדד השלישי הוא CLS, שסוכם את תזוזות המבנה הבלתי צפויות שמתרחשות בזמן רינדור האלמנטים.
נתוני Chrome מראים כי 90 אחוז מזמן השהות של הגולש מתרחש לאחר סיום הטעינה הראשונית של הדף. זו הסיבה שגוגל החליפה את מדד FID הישן, שמדד רק את עיכוב הקלט הראשון, במדד INP שבוחן את כל מחזור החיים של הדף. INP בוחן לחיצות עכבר, נגיעות במסך מגע והקשות מקלדת, אך מתעלם מפעולות גלילה או תנועת עכבר רגילה. עבור אתרים עם מספר אינטראקציות גבוה במיוחד, המערכת מתעלמת מאינטראקציה חריגה אחת לכל 50 אינטראקציות כדי למנוע עיוותים סטטיסטיים מקריים.
כדי לעבור את ההערכה של גוגל, עליכם לקבל ציון טוב בכל שלושת המדדים יחד באחוזון ה-75 של המשתמשים. מספיק שמדד בודד מבין השלושה ייפול לקטגוריית Needs Improvement כדי שהדף ייכשל בהערכה הכוללת. כאשר אין מספיק נתונים עבור INP, גוגל מאשר את הדף אם LCP ו-CLS נמצאים בטווח התקין. אם חסרים נתונים עבור LCP או CLS ברמת הכתובת הבודדת, גוגל בודק את נתוני כלל הדומיין כולו.
פירוק זמני הטעינה של LCP
זמן LCP מתפרק לארבעה מקטעים מדויקים שאינם חופפים: זמן קבלת הבייט הראשון מהשרת המכונה TTFB, עיכוב בטעינת המשאב, משך הורדת המשאב, ועיכוב ברינדור האלמנט. הבעיה הנפוצה ביותר מתחילה בתמונות ענק שלא הומרו לפורמטים מודרניים כמו WebP או AVIF. אם תמונת ה-LCP שלכם שוקלת כמה מגה-בייט, משך הורדת המשאב מתארך ופוגע בציון באופן ישיר.
זה לא תמיד עוזר.
כיווץ תמונות בלבד לא פותר בעיות שנובעות מתלויות בקוד. אם התמונה הראשית נטענת דרך קובץ JavaScript חיצוני ולא מופיעה ישירות בקוד ה-HTML הראשוני, הדפדפן מחכה לסיום הורדת הסקריפטים לפני שהוא בכלל מגלה את הצורך בהורדת התמונה. במצב כזה, שיפור משקל הקובץ מקצר רק את זמן ההורדה אך מעביר את כל הזמן שנחסך אל שלב עיכוב הרינדור, וזמן ה-LCP הכולל נשאר ללא שינוי.
מדד TTFB מודד את הזמן מרגע שהגולש לחץ על הקישור ועד שהדפדפן קיבל את הבייט הראשון של מסמך ה-HTML מהשרת. טווח תקין של TTFB עומד על 800 מילישניות ומטה, כאשר ערך מעל 1800 מילישניות מוגדר כגרוע. עיכובים בשרת נגרמים לרוב עקב הפניות מרובות, שרת אחסון שמרוחק פיזית מהגולשים, תנאי רשת ירודים או חוסר יכולת לנצל תוכן שמור בזיכרון מטמון. כאשר השרת שלכם איטי ומספק TTFB של שנייה וחצי, כמעט בלתי אפשרי לעמוד ביעד LCP של 2.5 שניות.
לא הייתי נוגע בתמונות לפני תיקון שרת איטי.
| מדד ביצועים | טווח תקין (Good) | דורש שיפור | גרוע (Poor) |
|---|---|---|---|
| LCP | עד 2.5 שניות | 2.5 עד 4.0 שניות | מעל 4.0 שניות |
| INP | עד 200 מילישניות | 200 עד 500 מילישניות | מעל 500 מילישניות |
| CLS | עד 0.1 | 0.1 עד 0.25 | מעל 0.25 |
| TTFB (ניסיוני) | עד 800 מילישניות | 800 עד 1800 מילישניות | מעל 1800 מילישניות |
| FCP | עד 1.8 שניות | 1.8 עד 3.0 שניות | מעל 3.0 שניות |
ניתוח פערים בין מדדי התצוגה
היחס בין מדד FCP שמודד מתי מופיע התוכן הראשוני על המסך לבין מדד TTFB חושף חסימות קריטיות. יעד FCP תקין עומד על 1.8 שניות ומטה, כאשר ערך מעל 3.0 שניות נחשב גרוע. פער גדול בין TTFB לבין FCP מצביע על כך שהדפדפן נאלץ להוריד קבצים רבים שחוסמים רינדור, כמו קובצי CSS וסקריפטים כבדים, לפני שהוא מסוגל להציג אפילו צבע רקע או כותרת עליונה.
פער משמעותי בין FCP לבין LCP מראה שאלמנט ה-LCP אינו זמין לדפדפן באופן מיידי בעת קריאת ה-HTML, או שהדפדפן עמוס בביצוע משימות אחרות לפני שהוא מתפנה להציג את התוכן הראשי. מצב כזה אופייני לאתרים שנשענים בכבדות על רינדור בצד הלקוח באמצעות סקריפטים מורכבים. כשאתם בוחנים את הדוח, כדאי לכם לבודד את הפערים האלה כדי לדעת אם הבעיה נובעת מתקשורת רשת או מעומס חישובי בדפדפן עצמו.
סדר פעולות לאופטימיזציה של הדף
- בדיקת נתוני שטח ב-PageSpeed Insights
- איתור אלמנט ה-LCP במפל הבקשות
- המרת תמונות לפורמט WebP או AVIF
- הקדמת טעינת התמונה ישירות ב-HTML
- חלוקת משימות ארוכות להפחתת עומס INP
כדי למדוד את חוויית המשתמש באופן עצמאי באפליקציות שלכם, ניתן להשתמש בספריית הקוד הרשמית web-vitals שנבנתה על ידי GoogleChrome וזמינה ב-GitHub. הספרייה משתמשת בממשקי הדפדפן כדי לאסוף את נתוני LCP, INP ו-CLS ישירות אצל הגולשים. שליחת הנתונים לשרת הניתוח שלכם מתבצעת באמצעות קריאת JavaScript פשוטה שמשתמשת בממשק navigator.sendBeacon, או בנתיב חלופי דרך קריאת fetch רגילה במקרה הצורך.
דפי בית נוטים להיות איטיים יותר מדפים פנימיים מכיוון שגולשים חדשים מגיעים אליהם ללא קבצים שמורים בזיכרון המטמון. כאשר אתם מנתחים ביצועים בכלי PageSpeed Insights, בדקו אם הדוח מציג נתונים ברמת כתובת הדף הבודדת או ברמת הדומיין המלא כדי לזהות אם הבעיה מקומית או מערכתית.
מקורות
- web.devhttps://web.dev/articles/vitals
- web.devhttps://web.dev/articles/optimize-lcp
- developers.google.comhttps://developers.google.com/speed/docs/insights/v5/about
- web.devhttps://web.dev/articles/inp
המדריך נכתב מהמקורות שלמעלה בתאריך הפרסום. מחירים ותנאים משתנים; לפני החלטה כספית בודקים מול המקור. מצאתם טעות? כתבו.