Core Web Vitals בעברית: LCP, INP ו-CLS – מה זה ואיך משפרים בוורדפרס

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

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

⏱ זמן קריאה: 18 דקות · זמן תיקון: שעה עד יום, לפי האתר · רמת קושי: בינוני · נבדק לאחרונה: 06.11.2026 (מול web.dev ומרכז העזרה של Search Console)

עובדות מפתח, נכון ל-6.11.2026:

• ספי "טוב" באחוזון ה-75: LCP עד 2.5 שניות, INP עד 200 מילישניות, CLS עד 0.1 (לפי web.dev).
• INP החליף את FID כמדד ליבה ב-12 במרץ 2024 (web.dev).
• נתוני השטח מסכמים 28 ימים, ואימות תיקון ב-Search Console נמשך 28 ימים (מרכז העזרה של Search Console).
• סטטוס של קבוצת כתובות נקבע לפי המדד הגרוע ביותר שלה, בנפרד למובייל ולמחשב.
• השפעת האחסון (הערכה שלנו): גבוהה על LCP דרך ה-TTFB, נמוכה על INP, כמעט אפסית על CLS.
• מדידה שלנו מישראל: ping לשרת Vultr בתל אביב 9 מילישניות בממוצע, מול 72 בפרנקפורט (6.11.2026, חיבור ביתי, אינדיקטיבי).

מה זה Core Web Vitals?

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

המדדים נמדדים על גולשים אמיתיים ב-Chrome, דרך מאגר הנתונים CrUX, ולא בבדיקת מעבדה. גוגל בודקת את האחוזון ה-75: אם 75% מהביקורים בעמוד טובים בכל שלושת המדדים, העמוד עובר. כך עמוד לא "נכשל" בגלל כמה גולשים עם טלפון ישן ברכבת, אבל גם לא עובר בזכות מחשב מהיר אחד.

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

הספים לפי web.dev ו-PageSpeed Insights, נכון לנובמבר 2026. INP החליף במרץ 2024 את המדד הקודם, FID, שמדד רק את העיכוב בלחיצה הראשונה. INP מחמיר יותר: הוא מסתכל על כל האינטראקציות בביקור.

איך בודקים Core Web Vitals באתר שלכם?

בודקים בשני מקומות: דוח Core Web Vitals ב-Search Console מראה איפה הבעיה באתר כולו, ו-PageSpeed Insights מסביר מה גורם לה בעמוד מסוים. כך עושים את זה:

1. היכנסו ל-Search Console, לדוח Core Web Vitals. שם רואים קבוצות של כתובות עם אותה בעיה, בנפרד למובייל ולמחשב. זה הכלי הכי טוב לדעת איפה הבעיה באתר כולו.
2. קחו כתובת אחת מכל קבוצה בעייתית והריצו אותה ב-PageSpeed Insights. החלק העליון מראה את נתוני השטח, והחלק התחתון (Lighthouse) מראה מה גורם לבעיה.
3. ב-PageSpeed, פתחו את האבחון של המדד שנכשל. למשל, ל-LCP תראו מה האלמנט הגדול ואיך מתחלק הזמן עד שהוא מופיע.

הסבר מלא על הכלים, על ההבדל בין נתוני שטח למעבדה ועל הציון מ-0 עד 100 נמצא במדריך בדיקת מהירות אתר. כמה כסף עולה אתר איטי? ראו כמה עולה אתר איטי.

איך קוראים את דוח Core Web Vitals ב-Search Console?

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

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

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

מצב האימות	מה זה אומר
Not started	אף כתובת עם הבעיה לא נכללה עדיין בבקשת אימות
Started	המעקב התחיל, ועד עכשיו לא נמצאו כתובות עם הבעיה
Looking good	כל מה שנבדק עד עכשיו תקין
Passed	כל הכתובות עברו, והבעיה סגורה
Failed	נמצאו כתובות שעדיין נכשלות. מתקנים ומתחילים מעקב חדש

מה זה LCP ואיך משפרים אותו בוורדפרס?

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

את הזמן של LCP אפשר לפרק לארבעה חלקים, וכל אחד מתוקן אחרת:

