איך לשפר Largest Contentful Paint באמצעות תיקון השלב האיטי ביותר ב-LCP

כדי לשפר Largest Contentful Paint, מזהים את הרכיב שקובע את LCP ומודדים מה מעכב את הופעתו. בתמונה מפרידים בין ההמתנה ל-HTML, העיכוב בתחילת הבקשה, ההורדה וההמתנה הנותרת לרינדור. אחר כך מתקנים את השלב שבאמת איטי, במקום להפעיל את כל שיפורי התמונות בבת אחת.

LCP נחשב טוב כאשר הוא 2.5 שניות או פחות באחוזון ה-75. היעד מתאר תוצאה עבור מבקרים. הוא אינו מגלה אם הגורם הוא שרת איטי, תמונה שהתגלתה מאוחר או דף שמסתיר תוכן שכבר הורד עד ש-JavaScript מסיים לעבוד.

מוצאים את הרכיב לפני שינוי אופן ההגשה

מקליטים טעינה ב-Chrome DevTools בגודל התצוגה שרוצים לבדוק. בוחנים את אירוע LCP ואת הרכיב המשויך אליו. משווים למה שנראה בהקלטה, משום שהדפדפן יכול לזהות מועמד גדול יותר בהמשך הטעינה.

מועמדים כוללים תמונות ובלוקי טקסט, עם כללים נוספים לתמונות רקע ולווידאו. LCP אינו פשוט צומת ה-DOM הגדול ביותר או בקשת הרשת האחרונה. מכל גדול וריק אינו הופך לתוכן משמעותי רק בגלל מידותיו.

חוזרים על הבדיקה בתבניות ובגדלי מכשיר רלוונטיים. כותרת יכולה לקבוע LCP במובייל, ותמונת מוצר במחשב. גם ניסוי או מצב הסכמה יכולים לשנות את התוכן הגלוי. מתעדים תנאים לצד הרכיב כדי שהבדיקה הבאה תבחן אותו תרחיש.

בפרויקט שמשלב את גרסת attribution של web-vitals, המודול הבא רושם את כתובת התמונה ואת זמני השלבים כאשר הם זמינים.

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  console.table({
    lcp: value,
    resource: attribution.url ?? 'Text or no image resource',
    ttfb: attribution.timeToFirstByte,
    loadDelay: attribution.resourceLoadDelay,
    loadDuration: attribution.resourceLoadDuration,
    renderDelay: attribution.elementRenderDelay
  });
});

זהו כלי עזר לתצפית, לא שירות ניטור שלם. הוא דורש חבילה תואמת מותקנת וסביבת בנייה שפותרת את הייבוא. איסוף בשטח מחייב גם נקודת קליטה וצבירה שתוכננו בקפידה. בעת שילוב הדוגמה בודקים את גרסת הספרייה ואת ממשק attribution שלה.

משתמשים בארבעת השלבים לבחירת התיקון הראשון

מדריך Google לשיפור LCP מפריד LCP מבוסס תמונה לשלבים הקשורים לסוגי עבודה שונים. ב-LCP מבוסס טקסט ייתכן שאין הורדת תמונה, ואין להמציא שלב כזה כדי להתאים למודל.

שינוי מועיל מקצר את המסלול המלא לתוכן גלוי. נניח שתמונה יורדת מוקדם יותר, אך ממתינה לאותה משימת רינדור ארוכה. שלב ההורדה מתקצר ועיכוב הרינדור גדל, כך ש-LCP כמעט אינו משתנה. זהו אבחון אמיתי, לא הוכחה שדחיסת תמונות לעולם אינה מועילה.

שומרים את ההקלטה המקורית. השוואת לפני ואחרי צריכה להראות איזה שלב השתנה והאם אותו רכיב עדיין קובע את LCP. אם רכיב אחר הפך למועמד, בודקים את המעבר במקום להשוות משאבים שונים ללא הסבר.

מצמצמים את הזמן עד הגעת HTML

הדפדפן אינו מגלה משאבי מסמך רגילים לפני שקיבל די מהמסמך כדי לזהותם. עוקבים אחר בקשת הניווט דרך הפניות, הקמת חיבור והתגובה הסופית. שרשרת הפניות יכולה לעכב גילוי גם כשהיישום עצמו מהיר.

משווים תגובות עם מטמון ובלעדיו. דף בית שכבר נשמר יכול להסתיר הרצה איטית בכתובות פחות נפוצות. בודקים אם ה-CDN שומר HTML או רק קבצים סטטיים, ואם עוגיות עוקפות באופן לא צפוי מטמון ציבורי.

לא הופכים דפים אישיים לציבוריים כדי לשפר זמן. המטמון חייב לשמור על סשנים, הרשאות ותוכן נכון. המדריך לזמן תגובת שרת מסביר את ההפרדה ואת מדידת העבודה שנחסכת בפגיעה במטמון.

