Core Web Vitals: המדדים שגוגל באמת בודק בדפדפן של המשתמש

מאת צוות מדיה דיל · 08.07.2026 · פיתוח אתרים · 5 דק׳

LCP, INP, CLS, נתוני CrUX מול Lighthouse, השפעה על דירוג בגוגל, ושיפור Long Tasks ו-Layout Shift בפועל.

צוות פיתוח יכול להריץ Lighthouse על מחשב חזק ברשת מהירה ולקבל ציון 98, בעוד משתמש אמיתי עם טלפון Android חלש ורשת 4G חלשה חווה דף שנתקע לשלוש שניות לפני שהוא מגיב ללחיצה. הפער הזה הוא בדיוק הסיבה ש-Google בנתה את Core Web Vitals — שלושה מדדים שנאספים מדפדפני Chrome אמיתיים דרך Chrome UX Report (CrUX), לא מסביבת מעבדה מלאכותית. Largest Contentful Paint, Interaction to Next Paint ו-Cumulative Layout Shift מודדים שלושה היבטים שונים של חוויית טעינה: מהירות, תגובתיות ויציבות ויזואלית.

LCP — מה בדיוק נטען

Largest Contentful Paint מודד את הזמן מתחילת הניווט ועד שהאלמנט הגדול ביותר בתצוגה — לרוב תמונת hero, כותרת גדולה או וידאו — מסיים להיצבע על המסך. הסף התקין הוא עד 2.5 שניות באחוזון ה-75 של המשתמשים. חשוב להבין: LCP לא מודד מתי הדף "התחיל" להיטען אלא מתי התוכן המשמעותי ביותר ויזואלית הפך לגלוי, ולכן תמונה שנטענת באיחור דרך JavaScript אחרי שהדף כבר "נראה מוכן" יכולה להרוס את המדד גם אם ה-DOM נבנה מהר.

INP — התגובתיות לאורך כל חיי הדף

Interaction to Next Paint החליף את First Input Delay במאי 2024 כי FID מדד רק את ההשהיה עד לפעולה הראשונה של המשתמש, בעוד INP עוקב אחרי כל לחיצה, הקשה או טאץ' לאורך כל חיי הדף ומדווח על הגרוע מביניהם (באחוזון גבוה). ציון טוב הוא מתחת ל-200 מילישניות. INP גבוה כמעט תמיד נובע מ-Long Tasks — בלוקים של JavaScript שרצים על ה-Main Thread ברצף של יותר מ-50 מילישניות וחוסמים את הדפדפן מלצייר את התגובה הוויזואלית ללחיצה, גם אם הלוגיקה עצמה מהירה.

CLS — כשהתוכן "קופץ"

Cumulative Layout Shift מחשב ציון מצטבר של כל תזוזה בלתי צפויה של אלמנטים גלויים, כתוצאה ממכפלת שטח האלמנט שזז במרחק שהוא זז יחסית לתצוגה. הגורמים הנפוצים ביותר הם תמונות בלי width/height מוגדרים מראש, פרסומות שמוזרקות דינמית בלי לשמור מקום, ופונטים מותאמים אישית שגורמים ל-Flash of Unstyled Text כשהם נטענים באיחור ומחליפים גופן ברוחב שונה. ציון תקין הוא מתחת ל-0.1.

איך גוגל משתמש בהם לדירוג

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

שיפור LCP בפועל

השיפור האפקטיבי ביותר ל-LCP הוא לוודא שהאלמנט הגדול ביותר נטען מוקדם ובלי תלות ב-JavaScript: preload לתמונת ה-hero עם fetchpriority="high", שרת שמחזיר HTML עם התוכן כבר בפנים (Server-Side Rendering או Static Generation) במקום לחכות ש-JS ירנדר אותו בצד הלקוח, והסרת render-blocking resources כמו CSS גדול שלא רלוונטי ל-above the fold. שימוש ב-CDN שמקרב את התוכן הסטטי גאוגרפית למשתמש מוריד עוד משמעותית מזמן ה-Time to First Byte שממנו מתחיל למדוד LCP.

שיפור INP ו-CLS

ל-INP הפתרון המרכזי הוא לפרק עבודה כבדה ל-chunks קטנים באמצעות scheduler.yield או setTimeout, לדחות טעינת JavaScript שלא קריטי לאינטראקציה הראשונית, ולהימנע מלטעון את כל הדף כאפליקציה אחת גדולה כשרוב התוכן בו סטטי — גישה שנקראת Islands Architecture ופותרת בדיוק את הבעיה הזו. ל-CLS הפתרון פשוט יותר: תמיד להגדיר width ו-height (או aspect-ratio) לתמונות ולמדיה, להקצות מקום קבוע לבאנרים ופרסומות לפני שהם נטענים, ולהשתמש ב-font-display: optional או swap עם fallback דומה כדי למנוע קפיצת טקסט.

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

תגיות: Core Web Vitals · LCP · INP · CLS · CrUX · Page Experience

← חזרה לבלוג · צור קשר