חלק	מה קורה	מי אשם בדרך כלל
זמן תגובת השרת (TTFB)	עד שמגיע הבייט הראשון של ה-HTML	האחסון, חוסר בקאש, מרחק
עיכוב בגילוי המשאב	עד שהדפדפן מבין שצריך את התמונה	תמונת רקע ב-CSS, Lazy Load על התמונה הראשית
זמן הורדת המשאב	הורדת התמונה עצמה	תמונה כבדה, בלי WebP/AVIF, בלי CDN
עיכוב ברינדור	עד שהתמונה מוצגת בפועל	CSS ו-JavaScript שחוסמים את הרינדור

איך מוצאים את אלמנט ה-LCP: דוגמה מעשית

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

1. הריצו את העמוד ב-PageSpeed Insights, בלשונית המובייל.
2. בחלק האבחון (Lighthouse) סננו לפי LCP ופתחו את האבחון Largest Contentful Paint element. תראו איזה אלמנט נבחר ואיך הזמן מתחלק בין ארבעת החלקים.
3. לבדיקה מקומית, פתחו את כלי המפתחים של Chrome (F12) בלשונית Performance. בתצוגת המדדים החיים מופיע ה-LCP שלכם לצד ה-LCP של גולשים אמיתיים מ-CrUX, והקלטה של טעינה מציגה את הפירוק לחלקים.
4. חפשו את כתובת הקובץ של האלמנט במפל הטעינה (Network) ובדקו מתי בדיוק התחילה הבקשה אליו.

לפי web.dev, בעמוד מאוזן ה-TTFB וזמן ההורדה לוקחים כל אחד כ-40% מה-LCP, ושני העיכובים פחות מ-10% כל אחד. זו הנחיה ולא חוק, אבל היא מראה מהר איפה לחפש.

דוגמה להמחשה (חישוב, לא מדידה של אתר אמיתי): דף בית של עסק עם LCP של 3.6 שניות במובייל. הפירוק: TTFB של 1.1 שניות, עיכוב בגילוי של 1.4 שניות, הורדה של 0.8 שניות ועיכוב ברינדור של 0.3 שניות. מה שבולט הוא העיכוב בגילוי, כמעט 40% מהזמן במקום פחות מ-10%. הסיבה הנפוצה: התמונה הראשית מוגדרת כרקע ב-CSS של בונה העמודים, או שתוסף סימן אותה ל-Lazy Load. מעבירים אותה לתגית img רגילה בלי טעינה עצלה, וה-LCP יכול לרדת לכ-2.3 שניות עוד לפני שנוגעים בשרת.

שני כלים עוזרים לדפדפן למצוא את התמונה מוקדם. הראשון הוא התכונה fetchpriority="high" על תגית התמונה הראשית, ורק על תמונה אחת או שתיים, אחרת היא מאבדת משמעות. השני הוא <link rel="preload">, כשהתמונה מוגדרת רק בקובץ CSS או JavaScript. ותמיד: לא עושים Lazy Load לתמונת ה-LCP.

שימו לב ב-Breeze: התבנית Standard של Breeze מפעילה Lazy Load Images. אחרי שהפעלתם אותה, ודאו ב-PageSpeed שתמונת ה-LCP לא נטענת בעצלות.

מה עושים, לפי סדר ההשפעה:

1. קאש עמודים בצד השרת. אם ה-TTFB לבד הוא 1.5 שניות, נשארה שנייה אחת לכל השאר. בשרתי קלאודוויז (Cloudways) יש Varnish ו-Breeze; ההסבר המלא במדריך TTFB גבוה.
2. לא לעשות Lazy Load לתמונה הראשית. טעינה עצלה מתאימה לתמונות שמתחת לקפל, לא לתמונה שהגולש רואה ראשונה. וורדפרס מוסיפה מאז גרסה 6.3 עדיפות טעינה גבוהה לתמונה שנראית כמו ה-LCP, אבל בוני עמודים ותוספים עוקפים את זה לפעמים.
3. להקטין את התמונה: פורמט WebP או AVIF, ורוחב שמתאים למסך. תמונה של 3,000 פיקסלים לבאנר במובייל היא הסיבה הנפוצה ביותר ל-LCP גרוע.
4. להימנע מסליידר בראש העמוד. סליידרים טוענים כמה תמונות וסקריפט לפני שהראשונה מוצגת.
5. CDN לקבצים הסטטיים, כך שהתמונה מגיעה מנקודה קרובה לגולש. בקלאודוויז אפשר להוסיף Cloudflare Enterprise: קלאודוויז וקלאודפלייר אנטרפרייז.

