המדד LCP או בשמו המלא Largest Contentful Paint הוא אחד משלושת מדדי הליבה שאנו מכירים כ-Core Web Vitals (לצד INP ו-CLS). הנתון LCP מתאר את הזמן מהרגע בו המשתמש יוזם טעינה של עמוד עד לרגע בו מוצגת למשתמש התמונה, או בלוק הטקסט הגדול ביותר בחלקו העליון הקריטי של המסך.
בכדי לספק חווית משתמש טובה עליכם לשאוף לתוצאת LCP הנמוכה מ-2.5 שניות בלפחות 75% מהצפיות בעמוד. לתוצאות מיטביות, כדאי לשאוף ל-2.0 שניות או פחות.
ישנם מספר גורמים היכולים להשפיע על המהירות בה הדפדפן מרנדר/מעבד עמוד אינטרנטי, והשהייה בכל אחד מאלו תשפיע באופן ישיר ומשמעותי על תוצאת ה-LCP. בואו נראה ממה מורכב ציון ה-LCP ונציג מספר דרכים לשפר נתון זה.
אומר מראש כי נדירים המצבים בהם תיקון מהיר בחלק ספציפי של עמוד יוביל לשינוי משמעותי בתוצאת ה-LCP. בכדי לשפר נתון זה עליכם להתייחס לתהליך הטעינה המלא של העמוד ולוודא כי אתם מבצעים אופטימיזציה לכל שלב ושלב בתהליך זה.
כיצד לזהות את אלמנט ה-LCP
לפני שתוכלו לשפר את ציון ה-LCP, עליכם קודם כל לזהות ולבודד את האלמנט סביבו אתם רוצים לבצע את האופטימיזציה.
ניתן למצוא את אלמנט ה-LCP של כל עמוד בעזרת כלי בדיקת המהירות של גוגל. הכניסו את כתובת ה-URL של העמוד בכלי זה ולחצו על "Analyze".
לאחר ש-PageSpeed מציגה לכם את דוח התוצאות, גללו מטה לחלק הנקרא "Diagnostics", לחצו על "Largest Contentful Paint element" ויוצג לפניכם אלמנט ה-LCP של העמוד:
כפי שציינו, אלמנט ה-LCP יכול להיות כותרת מסוימת, בלוק טקסט כזה או אחר או בהרבה מצבים הוא יכול להיות תמונה מסוימת.
ניתן לראות שאלמנט ה-LCP בעמוד שבדקנו בתמונה מעלה (עמוד הבית של האתר שלי) הוא האלמנט <div class="hero_inner"> והוא אף מסומן במסגרת צהובה.
במקרה של עמוד הבית באתר זה אלמנט ה-LCP הוא אותו
<div>מכיוון שלזה קיימת תמונת רקע (background-image).
ניתן גם להשתמש בתוסף Web Vitals ל-Chrome או בפאנל Performance ב-Chrome DevTools כדי לזהות את אלמנט ה-LCP. פאנל ה-Performance מציג את האלמנט המדויק ואת פירוט התזמון שלו, מה שמועיל לדיבוג.
מציאת אלמנט ה-LCP של העמוד תאפשר לנו להטמיע את טקטיקת האופטימיזציה הנכונה בכדי לשפר ציון ה-LCP. אולי שמתם לב בתמונה מעלה ש-PageSpeed מספקת גם טבלה המספקת מידע כיצד מחושב נתון ה-LCP שלכם. בחלק הבא נדבר בהרחבה על כיצד להבין ולנתח טבלה זו.
מחקרים מראים ששיעורי ההמרה יורדים בכ-12% על כל שנייה של עיכוב ב-LCP. שיפור LCP מ-4.0 שניות ל-2.0 שניות מוביל בדרך כלל לירידה של 15-25% בשיעורי היציאה ועלייה של 8-12% בשיעורי ההמרה.
מספר דרכים לבצע אופטימיזציה למדד LCP
בכדי לדעת כיצד לשפר את נתון ה-LCP באתר שלכם, יש להבין (פחות או יותר) כיצד נתון זה מחושב. הנה טבלה המתארת באחוזים את כל אחד מהגורמים המשפיעים על ציון ה-LCP:
| LCP sub-part | % of LCP |
|---|---|
| Time to first byte | ~40% |
| Resource load delay | <10% |
| Resource load duration | ~40% |
| Element render delay | <10% |
| TOTAL | 100% |
נסביר כעת כיצד ניתן לבצע אופטימיזציה לכל אחד מגורמים אלו. שימו לב כי נציג את ההמלצות לפי סדר חשיבותם כך שאלו שכנראה תהיה להם ההשפעה הגדולה ביותר על נתון ה-LCP יוצגו ראשונות.
למרות שלנתון Time to first byte השפעה גדולה מאוד על ציון ה-LCP אציג אותו אחרון. זאת מכיוון שלמפתחי אתרים בדרך כלל אין שליטה יותר מדי על נתון זה. עוד על TTFB בפוסט הבא.
1. Eliminate Resource Load Delay
בכדי לשפר גורם זה עלינו לוודא שנכס ה-LCP יתחיל להיטען כמה שיותר מוקדם. חוק אצבע במקרה זה הוא לוודא שנכס זה מתחיל להיטען באותו זמן שנטען הנכס הראשון בעמוד.
נכס ה-LCP יכול להיות אחד מהשניים: או שהוא יהיה תמונה או שהוא יהיה בלוק טקסט כלשהו המשתמש בפונט רשת.
אז לענייננו, אם נכס ה-LCP (ה-LCP Resource) מתחיל להיטען זמן מסוים לאחר שנטען הנכס הראשון באתר (First Resource) אז יש מקום לשיפור. התמונות הבאות יכולות להסביר זאת בצורה טובה. הראשונה מתארת מצב בו יש מקום לשיפור ה-Resource Load Delay:
התמונה מתארת מצב בו נכס ה-LCP נטען הרבה לאחר שנטען קובץ ה-CSS ראשון (first resource)
אנו רוצים להגיע כמה שיותר קרוב למצב הבא בו נכס ה-LCP מתחיל להיטען יחד עם הקובץ הראשון שנטען, כלומר יחד עם קובץ ה-CSS המסומן במקרה זה:
נכס ה-LCP מתחיל להיטען במקביל עם קובץ ה-CSS
בכדי לוודא שנכס ה-LCP ייטען כמה שיותר מהר עליכם לוודא שהדפדפן "רואה" נכס זה היישר לאחר תגובת ה-HTML הראשונית (כלומר לאחר הפס הכחול בתמונה הנקרא Document).
למשל, אם אלמנט ה-LCP באתר שלכם הוא בלוק טקסט כלשהו המשתמש בפונט רשת מסוים, עליכם לוודא שהדפדפן מגלה וטוען את אותו פונט ב-HTML Markup מוקדם ככל הניתן, וזאת על ידי טעינת הפונט ב-<head> של האתר באמצעות <link rel="preload">.
תנו מבט בפוסט הבא למידע נוסף על טעינת נכסים מראש באמצעות Preload.
אם אלמנט ה-LCP הוא <img>, הוסיפו fetchpriority="high" ישירות על אלמנט התמונה. זה מסמן לדפדפן שיש לתעדף תמונה זו על פני משאבים אחרים:
<img src="/path/to/hero-image.webp" fetchpriority="high" alt="Hero image" width="1200" height="600">שימו לב ש-fetchpriority="high" שונה מ-loading="eager". בעוד ש-loading="eager" הוא ברירת המחדל לתמונות ופשוט אומר "אל תטען את זה בעצלתיים", fetchpriority="high" אומר באופן אקטיבי לדפדפן לתעדף משאב זה מוקדם יותר בתהליך הטעינה.
במקרים בהם הרפרנס לאלמנט ה-LCP מתבצע מקובץ CSS או קובץ JavaScript חיצוני, למשל סיטואציה בה לאלמנט המדובר קיימת תמונת רקע (background-image) וזו מוגדרת בקובץ CSS חיצוני, יהיה עליכם לטעון אותה תמונה באמצעות <link rel="preload"> אך במקרה זה עם fetchpriority גבוה כבדוגמה הבאה:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
שימו לב! יש לוודא שתמונות LCP לעולם לא נטענות בעצלתיים. הסירו
loading="lazy"מכל תמונה שהיא אלמנט ה-LCP.
וטיפ נוסף ואחרון לסעיף זה – אם קיימות תמונות בחלקו העליון הקריטי של המסך שנטענות מוקדם אך אינן מוצגות ישר למשתמש (במקרים של קרוסלה למשל) – עליכם להוסיף לאלמנט ה-<img> בתמונות אלו את התכונה fetchpriority="low".
2. Eliminate Element Render Delay
המטרה בשלב זה היא לוודא שניתן להציג למשתמש את אלמנט ה-LCP מייד לאחר שהנכס שלו נטען. הסיבה העיקרית שאלמנט ה-LCP יכול להתעכב בהצגה שלו היא שתהליך העיבוד (rendering) של הדפדפן חסום מסיבה כזו או אחרת:
- תהליך העיבוד של העמוד חסום מפאת קבצי CSS או סקריפטים שאינם אסינכרוניים ב-
<head>של העמוד. - נכס ה-LCP הרלוונטי סיים להיטען אך אלמנט ה-LCP עדיין לא התווסף ל-DOM כי הוא ממתין שייטען קוד JavaScript כלשהו.
- האלמנט מוסתר על ידי קוד כלשהו (למשל במצבים של A/B Testing).
- ה-Thread הראשי חסום מפאת משימות JavaScript ארוכות (long tasks).
בחלק הבא נתאר כיצד לגשת למרבית הבעיות הגורמות ל-Element Render Delay.
א. Reduce or inline Render-Blocking Stylesheets
קבצי CSS הנטענים מה-HTML Markup יחסמו את העיבוד של כל התוכן הנמצא אחריהם (דבר חיובי מכיוון שאינכם רוצים להציג HTML ללא עיצוב).
עם זאת, במידה וקובץ ה-CSS הוא קובץ גדול והזמן שלוקח לטעון אותו גבוה משמעותית מהזמן שלוקח לטעון את נכס ה-LCP אז הוא יעכב את העיבוד של אלמנט ה-LCP, וזאת גם במצבים בהם הנכס כבר סיים להיטען.
אני מניח שזה מעט מבלבל אך התמונה הבאה תבהיר את הדברים:
התמונה וה-CSS מתחילים להיטען באותו זמן אך לא ניתן לרנדר את התמונה עד שה-CSS מוכן
בכדי לסדר זאת ניתן לבצע את הפעולות הבאות:
- להכניס את ה-CSS כ-inline ב-HTML.
- להקטין את משקל קובץ ה-CSS.
יש לציין כי inline של ה-CSS מומלץ רק במקרים בהם משקל קובץ ה-CSS הוא קטן מכיוון שתוכן inline ב-HTML אינו נהנה מהיתרונות של זיכרון מטמון (Cache) בביקורים חוזרים.
במרבית המקרים הדרך הטובה ביותר למנוע מקובץ CSS לחסום את העיבוד של הדף היא צמצום גודל הקובץ למצב בו הזמן שלוקח לטעון קובץ זה נמוך יותר מהזמן שלוקח לטעון את נכס ה-LCP.
הנה כמה המלצות בהקשר זה:
- הסירו CSS שאינו נחוץ מהקובץ – השתמשו ב-Chrome Dev Tools בכדי למצוא את חוקי ה-CSS שאינם בשימוש או כאלו שניתן להסיר או לדחות (פוטנציאלית) את הטעינה שלהם.
- עכבו טעינת CSS שאינו קריטי – נסו לפצל את קבצי ה-CSS ולהפריד בין חוקי CSS הנחוצים לטעינת הדף הראשונית וכאלו שניתן לטעון מאוחר יותר (lazy load).
- בצעו מיניפיקציה ודחסו את קובץ ה-CSS – נכון יהיה לצמצם את גודל וזמן ההעברה של כל קבצי ה-CSS, בין אם הקריטיים או אלו שאינם קריטיים.
ב. Defer or inline render-blocking JavaScript
במצבים נדירים בלבד יש צורך להכניס סקריפטים שאינם אסינכרוניים (ללא התכונה defer או async) ב-<head> של עמודי האתר. כל מצב אחר יגרום בוודאות להשפעה שלילית על הביצועים.
במצבים בהם יש צורך לטעון קוד JavaScript מוקדם ככל הניתן יהיה זה נכון להכניס אותו כ-inline script כך שהעיבוד שלו לא יתעכב.
גם במקרה של JavaScript עליכם להכניס אותו כ-inline script רק במקרה שהוא מאוד קטן.
ג. Break up long tasks
שימו לב, גם במקרים שקוד ה-JavaScript אינו מעכב את העיבוד או אינו אחראי לטעינה של אלמנטים כלשהם הוא עדיין יכול לעכב את ה-LCP. סיטואציה זו מתרחשת בדרך כלל כשהעמוד טוען קבצי JavaScript גדולים במיוחד, כאלו שיש לפרוס ולהריץ על ה-thread הראשי של הדפדפן.
במקרה זה, גם אם התמונה למשל ירדה במלואה, העיבוד וההצגה שלה עדיין יתעכבו עד שסקריפט כלשהו יסיים את ההרצה.
דפדפנים בימינו טוענים תמונות על ה-thread הראשי של הדפדפן, כך שאם זה עסוק במשימות אחרות יוביל הדבר להשהייה מיותרת בעיבוד אלמנט ה-LCP.
3. Reduce Resource Load Duration
המטרה בחלק זה היא להקטין בפועל את הזמן שלוקח להעביר את המידע של נכס כלשהו מהרשת לדפדפן של המשתמש. באופן כללי ישנן מספר דרכים לעשות זאת:
- לצמצם את גודל הנכס.
- לצמצם את המרחק שעל הנכס לעבור.
- לבטל "מריבות" בין נכסים הרוצים להיטען.
- ביטול מוחלט של הזמן הנדרש לטעינת הנכס.
נסביר במספר מילים על כל אחת מפעולות אלו:
א. צמצום גודל הנכסים
כפי שציינו נכס ה-LCP של עמוד יהיה אחת מהאופציות הבאות: או שהוא יהיה תמונה או שיהיה בלוק טקסט מסוים המושפע ישירות מזמן הטעינה של פונט כזה או אחר. הנקודות, כמו גם המדריכים הבאים יעזרו לכם להבין כיצד לצמצם את הגודל/המשקל של אלו:
- מניח שמיותר לציין כי עליכם לוודא שהתמונה בגודל הנכון ועברה אופטימיזציה.
- יש להשתמש בפורמט תמונות מודרני כמו WebP או AVIF. פורמט AVIF מציע דחיסה טובה אף יותר מ-WebP ונתמך על ידי כל הדפדפנים המרכזיים.
- השתמשו בתמונות רספונסיביות עם התכונה
srcsetכדי שהדפדפן יטען את התמונה בגודל המתאים למכשיר ולחלון הצפייה של המשתמש, במקום לטעון תמיד את הגרסה הגדולה ביותר. - במקרה של פונטים עדיף שאלו ייטענו לוקאלית מהשרת שלכם.
- בצעו אופטימיזציה לפונטים על ידי יצירת subset הכולל רק את התווים שאתם משתמשים בהם בפועל. זה יכול לצמצם באופן דרמטי את גודל קבצי הפונט.
ב. צמצום המרחק שעל הנכס לעבור
בנוסף לצמצום משקל הנכסים, תוכלו לצמצם את זמן הטעינה שלהם על ידי כך שהשרתים המגישים אלו יהיו קרובים גיאוגרפית למשתמש כמה שניתן. הדרך הטובה ביותר לעשות זאת היא כמובן שימוש ב-Content Delivery Network (CDN).
ג. בטלו "מריבות" בין נכסים
גם אם צמצמתם את הגודל והמרחק הגיאוגרפי של הנכסים מהדפדפן, עדיין ייתכן כי ייקח לנכס ה-LCP זמן רב להיטען אם אתם מנסים לטעון נכסים רבים במקביל.
אם הגדרתם את נכס ה-LCP כעדיפות גבוהה באמצעות fetchpriority, הדפדפן יעשה כמיטב יכולתו למנוע מצב בו הוא מתחרה עם נכסים פחות חשובים לחלקו העליון הקריטי של הדף. למרות הנאמר, אם קיימים הרבה נכסים עם fetchpriority גבוה או שבאופן כללי אתם טוענים המון נכסים אז הדבר עלול להשפיע על המהירות בה נכס ה-LCP ייטען.
ד. בטלו לגמרי את הזמן הנדרש לטעינת הנכס
הדרך הטובה ביותר לצמצם את זמן הטעינה של נכסים היא לבטל באופן מוחלט את הצורך לגשת לשרת בכדי לטעון נכסים אלו.
אם אתם טוענים נכסים עם הגדרות cache-control יעילות, אותם נכסים יוגשו לגולשים שכבר ביקרו באתר שלכם פעם אחת מזיכרון המטמון, דבר המבטל באופן מוחלט את אותו resource load duration עליו דיברנו קודם לכן.
אם נכס ה-LCP שלכם הוא פונט רשת, מעבר לאפשרות לצמצם את גודל הפונט ייתכן שתרצו לשקול אם תרצו שהפונט ייחשב כנכס החוסם טעינה או לא. אם תגדירו את התכונה font-display עם כל ערך שאינו block או auto, אז הטקסט תמיד יופיע במהלך הטעינה וה-LCP לא יתעכב.
שימו לב, להחלטה שלכם לגבי הערך של font-display תהיה השפעה על מדד היציבות החזותית (CLS) ב-Core Web Vitals.
4. צמצמו זמן בייט ראשון (TTFB)
המטרה בחלק זה היא להגיש את ה-HTML הראשוני מהר ככל הניתן. לאותו Time to first byte השפעה גדולה על ציון ה-LCP בפרט ועל זמן טעינת העמוד בכלל, וזאת מכיוון שהוא משפיע ישירות על כל אחד מהשלבים שבאים אחריו.
שום דבר לא יכול להתקדם לפני שהשרת מגיש את ה-byte הראשון של התוכן, כך שכל שיפור ב-TTFB כנראה ישפר כל מדד אחר ב-Core Web Vitals.
לשרת אחסון חזק ואיכותי יש השפעה משמעותית על זמן בייט ראשון בפרט ועל ציון ה-LCP באופן כללי. כתבתי בעבר פוסט מפורט המדבר על מהו וכיצד לשפר את הנתון TTFB באתרים. תנו מבט.
שאלות נפוצות
שאלות נפוצות בנושא Largest Contentful Paint:
לסיכום
הבנה ושיפור ציון ה-LCP באתרים יכול להיות מסובך והתזמון של נתון זה מושפע ממספר גורמים. אך אם תתייחסו לאופטימיזציה של LCP כאופטימיזציה של אלמנט ה-LCP ספציפית ייתכן שזה ייפשט את הדברים.
במבט על, ניתן לסכם את האופטימיזציה לציון ה-LCP בארבע נקודות עיקריות:
- וודאו שנכס ה-LCP נטען מוקדם ככל הניתן.
- וודאו שניתן לעבד ולהציג את אלמנט ה-LCP היישר לאחר שהנכס שלו סיים להיטען.
- צמצמו את זמן הטעינה של נכס ה-LCP ככל שניתן.
- וודאו שהשרת מגיש את ה-HTML הראשוני מהר ככל האפשר.
אם תבצעו פעולות אלו היו בטוחים שאתם מספקים חווית משתמש אופטימלית לגולשים מבחינה זו, ובמקרה זה תגלו במהרה כי ציון ה-LCP של האתר שלכם עולה בהתאם.
