ציון 100 ב-PageSpeed: איך אתר מהיר מייצר יותר לידים (ומה הורג את המהירות שלכם)
מה באמת מאט אתרים של עסקים ישראליים: בילדרים עמוסי תוספים, תמונות כבדות, פונטים וּוידג'טים. מה אפשר לתקן בלי לבנות מחדש — ומתי כן שווה.
כשאני אומר לבעלי עסקים שהאתר שלי מקבל 100 ב-PageSpeed, התגובה הנפוצה היא "נחמד, אבל למי אכפת מציון". תשובה הוגנת — הציון עצמו הוא לא המטרה. אבל מה שהציון מודד דווקא מאוד אכפת ללקוחות שלכם: כמה זמן עובר מהרגע שהם לחצו על הקישור ועד שהם יכולים לקרוא, ללחוץ ולהשאיר פרטים.
מחקרים של גוגל הראו שוב ושוב את אותו דבר: ככל שעמוד נטען לאט יותר, יותר אנשים נוטשים אותו לפני שראו בכלל מה יש לכם להציע. כל שנייה מיותרת היא לידים שהלכו למתחרה שהאתר שלו נפתח מיד. ומעבר לנטישה — גוגל משתמשת במדדי מהירות כחלק מהדירוג, כך שאתר איטי גם מקבל פחות תנועה מלכתחילה. כפל קנס.
אחרי שנים של תיקון אתרים איטיים, אני יכול להגיד לכם שכמעט תמיד מדובר באותם חמישה חשודים. בואו נעבור עליהם.
חמשת הדברים שבאמת הורגים אתרים של עסקים בישראל
1. בילדר + ארבעים תוספים
הסיפור הקלאסי: האתר נבנה באלמנטור או בילדר אחר, ואז לאורך השנים נוספו תוספים — אחד לטפסים, אחד לגלריה, אחד לפופאפים, שלושה ל"אופטימיזציה" שנלחמים זה בזה. כל תוסף מזריק קבצי CSS ו-JavaScript לכל עמוד באתר, גם עמודים שבכלל לא משתמשים בו. התוצאה: הדפדפן של הגולש מוריד ומריץ ערימת קוד רק כדי להציג עמוד "אודות" עם שלוש פסקאות. הבילדר עצמו מוסיף שכבה נוספת של קוד גנרי מעל הכל.
2. תמונות לא מאופטמות
החשוד הנפוץ ביותר, והכי קל לתיקון: תמונה שיצאה מהמצלמה או מ-Canva במשקל של כמה מגה-בייט, הועלתה כמו שהיא, ומוצגת בגודל של בול דואר. הגולש מוריד תמונה ברוחב אלפי פיקסלים כדי לראות אותה בריבוע קטן בגריד. פורמטים מודרניים (WebP, AVIF), מידות שמתאימות לתצוגה בפועל וטעינה עצלה (lazy loading) לתמונות שמתחת לקו המסך — פותרים את רוב הבעיה.
3. טעינת פונטים
פונטים עבריים יפים הם דבר נהדר, אבל אתר ממוצע טוען שלושה-ארבעה משקלים של שני פונטים משרתים חיצוניים, ובזמן הזה הטקסט או שמוסתר לגמרי או קופץ ומשנה צורה כשהפונט סוף-סוף מגיע. הפתרון: לארח את הפונטים על השרת שלכם, לטעון רק את המשקלים שבאמת בשימוש, ולהגדיר טעינה שמציגה טקסט מיד גם לפני שהפונט הגיע.
4. וידג'טים של צד שלישי
צ'אט של וואטסאפ, תוסף נגישות צף, פיקסלים של פייסבוק וטיקטוק, מפת גוגל מוטמעת — כל אחד מהם נשמע קטן, וביחד הם לפעמים כבדים יותר מהאתר עצמו. הם נטענים משרתים חיצוניים שאין לכם שליטה עליהם, ורבים מהם חוסמים או מעכבים את מה שחשוב באמת. אגב, על תוסף הנגישות הצף כתבתי מאמר שלם — הוא בעייתי לא רק לביצועים. את מה שחייבים להשאיר אפשר לטעון בחוכמה: אחרי שהעמוד כבר הוצג, או רק כשהגולש באמת צריך אותו.
5. סליידרים וקרוסלות
הסליידר בראש העמוד הוא אולי האלמנט הכי פופולרי והכי פחות משתלם בעולם האתרים: הוא טוען חמש תמונות ענקיות וספריית JavaScript שלמה, כדי שרוב הגולשים יראו רק את השקופית הראשונה ויגללו הלאה. תמונת חזית אחת טובה, סטטית ומאופטמת, עושה את העבודה טוב יותר — גם שיווקית וגם טכנית.
שלושת המדדים, בשפה של בני אדם
גוגל מודדת חוויית טעינה בשלושה מדדים מרכזיים (Core Web Vitals). הנה מה שהם אומרים בפועל:
LCP (Largest Contentful Paint) — כמה זמן לוקח עד שהאלמנט הגדול בעמוד — בדרך כלל תמונת החזית או הכותרת הראשית — מוצג על המסך. זה המדד שהכי קרוב לתחושת "האתר נפתח": אם ה-LCP איטי, הגולש בוהה במסך לבן ותוהה אם הקישור בכלל עובד.
CLS (Cumulative Layout Shift) — כמה העמוד "קופץ" בזמן הטעינה. מכירים את זה שאתם עומדים ללחוץ על כפתור ואז נטענת פרסומת שדוחפת הכל והלחיצה נוחתת על משהו אחר? זה CLS גרוע. הוא נגרם מתמונות בלי מידות מוגדרות, מפונטים שמחליפים צורה ומבאנרים שנדחפים באיחור.
INP (Interaction to Next Paint) — כמה מהר העמוד מגיב כשלוחצים עליו. פתחתם תפריט והוא נפתח אחרי חצי שנייה של שיהוי? זה INP גרוע, וכמעט תמיד האשם הוא עודף JavaScript שמעסיק את הדפדפן בזמן שהגולש מנסה לתקשר איתו.
איך נראה "טוב"?