מרחק השרת הוא חלק מה-TTFB. כל בקשה שלא מוגשת מקאש בקצה (CDN) עוברת את כל הדרך לשרת וחזרה. במדידה שעשינו מחיבור ביתי בישראל ב-6.11.2026, שרת Vultr בתל אביב ענה ל-ping בממוצע תוך 9 מילישניות, מול 72 מילישניות אצל אותו ספק בפרנקפורט. זו מדידה אינדיקטיבית ממקום אחד ולא מבחן ביצועים, אבל היא מסבירה למה לאתר שהקהל שלו בישראל כדאי לשקול שרת בתל אביב. השיטה והמספרים המלאים: בדיקת זמני תגובה לשרתים מישראל.

מה זה INP ואיך משפרים אותו בוורדפרס?

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

הסיבה כמעט תמיד בדפדפן, לא בשרת: יותר מדי JavaScript שרץ על ה-Thread הראשי ותופס אותו כשהגולש לוחץ. לכן אחסון מהיר יותר כמעט לא משפר INP. זה חשוב לדעת לפני שמחליפים אחסון בגלל המדד הזה.

1. מפו את הסקריפטים: ב-PageSpeed, באבחון "Reduce JavaScript execution time", תראו אילו קבצים כבדים. ברוב האתרים הישראליים אלה צ'אטים, תוספי נגישות, פיקסלים של פייסבוק וטיקטוק, ותגיות של Tag Manager.
2. דחו סקריפטים לא חיוניים עד אחרי הטעינה או עד אינטראקציה ראשונה. ב-Breeze יש אפשרות לדחות ביצוע JavaScript; ההגדרות במדריך Breeze. בדקו אחרי כל שינוי שהטפסים, התפריט והעגלה עדיין עובדים.
3. הורידו תוספים שמוסיפים סקריפט לכל עמוד כשהם נחוצים רק בעמוד אחד, למשל טופס צור קשר שנטען גם בבלוג.
4. בוני עמודים: אלמנטור ודומיו מוסיפים הרבה קוד. השתמשו בפחות ווידג'טים מונפשים, וכבו פיצ'רים שאתם לא משתמשים בהם.

INP בחנות ווקומרס: פילטרים בעמוד קטגוריה, וריאציות מוצר ועדכון עגלה ב-AJAX הם נקודות חמות. כאן כן יש חלק לשרת: אם הלחיצה שולחת בקשה לשרת ומחכה לתשובה, שרת איטי מאריך את התגובה. Redis ו-Object Cache Pro עוזרים לבקשות כאלה: Object Cache Pro בקלאודוויז.

INP בוורדפרס: איפה זה נתקע בפועל

web.dev מפרקת כל אינטראקציה לשלושה שלבים. הפירוק עוזר להבין מה לתקן:

שלב	מה קורה	דוגמה בוורדפרס
עיכוב קלט (Input delay)	מהלחיצה ועד שהקוד שמטפל בה מתחיל לרוץ	הגולש לוחץ על התפריט בזמן שסקריפט של צ'אט או פיקסל עדיין נטען ותופס את הדפדפן
זמן עיבוד (Processing duration)	הזמן שהקוד של הלחיצה עצמה רץ	פילטר בעמוד קטגוריה שמסנן מאות מוצרים בדפדפן בבת אחת
עיכוב הצגה (Presentation delay)	מסיום הקוד ועד שהמסך מצויר מחדש	עמוד ענק עם אלפי אלמנטים (DOM גדול) מבונה עמודים, שכל שינוי בו מחייב חישוב מחדש

