Core Web Vitals לחנות eCommerce - מה לתקן ראשון

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

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

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

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

להבין את שלושת המדדים דרך חנות אמיתית

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

INP, או Interaction to Next Paint, מודד תגובה לאינטראקציות לאורך הביקור. בחנות זה קשור ללחיצה על פילטר, פתיחת cart drawer, בחירת מידה, שינוי כמות, חיפוש פנימי או לחיצה על "הוסף לעגלה". אם JS כבד חוסם את הדפדפן, הלקוח מרגיש שהאתר תקוע.

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

טבלת יעדים:

| מדד | טוב | דורש שיפור | גרוע | |---|---:|---:|---:| | LCP | עד 2.5 שניות | עד 4 שניות | מעל 4 שניות | | INP | עד 200ms | עד 500ms | מעל 500ms | | CLS | עד 0.1 | עד 0.25 | מעל 0.25 |

חשוב להבדיל בין lab data לבין field data. Lighthouse נותן בדיקה בתנאים מוגדרים. Search Console ו-CrUX מבוססים על משתמשים אמיתיים. אם Lighthouse מצוין אבל Search Console רע, הבעיה כנראה מופיעה במכשירים, אזורים או תרחישים שהבדיקה המקומית לא מחקה. בישראל זה נפוץ: חלק מהלקוחות גולשים על 4G עמוס, מכשירים ישנים או רשת ביתית לא יציבה.

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

LCP: תמונת hero, גלריית מוצר וטעינה ראשונית

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

גורמים נפוצים ל-LCP איטי:

• תמונת hero במשקל 800KB עד 2MB.
• תמונת מוצר ראשית שלא עוברת resize אמיתי.
• lazy loading על תמונה שצריכה להיטען מיד.
• CSS קריטי שמגיע מאוחר.
• פונט חיצוני שחוסם תצוגת טקסט.
• שרת איטי או TTFB גבוה.

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

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

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

סדר תיקון מומלץ ל-LCP:

1. זהו את אלמנט ה-LCP ב-PageSpeed Insights. 2. כווצו והמירו תמונות ל-WebP או AVIF אם נתמך. 3. ודאו שהתמונה הראשית לא נטענת ב-lazy load. 4. השתמשו ב-preload רק לאלמנט LCP חשוב אחד. 5. הסירו סליידר כבד אם תמונה סטטית עושה את אותה עבודה. 6. בדקו TTFB אם הכל עדיין איטי.

דוגמה: חנות אופנה מציגה בעמוד הבית וידאו hero של 9MB. הוידאו נראה יפה, אבל במובייל הוא דוחה את הופעת הכותרת והמוצרים. החלפה לתמונה WebP של 180KB, עם כפתור שמוביל לקטגוריה, יכולה להוריד LCP באופן ברור וגם לשפר המרות. לקוחות לא נכנסים כדי להעריך אפקט. הם רוצים לראות קולקציה.

INP: למה לחיצה על פילטר או עגלה מרגישה תקועה

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

גורמים נפוצים ל-INP גבוה:

• cart drawer עם אנימציה כבדה.
• אפליקציות המלצות מוצרים.
• אפליקציות ביקורות שטוענות הרבה JS.
• פילטרים שמרנדרים מחדש מאות מוצרים.
• Google Tag Manager עמוס בתגים.
• חיפוש פנימי שמריץ logic בצד לקוח.

בחנות Shopify, כל אפליקציה רוצה להיטען בכל עמוד. אפליקציית pop-up, אפליקציית upsell, אפליקציית ביקורות, אפליקציית משלוחים, אפליקציית heatmap ותוסף צ'אט. כל אחת נראית סבירה בנפרד. יחד הן חוסמות thread ומאטות לחיצות. תיקון INP מתחיל ברשימת סקריפטים, לא בקוד המוצר.

ב-WooCommerce, בעיות מגיעות מתוספים כפולים. תוסף variation swatches, תוסף quick view, תוסף wishlist, תוסף ajax cart ותוסף checkout יכולים לעבוד יחד בצורה כבדה. אם כל לחיצה מפעילה כמה handlers, המשתמש מרגיש השהיה. לפעמים הסרה של quick view שלא משתמשים בו משפרת יותר מאופטימיזציה קטנה.

בדיקת INP צריכה להיות ידנית ומעשית. פתחו עמוד קטגוריה במובייל, הפעילו CPU throttling בכלי פיתוח, ולחצו על פילטר. פתחו מוצר, החליפו צבע, בחרו מידה, הוסיפו לעגלה, פתחו cart drawer וסגרו. אם יש delay מורגש, יש בעיה גם לפני שראיתם מספר.

מה מתקנים ראשון:

• הסרת סקריפטים שלא תורמים להכנסות.
• טעינת אפליקציות רק בעמודים שבהם הן דרושות.
• דחיית scripts שיווקיים אחרי אינטראקציה.
• צמצום re-render של רשימות מוצרים.
• הפחתת אנימציות cart drawer.
• פירוק משימות JS ארוכות.

תגים שיווקיים דורשים זהירות. לא מכבים Meta Pixel או Google Ads conversion בלי להבין את ההשפעה. כן בודקים אם יש כפילות, tags ישנים, heatmaps לא פעילים, או scripts שנשארו מקמפיין שנגמר. מנהל שיווק ומפתח צריכים לעבוד יחד. אחרת כל אחד מאשים את השני, והאתר נשאר איטי.

