Core Web Vitals בחנויות אונליין: LCP, INP ו-CLS בהסבר פשוט

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

צוות התוכן של FixReportsזמן קריאה: 11 דק׳

Core Web Vitals הם שלושה מדדים של Google שמתארים איך מבקרים אמיתיים חווים דף: Largest Contentful Paint (LCP) למהירות הטעינה, Interaction to Next Paint (INP) להיענות, ו-Cumulative Layout Shift (CLS) ליציבות החזותית. דף עובר כשלפחות 75% מהביקורים נמצאים בטווח "טוב": LCP של עד 2.5 שניות, INP של עד 200 מילישניות ו-CLS של 0.1 או פחות, כשהמדידה נעשית בנפרד למובייל ולמחשב. בחנויות אונליין, ציונים נכשלים נובעים בדרך כלל מתמונות hero ותמונות מוצר גדולות או כאלה שנטענות בטעינה עצלה (lazy loading), מסקריפטים של אפליקציות ומעקב, מגופני רשת, ומבאנרים או וידג׳טים של ביקורות שדוחפים את התוכן למטה אחרי שהדף כבר הופיע.

עיקרי הדברים

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

דף עומד ב-Core Web Vitals כשהאחוזון ה-75 של טעינות הדף נמצא בטווח הטוב בכל שלושת המדדים.

מדדמה הוא מודדטובדורש שיפורגרוע
LCPהזמן עד שהתמונה, הסרטון או בלוק הטקסט הגדול ביותר באזור התצוגה מוצג2.5 שניות או פחותמעל 2.5 שניות ועד 4.0 שניותמעל 4.0 שניות
INPהזמן מלחיצה, הקשה או לחיצה על מקש ועד שהפריים הבא מצויר200 ms או פחותמעל 200 ms ועד 500 msמעל 500 ms
CLSעד כמה תוכן גלוי זז באופן לא צפוי0.1 או פחותמעל 0.1 ועד 0.25מעל 0.25

הספים לקוחים מהמדריכים של web.dev ל-LCP (נפתח בכרטיסייה חדשה), ל-INP (נפתח בכרטיסייה חדשה) ול-CLS (נפתח בכרטיסייה חדשה), נכון לאוקטובר 2026.

האחוזון ה-75 פירושו שהתוצאה משקפת את רוב המבקרים ולא רק את המהירים ביותר, ו-Google מפרידה בין מובייל למחשב (נפתח בכרטיסייה חדשה). PageSpeed Insights מעביר דף כשכל שלושת המדדים טובים; כשאין מספיק נתוני INP, הוא שופט לפי LCP ו-CLS בלבד (התיעוד של PageSpeed Insights (נפתח בכרטיסייה חדשה)). Google מציינת שמדדי Core Web Vitals יציבים לא ישתנו יותר מפעם בשנה.

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

למה INP החליף את FID במרץ 2024?

INP החליף את FID כי FID מדד רק את האינטראקציה הראשונה, ורק חלק מהעיכוב שלה, ואילו INP בוחן אינטראקציות לאורך כל הביקור.

Google הודיעה במאי 2023 ש-INP יהפוך ל-Core Web Vital, והשינוי נכנס לתוקף ב-12 במרץ 2024 (נפתח בכרטיסייה חדשה). FID דיווח רק על האינטראקציה הראשונה, ורק על עיכוב הקלט שלה, בלי הזמן שנדרש להרצת מטפלי האירועים או לציור התוצאה. INP עוקב אחרי לחיצות, הקשות ולחיצות על מקשים לאורך כל הביקור ומדווח על הארוכה שבהן, תוך התעלמות מחריגים; גלילה וריחוף עם העכבר אינם נספרים. משתמשי ה-API של CrUX ושל PageSpeed Insights קיבלו זמן עד 9 בספטמבר 2024 כדי לעבור למדד החדש (web.dev (נפתח בכרטיסייה חדשה)).

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

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

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

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

נתוני מעבדהנתוני שטח
מקורטעינת דף מדומה אחת (Lighthouse, Chrome DevTools, חלק המעבדה ב-PageSpeed Insights)מבקרים אמיתיים ב-Chrome (Chrome UX Report), או ניטור משתמשים אמיתיים משלכם
תנאיםמכשיר ורשת קבועים. בדיקת המובייל של Lighthouse כברירת מחדל (נפתח בכרטיסייה חדשה) משתמשת בפרופיל "Slow 4G" (זמן הלוך-חזור של 150 ms, הורדה במהירות 1.6 Mbps) ובהאטת מעבד פי 4כל המכשירים, הרשתות והמיקומים של המבקרים שלכם
INPלא נמדד בטעינת דף רגילה. Total Blocking Time (TBT) הוא קירוב גסנמדד מאינטראקציות אמיתיות
מתאים במיוחד לניפוי באגים ובדיקת שינוי לפני העלאה לאווירהבנה של מה שהמבקרים מקבלים בפועל