• ווקומרס ו-Cart Fragments: הסקריפט wc-cart-fragments מעדכן את העגלה הקטנה דרך admin-ajax. מגרסה 7.8 ווקומרס כבר לא טוענת אותו בכל עמוד, אלא רק כשווידג'ט העגלה מוצג, או כשתוסף או תבנית דורשים אותו. אם הוא עדיין מופיע בכל עמוד באתר שלכם, בדקו מי טוען אותו. ווקומרס ממליצה לעבור לבלוק Mini-Cart, שלא משתמש בו.
• Delay All JavaScript ב-Breeze: האפשרות דוחה את כל הסקריפטים עד שהגולש מתחיל לפעול בעמוד, וכך מפנה את הדפדפן בזמן הטעינה. היא חלק מהתבנית Expert, ולכן בדקו אותה קודם ב-סביבת Staging. סקריפטים שחייבים לרוץ מיד, כמו תפריט או עגלה, מוסיפים לשדה List of scripts not to delay. אי אפשר להפעיל אותה יחד עם Combine JS.
• אלמנטור ובוני עמודים: כל אנימציה, סליידר וטאב מוסיפים קוד ואלמנטים לעמוד. עמוד עם פחות אלמנטים מגיב מהר יותר, ולכן לפעמים המהלך המשתלם הוא לפשט את העמוד, ולא להוסיף עוד תוסף אופטימיזציה.

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

מה זה CLS ואיך משפרים אותו בוורדפרס?

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

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

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

פונטים בעברית בלי קפיצות

פונטים עבריים הם מקור נפוץ ל-CLS ול-LCP איטי באתרים ישראליים, כי רובם לא מותקנים במכשיר ונטענים מבחוץ. ההנחיות של web.dev, בתרגום לעבודה בוורדפרס:

1. רק WOFF2. זה הפורמט עם הדחיסה הטובה ביותר, והוא נתמך בכל הדפדפנים המודרניים. אין צורך בקבצי TTF או WOFF נוספים.
2. preload רק לפונט הראשי. טעינה מוקדמת עוזרת כשהפונט מוגדר בקובץ CSS חיצוני, אבל היא לוקחת רוחב פס משאר העמוד. משקל אחד או שניים, לא כל המשפחה.
3. בחרו font-display בכוונה. swap מציג מיד טקסט בפונט גיבוי ומחליף כשהפונט מגיע, אבל החלפה מאוחרת יוצרת קפיצה. optional מחכה עד כ-100 מילישניות, ואם הפונט לא הגיע, העמוד נשאר עם פונט הגיבוי ובלי קפיצה.
4. התאימו את פונט הגיבוי. המאפיין size-adjust ב-CSS מגדיל או מקטין את פונט הגיבוי, כך שהשורות יתפסו בערך את אותו רוחב כמו הפונט העברי והקפיצה ברגע ההחלפה תקטן.
5. רק התווים שצריך. עם unicode-range (הטווח העברי ב-Unicode הוא U+0590–05FF) הדפדפן מוריד קובץ רק כשהעמוד באמת משתמש בתווים האלה. ודאו שהרישיון של הפונט מאפשר לחתוך אותו.

ב-Breeze יש אפשרות Host Files Locally ל-Google Fonts (בתבנית Advanced), שמגישה את קבצי הפונט מהשרת שלכם במקום מהשרתים של גוגל. web.dev מציינת שאירוח עצמי לא תמיד מהיר יותר, אז מדדו לפני ואחרי. עוד על אתרים בעברית: וורדפרס בעברית ו-RTL. מדריך מלא לפונטים בעברית: פונטים בעברית שמאטים את האתר.

האם החלפת אחסון תשפר את Core Web Vitals?

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

מדד	השפעת האחסון	מה האחסון תורם	מה נשאר עליכם
LCP	גבוהה	TTFB נמוך, קאש עמודים, CDN, HTTP/2–3, דחיסה	תמונה ראשית קלה, בלי סליידר
INP	נמוכה	תשובות AJAX מהירות (Redis)	פחות JavaScript, פחות תוספים
CLS	כמעט אפסית	אין	מידות, מקום שמור, פונטים

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

למה Core Web Vitals במובייל גרועים יותר מבמחשב?

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

• בבדיקת המעבדה של PageSpeed, המובייל מדמה מכשיר בינוני (Moto G4) ברשת סלולרית, והמחשב מדמה מחשב עם חיבור קווי. אותו עמוד יקבל כמעט תמיד ציון נמוך יותר במובייל.
• בנתוני השטח ההבדל מגיע מהמכשירים האמיתיים. מעבד חלש מריץ JavaScript לאט יותר, ולכן INP נכשל קודם כול במובייל. רשת סלולרית מאריכה גם את ה-LCP.
• העיצוב שונה: במובייל אלמנט ה-LCP יכול להיות אחר, למשל כותרת במקום תמונה רחבה, או תמונה אחרת שמוגדרת למסך צר. בדקו את האלמנט בכל מכשיר בנפרד.

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

