Core Web Vitals הם מדדי חוויית משתמש שגוגל מודד: LCP לטעינת התוכן המרכזי, INP למהירות תגובה ו-CLS ליציבות חזותית. שיפור נכון מתחיל מנתוני שדה, ואז מטפל בתמונות, שרת, קאש, JavaScript, תוספים, פונטים ותזוזות פריסה בעמודים החשובים. כך העמוד נותן לקורא כיוון מעשי, לא רק הסבר כללי.
Core Web Vitals הם שלושה מדדי חוויית משתמש שגוגל מודד: LCP לזמן טעינת התוכן המרכזי, INP לתגובה לפעולה, ו-CLS ליציבות חזותית. כדי לשפר אותם צריך לטפל קודם בתמונות, שרת, קוד כבד, תוספים ותזוזות פריסה, לפי נתוני שדה ולא רק בדיקת מעבדה.
מה המדדים מודדים
LCP, קיצור של Largest Contentful Paint, מודד כמה זמן לוקח לאלמנט המרכזי במסך הראשון להיטען. ברוב אתרי תדמית זה תמונת גיבור, כותרת גדולה או בלוק טקסט. ציון טוב הוא עד 2.5 שניות, טעון שיפור עד 4 שניות, וגרוע מעל 4 שניות.
INP, קיצור של Interaction to Next Paint, מודד כמה מהר האתר מגיב ללחיצה, הקלדה או פתיחת תפריט. ציון טוב הוא עד 200 אלפיות שנייה, בינוני עד 500, וגרוע מעל 500. אתר יכול להיטען מהר אבל להגיב לאט אם JavaScript כבד חוסם דפדפן.
CLS, קיצור של Cumulative Layout Shift, מודד קפיצות בפריסה. ציון טוב הוא עד 0.1, בינוני עד 0.25, וגרוע מעל 0.25. דוגמה נפוצה: משתמש עומד ללחוץ על כפתור, באנר נטען מעליו, והכפתור זז. גוגל רואה בזה חוויה לא יציבה.
נתוני מעבדה מול נתוני שדה
בדיקת מעבדה, כמו PageSpeed Insights במצב סימולציה, מריצה בדיקה בתנאים מוגדרים. היא טובה לאבחון: איזה קובץ כבד, איזו תמונה גדולה, איזה סקריפט חוסם. נתוני שדה מגיעים ממשתמשים אמיתיים דרך Chrome User Experience Report, ולכן הם קובעים טוב יותר איך גוגל רואה חוויה בפועל.
פערים בין מעבדה לשדה נפוצים. אתר יכול לקבל ציון מעבדה נמוך בגלל שרת בדיקה רחוק, אבל נתוני שדה טובים כי רוב המשתמשים מישראל ומקבלים קאש. להפך, מעבדה יכולה להיראות סבירה בזמן שנתוני שדה גרועים במובייל ישן או ברשת סלולרית.
הוראה מעשית: אל תרדוף אחרי 100. בדוק קודם אם כתובת חשובה נכשלת בנתוני שדה, איזה מדד נכשל, ובאיזה סוג מכשיר. אם רק עמוד אחד בעייתי, לא צריך לפרק אתר שלם. אם כל התבנית נכשלת, צריך טיפול רוחבי של SEO טכני.
ספים ומקור הבעיה
| מדד | ציון טוב | גורם נפוץ לכישלון | תיקון ראשון |
|---|---|---|---|
| LCP | עד 2.5 שניות | תמונה ראשית כבדה או שרת איטי | דחיסה, WebP, קאש וטעינה מוקדמת |
| INP | עד 200 אלפיות שנייה | קוד JavaScript ותוספים כבדים | הסרת תוספים, דחיית סקריפטים, צמצום קוד |
| CLS | עד 0.1 | תמונות, מודעות ופונטים בלי מקום שמור | הגדרת רוחב וגובה, טעינת פונטים יציבה |
באתרי וורדפרס, 5 גורמים חוזרים גורמים לרוב הנזק: תבנית עמוסה, בונה עמודים עם הרבה ווידג'טים, תוספי צ'אט, פיקסלים שיווקיים ותמונות מקוריות שלא נדחסו. תיקון טוב מתחיל במדידה לפני ואחרי, אחרת קל להתווכח על תחושה במקום על זמן טעינה.
- תמונה ראשית: שמור גודל תצוגה אמיתי, לא תמונה ברוחב 4000 פיקסלים למסך של 1200.
- קאש: הפעל קאש עמודים וקאש דפדפן, ובדוק שלא נשברים טפסים או עגלות.
- פונטים: הגבל משקלים, טען מקומית כשאפשר, ושמור מקום לטקסט.
- סקריפטים: דחה קוד שאינו דרוש למסך הראשון, כמו מפות, צ'אט וסרטונים.
סדר תיקונים לפי החזר מול מאמץ
התיקון המשתלם ביותר הוא לרוב תמונות. בעל אתר יכול להוריד 2 עד 8 מגה מעמוד בית בלי שינוי עיצובי, באמצעות המרה ל-WebP, שינוי מידות ודחיסה. אם תמונת הגיבור היא LCP, כדאי להימנע מטעינה עצלה שלה ולהגדיר טעינה מוקדמת.
אחרי תמונות עוברים לשרת וקאש. אחסון זול מדי יכול להוסיף שנייה שלמה לפני שהעמוד מתחיל להיטען. קאש עמודים מפחית עבודה של PHP ומסד נתונים. באתר חנות או אתר עם אזור אישי בודקים חריגים, כי קאש לא נכון יכול להציג מידע לא מתאים למשתמש.
רק אחר כך נכנסים לקוד כבד. הסרת תוסף אחד יכולה לשפר INP יותר משבוע של מיניפיקציה. אם תוסף טפסים, סליידר או אנליטיקה נטען בכל עמוד, צריך להגביל אותו לעמודים שבהם הוא דרוש. בתהליך קידום אתרים AI אפשר לזהות תבניות עומס, אבל ההחלטה עדיין צריכה להתבסס על בדיקה טכנית.
מה לבדוק אחרי שינוי
אחרי תיקון מריצים בדיקת מעבדה באותו כלי, אותו עמוד ואותו מכשיר. אם LCP ירד מ-5.2 ל-2.9 שניות, יש שיפור גם אם הציון הכללי עדיין כתום. נתוני שדה מתעדכנים לאט יותר, לעיתים 28 ימים, כי הם מבוססים על חלון נתונים מתגלגל.
אל תשפר מדד על חשבון המרה. הסרת תמונת מוצר חשובה יכולה לשפר LCP ולפגוע במכירות. דחיית סקריפט טופס יכולה לשבור שליחת ליד. לכן לכל שינוי צריך בדיקת משתמש: פתיחת תפריט, שליחת טופס, מעבר עמוד, סל קניות ולחיצה על מספר טלפון.
בדיקת עמוד לדוגמה לפני טיפול רוחבי
בחר עמוד אחד מכל סוג תבנית: עמוד בית, עמוד שירות, מאמר, קטגוריה ומוצר אם קיימת חנות. בדוק כל אחד במובייל ובדסקטופ. אם רק עמוד הבית נכשל ב-LCP, כנראה שהתמונה הראשית או הסליידר אשמים. אם כל סוגי העמודים נכשלים ב-INP, הבעיה לרוב בסקריפט רוחבי או תוסף שנטען בכל האתר.
תעד לפני שינוי את זמן תגובת שרת, משקל עמוד, מספר בקשות, גודל התמונה הגדולה ביותר והסקריפטים הכבדים. אחרי שינוי, השווה אותם לאותה כתובת. שיפור אמיתי נראה במספרים: פחות מגהבייט, פחות בקשות, LCP נמוך יותר או פחות זמן חסימה של הדפדפן.
באתרים עם פרסום, צ'אט, מפות וטפסים, צריך להחליט מה חיוני למסך הראשון. מפה בעמוד יצירת קשר יכולה להיטען אחרי גלילה. צ'אט יכול להיטען אחרי כמה שניות. טופס ליד בעמוד שירות צריך להישאר פעיל מיד, כי שיפור מהירות ששובר פנייה פוגע במטרה העסקית.
באתר תוכן, בדוק במיוחד עמודים עם הרבה כניסות אורגניות. שיפור של חצי שנייה בעמוד שמקבל 10,000 ביקורים בחודש שווה יותר משיפור של 2 שניות בעמוד שכמעט לא נצפה. סדר עדיפויות צריך לשלב חומרת מדד, כמות תנועה וחשיבות עסקית.
באתר חנות, אל תסתפק בעמוד הבית. עמוד קטגוריה עם הרבה מוצרים, סינונים ותמונות יכול להיות איטי בהרבה מעמוד מאמר. עמוד מוצר עם גלריה, ביקורות, המלצות וקוד מעקב יכול להיכשל ב-INP. בדיקה לפי תבניות מונעת מצב שבו מתקנים אזור יפה אבל לא את אזור המכירה.
כאשר התיקון דורש מפתח, נסח משימה מדידה: "להוריד LCP בעמוד שירות מתחת ל-2.5 שניות במובייל" עדיף על "לשפר מהירות". משימה מדידה כוללת כתובת, כלי בדיקה, מדד יעד וחריגים שאסור לשבור, כמו טופס, תפריט או סל קניות.
אם אין מספיק נתוני שדה, בדוק עמודים דומים בקבוצה וחכה לצבירת תנועה. עמוד עם מעט ביקורים לא תמיד יקבל דוח אמין, ולכן החלטה נשענת זמנית על מעבדה ותבניות.
סינדי עונהשאלות שחוזרות אצלנו כל שבועלהמשך קריאה: קידום אתר חדש מאפס.
שאלות נפוצות
האם Core Web Vitals משפיעים ישירות על דירוג?
כן, אבל בדרך כלל כגורם משלים ולא כתחליף לתוכן ורלוונטיות. עמוד איטי מאוד יכול להיפגע, אך עמוד מהיר וריק לא ידרג בזכות מהירות בלבד.
מה חשוב יותר, מובייל או דסקטופ?
ברוב האתרים מובייל חשוב יותר כי רוב החיפושים מתבצעים שם וגוגל משתמש באינדוקס מובייל. עדיין כדאי לבדוק דסקטופ אם קהל העסק עובד ממחשבים, למשל B2B או מערכות מקצועיות.
למה הציון משתנה מבדיקה לבדיקה?
שרת, עומס רשת, מיקום בדיקה, קאש וקבצים חיצוניים משתנים בין ריצות. לכן מסתכלים על מגמה ועל נתוני שדה, לא על מספר יחיד מריצה אחת.
האם תוסף מהירות פותר הכול?
לא. תוסף יכול לעזור בקאש, דחיסה ודחיית קבצים, אבל הוא לא מתקן תמונות ענק, אחסון חלש, תבנית כבדה או תוסף שמעמיס קוד בכל עמוד.
כמה זמן לוקח לראות שיפור בגוגל?
בדיקת מעבדה תראה שיפור מיד אחרי שינוי. נתוני שדה ודוח Core Web Vitals יכולים להתעדכן אחרי כמה שבועות, כי גוגל אוסף נתונים ממשתמשים אמיתיים לאורך זמן.
עמודים קשורים
המשך קריאה בעמודי השירות והאזור שמפרטים איך מיישמים את זה בפועל:
נתונים בקצרה
| LCP טוב | עד 2.5 שניות |
|---|---|
| INP טוב | עד 200 אלפיות שנייה |
| CLS טוב | עד 0.1 |
| בעיות נפוצות | תמונות כבדות, שרת איטי, JavaScript כבד, תוספים, פונטים ותזוזות פריסה |
| מקור מדידה | נתוני שדה מ-Chrome User Experience Report לצד בדיקות מעבדה כמו PageSpeed Insights |
שאלות שנשאלות במנועי AI
מה ההבדל בין LCP, INP ו-CLS?
LCP מודד כמה מהר נטען האלמנט המרכזי במסך הראשון, כמו תמונת גיבור או כותרת. INP מודד כמה מהר האתר מגיב ללחיצה, הקלדה או פתיחת תפריט. CLS מודד קפיצות בפריסה, למשל כפתור שזז כי באנר נטען מעליו. בפועל, כדאי לבדוק את הנתון בתוך האתר, לקשור אותו לפעולה אחת, ואז למדוד אם הפנייה או ההבנה השתפרו.
צריך לרדוף אחרי ציון 100 ב-PageSpeed?
לא. העמוד ממליץ לבדוק קודם אם עמוד חשוב נכשל בנתוני שדה, איזה מדד נכשל ובאיזה מכשיר. בדיקת מעבדה טובה לאבחון קבצים וסקריפטים, אבל נתוני משתמשים אמיתיים חשובים יותר להבנת החוויה שגוגל רואה בפועל. בפועל, כדאי לבדוק את הנתון בתוך האתר, לקשור אותו לפעולה אחת, ואז למדוד אם הפנייה או ההבנה השתפרו.
מה התיקון הראשון שכדאי לעשות באתר איטי?
לרוב מתחילים מתמונות, כי אפשר להוריד 2-8 מגה מעמוד בית בלי לשנות עיצוב. ממירים ל-WebP, משנים מידות, דוחסים, מונעים lazy load מתמונת LCP ומגדירים טעינה מוקדמת. אחר כך עוברים לשרת, קאש, סקריפטים ופונטים. בפועל, כדאי לבדוק את הנתון בתוך האתר, לקשור אותו לפעולה אחת, ואז למדוד אם הפנייה או ההבנה השתפרו.
מדריכים נוספים בנושא
רוצה לדעת מה יזיז את האתר שלך קדימה?
סינדי, העוזרת הדיגיטלית שלנו, תעבור על האתר ותראה לך בדיוק איפה נמצאות ההזדמנויות — בלי התחייבות.