TBT מסכם את החלק בכל משימה ב-main thread שחורג מ-50 ms; web.dev מציע ערך של פחות מ-200 ms בחומרת מובייל ממוצעת, אבל מציין שהוא אינו תחליף ל-INP (web.dev (נפתח בכרטיסייה חדשה)).

שלושה פרטים ב-Chrome UX Report (CrUX) חשובים לחנויות:

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

גם לוח הבקרה של ביצועי האתר ב-Shopify (נפתח בכרטיסייה חדשה) מדווח על LCP, INP ו-CLS של משתמשים אמיתיים באחוזון ה-75, לאורך 30 יום ולא 28, ולכן צפו להבדלים מסוימים לעומת CrUX.

מה מאט את ה-LCP בדפי חנות?

LCP איטי בחנויות בדרך כלל כי התמונה הראשית כבדה מדי, מתגלה מאוחר, או מתעכבת בכוונה בגלל טעינה עצלה או אנימציה.

  • טעינה עצלה של תמונת ה-LCP. לפי web.dev, אסור לעשות זאת לעולם (web.dev (נפתח בכרטיסייה חדשה)). הניתוח שלו של דפי WordPress מצא LCP איטי יותר באחוזון ה-75 באתרים שמשתמשים בטעינה עצלה מובנית, וביטול הטעינה העצלה לתמונות שבחלק העליון של הדף העלים את ההרעה (web.dev (נפתח בכרטיסייה חדשה)).
  • תמונה שמתגלה מאוחר. תמונת hero שמוגדרת כ-background-image ב-CSS, או מוזרקת על ידי סקריפט של סליידר, אינה נמצאת ב-HTML שהדפדפן סורק ראשון. Shopify ממליצה להימנע מרקעי CSS לתוכן hero ומאפקטי fade-in על תמונת ה-LCP (Shopify (נפתח בכרטיסייה חדשה)).
  • עדיפות נמוכה. תמונות נטענות בעדיפות נמוכה עד שהפריסה מסתיימת, ולכן Shopify ממליצה על fetchpriority="high" בתמונת ה-LCP (Shopify (נפתח בכרטיסייה חדשה)). web.dev מציין שהגדרה שלו ליותר מתמונה אחת או שתיים מפחיתה את התועלת שבו (web.dev (נפתח בכרטיסייה חדשה)).
  • CSS וסקריפטים שחוסמים רינדור. גיליונות סגנון גדולים וסקריפטים סינכרוניים ב-<head> מעכבים את הרינדור גם אחרי שהתמונה הגיעה (web.dev (נפתח בכרטיסייה חדשה)).
  • גודל קבצים וגופנים. השתמשו בפורמטים מודרניים, ב-srcset וב-sizes וב-CDN. לגופני רשת, השתמשו בערך font-display שאינו auto או block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

מה גורם ל-INP איטי בדפי חנות?

INP איטי בחנויות פירושו בדרך כלל יותר מדי JavaScript ב-main thread, שרובו מגיע מאפליקציות, מתגי מעקב ומפיצ׳רים של ערכת העיצוב, ולכן הקשות נאלצות לחכות.

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

web.dev ממליץ לפרק משימות ארוכות ולפנות מדי פעם את ה-main thread, לעדכן קודם את המסך ולדחות את השאר, ולשמור על DOM קטן יותר (web.dev (נפתח בכרטיסייה חדשה)). Shopify מוסיפה צעדים שייחודיים לחנויות: לבדוק כל אפליקציה, פיקסל וסקריפט של ערכת העיצוב, לדחות את מה שאינו קריטי, לטעון פיצ׳רים רק בעת אינטראקציה, ולכבות קטעי קוד נגד הבהוב (anti-flicker) של בדיקות A/B כשאין בדיקה פעילה (Shopify (נפתח בכרטיסייה חדשה)).

מה גורם לתזוזות פריסה בדפי מוצר וקטגוריה?

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

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

תזוזות בתוך 500 ms מקלט של המשתמש אינן נספרות, אבל תזוזות בזמן גלילה כן נספרות, וכלי מעבדה מפספסים אותן לעיתים קרובות (web.dev (נפתח בכרטיסייה חדשה)). הגדירו לתמונות width ו-height או aspect-ratio ב-CSS, שמרו מקום לווידג׳טים, הציגו באנרים כשכבה מעל התוכן, צמצמו תזוזות של החלפת גופנים בעזרת size-adjust, והנפישו בעזרת transform במקום top או left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

איך משפרים Core Web Vitals ב-Shopify?

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

בדקו את הנתונים בממשק הניהול

סיכום מופיע בדף Online Store > Themes, והדוחות המלאים של LCP, INP ו-CLS נמצאים תחת Analytics > Reports. הנתונים עשויים להתעכב עד 36 שעות, והמצב הפרטי (private mode) חייב להיות כבוי (Shopify Help Center (נפתח בכרטיסייה חדשה)).

שליטה בטעינת תמונות ב-Liquid

