Core Web Vitals ו-INP: מדדי הליבה של גוגל לחוויית משתמש ב-2026
האתר שלכם "מהיר". אצל מי בדיוק?
כמעט כל בעל אתר שאנחנו פוגשים אומר את אותו משפט: "האתר נטען אצלי מיד". כמובן שכן - אתם על סיבים, בדפדפן שכבר שמר הכל במטמון, במחשב חזק. הלקוח שלכם נמצא ברכבת, על אנדרואיד בן שלוש שנים, עם קליטה בינונית.
Core Web Vitals הם הניסיון של גוגל למדוד את החוויה של הלקוח הזה, לא שלכם. הנתונים נאספים מגולשים אמיתיים בכרום, והם משפיעים על הדירוג - כשיקול משני, אבל אמיתי, ובעיקר כשהתחרות צמודה.
שלושת המדדים והספים שלהם
- LCP - Largest Contentful Paint. מתי האלמנט הגדול בעמוד (בדרך כלל תמונת הכותרת) מסיים להיטען. טוב: עד 2.5 שניות.
- INP - Interaction to Next Paint. כמה זמן עובר מרגע שהמשתמש לחץ ועד שמשהו על המסך באמת מגיב. טוב: עד 200 מילישניות.
- CLS - Cumulative Layout Shift. כמה התוכן "קופץ" תוך כדי טעינה. טוב: מתחת ל-0.1.
שימו לב: גוגל מודדת את האחוזון ה-75. כלומר צריך ש-75% מהביקורים יהיו מתחת לסף, לא הממוצע. ממוצע יפה עם זנב נורא - נכשל.
למה INP הפיל אתרים שנראו בסדר גמור
עד 2024 המדד היה FID, והוא מדד רק את האינטראקציה הראשונה - ובאופן חלקי. INP, שהחליף אותו במרץ 2024, מסתכל על כל האינטראקציות לאורך הביקור ולוקח את הגרועות שבהן.
התוצאה הייתה לא נעימה להרבה אתרים: אתר עמוס תוספים ו-JavaScript יכול להיטען מהר ועדיין להרגיש דביק - תפריט שנפתח באיחור, פילטר בחנות שתוקע את הדף לשנייה, כפתור שצריך ללחוץ עליו פעמיים. FID לא ראה את זה. INP רואה.
וידאו: How to optimize web responsiveness with Interaction to Next Paint (ערוץ Chrome for Developers)
איפה זה נשבר בפועל - ומה עושים
LCP איטי
ברוב האתרים בישראל האשם הוא תמונה. תמונת רקע במשקל 2 מגה שנשלחת כמו שהיא לנייד. ההצלה: פורמט WebP או AVIF, מידות מותאמות למסך, ו-fetchpriority="high" לתמונת הכותרת. אחריה - זמן תגובת שרת ואחסון איטי.
INP גבוה
כאן האשם כמעט תמיד סקריפטים של צד שלישי: פיקסלים, כלי צ'אט, מפות חום, בוחרי גופנים, שלושה כלי אנליטיקס שונים שאף אחד כבר לא זוכר למה הותקנו. עשו ספירת מלאי, מחקו מה שלא מייצר ערך, ודחו טעינה של מה שנשאר.
CLS גבוה
הכי קל לתיקון והכי מוזנח: תמיד להגדיר width ו-height לתמונות ולמסגרות, לשריין מקום לבאנרים, ולטעון גופנים עם font-display: swap.
איך למדוד נכון
- הריצו את הכתובת ב-PageSpeed Insights. החלק החשוב הוא נתוני השטח למעלה, לא ציון המעבדה הצבעוני למטה.
- פתחו את דוח Core Web Vitals בSearch Console - שם רואים את כל האתר לפי קבוצות עמודים, לא עמוד בודד.
- מדדו בנייד. תמיד. שם רוב התנועה ושם הבעיות.
עצה שחוסכת כסף: אל תרדפו אחרי ציון 100. הפער בין 60 ל-90 שווה כסף אמיתי, הפער בין 95 ל-100 בדרך כלל לא.
זה לא רק דירוג - זה כסף
גוגל מצאה שככל שזמן הטעינה עולה, שיעור הנטישה מזנק - קפיצה משנייה אחת לשלוש שניות מעלה את הסיכוי לנטישה באופן דרמטי. במילים אחרות, גם אם הדירוג לא היה זז בכלל, שיפור המהירות עדיין היה משתלם. זו אותה לוגיקה שמאחורי אופטימיזציית המרות.
אם אתם רוצים להעמיק בצד המעשי, המדריך שלנו על שיפור מהירות האתר וזמן הטעינה מכסה את שכבת האחסון והמטמון. ואם אתם מתלבטים אם בכלל שווה לשפץ - לפעמים מעבר לארכיטקטורה מודרנית זול יותר מלרדוף אחרי תוספים.
בפוקס מדיה אנחנו בונים אתרים שעוברים את המדדים מהיום הראשון. רוצים אבחון מהירות? צרו קשר.
שאלות נפוצות
מה הסף התקין של INP?
INP נחשב טוב עד 200 מילישניות, בינוני בין 200 ל-500, וגרוע מעל 500. גוגל מודדת את האחוזון ה-75 של הגולשים האמיתיים, כך שצריך ש-75% מהאינטראקציות יהיו מתחת לסף.
האם Core Web Vitals באמת משפיעים על הדירוג?
כן, אבל כשיקול משני. תוכן רלוונטי ואיכותי חשוב יותר. המדדים מכריעים בעיקר כשכמה תוצאות מתחרות באותה רמת רלוונטיות - ובנוסף הם משפיעים ישירות על שיעור הנטישה ועל ההמרות.
למה הציון ב-PageSpeed שונה בכל בדיקה?
החלק העליון של הדוח הוא נתוני שטח אמיתיים מ-28 הימים האחרונים והוא יציב. החלק התחתון הוא בדיקת מעבדה שמורצת בזמן אמת ומושפעת מעומס הרשת והשרת, ולכן משתנה בין הרצות.
מה משפר את המהירות הכי מהר?
כמעט תמיד תמונות: המרה ל-WebP או AVIF, התאמת מידות למסך וטעינה עצלה. אחרי זה - הסרת סקריפטים של צד שלישי שאיש כבר לא משתמש בהם, ואחסון עם זמן תגובה טוב.
לקוחות שאנחנו אוהבים
