Core Web Vitals והמרות: LCP, INP ו-CLS, הספים של Google ואיך מודדים

נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 10.11.2026

מה הם Core Web Vitals ומה הספים של Google?

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

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

לגבי יציבות ההגדרות: web.dev מציין שמדדים יציבים של Core Web Vitals לא ישתנו יותר מפעם בשנה. השינוי האחרון היה ב-2024, כש-INP החליף את FID כמדד התגובתיות.

מה כל אחד מהמדדים מודד בפועל?

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

INP, Interaction to Next Paint. מדד לתגובתיות הכוללת של העמוד לאורך כל הביקור. לפי web.dev הוא מתבסס על האינטראקציה הארוכה ביותר שנצפתה, בהתעלמות מחריגים. נספרות הקלקות עכבר, הקשות על מסך מגע ולחיצות מקלדת, בעוד שגלילה וריחוף לא נספרים. עמוד שהמשתמש לא לחץ בו על כלום לא ידווח INP בכלל.

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

מה ההבדל בין נתוני שטח לנתוני מעבדה?

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

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

השנייה היא מי נמדד. לפי מסמך המתודולוגיה של CrUX הנתונים מגיעים ממשתמשי Chrome בדסקטופ ובאנדרואיד שעומדים בתנאים מסוימים, בהם הפעלת דיווח סטטיסטיקות שימוש וסנכרון היסטוריית גלישה. Chrome ב-iOS לא מספק נתונים, כמו גם דפדפנים אחרים מבוססי Chromium כגון Edge. המשמעות: אם חלק גדול מהקונים שלכם גולשים מאייפון, נתוני השטח של Google לא מייצגים אותם. כדי לראות אותם צריך למדוד בעצמכם.

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

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

מה שלא כתוב שם: הבטחה לדירוג גבוה יותר או משקל מספרי. מי שמוכר שיפור מהירות כקיצור דרך למקום הראשון מבטיח יותר ממה ש-Google אומרת.

איך Core Web Vitals קשורים להמרות?

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

מקרה בוחן אחד מ-web.dev ממחיש את הקשר: לפי העמוד, Vodafone איטליה שיפרה את LCP ב-31% והשיגה 8% יותר מכירות. הלקח שמצוטט שם מאותו מקרה הוא ש-A/B testing הוא הדרך הטובה ביותר למדוד את ההשפעה.

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

איך מודדים Core Web Vitals על המשתמשים שלכם ב-GA4?

בעזרת ספריית web-vitals של Google. לפי web.dev זו הדרך הקלה ביותר למדוד את כל המדדים.

1. טוענים את הספרייה. היא מספקת את הפונקציות onLCP, onINP ו-onCLS, שכל אחת מהן מקבלת פונקציה שתיקרא כשהמדד מוכן לדיווח.
2. שולחים אירוע ל-GA4. הדוגמה בתיעוד של הספרייה שולחת את שם המדד כשם האירוע, עם הפרמטרים value, metric_id, metric_value ו-metric_delta.
3. מוסיפים את הדירוג. לכל מדד יש מאפיין rating שמחזיר אם הערך בטווח הטוב, דורש שיפור או חלש. כך לא צריך לחשב את הספים בעצמכם.
4. מייצאים ל-BigQuery. לפי התיעוד של הספרייה, Google Analytics לא תומך בדיווח על התפלגות של מדד בדוחות המובנים, לכן את אחוזון 75 מחשבים מהאירועים הגולמיים. את הייצוא פירטנו במדריך לייצוא GA4 ל-BigQuery.
5. מקבצים לפי metric_id. אותו מדד יכול להישלח יותר מפעם אחת באותה טעינה, למשל CLS ו-INP בכל פעם שהלשונית עוברת לרקע. לפי התיעוד של הספרייה ה-metric_id נועד בדיוק לזה: סכום ערכי ה-delta של אותו מזהה הוא הערך המלא של המדד.

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

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToGA4({name, delta, value, id, rating}) {
  gtag('event', name, {
    value: delta,
    metric_id: id,
    metric_value: value,
    metric_delta: delta,
    metric_rating: rating
  });
}

onCLS(sendToGA4);
onINP(sendToGA4);
onLCP(sendToGA4);

הפרמטר metric_rating מופיע בדוגמה המקורית כתוספת אופציונלית וכאן הוא פעיל. שתי הערות מהתיעוד של הספרייה: לא קוראים לפונקציות יותר מפעם אחת בטעינת עמוד בלי סיבה טובה. בנוסף, onCLS נתמך כרגע רק בדפדפני Chromium, בעוד ש-onLCP ו-onINP נתמכות גם ב-Firefox וב-Safari. כלומר ממשתמשי אייפון אפשר לקבל LCP ו-INP אבל לא CLS.

איך בודקים אם המהירות פוגעת בהמרות אצלכם?

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

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

ההוכחה הנקייה היא ניסוי: גרסה מהירה מול הגרסה הקיימת על אותה תנועה. לא לכל אתר יש מספיק תנועה לזה. מה עושים במצב כזה הסברנו במדריך על ניסוי A/B בלי מספיק נתונים.

מה מתקנים קודם?

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

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

שאלות נפוצות

מה השורה התחתונה?

הספים של Google ברורים: LCP עד 2.5 שניות, INP עד 200 אלפיות שנייה ו-CLS עד 0.1, באחוזון ה-75 ובנתוני שטח. מה שלא ברור מראש הוא כמה זה שווה לכם. נתוני השטח של Google לא כוללים משתמשי אייפון ולא מחוברים להמרות. לכן הדרך לענות על השאלה היא למדוד את המדדים בעצמכם עם ספריית web-vitals, לשלוח אותם ל-GA4 ולהשוות שיעור המרה בין משתמשים עם חוויה טובה לחלשה, לפי סוג עמוד ומכשיר. רק אז יודעים איזו תבנית לתקן קודם ואם ההשקעה מוצדקת. את החיבור הזה בין נתוני ביצועים, משפך והקלטות אנחנו בונים כחלק משירות שיפור המרות וניתוח התנהגות גולשים. אם אתם רוצים לדעת אם המהירות היא מה שעוצר את ההמרות אצלכם, כתבו לנו.

מקורות

web.dev: Web Vitals, Google Search Central: Understanding Core Web Vitals and Google search results, Google for Developers: About PageSpeed Insights, Chrome for Developers: CrUX methodology, GitHub GoogleChrome: web-vitals, web.dev: The business impact of Core Web Vitals

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