לגוגל יש ספים רשמיים לכל מדד — ירוק, כתום ואדום — והכלי החינמי PageSpeed Insights יראה לכם בדיוק איפה אתם, גם על נתוני מעבדה וגם על נתוני גולשים אמיתיים. אבל הבדיקה הפשוטה ביותר לא דורשת כלים: פתחו את האתר שלכם מהטלפון, על גלישה סלולרית, במצב גלישה בסתר. ספרו לעצמכם עד כמה. אם הספקתם להגיע לשלוש לפני שאפשר לקרוא את הכותרת — יש עבודה.
ציון 100 הוא לא קסם ולא מזל. הוא תוצאה של להוריד מהעמוד כל מה שלא משרת את הגולש — ולטעון את מה שנשאר בסדר הנכון.
"בדקתי אתמול וקיבלתי 92, היום 68" — למה הציון קופץ
זו כנראה השאלה שאני עונה עליה הכי הרבה, ובצדק: קשה להתייחס ברצינות למספר שמשתנה בכל רענון. הסיבה היא שיש שני סוגי נתונים שונים לגמרי, ושניהם מופיעים באותו מסך.
נתוני מעבדה (Lab). הבדיקה שרצה ברגע שלחצתם. גוגל מדמה מכשיר בינוני על רשת סלולרית מוגבלת ומודדת פעם אחת. זה נתון רועש מטבעו: שרת עמוס לרגע, סקריפט של צד שלישי שהגיב לאט, או פשוט תור עמוס אצל גוגל — וקיבלתם עשר נקודות פחות. הציון הצבעוני הגדול הוא זה.
נתוני שטח (Field). מה שקרה לגולשים אמיתיים שלכם בשלושים הימים האחרונים, מתוך נתוני Chrome. הנתון הזה יציב, הוא לא זז בין בדיקות, והוא זה שגוגל מסתכלת עליו. הוא מופיע בחלק העליון של הדוח, ורק אם יש לאתר מספיק תנועה.
מה זה אומר בפועל:
- אל תסיקו מסקנות מבדיקה בודדת. הריצו שלוש, קחו את האמצעית.
- בדקו תמיד באותם תנאים: מובייל מול מובייל, אותו עמוד, גלישה בסתר (תוספים בדפדפן מעוותים את התוצאה).
- אם יש לכם נתוני שטח — הם התשובה. נתוני המעבדה הם רק כלי אבחון שמראה למה.
- אחרי תיקון, נתוני השטח מתעדכנים בהדרגה על פני שבועות, לא מיד. אל תיבהלו שהמספר לא זז ביום למחרת.
ואם הפער בין השניים גדול — למשל מעבדה ירוקה ושטח אדום — זה כמעט תמיד אומר שהגולשים האמיתיים שלכם על מכשירים חלשים או רשתות איטיות יותר ממה שהבדיקה מדמה.
דסקטופ ירוק, מובייל אדום — על איזה מסתכלים?
הדוח מציג שתי לשוניות, וכמעט תמיד הן מספרות סיפורים שונים: 95 בדסקטופ, 60 במובייל. שני המספרים נכונים. חשוב רק אחד מהם.
הבדיקה במובייל מדמה בכוונה מכשיר בינוני על רשת סלולרית חנוקה — לא כי גוגל פסימית, אלא כי זה המכשיר של גולש אמיתי בדרך לעבודה. ובדיוק משם מגיעה רוב התנועה לאתרים עסקיים: מהמודעות, מהוואטסאפ, מהחיפוש בטלפון. גוגל גם מדרגת לפי גרסת המובייל של האתר, לא לפי הדסקטופ.
אז הציון בדסקטופ נחמד לאגו, והציון במובייל קובע את הלידים. אם חייבים מספר אחד לעקוב אחריו — זה השני.
הדבר שאי אפשר לתקן בקוד: זמן התגובה של השרת
יש רכיב אחד שלא משנה כמה תדחסו תמונות — הוא לא יזוז: כמה זמן לוקח לשרת להתחיל לענות בכלל. זה מכונה TTFB, ובעברית פשוטה זה הזמן מהרגע שהדפדפן ביקש את העמוד ועד שהגיע התו הראשון. כל שאר האופטימיזציות מתחילות רק אחרי שזה נגמר.
איך יודעים שזו הבעיה שלכם: אם הדוח מראה שהתמונות בסדר, הסקריפטים סבירים, והציון עדיין נמוך — תסתכלו על זמן התגובה. ואם הבדיקה הראשונה בבוקר איטית והשנייה מהירה, זה כמעט תמיד אחסון משותף שהיה עסוק.
מה שבדרך כלל אשם:
- אחסון משותף זול שבו מאות אתרים חולקים את אותם משאבים. אתם משלמים מעט ומחכים בתור.
- מסד נתונים מנופח — טבלאות שהתמלאו בגרסאות ישנות של פוסטים, יומני תוספים ותורי משימות שאף אחד לא ניקה שנים.
- בלי מטמון. בלי שכבת קאשינג, וורדפרס בונה כל עמוד מחדש בכל בקשה, גם כשהעמוד לא השתנה חצי שנה.
- שרת רחוק מהגולשים. אם הקהל בישראל והשרת בארה"ב, כל בקשה נוסעת הלוך ושוב.
הבשורה הטובה: זה בדרך כלל התיקון הכי זול ביחס להשפעה. מעבר לאחסון סביר עם מטמון תקין יכול להוריד שנייה שלמה בלי לגעת בשורת קוד אחת — ושנייה כזאת מורגשת בכל עמוד, לא רק בעמוד הבית. איך בוחרים אחסון כזה, וממה להיזהר בדרך — במדריך האחסון.
מה אפשר לתקן בלי לבנות מחדש
חדשות טובות: חלק גדול מהבעיות מטופל באתר הקיים, בלי לגעת בעיצוב:
- דחיסת והמרת תמונות לפורמטים מודרניים, עם מידות נכונות וטעינה עצלה
- צמצום תוספים — מחיקת מה שלא בשימוש ואיחוד כפילויות (שלושה תוספי קאשינג זה לא "יותר מהירות", זו תאונה ממתינה)
- אירוח פונטים מקומי וטעינה של המשקלים הנחוצים בלבד
- דחיית וידג'טים של צד שלישי לאחרי הטעינה הראשונית
- קאשינג ו-CDN מוגדרים כמו שצריך ברמת השרת
- החלפת הסליידר בתמונת חזית סטטית אחת
טיפול כזה מקפיץ את רוב האתרים בצורה מורגשת — זה בדיוק סוג העבודה שאני עושה בשיפור ותיקון אתרים קיימים.
ורגע לפני שמשקיעים במהירות
מהירות מכפילה תוצאה קיימת — היא לא יוצרת אותה. אם האתר בכלל לא מופיע בגוגל, הבעיה כנראה טכנית ואחרת לגמרי, וכתבתי עליה בנפרד: 6 סיבות טכניות שאתר לא מופיע בגוגל. שווה לוודא שהדלת פתוחה לפני שמשפצים את הסלון.
ומתי בנייה מחדש משתלמת?
יש נקודה שבה אופטימיזציה הופכת למירוץ נגד הארכיטקטורה. אם האתר בנוי על בילדר כבד עם עשרות תוספים, כל שיפור הוא מאבק במגבלות המבנה: אפשר לרדת מ-40 נקודות ל-70, אבל ה-30 האחרונות כלואות בתוך יסודות שאי אפשר להחליף בלי לפרק. הסימנים שהגעתם לשם: כל תוסף חדש שובר משהו, עדכונים מפחידים אתכם, וכבר שילמתם לשני "מומחי מהירות" שהזיזו את המחט בקושי.
במצב כזה, אתר חדש שנבנה רזה ונכון מהיסוד — בלי שכבות של קוד גנרי, עם ביצועים כדרישת בסיס ולא כתוספת — משתלם יותר תוך שנה-שנתיים, גם בכסף וגם בלידים. זה בדיוק מה שאני בונה בפיתוח אתרים: אתרים שמקבלים 100 כי הם בנויים לזה, לא כי מישהו נלחם בהם עד שנכנעו.
רוצים לדעת איפה האתר שלכם עומד ומה יעיל יותר במקרה שלכם — שיפור או בנייה מחדש? דברו איתי ואחזור אליכם עם תשובה כנה, גם אם היא "האתר שלכם בסדר גמור, תשקיעו את הכסף בשיווק".
עוד מהבלוג
- טכנולוגיה
אחסון אתרים: איך בוחרים, ממה להיזהר, ומתי הוא הבעיה האמיתית
מדריך לבחירת אחסון לאתר: בדיקת דקה שחושפת שרת איטי, שבעה דברים לבדוק לפני שחותמים, מה ש'ללא הגבלה' באמת אומר, ומתי אתר סטטי עדיף.
6 דקות קריאה - נגישות
הנגשת אתרים בישראל: כל מה שהחוק דורש מבעלי עסקים (ת"י 5568)
מדריך מעשי בעברית פשוטה לחוק הנגשת אתרים בישראל: מי חייב, מה דורש ת"י 5568, למה תוסף צף לא מספיק, ומה חייבת לכלול הצהרת נגישות.
9 דקות קריאה - תהליך
איך בוחרים מפתח אתרים? 9 שאלות לשאול לפני שחותמים
לפני שמזמינים אתר: תשע שאלות שחושפות מי באמת עומד מולכם — בעלות על הדומיין והקוד, מה קורה אחרי ההשקה, נגישות ומהירות כברירת מחדל, ומה עושים אם הוא נעלם.
7 דקות קריאה
ספרו לי מה אתם בונים.
הודעה קצרה מספיקה. אחזור אליכם תוך יום עסקים — עם תשובה עניינית, לא עם תסריט מכירה.