Core Web Vitals: המדריך המלא לשיפור מהירות האתר

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

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

מה זה Core Web Vitals ולמה זה חשוב?

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

המדדים הם חלק ממה שגוגל מכנה "חוויית עמוד", לצד דברים כמו חיבור מאובטח (HTTPS) והימנעות מחלונות קופצים שמסתירים את התוכן בנייד. הם לא מחליפים תוכן טוב, אבל הם קובעים אם מי שהגיע אליו יישאר לקרוא.

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

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

LCP - מהירות הצגת התוכן העיקרי

LCP מודד מתי האלמנט הגדול ביותר בחלון הצפייה הופך לגלוי. באתר תדמית זו כמעט תמיד תמונת הכותרת או הכותרת הראשית עצמה. היעד: עד 2.5 שניות.

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

• זמן תגובת שרת (TTFB) - עד שה-HTML הראשון מגיע. תלוי באחסון, במטמון ובמרחק מהשרת.
• עיכוב טעינה - כמה זמן עובר עד שהדפדפן בכלל מגלה שהוא צריך את התמונה הראשית.
• זמן הורדה - כמה זמן לוקח להוריד אותה. תלוי במשקל הקובץ.
• עיכוב רינדור - הזמן מסיום ההורדה ועד שהיא מוצגת, בדרך כלל בגלל CSS, גופנים או JavaScript שחוסמים.

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

1. תמונת hero כבדה. קובץ JPEG של 2MB שהועלה ישירות מהמצלמה. המרה ל-WebP או AVIF והתאמת מידות מורידה את המשקל בעשרות אחוזים, ולרוב ביותר, בלי הבדל נראה לעין.
2. גופנים חוסמי רינדור. שלוש משפחות מ-CDN חיצוני, שהטקסט ממתין להן.
3. CSS חוסם. קובץ סגנון של 200KB שחייב לרדת במלואו לפני שמשהו מוצג.
4. זמן תגובת שרת איטי. אחסון משותף זול שמחזיר את ה-HTML הראשון אחרי שנייה שלמה.
5. סקריפטים של צד שלישי. צ׳אטים, פיקסלים ובאנרי עוגיות שנטענים לפני התוכן.

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

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

INP - תגובתיות לאינטראקציה

INP מודד כמה זמן עובר מלחיצה, הקשה או הקלדה ועד שהמסך מציג תגובה, והיעד הוא עד 200 מילישניות. הוא החליף את FID במרץ 2024, והוא מחמיר יותר: במקום למדוד רק את האינטראקציה הראשונה, הוא בוחן את כל האינטראקציות לאורך הביקור ומדווח על הגרועות שבהן.

INP גבוה כמעט תמיד אומר דבר אחד - יותר מדי JavaScript שרץ ב-thread הראשי. כשהדפדפן עסוק בהרצת קוד, הוא לא יכול להגיב ללחיצה. הזמן מתחלק לשלושה: ההמתנה עד שהדפדפן מתפנה לטפל בלחיצה, זמן הריצה של הקוד שמגיב לה, והזמן עד שהמסך מצויר מחדש. כל משימה שרצה יותר מ-50 מילישניות ברצף נחשבת "משימה ארוכה", והיא החשוד הראשון.

מה שעוזר בפועל:

• הסירו ספריות שאתם לא באמת משתמשים בהן. אתר תדמית טיפוסי לא צריך jQuery, ולרוב גם לא ספריית סליידר.
• טענו סקריפטים עם defer כדי שלא יחסמו את הפירוק של ה-HTML.
• דחו סקריפטים של צד שלישי עד אחרי האינטראקציה הראשונה של המשתמש.
• פרקו עבודה כבדה למשימות קטנות, ותנו משוב ויזואלי מיד אחרי הלחיצה - גם אם התוצאה המלאה מגיעה רגע אחר כך.
• הימנעו מאנימציות שמשנות מאפייני פריסה. הנפישו transform ו-opacity בלבד.

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

CLS - יציבות ויזואלית

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

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

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

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

איך למדוד נכון (ולמה Lighthouse משקר לכם)

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

נתוני מעבדה - Lighthouse ו-PageSpeed Insights מריצים סימולציה על מכשיר וירטואלי בתנאי רשת מוגדרים. הם מצוינים לאיתור בעיות ולבדיקה חוזרת אחרי תיקון, אבל הם לא משקפים את המשתמשים שלכם. במעבדה גם אין מישהו שלוחץ, ולכן Lighthouse לא מודד INP אמיתי ומציג במקומו את TBT (זמן החסימה הכולל) כאינדיקציה.

נתוני שדה - מה שמשתמשי Chrome אמיתיים חוו בפועל, ב-28 הימים האחרונים. אלה הנתונים שגוגל משתמשת בהם, והם מופיעים בדוח Core Web Vitals ב-Search Console ובחלק העליון של PageSpeed Insights.

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

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

דוגמה: מ-4.1 שניות ל-2.3 שניות

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

