לפעמים קשה לשפר את מדד המהירות שבה נטען רכיב התוכן הכי גדול (LCP) של דף, ולרוב יש בו כמה שינויים ורכיבים זזים. הפוסט הזה בוחן נתוני שדות מטעינות של דפים אמיתיים באינטרנט כדי לקבוע איפה כדאי למפתחים למקד את מאמצי האופטימיזציה שלהם.
עצה לגבי LCP קלאסי: הקטנה של התמונות.
ברוב הדפים באינטרנט, רכיב ה-LCP הוא תמונה. לאחר מכן, מקובל להניח שהדרך הטובה ביותר לשפר את מדד ה-LCP היא לבצע אופטימיזציה של תמונת ה-LCP.
בחמש השנים האחרונות מאז השקת ה-LCP, זו הייתה העצה הכי טובה בדרך כלל. חשוב לוודא שהתמונות בגודל הנכון ודחוסות מספיק, ואולי להשתמש בפורמט תמונה של המאה ה-21 כשאתם נמצאים שם. כדי להגיש את ההצעות האלה, ב-Lighthouse יש אפילו שלוש ביקורות שונות.
אחת הסיבות לכך שזוהי עצה נפוצה כל כך היא שקל למדוד יותר מדי בייטים, וקל להציע כלים לדחיסת תמונות. יכול להיות שיהיה גם קל להטמיע אותו, בהתאם לצינורות עיבוד הנתונים ל-build ולפריסה.
אם כן, עשה זאת! כמעט תמיד עדיף לשלוח פחות בייטים למשתמשים. יש הרבה אתרים באינטרנט שעדיין מציגים תמונות גדולות מדי, שאפילו דחיסה בסיסית תוכל לתקן.
עם זאת, כשהתחלנו לבחון את נתוני ביצועי השטח של משתמשים ב-Chrome כדי לראות היכן בדרך כלל מושקע הזמן שלך ב-LCP, גילינו שזמן ההורדה של התמונה הוא כמעט אף פעם לא צוואר בקבוק.
במקום זאת, חלקים אחרים של מדד ה-LCP הם בעיה הרבה יותר גדולה.
פירוט של חלקי משנה מסוג LCP
כדי להבין מהם התחומים החשובים ביותר שמאפשרים לשפר את מדד ה-LCP, בחנו נתונים מחלקי המשנה של ה-LCP, כפי שמתואר במאמר Optimize 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 נמוך, משך הטעינה החציוני של תמונה בפורמט p75 איטי רק ב-20% בנייד מאשר במחשב.
זמן עד בייט ראשון (TTFB)
בניווטים שמבצעים בקשות רשת, תמיד ייקח זמן מה-TTFB. לוקח זמן לבצע חיפוש DNS ולהתחיל חיבור. אי אפשר לנצח את הפיזיקה: הבקשה חייבת לעבור בעולם האמיתי דרך חוטים וכבלים אופטיים כדי להגיע לשרת, ואז התגובה צריכה להחזיר את התגובה. גם המקור החציוני עם LCP טוב מנצל יותר מחצי שנייה על TicketFB באחוזון ה-75.
עם זאת, ההבדל בין ה-TTDFB בין מקורות ה-LCP הטובים והנמוכים מצביע על הזדמנות לשיפור. בלפחות מחצית מהמקורות עם LCP נמוך, הערך p75 TTFB של 2,270 אלפיות השנייה נפרד כמעט מתחייב שה-LCP של p75 לא יהיה מהיר יותר מהמדד 'טוב' של 2.5 שניות. סף החיוב. גם הפחתה מתונה באחוזים במשך הזמן הזה תביא לשיפור משמעותי ב-LCP.
אולי אי אפשר לנצח את הפיזיקה, אבל יש דברים שאפשר לעשות. לדוגמה, אם המשתמשים נמצאים לעיתים קרובות במיקום שונה מאוד מזה של השרתים שלכם, CDN יכול לקרב את התוכן שלכם אליהם.
מידע נוסף זמין במדריך לאופטימיזציה של 'דברים שאפשר לעשות' (TTFB).
השהיה בטעינת משאב, גורם הבעיה ב-LCP האיטי
אם אפשר לשפר את טופס ה-TTDFB אבל השיפורים מוגבלים בפיזיקה, אפשר לבטל את ההשהיה של טעינת המשאבים, בפועל רק בהתאם לארכיטקטורת ההצגה.
חלק המשנה הזה מודד את הזמן מרגע קבלת הבייט הראשון של תגובת ה-HTML (TTFB) עד למועד שבו הדפדפן מפעיל בקשה לקבלת תמונת ה-LCP. במשך שנים היינו ממוקדים מאוד במשך זמן ההורדה של תמונות LCP, אבל לעיתים קרובות התעלמנו בזמן שהתבזבזנו לפני שנציגי הדפדפן אפילו החליטו להתחיל את ההורדה.
האתר החציוני עם נתוני LCP נמוך מבזבז כמעט פי ארבעה זמן על המתנה לתחילת ההורדה של תמונת ה-LCP אחרי ההורדה שלה בפועל, בהמתנה של 1.3 שניות בין ה-TTFB לבין בקשת התמונה. יותר ממחצית מתקציב ה-LCP של 2.5 שניות, שמושקע בחלק משנה אחד.
שרשראות תלות הן סיבה נפוצה לעיכובים ארוכים בטעינה. הדף הפשוט יותר הוא טעינת דף סגנונות. אחרי שהדפדפן מבצע פריסה, המערכת מגדירה תמונת רקע, שבסופו של דבר תהיה ה-LCP. כל השלבים האלה חייבים להתרחש לפני שהדפדפן בכלל מתחיל להוריד את תמונת ה-LCP.
שימוש בנתוני סריקה ציבורית בארכיון HTTP, שמתעד את "יוזם" שרשרת בקשות הרשת ממסמך ה-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, כי סביר להניח שיש הזדמנויות הרבה יותר גדולות לשיפור.
לצורך איסוף הנתונים האלה בשטח, מודל השיוך (Attribution) של ספריית web-vitals כולל תזמונים של חלקי המשנה מסוג LCP. הדוח על חוויית המשתמש ב-Chrome (CrUX) עדיין לא כולל את כל הנתונים האלה, אבל יש בו ערכים עבור TTFB ו-LCP, ולכן זוהי התחלה. אנחנו מקווים לכלול את הנתונים שישמשו לפוסט הזה ב-CrUX בעתיד, אז כדאי לעקוב אחר חדשות נוספות בנושא.
כדי לבדוק חלקי משנה של LCP באופן מקומי, אפשר לנסות את התוסף Web Vitals או את קטע הקוד של JavaScript במאמר הזה. ב-Lighthouse יש פירוט גם ברכיב "המהירות שבה נטען רכיב התוכן הכי גדול (LCP)" ביקורת. עצות נוספות לגבי חלקי LCP זמינות בחלונית הביצועים של כלי הפיתוח, בקרוב.