גם רינדור בשרת דורש הקשר. HTML שימושי יכול לחסוך עבודת גילוי בצד הלקוח, אך תהליך רינדור כבד יכול להגדיל TTFB. מודדים את התגובה ואת הציור שמגיע אחריה. שלד ריק ומהיר אינו המטרה.

מאפשרים גילוי מיידי של התמונה החשובה

כתובת תמונה ב-HTML הראשוני זמינה למנגנון גילוי המשאבים של הדפדפן. תמונה שנוצרת רק אחרי JavaScript יורשת את התלות בו. תמונת רקע ב-CSS עשויה לחכות להגעה ולעיבוד של גיליון הסגנונות לפני גילוי כתובתה.

מעדיפים רכיב תמונה רגיל לתוכן משמעותי, כאשר הדבר מתאים לעיצוב ולמשמעות. נותנים לו טקסט חלופי מדויק ומידות. לא מוסיפים loading="lazy" לתמונה שאמורה להופיע במסך הראשון רק משום ששאר המדיה נטענת בעצלתיים.

הדוגמה מניחה תמונה ברוחב של עד 960 פיקסלי CSS ופריסה צרה יותר במובייל. הקבצים הם נכסי דוגמה שהבנייה שלכם צריכה לספק.

<img
  src="/images/guide-960.webp"
  srcset="/images/guide-640.webp 640w,
          /images/guide-960.webp 960w,
          /images/guide-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A browser displaying a highlighted content panel"
>

הדפדפן בוחר משאב לפי sizes, רוחבי המועמדים ומאפייני המכשיר. sizes חייב להתאים לפריסה בפועל; הוא אינו מגדיר את רוחב ה-CSS. אם התמונה תופסת חצי עמודה ומתארים אותה כרוחב מסך מלא, עלולה להיבחר הורדה גדולה ללא צורך.

fetchpriority="high" מסמן שהבקשה חשובה במיוחד. הוא אינו הופך משאב נסתר לגלוי. הגדרתו בתמונות מתחרות רבות מחלישה את התעדוף הרצוי. מתחילים במועמד LCP שנמדד ובודקים אחר כך את רצף הבקשות.

משתמשים ב-preload רק כשגילוי מוקדם פותר עיכוב אמיתי

preload מתאים למשאב קריטי שאחרת יתגלה מאוחר. זו אינה הוראה להוריד את כל הנכסים הגלויים לפני שהדפדפן מארגן בעצמו את העבודה.

ברקע CSS קריטי באמת, preload לתמונה יכול להתחיל את הבקשה לפני שגיליון הסגנונות חושף אותה. שתי הדוגמאות משתמשות באותה כתובת כדי לאפשר שימוש חוזר בבקשה.

<link rel="preload" as="image" href="/images/banner.webp"
      fetchpriority="high">

.banner {
  min-height: 18rem;
  background-image: url('/images/banner.webp');
  background-size: cover;
  background-position: center;
}

המידות בדוגמה הן החלטות עיצוב, לא ספי ביצועים. כאשר התמונה מעבירה מידע שזקוק לטקסט חלופי, משתמשים במקום זאת ברכיב תמונה בעל משמעות מתאימה.

בתמונות רספונסיביות גם בחירת ה-preload צריכה להתאים. כתובת קבועה יכולה לבזבז רוחב פס אם רכיב התמונה בוחר מועמד אחר. בודקים כתובות, סוגי משאב והתנהגות אישורי גישה, ולא מניחים ששתי הפניות דומות הן העברה אחת.

אחרי הוספת הרמז בודקים אם הבקשה הרצויה התחילה מוקדם יותר ואם עבודה קריטית אחרת נדחקה. אזהרה על preload שלא נוצל היא סיבה לבדוק את המימוש, לא רק להסתיר את האזהרה.

מצמצמים בייטים בלי לפגוע בתוכן

לאחר שהגילוי מתרחש בזמן, בודקים את מידות התמונה שנבחרה ואת גודל ההעברה. מייצאים גרסאות המתאימות לשטח המוצג ולצפיפות הפיקסלים הרצויה. מסך בצפיפות גבוהה יכול להזדקק ליותר פיקסלי תמונה מרוחב CSS, ולכן הכלל אינו להשוות תמיד את המספרים.

משווים פורמטים והגדרות דחיסה על התמונה עצמה. AVIF או WebP יכולים להתאים, אך התוכן, דרישות האיכות ובחירת הקידוד משפיעים על התוצאה. טקסט קטן, תרשימים וצילומים אינם מגיבים בהכרח באותו אופן.

בודקים את התוצאה בגודל התצוגה. פרטי מוצר מטושטשים, אותיות פגומות או עיוותים אינם מקובלים רק מפני שהקובץ קטן יותר. שומרים את המקור והגדרות ייצוא שניתן לשחזר, כדי שעריכה עתידית לא תבטל את השיפור.

CDN לתמונות או תהליך עיבוד ב-CMS יכולים לייצר גרסאות אוטומטית. עדיין בודקים את ה-HTML שנפלט ואת הבקשה שנבחרה. תכונה שמכונה רספונסיבית אינה מוכיחה ש-sizes מתאים לתבנית. מדריך אופטימיזציית תמונות מרחיב על פורמטים וסימון רספונסיבי.

