תום שבתאי
מהירות האתר משפיעה על כמות הלידים בשתי דרכים: גולשים נוטשים לפני שהדף נטען, וגוגל מדרגת נמוך יותר אתרים איטיים. מחקר של Google ו-Deloitte מצא ששיפור של עשירית השנייה בלבד העלה המרות בקמעונאות ב-8.4% — כלומר הרווח מתחיל הרבה לפני שהאתר מרגיש איטי.
עיקרי הדברים
- הסף שגוגל מגדירה כטוב: LCP עד 2.5 שניות, INP עד 200 מילישניות, CLS עד 0.1.
- שיפור של 0.1 שנייה העלה המרות ב-8.4% ושווי הזמנה ב-9.2% (Deloitte, 2020).
- השרת הוא רק חלק מהסיפור — תמונות ותוספים אורבים לרוב לנזק הגדול.
- המדידה הקובעת היא על משתמשים אמיתיים במובייל, לא במעבדה.
- אתר מהיר משפר גם את עלות הקליק בפרסום ממומן, לא רק את האורגני.
מהי בעצם מהירות אתר, ואיך מודדים אותה?
מהירות אתר היא מדד מורכב שמתאר כמה מהר המשתמש רואה תוכן, כמה מהר הדף מגיב ללחיצות, וכמה הוא יציב בזמן הטעינה. גוגל מודדת אותה בשלושה מדדים שנקראים Core Web Vitals, והספים מפורסמים במסמכי web.dev של Google (2026).
נקודה שחשוב להבין: הציון שקובע מבוסס על אחוזון 75 של משתמשים אמיתיים, לא על בדיקה אחת ממחשב משרדי מהיר. בישראל, שבה רוב הגלישה היא מובייל ולעיתים ברשת סלולרית, הפער בין הבדיקה במשרד למציאות יכול להיות גדול מאוד.
מהם הספים שצריך לעמוד בהם?
למה אתר איטי מאבד לידים גם כשהתנועה מגיעה?
כי הנטישה קורית לפני שהגולש בכלל ראה מה אתם מציעים. מי שהגיע ממודעה ונתקל במסך לבן שלוש שניות חוזר לתוצאות ומקליק על המתחרה — ואתם שילמתם על הקליק הזה. זו הסיבה שמהירות היא בעיית תקציב, לא רק בעיית חוויה.
האפקט מצטבר גם בכיוון השני: אתר מהיר משפר את חוויית דף הנחיתה שגוגל מדרגת, ודרכה את ציון האיכות ומחיר הקליק. מי שמשקיע במהירות משלם פחות על אותה תנועה.
מה באמת מאט אתרים עסקיים בישראל?
לפי סדר החומרה בפועל, אלה האשמים החוזרים:
- תמונות לא דחוסות — תמונה שהועלתה ישירות מהמצלמה שוקלת פי עשרות מהנדרש. המרה ל-WebP או AVIF היא התיקון הזול ביותר.
- עודף תוספים — כל תוסף מוסיף קוד שנטען בכל עמוד, גם אם משתמשים בו בעמוד אחד בלבד.
- אחסון משותף עמוס — חבילות זולות מאחסנות מאות אתרים על אותו משאב.
- סקריפטי צד שלישי — צ'אטבוטים, פיקסלים ווידגטי ביקורות שנטענים לפני התוכן.
- בילדרים כבדים — עיצוב עשיר באנימציות שמוסיף קוד בלי להוסיף ערך.
אם האתר נבנה מלכתחילה עם הקפדה על ביצועים, חוסכים את רוב העבודה הזו. ראו בניית אתרים מותאמת ביצועים ואת שלבי בניית אתר עסקי.
מה לתקן קודם אם יש זמן מוגבל?
סדר עדיפויות שנותן את מרבית השיפור במינימום מאמץ: קודם דחיסת התמונות והמרתן לפורמט מודרני; אחר כך הגדרת מידות מפורשות לכל תמונה כדי למנוע קפיצות בפריסה; אחר כך מחיקת תוספים לא פעילים; ורק בסוף מעבר אחסון.
אחרי כל תיקון כדאי לבדוק מחדש במובייל וברשת סלולרית, ולא רק במשרד. שיפור שנראה דרמטי בבדיקה מהמשרד עשוי להיות זניח אצל המשתמש בשטח.
שאלות נפוצות
כמה שניות נחשבות איטיות מדי?
מעל ארבע שניות ל-LCP נחשב גרוע לפי הסף של גוגל. אבל כבר מעל 2.5 שניות אתם משלמים מחיר בהמרות.
האם מעבר לאחסון יקר יותר פותר את הבעיה?
לרוב לא לבדו. אחסון חלש מחמיר את המצב, אבל אם התמונות כבדות והקוד עמוס, שרת חזק רק יעביר את העומס מהר יותר.
האם מהירות היא גורם דירוג בגוגל?
כן, אך משני. תוכן טוב יותר ינצח אתר מהיר עם תוכן דל. אבל בין שני אתרים דומים — המהיר מנצח.
כל כמה זמן כדאי לבדוק מהירות?
פעם ברבעון, ותמיד אחרי הוספת תוסף חדש או שינוי עיצובי משמעותי. רוב ההידרדויות מתחילות משינוי שנראה תמים.
סיכום
- מדדו במובייל וברשת סלולרית, לא במשרד.
- המטרה: LCP מתחת ל-2.5 שניות.
- התחילו מדחיסת תמונות — הרווח הגדול במאמץ הקטן.
- הסירו תוספים שאינם בשימוש בפועל.
- בדקו מחדש אחרי כל שינוי משמעותי באתר.
