Core Web Vitals הם שלושה מדדים שגוגל משתמשת בהם כדי למדוד את חוויית הטעינה של עמוד: LCP (כמה מהר מופיע התוכן הראשי), INP (כמה מהר העמוד מגיב לאינטראקציה) ו-CLS (כמה התוכן קופץ בזמן הטעינה). עמוד נחשב טוב כש-LCP הוא עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1, אצל 75% מהגולשים. רוב האתרים לא עומדים בזה בטלפון — והסיבות כמעט תמיד בקוד, לא בשרת.
במאמר הזה אני עובר על שלושת המדדים מנקודת המבט של מי שכותב את הקוד: מה גורם לכל בעיה, איך מאבחנים אותה, ומה מתקן אותה בלי לשבור את האתר.
המצב בפועל: רוב האתרים נכשלים בטלפון
לפי פרק הביצועים בדוח Web Almanac 2025 של HTTP Archive, שמבוסס על נתוני גולשים אמיתיים מיולי 2025, רק 48% מהאתרים עומדים בכל שלושת המדדים בטלפון (56% במחשב). זה שיפור — ב-2023 המספר בטלפון היה 36% — אבל עדיין יותר ממחצית האתרים נכשלים.
| מדד | מה הוא מודד | סף "טוב" | אתרים עם ציון טוב בטלפון (2025) |
|---|---|---|---|
| LCP | זמן עד הצגת האלמנט הגדול בתצוגה הראשונה | ≤ 2.5s | 62% |
| INP | זמן התגובה לאינטראקציות לאורך השימוש בעמוד | ≤ 200ms | 77% |
| CLS | כמה התוכן זז בזמן הטעינה | ≤ 0.1 | 81% |
הספים מוגדרים על ידי גוגל ב-web.dev. LCP הוא המדד שבו הכי הרבה אתרים נכשלים, ולכן ממנו כדאי להתחיל.
LCP — למה התוכן הראשי מתעכב
ברוב העמודים, האלמנט הגדול בתצוגה הראשונה הוא תמונה: לפי אותו דוח, ב-76% מעמודי המובייל ה-LCP הוא תמונה, ובשאר הוא טקסט. LCP איטי נובע כמעט תמיד מאחד מארבעה מקורות:
- השרת מגיב לאט (TTFB). העמוד נבנה בכל בקשה מחדש, עם שאילתות כבדות. הפתרון: מטמון עמודים, שאילתות יעילות וגרסת PHP עדכנית.
- הדפדפן מגלה את התמונה מאוחר. כשהתמונה הראשית מוגדרת כרקע ב-CSS או נטענת ב-JavaScript, הדפדפן לא יודע עליה עד שהקבצים האלה נטענו.
- התמונה בטעינה עצלה. כ-17% מעמודי המובייל טוענים את תמונת ה-LCP שלהם בטעינה עצלה — כלומר מבקשים מהדפדפן לחכות דווקא עם התמונה הכי חשובה. תוסף "lazy load" שמופעל על כל התמונות הוא הגורם הנפוץ.
- התמונה כבדה מדי. תמונה ברוחב של מסך מחשב שנשלחת לטלפון.
מה מתקן
- התמונה הראשית ב-
<img>רגיל ב-HTML, עםfetchpriority="high"ובליloading="lazy". srcsetו-sizesכדי שכל מסך יקבל גודל מתאים, ופורמט מודרני (WebP או AVIF).- מטמון עמודים בצד השרת, כדי שה-HTML יגיע מהר.
- כשהתמונה מגיעה מדומיין אחר —
preconnectלאותו דומיין.
INP — למה הלחיצה לא מגיבה
INP החליף ב-2024 את המדד הקודם FID. ההבדל חשוב: FID מדד רק את העיכוב לפני האינטראקציה הראשונה, ו-INP מודד את התגובה לאורך כל השימוש בעמוד — כל לחיצה על תפריט, כל פתיחה של אקורדיון, כל הקלדה בטופס.
הבעיה כמעט תמיד אחת: יותר מדי JavaScript שרץ על ה-thread הראשי. כשהדפדפן עסוק בהרצת סקריפט, הוא לא יכול לצייר את התגובה ללחיצה. המקורות הנפוצים:
- ספריות שלמות שנטענות בשביל פונקציה קטנה — jQuery רק בשביל תפריט נפתח, ספריית סליידר שלמה בשביל קרוסלה אחת.
- בוני עמודים שטוענים את כל הרכיבים שלהם בכל עמוד.
- סקריפטים של צד שלישי: צ׳אט, פיקסלים של כמה פלטפורמות פרסום, וידג׳טים של ביקורות, כלי הקלטת גלישה.
- מטפלי אירועים שמבצעים עבודה כבדה בכל גלילה או הקלדה.
מה מתקן
- להסיר מה שלא נחוץ. זה הצעד עם התשואה הגבוהה ביותר, ורוב האתרים לא עושים אותו.
- לטעון סקריפטים עם
defer, ואת סקריפטי הצד השלישי רק אחרי שהעמוד מוכן או רק כשצריך אותם (למשל צ׳אט שנטען בלחיצה על הכפתור שלו). - לפצל משימות ארוכות, כדי שהדפדפן יוכל להגיב ביניהן.
- בתגובה ללחיצה — לעדכן קודם את מה שהגולש רואה, ורק אחר כך לבצע עבודה כבדה.
CLS — למה התוכן קופץ
CLS מודד כמה אלמנטים זזים אחרי שכבר הופיעו. כולנו מכירים את זה: מתחילים לקרוא, ואז באנר נטען מעל הטקסט ודוחף אותו למטה, או שמנסים ללחוץ על קישור והוא בורח. הגורמים:
- תמונות ו-iframe בלי
widthו-height— הדפדפן לא יודע כמה מקום לשמור להם. - מודעות, באנרים ותוכן שמוזרק אחרי הטעינה, בלי מקום שמור.
- גופנים שנטענים מאוחר ומחליפים גופן אחר בגודל שונה.
- אנימציות שמשנות מיקום או גודל במקום להשתמש ב-
transform.
גופנים בעברית: מקור נפוץ לבעיות שלא רואים
לפי Web Almanac, 87% מעמודי המובייל משתמשים בגופן רשת אחד לפחות, ורק 16% טוענים אותו מראש עם preload. באתרים בעברית הבעיה חריפה יותר: קובץ גופן שכולל עברית, לטינית ומשקלים רבים יכול להיות כבד, וכשהוא נטען משירות חיצוני נוסף עוד חיבור לפני שהטקסט מופיע בגופן הנכון.
מה שעובד:
- אירוח הגופן באתר עצמו במקום טעינה משירות חיצוני.
- חיתוך לתווים שבשימוש — קובץ נפרד לעברית ולטינית, עם
unicode-range, כך שהדפדפן מוריד רק את מה שהעמוד צריך. - גופן משתנה (variable) במקום קובץ נפרד לכל משקל.
font-display: swapו-preloadלקובץ הראשי, כדי שהטקסט יופיע מיד.
כך בניתי את האתר הזה: גופן Heebo משתנה, מתארח באתר עצמו ומחולק לקבצים של עברית ולטינית.
איך מודדים נכון
הטעות הנפוצה ביותר היא להסתמך על ציון אחד של PageSpeed במחשב חזק. יש שני סוגי נתונים:
- נתוני שדה — מה שגולשים אמיתיים חווים, מתוך Chrome UX Report. זה מה שגוגל משתמשת בו, ואותו רואים ב-Search Console ובחלק העליון של דוח PageSpeed Insights (כשיש מספיק תנועה).
- נתוני מעבדה — הדמיה של טלפון בינוני ברשת איטית (Lighthouse). מצוינים לאבחון ולבדיקה לפני השקה, אבל הם לא מה שגוגל מדרגת לפיו.
סדר העבודה שאני ממליץ עליו: מתחילים מנתוני השדה ב-Search Console כדי לראות אילו סוגי עמודים נכשלים, מאבחנים בכלי המעבדה מה בדיוק מאט אותם, מתקנים ברמת התבנית (כי תבנית אחת משפיעה על מאות עמודים), ובודקים שוב בנתוני השדה אחרי כמה שבועות. מדריך מפורט לכלים ולקריאת הדוחות: בדיקת מהירות אתר.
מתי זה משנה לדירוג
חשוב להיות כנים: Core Web Vitals הם חלק מאותות חוויית העמוד של גוגל, אבל הם לא מחליפים תוכן רלוונטי. עמוד איטי עם התשובה הטובה ביותר עדיין יכול לדרג. ההשפעה הברורה יותר היא על הגולשים — פחות נטישה, יותר פניות, ופחות כסף שהולך לאיבוד על קליקים ממומנים שלא הבשילו — במיוחד בדפי נחיתה לקמפיינים.
רשימת בדיקה קצרה
- התמונה הראשית לא בטעינה עצלה, עם
fetchpriority="high"וגודל מתאים למסך. - לכל תמונה ו-iframe יש מידות.
- הגופן מתארח באתר, חתוך לעברית ולטינית, עם
font-display: swap. - כל הסקריפטים נטענים עם
defer, וסקריפטי צד שלישי מאוחר ככל האפשר. - אין ספרייה שלמה בשביל פונקציה אחת.
- יש מטמון עמודים בצד השרת.
- ההחלטות מתקבלות לפי נתוני שדה, לא לפי ציון מעבדה אחד.
באתרים רבים, התמונה הראשית היא אלמנט ה-LCP, ולכן דחיסה נכונה שלה משפיעה ישירות על המדד — פירטתי במאמר אופטימיזציה לתמונות באתר.
מאמרים קשורים: משאבים חוסמי רינדור ו-Critical CSS: למה האתר מציג מסך לבן.
אם האתר שלכם נכשל באחד המדדים ואתם רוצים שמישהו יבדוק את זה ברמת הקוד, ראו שיפור מהירות אתר. ובאתרי וורדפרס, הרבה מהבעיות מתחילות בבונה העמודים — הרחבתי על כך במאמר וורדפרס בלי בוני עמודים.
אהבתם את המאמר?
