מדריך מפורט שמסביר איך לפרק את LCP ולזהות את התחומים העיקריים שצריך לשפר.
תאריך פרסום: 30 באפריל 2020, תאריך עדכון אחרון: 31 במרץ 2025
Largest Contentful Paint (LCP) הוא אחד משלושת מדדי Core Web Vitals, והוא מייצג את המהירות שבה נטען התוכן העיקרי של דף אינטרנט. באופן ספציפי, מדד LCP מודד את הזמן שחולף מהרגע שבו המשתמש מתחיל לטעון את הדף ועד שהתמונה או בלוק הטקסט הגדולים ביותר מעובדים באזור התצוגה.
כדי לספק חוויית משתמש טובה, באתרים צריך לשאוף להשיג LCP של 2.5 שניות או פחות לפחות ב-75% מהביקורים בדפים.
יש כמה גורמים שיכולים להשפיע על המהירות שבה הדפדפן יכול לטעון דף אינטרנט ולהציג אותו, ועיכובים בכל אחד מהגורמים האלה יכולים להשפיע באופן משמעותי על ה-LCP.
נדיר שתיקון מהיר של חלק אחד בדף יוביל לשיפור משמעותי של ה-LCP. כדי לשפר את מדד ה-LCP, צריך לבדוק את כל תהליך הטעינה ולוודא שכל שלב בדרך מותאם בצורה אופטימלית.
הסבר על מדד LCP
לפני שמבצעים אופטימיזציה של LCP, מפתחים צריכים להבין אם יש להם בעיה שקשורה ל-LCP, ואם כן, מה היקף הבעיה.
אפשר למדוד את LCP בכמה כלים, אבל לא כולם מודדים את LCP באותה דרך. כדי להבין את מדד ה-LCP של משתמשים אמיתיים, צריך לבדוק את החוויה של משתמשים אמיתיים, ולא את מה שמוצג בכלי מבוסס-מעבדה כמו Lighthouse או בבדיקות מקומיות. הכלים האלה מבוססי-מעבדה ויכולים לספק מידע רב שיעזור לכם להבין את מדד ה-LCP ולשפר אותו, אבל חשוב לזכור שבדיקות מעבדה בלבד לא תמיד מייצגות באופן מלא את חוויית המשתמשים בפועל.
אפשר להציג נתוני LCP שמבוססים על משתמשים אמיתיים באמצעות כלים לניטור משתמשים אמיתיים (RUM) שמותקנים באתר, או באמצעות הדוח על חוויית המשתמש ב-Chrome (CrUX), שבו נאספים נתונים אנונימיים ממשתמשי Chrome אמיתיים עבור מיליוני אתרים.
שימוש בנתוני LCP של CrUX בכלי הפיתוח ל-Chrome
בחלונית Performance של כלי הפיתוח ל-Chrome מוצגת חוויית ה-LCP המקומית לצד מדד ה-LCP של הדף או המקור מ-CrUX בתצוגת המדדים בזמן אמת, ובתובנות של מעקב ביצועים, כולל פירוט של תזמוני חלקי ה-LCP (שנסביר עליהם בהמשך).
הוספת נתוני שדות לחלונית הביצועים מאפשרת להעריך אם יש בדף בעיות LCP שמשפיעות על משתמשים אמיתיים, ולהתאים את הגדרות הסביבה המקומית כדי לשחזר ולפתור את הבעיות האלה בצורה טובה יותר.
שימוש בנתוני LCP מ-CrUX ב-PageSpeed Insights
בקטע העליון של הכלי PageSpeed Insights, שנקרא רוצה נתונים על החוויה של המשתמשים באתר בפועל?, אפשר לגשת לנתוני CrUX. נתונים מפורטים יותר שמבוססים על בדיקות מעבדה זמינים בקטע התחתון שכותרתו אבחון בעיות בביצועים. אם נתוני CrUX זמינים לאתר שלכם, תמיד כדאי להתמקד קודם בנתונים של משתמשים אמיתיים.
ב-PageSpeed Insights מוצגים עד ארבעה סוגים שונים של נתוני CrUX:
- נתוני נייד עבור כתובת ה-URL הזו
- נתוני מחשב עבור כתובת ה-URL הזו
- חבילת גלישה לכל Origin
- נתוני מחשב לכל המקור
אפשר להחליף ביניהם באמצעות אמצעי הבקרה בחלק העליון ובפינה השמאלית העליונה של הקטע הזה. אם אין מספיק נתונים לגבי כתובת URL כדי להציג אותה ברמת כתובת ה-URL, אבל יש נתונים לגבי המקור, ב-PageSpeed Insights תמיד יוצגו נתוני המקור.
הערך של LCP עבור כל המקור עשוי להיות שונה מאוד מהערך של LCP של דף ספציפי, בהתאם לאופן הטעינה של LCP בדף הזה בהשוואה לדפים אחרים במקור הזה. הוא יכול להיות מושפע גם מהאופן שבו המבקרים מגיעים לדפים האלה. משתמשים חדשים נוטים לבקר בדפי הבית, ולכן יכול להיות שהם נטענים לעיתים קרובות 'בטעינה קרה', ללא תוכן שנשמר במטמון, ולכן הם לרוב הדפים הכי איטיים באתר.
העיון בארבע הקטגוריות השונות של נתוני CrUX יכול לעזור לכם להבין אם בעיית LCP ספציפית לדף הזה, או שמדובר בבעיה כללית יותר באתר. באופן דומה, אפשר לראות אילו סוגי מכשירים סובלים מבעיות LCP.
שימוש במדדים משלימים של CrUX ב-PageSpeed Insights
כדי לבצע אופטימיזציה של LCP, מומלץ גם להשתמש בנתוני התזמון של הצגת תוכן ראשוני (FCP) ושל הזמן עד לבייט הראשון (TTFB). אלה מדדים טובים לאבחון שיכולים לספק תובנות חשובות לגבי LCP.
המדד TTFB הוא הזמן שחולף מרגע שהמבקר מתחיל לנווט לדף (למשל, לחיצה על קישור) ועד לרגע שמתקבלים הבייטים הראשונים של מסמך ה-HTML. זמן גבוה עד לבית הראשון (TTFB) יכול להקשות על השגת LCP של 2.5 שניות, או אפילו למנוע אותה.
זמן גבוה עד לבייט הראשון יכול להיות תוצאה של הפניות אוטומטיות רבות בשרת, מבקרים שנמצאים רחוק משרת האתר הקרוב ביותר, מבקרים עם תנאי רשת גרועים או חוסר יכולת להשתמש בתוכן שנשמר במטמון בגלל פרמטרים של שאילתות.
אחרי שהדף מתחיל לעבור עיבוד, יכול להיות שיוצג צבע הרקע, ואחריו יופיע תוכן מסוים (למשל כותרת האתר). המדד 'הצגת תוכן ראשוני (FCP)' מודד את המועד שבו התוכן הראשוני מופיע. ההבדל בין FCP לבין מדדים אחרים יכול לספק מידע רב.
פער גדול בין TTFB ל-FCP יכול להצביע על כך שהדפדפן צריך להוריד הרבה נכסים שחוסמים את העיבוד. יכול להיות גם שזה סימן לכך שהאתר צריך לבצע הרבה עבודה כדי להציג תוכן משמעותי כלשהו – סימן קלאסי לאתר שמסתמך במידה רבה על עיבוד בצד הלקוח.
פער גדול בין FCP ל-LCP מצביע על כך שמשאב ה-LCP לא זמין באופן מיידי לדפדפן כדי לתת לו עדיפות (לדוגמה, טקסט או תמונות שמנוהלים על ידי JavaScript ולא זמינים ב-HTML הראשוני), או שהדפדפן מבצע עבודה אחרת לפני שהוא יכול להציג את תוכן ה-LCP.
שימוש בנתוני Lighthouse של PageSpeed Insights
הקטע Lighthouse בכלי PageSpeed Insights מציע כמה הנחיות לשיפור LCP, אבל קודם צריך לבדוק אם ערך ה-LCP שמוצג תואם במידה רבה לנתוני משתמשים אמיתיים שסופקו על ידי CrUX. אם יש הבדלים בין התוצאות של Lighthouse ו-CrUX, סביר להניח ש-CrUX מספק תמונה מדויקת יותר של חוויית המשתמש. לפני שפועלים לפי נתוני CrUX, חשוב לוודא שהם מתייחסים לדף ולא למקור המלא.
אם גם ב-Lighthouse וגם ב-CrUX מוצגים ערכי LCP שדורשים שיפור, הקטע Lighthouse יכול לספק הנחיות חשובות לשיפור ה-LCP. כדי להציג רק ביקורות שרלוונטיות ל-LCP, משתמשים במסנן LCP באופן הבא:
בנוסף להזדמנויות לשיפור, יש גם מידע לאבחון שיכול לספק מידע נוסף שיעזור לנתח את הבעיה. בכלי האבחון Largest Contentful Paint element מוצג פירוט שימושי של משכי הזמן השונים שמרכיבים את ה-LCP:
סוגי המשאבים של LCP וחלקי המשנה שלהם זמינים גם ב-CrUX.
בקטעים הבאים נתעמק בחלקים האלה.
פירוט של LCP
אופטימיזציה של LCP יכולה להיות משימה מורכבת יותר אם הכלי PageSpeed Insights לא מספק תשובה לשאלה איך לשפר את המדד הזה. במשימות מורכבות, בדרך כלל עדיף לפצל אותן למשימות קטנות יותר וקלות יותר לניהול, ולטפל בכל אחת מהן בנפרד.
בקטע הזה מוצגת מתודולוגיה לפירוק של LCP לחלקים משניים קריטיים ביותר, ולאחר מכן מוצגות המלצות ספציפיות ושיטות מומלצות לאופטימיזציה של כל חלק.
בדרך כלל, טעינה של דף כוללת מספר בקשות לרשת, אבל כדי לזהות הזדמנויות לשיפור ה-LCP, כדאי להתחיל בבדיקה של שתי בקשות בלבד:
- מסמך ה-HTML הראשוני
- משאב ה-LCP (אם רלוונטי)
בקשות אחרות בדף יכולות להשפיע על ה-LCP, אבל שתי הבקשות האלה – במיוחד הזמנים שבהם מתחיל ומסתיים השימוש במשאב ה-LCP – חושפות אם הדף שלכם עבר אופטימיזציה ל-LCP.
כדי לזהות את משאב ה-LCP, אפשר להשתמש בכלים למפתחים (כמו PageSpeed Insights שדיברנו עליו קודם, כלי הפיתוח ל-Chrome או WebPageTest) כדי לקבוע את רכיב ה-LCP. משם אפשר להתאים את כתובת ה-URL (שוב, אם רלוונטי) שנטענה על ידי האלמנט בתרשים מפל של הרשת של כל המשאבים שנטענו על ידי הדף.
לדוגמה, בתרשים הוויזואלי הבא מוצגים המשאבים האלה כשהם מודגשים בתרשים של טעינת דף אופיינית, שבו רכיב ה-LCP דורש בקשת תמונה כדי לבצע רינדור.
