Core Web Vitals ב־2026: איך מתקנים LCP, INP ו־CLS, כולל מעבר על דו"ח PageSpeed

בקצרה: Core Web Vitals הם שלושה מדדים של כניסות אמיתיות: LCP (טעינה, טוב עד 2.5 שניות), INP (תגובתיות, טוב עד 200 אלפיות שנייה) ו־CLS (יציבות חזותית, טוב עד 0.1). גוגל שופטת כל אחד באחוזון ה־75 של הכניסות. ב־PageSpeed Insights, נתוני השטח למעלה הם מה שקובע, וציון המעבדה שמתחתם נועד למצוא סיבות. רוב בעיות ה־LCP הן תמונה ראשית איטית או כזו שהדפדפן מגלה מאוחר, רוב בעיות ה־INP הן משימות JavaScript ארוכות, ורוב בעיות ה־CLS הן תמונות והטמעות בלי מקום שמור. אפשר לבדוק את העמוד שלכם בבדיקת המהירות שלנו.

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

מה זה Core Web Vitals?

Core Web Vitals הם שלושה מדדים שגוגל משתמשת בהם כדי לתאר איך עמוד מרגיש לגולשים אמיתיים: כמה מהר התוכן הראשי מופיע, כמה מהר העמוד מגיב, וכמה הפריסה קופצת. LCP, או Largest Contentful Paint, הוא הזמן עד שהתמונה או בלוק הטקסט הגדולים ביותר במסך סיימו להיטען. INP, או Interaction to Next Paint, הוא בערך התגובה האיטית ביותר ללחיצה, נגיעה או הקשה במהלך הביקור. CLS, או Cumulative Layout Shift, נותן ציון לכמה תוכן גלוי זז בלי שציפו לזה. גוגל מפרסמת את ההגדרות והספים ב־web.dev. כל מדד נשפט באחוזון ה־75 של טעינות העמוד מתוך דו"ח חוויית המשתמש של Chrome, בנפרד לנייד ולמחשב. כלומר עמוד "עובר" LCP כשלפחות שלוש מתוך ארבע כניסות מקבלות את התוכן הראשי תוך 2.5 שניות. הרבע האיטי יכול להיות איטי בלי להפיל את העמוד, והכניסה החציונית היא לא הרף.

הספים לא השתנו מאז שהמדדים הוצגו. ההרכב כן: INP החליף את First Input Delay ב־12 במרץ 2024.

Core Web Vitals משפיעים על הדירוג?

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

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

איך קוראים דו"ח PageSpeed Insights?

PageSpeed Insights שם שני דברים שונים על מסך אחד, ורוב הבלבול נובע מערבוב ביניהם.

החלק העליון, שבממשק האנגלי נקרא "Discover what your real users are experiencing", הוא נתוני שטח מדו"ח חוויית המשתמש של Chrome: 28 יום של כניסות Chrome אמיתיות, עם LCP, INP ו־CLS באחוזון ה־75 ועם תוצאה של עבר או נכשל בהערכת Core Web Vitals. מתג מאפשר לעבור בין הכתובת הזו לבין האתר כולו. אם לעמוד אין מספיק תנועה, החלק הזה יגיד שאין מספיק נתונים, ותקבלו רק את מבחן המעבדה.

החלק התחתון, "Diagnose performance issues" בממשק האנגלי, הוא מבחן מעבדה של Lighthouse: טעינה מדומה אחת בטלפון בינוני עם רשת מואטת, שמפיקה את ציון הביצועים המפורסם בין 0 ל־100. הוא שימושי למציאת סיבות וחסר ערך כפסק דין, כי הוא משתנה מהרצה להרצה ולעולם לא מודד INP (אין שם גולש אמיתי שלוחץ על משהו). קוראים את נתוני השטח כדי לדעת אם יש בעיה, ואת האבחון של המעבדה כדי להבין למה.

איך מתקנים LCP איטי?

מתחילים במציאת אלמנט ה־LCP. האבחון ב־PageSpeed מציין אותו, ובדרך כלל זו התמונה הראשית או כותרת גדולה. אחר כך מפרקים את הזמן לארבעת החלקים של המדריך לשיפור LCP ב־web.dev: הזמן עד הבייט הראשון, העיכוב עד שהדפדפן מתחיל לטעון את המשאב, זמן ההורדה, והעיכוב עד שהוא מוצג. מתחילים לתקן בחלק הארוך ביותר.

המקרה הנפוץ אצלנו: תמונה ראשית שהדפדפן מגלה מאוחר, כי היא מוגדרת כרקע ב־CSS, נטענת ב־JavaScript, או מסומנת loading="lazy". שמים אותה ב־HTML כ־<img>, אומרים לדפדפן שהיא חשובה, ונותנים לו גדלים לבחור מהם:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="עמדת מיקס באולפן עם האורות דולקים"
  fetchpriority="high">