מחשבון החיסכון בתמונות משווה שינוי בבייטים. הוא מעריך חיסכון בהעברה לפי הקלט, לא כמה אלפיות שנייה ייחסכו ב-LCP. טעינה מקבילה, מטמון ושלבים אחרים ממשיכים להשפיע.

בודקים את הפער בין ההורדה לציור

אם התמונה התקבלה אך מופיעה הרבה אחר כך, בודקים מה מונע רינדור. אולי עדיין חסרים סגנונות, JavaScript תופס את זרם הביצוע הראשי, או שהרכיב מוסתר עד סיום אנימציה, אתחול או מצב שמרונדר בצד הלקוח.

מסירים תלויות מיותרות להצגה. תמונה חשובה לא צריכה להמתין ללוגיקת קרוסלה אחרת אם אפשר לייצג את השקופית הראשונה ב-HTML רגיל. בודקים אם שכבת טעינה מכסה תוכן מוכן או שאנימציית כניסה מעכבת את המדד בלי לעזור למבקר.

בוחנים CSS חוסם רינדור בזהירות. המטרה אינה למחוק כל גיליון או לדחות את כל העיצוב. המסך הראשון דורש סגנונות נכונים למניעת הבהובים ותזוזות. מזהים נכסים לא בשימוש או לא קריטיים, ושומרים את הכללים הנחוצים לאזור הראשוני.

עבודה בזרם הראשי יכולה לעכב רינדור גם אחרי סיום הרשת. מחפשים סקריפטים גדולים, hydration ואתחול סינכרוני סביב הזמן הרלוונטי. המדריך למשאבים חוסמי רינדור מפריד בין תלויות גילוי והרצה שקל לבלבל.

ב-LCP של טקסט בודקים גופנים ונראות. בקשת גופן יכולה להשפיע על הופעת הכותרת, ומדדי גופן חלופי על הפריסה. אין להניח ש-preload לכל הגופנים הוא הפתרון: הם עלולים להתחרות במשאבים דחופים יותר למסך הראשון.

בודקים את גרסאות המובייל והתוכן שבאמת מוגשות

בודקים כותרת ארוכה וקצרה, כתבה עם תמונה ראשית וכתבה בלעדיה. כוללים מצב הסכמה, פרסום ושפה אמיתיים כאשר הם משנים את הפריסה הגלויה. אותו קוד יכול לייצר מועמדי LCP שונים לפי התוכן.

אזור תצוגה צר יכול לחתוך או להסתיר תמונת מחשב בזמן שהדפדפן ממשיך להוריד אותה בגלל חוסר התאמה בין HTML לסגנונות. מנגד, נכס מובייל יכול להישלח מאוחר אם סקריפט בוחר בו אחרי ההפעלה. בודקים בקשות אמיתיות, לא רק את הדף הסופי.

בגרסאות מתורגמות, כיסוי תווים בגופן ושבירת שורות יכולים לשנות את המועמד ואת תלויותיו. משתמשים באותו אבחון בכל שפה, ולא מניחים ששיפור באנגלית מוכיח שיפור בכל הגרסאות.

מאמתים השערה אחת בהקלטה שאפשר להשוות

כותבים השערה לפני העריכה: למשל, תמונת LCP מתגלה מאוחר כי רכיב מוסיף אותה אחרי אתחול. מבצעים את השינוי הקטן ביותר שבודק את ההסבר ומקליטים שוב אותו תרחיש.

משווים תחילת בקשה, סיום העברה, ציור ו-LCP כולל. חוזרים באותו גודל מסך, הגבלת משאבים ומצב מטמון. שומרים הרצות כושלות ושגיאות גלויות; דף שהפסיק לטעון תכונה חשובה עלול להיראות מהיר מהסיבה הלא נכונה.

אחרי הפריסה בוחנים נתוני משתמשים לאורך חלון האיסוף. LCP בשטח עשוי להיות שונה בגלל חומרה, חיבורים, מיקום והתנהגות ניווט. שיפור במעבדה הוא ראיה מועילה, אך אינו תחליף לתוצאת השטח.

מקלים על תחזוקת התוצאה

מתעדים איזה רכיב חשוב, כיצד הוא מתגלה ואיזו אופטימיזציה מכוונת. הערה קצרה יכולה למנוע מתוסף להחזיר טעינה עצלה או מעיצוב חדש לשנות את השטח בלי לעדכן sizes.

שומרים את המקרה בשגרת הבדיקה: דף מייצג, מועמד התמונה הרצוי, מסלול הגילוי הצפוי והקלטה שמורה. נעזרים במדריכי Core Web Vitals כאשר מדד אחר הופך למגבלה. המשימה הבאה צריכה לנבוע מההשהיה הבאה שנמדדה, לא מעוד מתג אופטימיזציה כללי.