המסנן image_tag טוען בטעינה עצלה תמונות ב-sections שנמצאים נמוך יותר בדף, אלא אם מגדירים preload (התיעוד של image_tag (נפתח בכרטיסייה חדשה)): טעינה מיידית ל-sections 1 עד 3, וטעינה עצלה מ-section 4 והלאה. מכיוון ש-section.index הוא nil בעורך ערכת העיצוב, בדקו עם > 3 ולא עם <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

ברשתות מוצרים, Shopify מציעה לטעון באופן מיידי רק את הכרטיסים הראשונים (למשל forloop.index <= 4) (Shopify (נפתח בכרטיסייה חדשה)). השתמשו ב-preload: true במשורה; Shopify ממליצה לבצע preload רק למשאב אחד או שניים שמתגלים מאוחר.

הסירו את מה שאפליקציות משאירות אחריהן

כבו הטמעות אפליקציה (app embeds) שאינן בשימוש תחת Online Store > Edit theme > App embeds (Shopify Help Center (נפתח בכרטיסייה חדשה)). הסרת אפליקציה מסירה את בלוקי האפליקציה שלה, אבל אפליקציות שערכו ישירות את קובצי ערכת העיצוב עלולות להשאיר "קוד רפאים" (ghost code), שלדברי Shopify עלול לגרום לבעיות איכות וביצועים (Shopify (נפתח בכרטיסייה חדשה)). Shopify גם מציינת שתגי script יפסיקו לפעול ב-1 במרץ 2027. לגבי גופנים, Shopify ממליצה על ה-CDN שלה או על גופני מערכת, ולא על שירותי גופנים חיצוניים (Shopify (נפתח בכרטיסייה חדשה)).

איך משפרים Core Web Vitals ב-WooCommerce?

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

  • השאירו את הטיפול בתמונות של הליבה. מאז WordPress 6.3 (שיצאה ב-8 באוגוסט 2023), הליבה מוסיפה fetchpriority="high" לתמונה שסביר שתהיה תמונת ה-LCP (לפחות 50,000 פיקסלים רבועים כברירת מחדל) ומדלגת על טעינה עצלה בשלוש תמונות התוכן הראשונות (Make WordPress Core (נפתח בכרטיסייה חדשה)). אם תוסף אופטימיזציה מוסיף טעינה עצלה משלו, בדקו שהוא מחריג את תמונת ה-hero ואת תמונת המוצר הראשית.
  • שמרו דפים במטמון, לא סלי קניות. המדריך של WooCommerce ממליץ על מטמון דפים בשרת או בתוסף ועל CDN, תוך השארת דפי הסל והקופה מחוץ למטמון (התיעוד למפתחים של WooCommerce (נפתח בכרטיסייה חדשה)).
  • בדקו את cart fragments. מאז WooCommerce 7.8, הסקריפט של cart fragments נטען רק במקומות שבהם יש וידג׳ט Cart, אבל חלק מערכות העיצוב מקודדות את הווידג׳ט הזה באופן קשיח. הבלוק Mini-Cart אינו משתמש ב-cart fragments (הבלוג למפתחים של WooCommerce (נפתח בכרטיסייה חדשה)).
  • אתרו תוספים כבדים. WooCommerce מציעה את Query Monitor לאיתור תוספים איטיים, וממליצה לדחות JavaScript שאינו קריטי.

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

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

כמה זמן לוקח עד שהתיקונים ניכרים?

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

הריצו את בדיקת המעבדה כמה פעמים לפני השינוי ואחריו, כי תוצאות של ריצה בודדת משתנות, ואז עקבו אחרי נתוני השטח ב-PageSpeed Insights, בדוח Core Web Vitals של Search Console או בדוחות של Shopify. הסריקה החינמית נותנת תמונה ראשונה בתוך כדקה. דוח ביצועים מריץ בדיקת מעבדה במובייל בתנאים מוגבלים (slow 4G, האטת מעבד פי 4) ומוסיף נתוני שטח מ-Chrome UX Report, כולל INP כשיש ל-Google מספיק נתונים על החנות שלכם.

שאלות נפוצות

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

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

למה PageSpeed Insights לא מציג נתוני שטח לחנות שלי?

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

האם צריך ציון Lighthouse של 90 ומעלה כדי לעבור?

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

האם לטעון את כל תמונות המוצר בטעינה עצלה?

לא. השתמשו בטעינה עצלה לתמונות שמתחת למסך הראשון, אבל טענו את תמונת ה-hero ואת תמונת המוצר הראשית באופן מיידי, עם fetchpriority="high" על אחת מהן.

למה התוצאות במובייל גרועות יותר מאשר במחשב?

Google מודדת מובייל ומחשב בנפרד, ולטלפונים יש מעבדים ורשתות איטיים יותר. בדיקת המובייל של Lighthouse מדמה זאת בעזרת פרופיל Slow 4G והאטת מעבד פי 4.

מקורות

כל המדריכים