CLS: התזוזות הקטנות שמפילות אמון

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

גורמים נפוצים:

• תמונות בלי width ו-height.
• גריד מוצרים בלי aspect ratio קבוע.
• פונט Google שמחליף פונט ברירת מחדל.
• banner חינמי שמופיע אחרי טעינה.
• sticky header שמשנה גובה.
• אזור ביקורות שנטען מאוחר מעל כפתור קנייה.

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

פונטים הם מקור שקט לבעיות. חנות בעברית עם Google Fonts יכולה להציג פונט מערכת ואז להחליף לפונט מותגי. אם ההחלפה משנה רוחב וגובה טקסט, הכותרות זזות. אפשר להשתמש ב-font-display מתאים, לבחור פונט fallback קרוב, או לצמצם משקלי פונט. אין סיבה לטעון 8 משקלים בעברית בשביל חנות קטנה.

באנרים צריכים מקום שמור. אם יש רצועת "משלוח חינם מעל 299 ₪", היא צריכה להופיע מיד או לקבל גובה קבוע מראש. Pop-up שמופיע באמצע הוא בעיה אחרת, אבל banner שדוחף תוכן הוא CLS קלאסי. אותו דבר לגבי הודעת cookies, תיבת קופון או הודעת "נשארו 3 במלאי".

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

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

סדר עדיפויות: מה לתקן ראשון כשאין שבוע פנוי

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

סדר עבודה מומלץ:

1. בדקו Search Console לפי mobile. 2. זהו קבוצות URL גרועות: מוצר, קטגוריה, בית או בלוג. 3. בחרו 5 URLים עם ערך עסקי גבוה. 4. בדקו PageSpeed Insights ו-Lighthouse לכל URL. 5. רשמו את אלמנט LCP ואת האינטראקציה האיטית. 6. תקנו שינוי אחד עד שלושה בכל גל.

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

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

יש מקרים שבהם הסדר משתנה. אם Search Console מציג CLS גרוע בכל האתר בגלל banner אחד, מתקנים אותו קודם. אם עמודי מוצר נטענים מהר אבל cart drawer תקוע ל-900ms, מטפלים ב-INP. אם TTFB גבוה בכל האתר, שיפור תמונות לא יספיק. צריך לבדוק אחסון, cache ו-CDN.

בישראל, מובייל צריך לקבל משקל גבוה. לקוחות נכנסים דרך WhatsApp, Instagram, Google Ads וחיפוש אורגני. חלקם ברשת סלולרית לא יציבה. אם האתר עובד נהדר ב-desktop אבל מקרטע באנדרואיד בינוני, אתם מפסידים קהל אמיתי. בדיקה על iPhone חדש בלבד אינה מדד מספיק.

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

PageSpeed Insights הוא נקודת פתיחה טובה כי הוא משלב נתוני שדה אם קיימים עם בדיקת lab. Search Console מציג קבוצות URL, וזה חשוב לחנויות עם הרבה עמודים דומים. Lighthouse בתוך Chrome עוזר להבין פרטים. WebPageTest יכול לתת מבט עמוק יותר על טעינה, waterfall ותמונות.

אבל כלים לא מחליפים בדיקת קנייה. הבדיקה צריכה להתבצע גם באנדרואיד בינוני. פתחו את האתר כמו לקוח:

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

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

כדאי לנהל לוח תיקונים פשוט:

| בעיה | עמוד | מדד | השפעה עסקית | פעולה | |---|---|---|---|---| | תמונת hero כבדה | בית | LCP | גבוהה | להחליף ל-WebP | | cart drawer איטי | מוצר | INP | גבוהה | להסיר אנימציה כבדה | | banner קופץ | כל האתר | CLS | בינונית | לשמור גובה | | reviews script | מוצר | INP | בינונית | לטעון אחרי תוכן | | פונט כבד | כל האתר | LCP/CLS | נמוכה עד בינונית | לצמצם משקלים |

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

מתי לא לרדוף אחרי 100

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

אם תיקון מסוים חוסך 50ms אבל דורש שבוע פיתוח וסיכון ל-checkout, הוא כנראה לא ראשון בתור. אם הסרת סליידר חוסכת 1.2 שניות ומשפרת לחיצה לקטגוריה, זה טיפול טוב. אם דחיית tag שוברת מדידת רכישות, צריך למצוא פתרון מדידה אחר לפני שינוי production.

מדדי יעד סבירים לחנות:

• כל עמודי הכסף במצב Good או קרובים אליו.
• LCP במובייל עד 2.5 שניות בעמודים מרכזיים.
• הוספה לעגלה בלי השהיה מורגשת.
• אין תזוזה באזור כפתור קנייה.
• תמונות מוצר חדות אבל לא כבדות.
• scripts שיווקיים מתועדים ומבוקרים.

תיקון Core Web Vitals טוב משלב מפתח, SEO ומנהל שיווק. מפתח רואה JS ותמונות. SEO רואה Search Console וקבוצות URL. מנהל שיווק יודע אילו tags ואפליקציות באמת דרושים. כאשר כולם עובדים יחד, התיקונים לא נשארים ברמת "לכווץ תמונות".

שאלות נפוצות

רוצים לבדוק התאמה?

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

לבדיקת Core Web Vitals לחנות

להתקשרות מהירה