אם אלמנט ה־LCP הוא טקסט, האשם הרגיל הוא פונט שחוסם את התצוגה. באתרים בעברית זה קורה הרבה, כי פונטים עבריים נטענים לא פעם משירות חיצוני בקובץ אחד כבד. מאחסנים את הפונט באתר, טוענים מראש רק את הקובץ שהמסך הראשון צריך, ומשתמשים ב־font-display: swap. אם הזמן עד הבייט הראשון הוא החלק הגדול, התיקון בשרת: מטמון, CDN, או בנייה סטטית במקום לבנות כל עמוד בכל בקשה.

איך מתקנים INP חלש?

INP נכשל כשהתהליכון הראשי של הדפדפן עסוק ברגע שהגולש לוחץ. JavaScript רץ על התהליכון הזה, וכל עוד משימה רצה הדפדפן לא יכול לצייר את התגובה. משימות ארוכות, כל מה שמעל 50 אלפיות שנייה, הן הסיבה כמעט תמיד. לשונית Performance בכלי הפיתוח של Chrome מסמנת אותן באדום; מקליטים לחיצה על הרכיב האיטי ומסתכלים מה רץ.

התיקונים, לפי המדריך לשיפור INP:

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

ככה נראה פינוי התהליכון. scheduler.yield() זמין בדפדפני Chromium, והגיבוי מכסה את השאר:

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function saveForm(fields) {
  showSavingState();        // הגולש רואה תגובה מיד
  await yieldToMain();
  validate(fields);
  await yieldToMain();
  sendAnalytics(fields);    // עבודה שאף אחד לא מחכה לה, בסוף
}

איך מתקנים CLS גבוה?

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

נותנים לכל תמונה וסרטון מאפייני width ו־height (הדפדפן משתמש בהם כדי לשמור את יחס הגובה־רוחב הנכון גם עם CSS רספונסיבי). נותנים להטמעות מכל עם aspect-ratio או min-height קבועים. ובפונטים, מתאימים את פונט הגיבוי לפונט האתר כדי שההחלפה לא תזיז את הטקסט:

@font-face {
  font-family: "Heebo Fallback";
  src: local("Arial");
  size-adjust: 104%;
}
body { font-family: "Heebo", "Heebo Fallback", sans-serif; }

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

איך נראה אתר שעובר?

אתר של עסק קטן לא צריך קסמים כדי לעבור. HTML סטטי או כזה שמגיע מהשרת, פונטים שמאוחסנים באתר, תמונה ראשית ב־WebP בטעינה מוקדמת וכמה קילובייט של JavaScript יביאו בדרך כלל את ה־LCP בנייד אל מתחת לשנייה במעבדה ואת ה־CLS לקרוב לאפס, הרבה מתחת לסף ה"טוב" של 0.1. האתרים שנכשלים נכשלים בדרך כלל מאותן סיבות: קרוסלה של תמונות בגודל מלא בראש העמוד, וידג'ט צ'אט ושלושה סקריפטים של מעקב שנטענים לפני כל דבר אחר, ופונטים שמתחלפים באיחור ומזיזים את הטקסט. הדוגמה המלאה שלנו מראה איך נראה תיקון של הדברים האלה אצל מרפאת שיניים בדויה.

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

בדיקת Core Web Vitals בחצי שעה

1. להריץ את דף הבית ואת עמוד הנחיתה החשוב ביותר בבדיקת המהירות, בנייד.
2. לקרוא קודם את נתוני השטח ולרשום מי מבין LCP, INP ו־CLS נכשל, אם בכלל.
3. אם אין נתוני שטח, להתייחס ל־LCP ול־CLS של המעבדה כהערכה, ולהתעלם מהציון הכללי.
4. ב־LCP, למצוא את האלמנט באבחון ולוודא שהוא <img> אמיתי, בלי טעינה עצלה ועם fetchpriority="high".
5. ב־CLS, לוודא שלכל תמונה יש width ו־height ושאין תוכן שנכנס מעל קו הגלילה אחרי הטעינה.
6. ב־INP, להקליט בכלי הפיתוח של Chrome את האינטראקציה האיטית ולחפש משימות ארוכות.
7. לבדוק שוב אחרי כל שינוי, ולזכור שנתוני השטח לוקחים עד 28 יום להראות תיקון.

Core Web Vitals הם אחת משבע הקטגוריות בבדיקה שלנו, במשקל 10%. הדו"ח המלא מודד אותם בכל עמוד חשוב לצד שש הקטגוריות האחרות, והמדריך החינמי ל־SEO ו־GEO כולל את הבדיקות שאפשר להריץ לבד.