דלג לתוכן הראשי
טכנולוגיה

בדיקת מהירות אתר: איך בודקים, מה המספרים אומרים ואיך משפרים (Core Web Vitals)

איך עושים בדיקת מהירות אתר, מה LCP, INP ו-CLS אומרים בעברית פשוטה, ומה 10 התיקונים שבאמת מזיזים את המחט באתרים של עסקים ישראליים.

צוות Simple Web2 בספטמבר, 20267 דק׳ קריאה
בדיקת מהירות אתר: איך בודקים, מה המספרים אומרים ואיך משפרים (Core Web Vitals)

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

איך עושים בדיקת מהירות אתר ב-PageSpeed Insights

הכלי החינמי של גוגל, PageSpeed Insights, הוא נקודת ההתחלה. הוא לא הכלי היחיד, אבל הוא היחיד שמראה את הנתונים שגוגל עצמה משתמשת בהם. איך לבדוק בעצמכם, בארבעה צעדים:

  1. הזינו את כתובת העמוד, לא רק את הדומיין. עמוד הבית, עמוד שירות מרכזי ודף נחיתה פעיל הם שלושה עמודים שונים עם תוצאות שונות.
  2. התחילו מהלשונית “נייד”. רוב הגולשים בישראל מגיעים מהטלפון, ולכן גוגל מודדת את האתר קודם כל שם. ציון הדסקטופ כמעט תמיד יפה יותר, ולכן הוא פחות מעניין.
  3. הסתכלו על החלק העליון של הדוח לפני הציון. שם מופיעים “נתוני שדה” (Field data): מה שקרה בפועל לגולשים אמיתיים ב-28 הימים האחרונים, מתוך דוח חוויית המשתמש של Chrome (CrUX). זה המידע שגוגל מתייחסת אליו.
  4. רק אחר כך רדו לציון 0–100. הציון הזה הוא “נתוני מעבדה” (Lab data): סימולציה חד-פעמית של Lighthouse על מכשיר איטי ורשת איטית. הוא מצוין לאבחון, אבל הוא לא מה שמדורג.

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

מה המספרים אומרים: LCP, INP ו-CLS בעברית פשוטה

שלושה כרטיסים תלת-ממדיים עם הספים הירוקים של LCP, INP ו-CLS

גוגל מסכמת את חוויית הטעינה בשלושה מדדים שנקראים Core Web Vitals. כל אחד מהם נמדד על גולשים אמיתיים, ולכל אחד יש סף “ירוק”. הנה התרגום לעברית של בעלי עסקים.

LCP – כמה מהר רואים את הדבר העיקרי

Largest Contentful Paint מודד כמה זמן עובר עד שהאלמנט הגדול בעמוד (בדרך כלל תמונת הכותרת) מופיע על המסך. הסף הירוק הוא עד 2.5 שניות. בין 2.5 ל-4 שניות דורש שיפור, ומעל 4 שניות נחשב גרוע. במילים פשוטות: כמה זמן הלקוח מסתכל על מסך לבן.

INP – כמה מהר האתר מגיב ללחיצה

Interaction to Next Paint מודד את הזמן בין לחיצה (על תפריט, כפתור, שדה בטופס) לבין התגובה על המסך. הסף הירוק הוא עד 200 אלפיות שנייה. בין 200 ל-500 דורש שיפור, ומעל 500 גרוע. המדד הזה החליף את FID ב-2024, ולכן הרבה מדריכים ישנים עדיין לא מזכירים אותו.

CLS – כמה האתר “קופץ” בזמן הטעינה

Cumulative Layout Shift מודד כמה אלמנטים זזים בזמן שהעמוד נטען: הכפתור שברח רגע לפני שלחצתם עליו, הטקסט שירד למטה כשנטענה תמונה. הסף הירוק הוא עד 0.1. בין 0.1 ל-0.25 דורש שיפור, ומעל 0.25 גרוע.

שימו לב: אפשר לקבל ציון מעבדה של 60 ולהיות ירוקים בשלושת המדדים, וגם להפך. לכן, כשמפתח מבטיח “ציון 100”, שאלו אותו קודם על נתוני השדה.

למה מהירות אתר חשובה לעסק, לא רק לגוגל

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

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

  • גולשים בנייד נוטשים לפני שהעמוד נטען. הם הגיעו מקמפיין ששילמתם עליו, ולא ראו אפילו את הכותרת.
  • טפסים נשלחים פחות. INP גבוה גורם ללחיצות שלא “מרגישות” שעבדו, ולקוחות מוותרים או שולחים פעמיים.
  • קמפיינים ממומנים מתייקרים. גוגל מעריכה את חוויית דף הנחיתה, ודף איטי עלול להוריד את ציון האיכות (Quality Score). כתוצאה מכך אתם עלולים לשלם יותר על כל קליק.