למה Lighthouse ירוק ו-Search Console אדום?

כי Lighthouse מודד טעינה אחת במעבדה, בלי לחיצות ובלי גלילה, ו-Search Console מסכם 28 ימים של גולשים אמיתיים. לפי web.dev, אלה הסיבות הקבועות לפער:

• INP לא נמדד במעבדה. Lighthouse מודד TBT, שלא כולל את הרגע שבו גולש אמיתי לוחץ. אם INP אדום בשטח, ציון ירוק במעבדה לא מבטיח כלום.
• CLS אחרי גלילה. בדיקת המעבדה לא גוללת. תמונות ו-iframe בלי מידות, באנרים שנטענים בהמשך העמוד ופרסומות מותאמות אישית זזים רק אצל גולשים אמיתיים.
• אלמנט LCP אחר. גודל המסך, משתמש מחובר, בדיקות A/B או פופאפ יכולים לשנות מה האלמנט הגדול בעמוד.
• קאש ומכשיר. המעבדה טוענת עמוד בלי קאש, ממכשיר אחד וממיקום אחד. בשטח יש גולשים חוזרים עם קאש, וגם גולשים עם טלפון ישן בקליטה חלשה.

הפתרון: למדוד בעצמכם (RUM). RUM (Real User Monitoring) היא מדידה של הגולשים שלכם, באתר שלכם, עם פרטים שאין ב-CrUX: על איזה אלמנט לחצו, ואיזה אלמנט היה ה-LCP. הדרך הפשוטה היא הספרייה web-vitals של צוות Chrome, כ-3KB אחרי דחיסה. גרסת ה-attribution שלה מוסיפה לכל מדידה את האלמנט שגרם לה (interactionTarget ב-INP ו-target ב-LCP), ואפשר לשלוח את הנתונים כאירועים ל-Google Analytics 4. למפתחים, בערך כך:

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

function send({name, delta, id, attribution}) {
  gtag('event', name, {
    value: delta,
    metric_id: id,
    debug_target: attribution.interactionTarget || attribution.target || ''
  });
}

onLCP(send);
onINP(send);
onCLS(send);

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

אילו טעויות נפוצות מונעות שיפור ב-Core Web Vitals?

"תיקנתי, ו-Search Console עדיין אדום": נתוני השטח מסכמים 28 ימים. אחרי תיקון לחצו בעמוד הבעיה על Start Tracking וחכו לסוף תקופת המעקב של 28 ימים.

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

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

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

שאלות נפוצות

מדריכים קשורים

• בדיקת מהירות אתר: PageSpeed, GTmetrix ומה המספרים אומרים
• TTFB גבוה – מה זה ולמה האחסון הוא החשוד הראשון
• איך לשפר את מהירות אתר הוורדפרס
• ביקורת קלאודוויז
• כל המדריכים בתחום: ביצועים ומהירות

מקורות

• Web Vitals (web.dev)
• Optimize Largest Contentful Paint (web.dev)
• Optimize Interaction to Next Paint (web.dev)
• Why lab and field data can be different (web.dev)
• Best practices for fonts (web.dev)
• INP is officially a Core Web Vital (web.dev)
• Core Web Vitals report (Search Console Help)
• About PageSpeed Insights (Google)
• web-vitals library (GoogleChrome, GitHub)
• Best practices for the use of the cart fragments API (WooCommerce)
• How to configure Breeze (Cloudways Knowledge Base)
• מדידת זמני תגובה מישראל: מדידה שלנו, 6.11.2026 (השיטה והנתונים)

מקורות רשמיים: Web Vitals, Largest Contentful Paint, Interaction to Next Paint ו-Cumulative Layout Shift (web.dev), About PageSpeed Insights (Google), Core Web Vitals report (Search Console Help), Optimize LCP, Optimize INP, Lab and field data differences, Font best practices ו-INP is a Core Web Vital (web.dev), web-vitals (GoogleChrome), Cart Fragments API (WooCommerce), How to configure Breeze (Cloudways Knowledge Base). נבדק 06.11.2026. נכתב ונבדק על ידי עשהאל דרייר · עודכן: 06.11.2026

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