יכול להיות קשה לשפר את הצגת חלק התוכן הגדול ביותר (LCP) של דף, כי לרוב יש צורך לבצע מספר פעולות שונות ולמצוא איזון בין גורמים שונים. בפוסט הזה נסקור נתוני שטח מהטעינות האמיתיות של דפים באינטרנט, כדי לקבוע איפה המפתחים צריכים למקד את מאמצי האופטימיזציה שלהם.
עצה קלאסית בנושא LCP: כדאי להקטין את גודל התמונות.
ברוב הדפים באינטרנט, אלמנט ה-LCP הוא תמונה. לכן, הגיוני להניח שהדרך הטובה ביותר לשפר את ה-LCP היא לבצע אופטימיזציה של התמונה של ה-LCP.
בחמש השנים בערך מאז ההשקה של LCP, זו הייתה לרוב העצה העיקרית. חשוב לוודא שהתמונות בגודל המתאים ובדחיסה מספקת, ורצוי להשתמש בפורמט תמונה מהמאה ה-21. ב-Lighthouse יש אפילו שלושה בדיקות שונות שמאפשרות להציע את ההצעות האלה.
חלק מהסיבה לכך שהעצה הזו נפוצה כל כך היא שקל למדוד בייטים מיותרים וקל להציע כלים לדחיסת תמונות. בהתאם לצינורות עיבוד הנתונים ל-build ולפריסה, יכול להיות שגם יהיה קל להטמיע את הכלי.
אם כן, כדאי לעשות זאת. כמעט תמיד כדאי לשלוח פחות בייטים למשתמשים. יש הרבה אתרים באינטרנט שעדיין מציגים תמונות גדולות מדי שלא נדרשות, ואפשר לפתור את הבעיה הזו גם באמצעות דחיסה בסיסית.
עם זאת, כשהתחלנו לבדוק את נתוני הביצועים בשטח של משתמשים ב-Chrome כדי לראות איפה בדרך כלל מתבצע הזמן עד ל-LCP, גילינו שזמן ההורדה של התמונות כמעט אף פעם לא מהווה את צוואר הבקבוק.
במקום זאת, חלקים אחרים של LCP הם בעיה גדולה הרבה יותר.
פירוט של חלקי משנה של LCP
כדי להבין איפה נמצאות ההזדמנויות הגדולות ביותר לשיפור ה-LCP, בדקנו את הנתונים מהחלקים המשניים של ה-LCP, כפי שמתואר במאמר אופטימיזציה של LCP.
כל דף וכל מסגרת עשויים להשתמש בגישה שונה לטעינת התוכן שיהפוך לרכיב ה-LCP של הדף ולהצגתו, אבל אפשר לחלק כל אחד מהם לחלקי משנה הבאים:
לפי המאמר הזה, החלקים המשניים הם:
- זמן עד בייט ראשון (TTFB)
- הזמן מהרגע שבו המשתמש מתחיל את הטעינה של הדף ועד שהדפדפן מקבל את הבייט הראשון בתגובה של מסמך ה-HTML.
- עיכוב בטעינת המשאבים
- הזמן שחלף מ-TTFB ועד שהדפדפן התחיל לטעון את משאב ה-LCP. אם אלמנט ה-LCP לא דורש טעינה של משאבים כדי להציג, הזמן הזה הוא
0. - משך הטעינה של משאבים
- משך הזמן שלוקח לטעון את משאב ה-LCP עצמו. אם לאלמנט LCP לא נדרש טעינת משאב כדי להציג אותו, הזמן הזה הוא
0. - עיכוב בעיבוד הרכיב
- הזמן שחלף בין סיום טעינת המשאב של LCP לבין הזמן שבו רכיב LCP עבר רינדור מלא.
נתוני ביצועים אמיתיים של ניווט
| דירוג LCP | TTFB (אלפיות שנייה) | עיכוב בטעינת התמונה (אלפיות השנייה) | משך הטעינה של התמונה (אלפיות השנייה) | השהיית רינדור (אלפיות השנייה) |
|---|---|---|---|---|
| טוב | 600 | 350 | 160 | 230 |
| דרוש שיפור | 1,360 | 720 | 270 | 310 |
| גרועה | 2,270 | 1,290 | 350 | 360 |
במאמר הזה השתמשנו בנתונים מניתוחים של ניווט בדפים עם LCP של תמונה של משאב משנה ב-Chrome, כדי לבחון את החלקים המשניים של LCP. בדקנו נתונים מהסוג הזה בעבר, אבל אף פעם לא מנתוני שדה כדי לראות איפה משתמשים אמיתיים מבלים את הזמן שלהם בזמן ההמתנה ל-LCP של דף.
כמו במדדי הליבה לבדיקת חוויית המשתמש באתר, לקחנו את האחוזון ה-75 (p75) של כל חלק משנה של LCP לכל מקור במערך הנתונים של CrUX, וכתוצאה מכך נוצרו ארבעה פיזורים של ערכי p75 (אחד לכל חלק משנה). כדי לסכם את הפלטפורמות האלה, לקחנו את החציון של הערכים האלה בכל המקורות לכל אחד מארבעת החלקים המשניים של LCP.
לבסוף, אנחנו מפצלים את מקורות הנתונים לקטגוריות על סמך זמן הטעינה של רכיב ה-LCP באחוזון ה-75: 'טוב', 'דרוש שיפור' או 'גרוע'. כך תוכלו להבין מה ההבדל בין מקור עם LCP טוב לבין מקור עם LCP נמוך.
האם כדאי להקטין את גודל התמונה של LCP? הפעם עם נתונים
משך הטעינה הוא המדד של משך הזמן שנדרש לאחזור משאב ה-LCP, במקרה הזה תמונה. הזמן הזה בדרך כלל יחסי למספר הבייטים בתמונה, ולכן כל ההמלצות לשיפור הביצועים מתמקדות בהקטנת מספר הבייטים.
כשבודקים את הזמן שחולף בתרשים הקודם, דבר אחד בולט: לא הרבה זמן עובר בזמן טעינת התמונה. למעשה, זהו החלק הקצר ביותר ב-LCP בכל הקטגוריות של LCP. משך הטעינה ארוך יותר במקורות עם LCP נמוך בהשוואה למקורות עם LCP גבוה, אבל עדיין לא שם מתבצע רוב הזמן.
רוב מקורות הנתונים עם LCP נמוך משקיעים פחות מ-10% מזמן ה-LCP החציוני (p75) שלהם בהורדת תמונת ה-LCP.
כן, כדאי לוודא שהתמונות שלכם עברו אופטימיזציה, אבל זו רק אחת מהדרכים לשיפור ה-LCP. בנוסף, ברור מהנתונים האלה שלמקור טיפוסי באינטרנט, השיפורים הפוטנציאליים ב-LCP בסך הכול הם קטנים, לא משנה כמה מורכבת תוכנית הדחיסה.
עוד הפתעה: בעבר, משך הטעינה הארוך היה בדרך כלל תוצאה של מכשירים ניידים ואיכות הרשתות הניידות. בעבר, יכול להיות שהייתם מצפים שתהליך ההורדה של אותה קובץ אימג' בטלפון רגיל יימשך פי כמה יותר זמן מאשר במחשב שולחני שמחובר בחוט. הנתונים מצביעים על כך שהמצב הזה כבר לא קיים. במקורות עם נתוני LCP נמוכים, משך הטעינה החציוני של התמונה (p75) איטי יותר בנייד רק ב-20% בהשוואה למחשב.
זמן עד בייט ראשון (TTFB)
בניווטים שמתבצעת בהם בקשה לרשת, זמן ה-TTFB תמיד יהיה ארוך. נדרש זמן כדי לבצע חיפוש DNS ולהתחיל חיבור. אי אפשר לעקוף את הפיזיקה: בקשה צריכה לעבור דרך העולם האמיתי באמצעות חוטים וכבלי אופטי כדי להגיע לשרת, ואז התשובה צריכה לעשות את אותו המסע חזרה. גם במקור החציוני עם מדד LCP טוב, זמן אחזור ה-TTFB הוא יותר מחצי שנייה באחוזון ה-75.
עם זאת, הפער בזמן אחזור הבקשה (TTFB) בין מקורות ה-LCP הטובים לבין מקורות ה-LCP הגרועים מראה שיש הזדמנות לשיפור. לפחות ב-50% מהמקורות עם LCP נמוך, זמן אחזור ה-TTFB של p75 של 2,270 אלפיות השנייה בלבד כמעט מבטיח שה-LCP של p75 לא יכול להיות מהיר יותר מהסף 'טוב' של 2.5 שניות. גם ירידה מתונה באחוזים בזמן הזה תגרום לשיפור משמעותי ב-LCP.
אולי לא תוכלו לנצח את הפיזיקה, אבל יש דברים שאפשר לעשות. לדוגמה, אם המשתמשים שלכם נמצאים לעיתים קרובות במיקום שונה מאוד מהשרתים שלכם, CDN יכול להביא את התוכן שלכם קרוב יותר אליהם.
מידע נוסף זמין במדריך לאופטימיזציה של זמן אחזור הבקשה הראשון (TTFB).
עיכוב בטעינת המשאבים – הגורם העיקרי לזמן LCP איטי שרבים מתעלמים ממנו
אם אפשר לשפר את זמן אחזור ה-TTFB אבל השיפורים מוגבלים על ידי הפיזיקה, יכול להיות שאפשר לבטל את עיכוב הטעינה של המשאבים. בפועל, האפשרות הזו מוגבלת רק על ידי ארכיטקטורת ההצגה שלכם.
החלק המשני הזה מודד את הזמן שחלף מהגעת הבייט הראשון של תגובת ה-HTML (TTFB) ועד שהדפדפן מתחיל לשלוח בקשה לתמונה של LCP. במשך שנים התמקדנו בזמן הנדרש להורדת תמונות LCP, אבל לעיתים קרובות התעלמנו מהזמן שהתבזבז עוד לפני שהודעה נשלחה לדפדפן להתחיל את ההורדה.
באתרים במדד החציוני עם LCP נמוך, משך ההמתנה להורדת קובץ ה-LCP ארוך פי ארבעה כמעט מזמן ההורדה בפועל. משך ההמתנה בין זמן אחזור הדף לבקשת התמונה הוא 1.3 שניות. יותר ממחצית מתקציב ה-LCP של 2.5 שניות נוצלה בחלק משנה אחד.
רשתות של יחסי תלות הן סיבה נפוצה לעיכובים ארוכים בטעינת האתר. בצד הפשוט יותר, דף שבו נטען גיליון סגנונות, שמגדיר תמונת רקע אחרי שהדפדפן מסדר את הפריסה, והיא תהפוך ל-LCP. כל השלבים האלה צריכים להתרחש עוד לפני שהדפדפן יודע להתחיל להוריד את קובץ האימג' של LCP.
בעזרת נתוני הסריקה הציבוריים של HTTP Archive, שמתעדים את שרשרת הבקשות 'המפעילה' של בקשות הרשת ממסמך ה-HTML לתמונה של LCP, אפשר לראות את הקשר הברור בין אורך שרשרת הבקשות לבין זמן LCP איטי יותר.
המפתח הוא להודיע לדפדפן כמה שיותר מהר מה יהיה ה-LCP כדי שהוא יוכל להתחיל לטעון אותו, עוד לפני שיש לו מקום בפריסת הדף. יש כמה כלים שאפשר להשתמש בהם כדי לעשות זאת, כמו תג <img> קלאסי ב-HTML כדי שסורק ההורדה מראש יוכל למצוא אותו במהירות ולהתחיל להוריד אותו, או תג <link rel="preload"> (או כותרת HTTP) לתמונות שלא יהיו <img>.
חשוב גם לעזור לדפדפן לקבוע אילו משאבים לתת להם עדיפות. המצב הזה נכון במיוחד אם הדף שולח הרבה בקשות במהלך טעינת הדף, כי לרוב הדפדפן לא יידע מה יהיה רכיב ה-LCP עד שרוב המשאבים האלה ייטענו והפריסה תתבצע. הוספת הערה לאלמנט ה-LCP הסביר ביותר באמצעות מאפיין fetchpriority="high" (והימנעות משימוש ב-loading="lazy") מאפשרת לדפדפן להתחיל לטעון את המשאב באופן מיידי.
מידע נוסף על אופטימיזציה של זמן הטעינה
השהיית רינדור
עיכוב העיבוד הוא המדד של הזמן שחלף מאותו רגע שבו תמונת ה-LCP נטענה והוכנה בדפדפן, אבל מסיבה כלשהי יש עיכוב עד שהיא מוצגת במסך. לפעמים זו משימה ארוכה שגורמת לחסימה של ה-thread הראשי כשהתמונה מוכנה, ובמקרים אחרים זו יכולה להיות בחירה של ממשק המשתמש לחשוף רכיב מוסתר.
במקור טיפוסי באינטרנט, נראה שאין הזדמנות גדולה לקצץ את זמן העיבוד, אבל במהלך האופטימיזציה אפשר לפעמים ליצור עיכוב עיבוד מתוך זמן שהיה בעבר מושקע בחלקים משנה אחרים. לדוגמה, אם דף מתחיל לטעון מראש את התמונה של LCP כדי שהיא תהיה זמינה במהירות, לא יהיה יותר עיכוב טעינה ארוך. עם זאת, אם הדף עצמו לא מוכן להציג את התמונה – למשל, בגלל גיליון סגנונות גדול שחוסם את העיבוד או אפליקציה לעיבוד בצד הלקוח שצריכה לסיים את טעינת כל קוד ה-JavaScript שלה לפני שאפשר להציג משהו – זמן ה-LCP עדיין יהיה איטי יותר מהרגיל, והזמן שחלף בהמתנה יופיע עכשיו כ'עיכוב עיבוד'. לכן, לעיבוד בצד השרת או ל-HTML סטטי יש לרוב יתרון כשמדובר ב-LCP.
אם התוכן שלכם מושפע מהשינוי, כדאי לעיין בטיפים נוספים לאופטימיזציה של זמן העיבוד.
בודקים את כל החלקים המשניים האלה
ברור שכדי לבצע אופטימיזציה יעילה של LCP, המפתחים צריכים לבחון את טעינת הדף באופן מקיף, ולא להתמקד רק באופטימיזציה של תמונות. כדאי לבדוק כל חלק מזמן הטעינה עד LCP, כי סביר להניח שיש הזדמנויות רבות יותר לשיפור.
כדי לאסוף את הנתונים האלה בשטח, גרסת build השיוך של ספריית מדדי הליבה לאינטרנט כוללת תזמונים לחלקי המשנה של LCP. הדוח לגבי חוויית המשתמש ב-Chrome (CrUX) עדיין לא כולל את כל הנתונים האלה, אבל יש בו רשומות של TTFB ו-LCP, כך שזהו התחלה. אנחנו מקווים לכלול ב-CrUX בעתיד את הנתונים ששימשו לפרסום הפוסט הזה, אז כדאי להתעדכן בהמשך.
כדי לבדוק חלקים משניים של LCP באופן מקומי, אפשר להשתמש בתוסף Web Vitals או בקטע הקוד של JavaScript שמופיע במאמר הזה. ב-Lighthouse הניתוח הזה נכלל בביקורת 'רכיב ה-Largest Contentful Paint (LCP)'. עצות נוספות לגבי חלקי LCP מופיעות בחלונית 'ביצועים' ב-DevTools, בקרוב.