במילים אחרות, שיפור מהירות אתר הוא לרוב התיקון הזול ביותר לקמפיין יקר.

10 התיקונים הנפוצים לשיפור מהירות אתר בעסקים ישראליים

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

מה אנחנו רואים בשטח

אחרי עבודה עם 200+ עסקים, הבדיקה הראשונה שלנו באתר קיים היא תמיד אותה בדיקה: נתוני השדה בנייד, אחר כך זמן התגובה של השרת (TTFB), ואז מה בדיוק האלמנט שנמדד כ-LCP. הסדר הזה חוסך זמן, כי אין טעם לדחוס תמונות כשהשרת עונה אחרי שנייה וחצי. הטעות שאנחנו פוגשים הכי הרבה היא מפתח שמציג צילום מסך של ציון 95 בדסקטופ, בזמן שה-LCP בנייד אדום אצל גולשים אמיתיים. לכן אצלנו היעד הוא לא ציון מעבדה: כל אתר שאנחנו מוסרים עולה לאוויר עם שלושת המדדים ירוקים בנייד, ואת הבדיקה החוזרת עושים אחרי שנתוני השדה התעדכנו.

הרשימה הבאה מסודרת לפי מה שבדרך כלל נותן הכי הרבה:

  1. תמונות כבדות. התמונה הראשית היא כמעט תמיד ה-LCP. המירו ל-WebP או AVIF, והגדירו רוחב אמיתי (לא תמונה של 4,000 פיקסלים בתוך תיבה של 800). טענו בעצלות (lazy load) רק תמונות שמתחת לקפל. תמונת הכותרת לא נטענת בעצלות.
  2. אחסון איטי. אם זמן התגובה הראשון של השרת (TTFB) חורג משנייה, שום אופטימיזציה לא תציל את ה-LCP. שרת קרוב לישראל או CDN מול השרת פותרים את זה. הרחבנו על סוגי האחסון במדריך קניית דומיין ואחסון אתרים.
  3. עודף תוספים ב-WordPress. כל תוסף מוסיף קוד שנטען בכל עמוד. לכן, מחקו תוספים לא פעילים, ואחדו כפילויות (שני תוספי SEO, שלושה תוספי טפסים).
  4. פונטים עבריים. פונט עברי נטען לפעמים בחמישה משקלים, כשבפועל משתמשים בשניים. השאירו שני משקלים, הגדירו font-display: swap, ואם אפשר אחסנו את הפונט על השרת שלכם.
  5. סקריפטים של צד שלישי. צ'אט, פיקסלים, מפות, סרטון YouTube מוטמע, כלי הקלטת גולשים. כל אחד לגיטימי, אבל ביחד הם אלה שהורגים את ה-INP. טענו אותם באיחור (defer) או אחרי האינטראקציה הראשונה.
  6. בלי מטמון ובלי CDN. מטמון (cache) חוסך לשרת עבודה חוזרת, ו-CDN כמו Cloudflare מגיש את הקבצים מהנקודה הקרובה לגולש. שניהם זולים, ולעיתים חינמיים.
  7. CSS ו-JavaScript שלא בשימוש. בוני עמודים כמו Elementor טוענים את כל הספרייה בכל עמוד. הפעילו טעינה מותנית, וצמצמו (minify) את הקבצים.
  8. סרטון רקע בכותרת. נראה מרשים בדסקטופ, הורס את ה-LCP בנייד. השתמשו בתמונת poster בנייד, וטענו את הסרטון רק בדסקטופ.
  9. אלמנטים בלי מידות. תמונות, באנרים ומודעות שלא הוגדר להן גובה מראש גורמים ל-CLS. הגדירו width ו-height, ושמרו מקום קבוע לבאנרים.
  10. שרשרת הפניות. מ-http ל-https, מבלי www ל-www, מדומיין ישן לחדש. כל הפניה מוסיפה זמן עוד לפני שהתחילה הטעינה. הפניה אחת, ישירה, לכתובת הסופית.

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