נניח אתר תדמית שה-LCP שלו בנייד, לפי נתוני השדה, הוא 4.1 שניות. הפירוק מראה: תגובת שרת של 0.9 שניות, תמונת hero של 1.6MB עם loading="lazy", שלוש משפחות גופנים מ-CDN חיצוני, וצ׳אט שנטען בראש העמוד.

סך הכול, ירידה מ-4.1 לסביבות 2.3 שניות - מעבר מ"גרוע" ל"טוב". ההשפעות לא תמיד מצטברות באופן ליניארי, ולכן מודדים אחרי כל תיקון ולא רק בסוף. והחלק החשוב: נתוני השדה יתעדכנו רק אחרי כשלושה-ארבעה שבועות, כשחלון 28 הימים יתמלא בביקורים החדשים.

סדר הפעולות המומלץ

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

1. תמונות. המרה ל-WebP או AVIF, התאמת מידות, width/height, ו-lazy loading לכל מה שלא בחלון הראשון.
2. גופנים. משפחה אחת, אחסון עצמי, preload ו-font-display: swap.
3. ניקוי JavaScript. הסרת ספריות שלא בשימוש ו-defer על השאר.
4. CSS. הסרת סגנונות מתים והטמעת הקריטי בלבד.
5. שרת ומטמון. אחסון סביר, דחיסה, וכותרות מטמון ארוכות לנכסים.
6. צד שלישי. ביקורת מה באמת נחוץ, ודחייה של השאר.

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

מתי לא כדאי להשקיע עוד

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

מה מיוחד באתרים בעברית

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

• הגופן העברי הוא לרוב הנכס הכבד ביותר. קובץ מלא של משפחה עברית יכול להגיע ל-200KB. תת־קבוצה שמכילה רק את הטווח העברי והסימנים הנחוצים יורדת לכ-12KB.
• טעינת שלוש משפחות היא הנורמה, וזו טעות. ראינו אינספור אתרים שטוענים שלוש משפחות בחמישה משקלים כל אחת - חמישה־עשר קבצים לפני שמוצג טקסט.
• ה-LCP הוא לרוב הכותרת ולא תמונה. באתרים עבריים רבים ה-hero הוא טיפוגרפי, ולכן הגופן הוא הנתיב הקריטי. preload על קובץ הגופן משפר את ה-LCP ישירות.
• תוספי נגישות, צ׳אט ועוגיות. בישראל כמעט כל אתר מציג תפריט נגישות, ולעיתים קרובות הוא סקריפט חיצוני כבד שנטען בכל עמוד. תפריט נגישות שנכתב כחלק מהאתר חוסך את הטעינה הזו, ובכל מקרה הוא לא תחליף לאתר שנבנה נגיש מלכתחילה.

אנחנו נוטים להגיש הכול מהדומיין של האתר עצמו. באתר של אלצ׳קו בשרים כל הגופנים והספריות מוגשים מהדומיין של האתר, ומפת Google נטענת רק אחרי לחיצה. באתר של ZAVUROV & CO. המפה היא תמונה סטטית שנבנית בשרת מאריחי OpenStreetMap, ותפריט הנגישות נכתב מאפס בלי סקריפט צד שלישי. כל רכיב חיצוני שלא נטען הוא רכיב שלא יכול לעכב את העמוד.

וורדפרס, Wix ו-Shopify: מה אפשר לשפר בכל אחת?

בכל פלטפורמה אפשר לשפר את המדדים, אבל השליטה שלכם שונה: בוורדפרס אתם שולטים כמעט בהכול, ובפלטפורמות מנוהלות כמו Wix ו-Shopify השרת והקוד הבסיסי בידי הפלטפורמה. זה משנה איפה כדאי להשקיע:

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

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

רשימת בדיקה לפני עלייה לאוויר

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

1. תמונת ה-LCP בפורמט מודרני, במידות שמתאימות לתצוגה, בלי loading="lazy" ועם fetchpriority="high".
2. לכל תמונה ולכל וידאו יש width ו-height.
3. לכל מה שמתחת למסך הראשון יש lazy loading.
4. משפחת גופנים אחת או שתיים, באחסון עצמי, עם preload לקובץ הקריטי.
5. כל הסקריפטים נטענים עם defer, וסקריפטים של צד שלישי נדחים.
6. אין ספריות שאף אחד לא משתמש בהן.
7. באנר העוגיות והודעות מרחפים מעל התוכן ולא דוחפים אותו.
8. למודעות ולתוכן מוטמע יש מיכל בגובה קבוע.
9. מפות, וידאו וצ׳אט נטענים רק כשצריך.
10. השרת מחזיר HTML מהר, עם דחיסה ומטמון לנכסים סטטיים.
11. PageSpeed Insights במצב נייד לא מציג אזהרות אדומות בשלושת המדדים.
12. אחרי ארבעה שבועות - בדיקה חוזרת של נתוני השדה ב-Search Console.

שורה תחתונה

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

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