מה לדרוש מהמפתח לפני שמשלמים על שיפור מהירות אתר

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

  1. מספרים לפני ואחרי, מנתוני השדה. לא צילום מסך של ציון מעבדה בדסקטופ.
  2. יעד מוגדר בנייד: LCP עד 2.5 שניות, INP עד 200 אלפיות שנייה, CLS עד 0.1. אם המפתח לא מכיר את המונחים, זו תשובה בפני עצמה.
  3. בדיקה על שלושה עמודים לפחות, כולל דף הנחיתה שהקמפיין מפנה אליו.
  4. סביבת ניסוי (staging). שינויים במטמון ובתוספים נשברים בקלות. שום דבר לא עולה לאוויר בלי בדיקה לפני.
  5. בדיקה חוזרת אחרי חודש. נתוני השדה מתעדכנים לאט, ולכן התוצאה האמיתית נראית רק אחרי כמה שבועות.

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

מה Simple Web עושה בעניין

Simple Web היא סוכנות שיווק מבוססת AI מבני ברק, שותפי Meta מוסמכים ומומחי פרסום בגוגל, שעובדת עם 200+ עסקים ומחזיקה 28 ביקורות 5★ בגוגל (עוד על הצוות בעמוד אודות). מהירות אצלנו היא חלק מהמפרט, לא תוספת. כל אתר שאנחנו בונים עולה לאוויר עם Core Web Vitals ירוקים ומהירות A+, על תשתית שמוכנה ל-SEO ולחיפוש ב-AI. אתר תדמית מתחיל מ-₪5,000, מוכן תוך כ-3 שבועות (14 ימי עסקים), וכולל 6 חודשי תוכן SEO במתנה (שווי ₪4,500).

לאתר קיים יש שתי אפשרויות. הראשונה היא שיחת אבחון חינמית, שבה אנחנו מריצים את הבדיקה ביחד ומסבירים מה המספרים אומרים. השנייה היא Simpi, סוכן ה-AI שלנו שמתחבר לאתר ומפיק דוח ראשוני חינמי תוך דקות. אחר כך הוא מתקן בעיות טכניות כמו מהירות, מפת אתר וקישורים שבורים באופן אוטומטי. Simpi עולה מ-₪750 + מע"מ לחודש לקידום האתר, בהתחייבות ל-3 חודשים בלבד.

סיכום

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

שאלות נפוצות
בפועל גוגל לא מדברת על "שניות לטעינה" אלא על שלושה מדדים. אתר נחשב מהיר כשבנתוני השדה בנייד LCP הוא עד 2.5 שניות, INP עד 200 אלפיות שנייה ו-CLS עד 0.1. ציון המעבדה 0–100 הוא כלי אבחון, ולכן 90 ומעלה נחמד אבל לא חובה.
כי הבדיקה בנייד מדמה טלפון בינוני ברשת סלולרית איטית, בעוד הדסקטופ נבדק על מחשב חזק ברשת מהירה. בנוסף, רוב הגולשים בישראל מגיעים מהנייד, ולכן גוגל מתייחסת בעיקר לנתונים שלו. תמיד תקנו קודם לנייד.
לא. ציון 100 הוא סימולציה, ולעיתים ההשקעה בעשר הנקודות האחרונות לא משתלמת. המטרה העסקית היא שלושה מדדי Core Web Vitals ירוקים על גולשים אמיתיים. אתר עם ציון 75 ומדדים ירוקים במצב טוב יותר מאתר עם 95 ו-LCP אדום.
תיקונים בסיסיים, כמו דחיסת תמונות, הפעלת מטמון וחיבור CDN, נעשים בדרך כלל תוך ימים. עם זאת, נתוני השדה מתעדכנים על בסיס 28 ימים, ולכן התוצאה בדוח נראית רק אחרי כמה שבועות. בעיות תשתית, כמו אחסון או תבנית כבדה, לוקחות יותר.
כן, אבל כסימן משלים. Core Web Vitals הם חלק ממדדי חוויית העמוד של גוגל, ולכן אתר איטי במיוחד נפגע. עם זאת, תוכן רלוונטי וסמכות עדיין חשובים יותר. ההשפעה הגדולה של מהירות היא על נטישה והמרות, ושם ההבדל מורגש מיד.
נתוני שדה נאספים מגולשים אמיתיים ב-Chrome ב-28 הימים האחרונים ומייצגים את החוויה בפועל. נתוני מעבדה הם סימולציה אחת שרצה ברגע הבדיקה, בתנאים קבועים. גוגל מדרגת לפי השדה, ומפתחים מאבחנים לפי המעבדה. לכן צריך להסתכל על שניהם.

שתפו: