שבע וחצי בערב, יום שלישי. מישהו באוטובוס בדרך הביתה מחפש "פיצה פתח תקווה", נוגע בתוצאה שלכם, ומקבל מסך לבן. הוא מחכה שנייה. שתיים. ואז חוזר לתוצאות החיפוש ומזמין מהמקום הבא ברשימה. הוא לא כועס עליכם — הוא בכלל לא זוכר שהיה אצלכם.
זו לא תחושת בטן. המחקר של גוגל The Need for Mobile Speed הוא המקור למספר שכולם מצטטים: כ-53% מהביקורים בנייד נוטשים דף שנטען יותר משלוש שניות. ומהצד השני של המשוואה, מחקר Milliseconds Make Millions של Deloitte, שבדק 37 מותגים ויותר מ-30 מיליון סשנים, מצא שהאצה של עשירית שנייה אחת בנייד העלתה את שיעור ההמרה באתרי קמעונאות ב-8.4% ואת שווי העגלה הממוצע ב-9.2%. עשירית שנייה.
והנה החלק שתמיד מפתיע: רוב בעלי המסעדות שאני מדבר איתם משוכנעים שהאתר שלהם מהיר. הם בודקים אותו מהטלפון שלהם, ברשת של המסעדה, כשהדף כבר שמור במטמון מאתמול. זה כמו לטעום מרק שאתם מכירים בעל פה. המדריך הזה הוא על למה הוא בעצם לא מהיר, מה בדיוק אשם, ומה לתקן קודם.
שלושה מספרים, וזה כל מה שגוגל מודד
לפני שפותחים כלים וקונים תוספים, כדאי לדעת שהשיחה הזו מצטמצמת לשלושה מספרים. גוגל קורא להם Core Web Vitals, והם מודדים שלושה דברים שונים לגמרי: כמה זמן עד שרואים משהו, כמה זמן עד שהדף מגיב לנגיעה, וכמה הדף זז מתחת לאצבע בזמן הטעינה. לכל אחד יש יעד מוגדר.
| המטריקה | מה הלקוח מרגיש | היעד ("טוב") | מה בדרך כלל אשם באתר מסעדה |
|---|---|---|---|
| LCP טעינה | מתי התמונה או הכותרת הגדולה בדף באמת מופיעות על המסך | עד 2.5 שניות | תמונת רקע או סליידר במשקל כמה מגה-בייט |
| INP תגובתיות | מתי הדף מגיב לנגיעה — לחיצה על "תפריט" או פתיחת קטגוריה | עד 200 אלפיות שנייה | עומס סקריפטים: ווידג'טים, פיקסלים, צ'אט |
| CLS יציבות | כמה הדף קופץ בזמן הטעינה והאצבע מפספסת את מה שרצתה | עד 0.1 | תמונות בלי מידות, באנר שנדחף למעלה באיחור |
מה באמת מאט אתר של מסעדה — חמשת החשודים
פתחתי לא מעט אתרים של מסעדות, פיצריות ובתי קפה, וההרכב חוזר על עצמו כמעט בלי שינוי. לא מדובר בשרת, לא בקוד ולא בחברת האחסון — אלא בחמשת הדברים הבאים, לפי סדר הנזק.
תמונות שהועלו ישר מהטלפון
זה החשוד הראשון בכמעט כל אתר שאני פותח, ובדרך כלל הוא לבד אחראי על 80 עד 90 אחוז ממשקל הדף. תמונה מהטלפון היא 3 עד 5 מגה-בייט ברוחב של יותר מ-4,000 פיקסלים — והיא מוצגת על מסך ברוחב 390 פיקסלים. הדפדפן לא יודע את זה: הוא מוריד את כל הקובץ ואז מקטין אותו בזיכרון. כלומר הלקוח שילם בסלולר על עשרה מגה כדי לראות תמונה בגודל כרטיס ביקור.
הפתרון הוא שתי פעולות, ואף אחת מהן לא דורשת מתכנת: להקטין את הצד הארוך — כ-1,600 פיקסלים לתמונת רקע רחבה, כ-900 לתמונת מנה בתפריט — ולשמור בפורמט מודרני. בבדיקות שמשוות קבצים באיכות נתפסת זהה, WebP קטן מ-JPEG בכשליש (חציון של כ-31%) ו-AVIF בכמחצית (חציון של כ-50%). אותה תמונה, אותו מראה, חצי משקל.
תמונת מנה בתפריט: מתחת ל-80KB.
דף תפריט שלם עם 12–15 תמונות: מתחת ל-1.5MB. אם אתם מעל — זה המקום להתחיל.
הסליידר והווידאו בראש העמוד
סליידר של חמש תמונות בראש הדף נראה בחינם, אבל הוא לא: בחלק מהמימושים הדפדפן מוריד את כל חמש התמונות לפני שהוא מראה את הראשונה. אתם משלמים על חמש ומראים אחת, כי רוב המבקרים בנייד אפילו לא מחליקים לתמונה השנייה. וידאו רקע שמתנגן אוטומטית הוא הגרסה היקרה של אותה טעות — מגה-בייטים, ועומס על המעבד של הטלפון בדיוק ברגע שבו הוא מנסה לצייר את הדף.
זה בדיוק מה ש-LCP מודד, ולכן זו הנקודה שבה הכי קל לראות שיפור. תמונה אחת קבועה בראש הדף — הכי טובה שיש לכם — ואז לגלול לתפריט. אם אתם חייבים וידאו, שימו אותו למטה בדף, עם תמונת פוסטר, בלי הפעלה אוטומטית בנייד.
התפריט שהוא קובץ PDF
קובץ PDF של תפריט הוא בדרך כלל 2 עד 8 מגה-בייט, הוא לא מתאים את עצמו למסך, ובנייד הוא נפתח בצופה חיצוני שבו צריך לצבוט ולזום כדי לקרוא מחיר. מעבר למשקל, זו גם בעיית חיפוש: גוגל קורא PDF חלקית בלבד, כך ששמות המנות שלכם לא באמת נמצאים באתר.
מי שרוצה להדפיס את התפריט — תנו לו קישור להורדה בתחתית העמוד. אבל התפריט עצמו צריך להיות עמוד HTML עם קטגוריות, שמות מנות ומחירים כטקסט. כתבתי על ההבדל בין PDF, תמונה ועמוד בהרחבה כאן.
הווידג'טים והפיקסלים שהצטברו
אתר ממוצע של מסעדה אחרי שלוש שנים מחזיק ווידג'ט צ'אט, ווידג'ט ביקורות, ווידג'ט הזמנות של ספק חיצוני, פיקסל של מטא, תגית של גוגל, ופעם הוסיפו גם כלי פופ-אפ לניוזלטר שאף אחד לא מנהל. כל אחד מהם הוא קוד JavaScript שרץ על אותו תהליך שמצייר את הדף. זה מה שהורג את INP — לא התמונות. הלקוח נוגע ב"תפריט", ושום דבר לא קורה במשך שליש שנייה, כי הדפדפן עסוק.
הכלל שאני עובד לפיו פשוט: כל ווידג'ט צריך להצדיק את עצמו במספר או לצאת. אם אתם לא יודעים כמה פניות הגיעו מהצ'אט בחודש האחרון, הוא לא נשאר. ואם צ'אט חשוב לכם — אפשר לטעון אותו רק בלחיצה על כפתור, במקום בכל טעינת דף.
הפונט בשישה משקלים
זה החשוד הקטן שאף אחד לא חושד בו. פונט עברי שנטען בשישה משקלים הוא שישה קבצים נפרדים, והטקסט לפעמים פשוט לא מוצג בכלל עד שהם מגיעים. הלקוח רואה דף עם תמונות ובלי מילים, וזה נראה שבור יותר מדף איטי.
בפועל צריך שני משקלים: רגיל לטקסט וכבד לכותרות. שווה גם לבקש font-display:swap, שמציג מיד טקסט בפונט ברירת מחדל ומחליף אותו כשהפונט מגיע, ו-preconnect לשרת הפונטים כדי לחסוך את זמן ההתחברות אליו.
איך בודקים נכון — שלושה שלבים
אל תתחילו מקניית תוסף "אופטימיזציה". תתחילו ממדידה, אחרת אין לכם דרך לדעת אם משהו עזר.
PageSpeed Insights — ותקראו את החלק העליון
מכניסים את כתובת הדף (לא רק את הדף הראשי — בדקו גם את דף התפריט) ובוחרים Mobile. החלק העליון של הדוח הוא נתוני שדה מגולשים אמיתיים, וזה מה שגוגל סופר. הציון הצבעוני הגדול מתחתיו הוא סימולציה במעבדה: שימושי כדי להבין מה לתקן, אבל הוא לא הציון שלכם. אתר יכול לקבל 72 במעבדה ולעבור את שלוש המטריקות בשטח, ולהיפך.
Search Console — איזה דף נכשל, לא רק אם
בדוח Core Web Vitals בסרץ' קונסול גוגל מקבצת את כתובות האתר לקבוצות ואומרת מה נכשל ובמה. זה המקום שבו מתגלה שהדף הראשי בסדר גמור ודווקא דף התפריט — זה שכל הלקוחות פותחים — הוא הבעייתי. בלי זה אתם מתקנים באפלה.
הטלפון שלכם, מחוץ לוויפיי של המסעדה
הבדיקה שאני מבקש מכל לקוח: לצאת מהמסעדה, לכבות ויפיי, לפתוח את האתר ברשת סלולרית בגלישה פרטית (כדי שלא יהיה מטמון) ולספור בקול. אם הגעתם ל"שלוש" לפני שהתפריט קריא, מצאתם את הבעיה בלי שום כלי.
מה לתקן קודם — לפי תמורה לשעת עבודה
אם יש לכם יום אחד בלבד, זה הסדר. הוא לא לפי מה שמעניין טכנית, אלא לפי כמה שניות כל צעד מחזיר.
1. להקטין ולהמיר את התמונות (כאן נמצא רוב המשקל).
2. להוריד את הסליידר או הווידאו מראש העמוד.
3. למחוק ווידג'טים שלא מודדים.
4. לצמצם את הפונט לשני משקלים.
ארבעת הצעדים האלה הם לרוב יום עבודה, והם לא נוגעים בעיצוב ולא בתוכן של האתר — אותו דף, אותן תמונות, אותו תפריט.
לא לקנות תוסף "האצה" שמבטיח 100 בציון — הוא בדרך כלל דוחה את טעינת הסקריפטים ושובר משהו אחר. לא לרדוף אחרי 100 במעבדה במקום אחרי שלושת מספרי השדה. ולא להמשיך לתקן אתר בן שש שנים עם 14 תוספים: לפעמים בנייה מחדש זולה יותר מחשבון השעות של התיקונים.
איך נראה הפרש כזה במספרים
כדי לתת סדר גודל — ככה נראה דף תפריט טיפוסי של פיצרייה לפני הטיפול ואחריו. המספרים כאן הם הטווח שאני פוגש בפועל, לא הבטחה:
משקל הדף: כ-9MB. LCP ברשת סלולרית: מעל 6 שניות.
אחרי: אותן 14 תמונות ב-WebP ברוחב 900 פיקסלים (ממוצע כ-62KB), תמונה אחת קבועה בראש העמוד, צ'אט שנטען בלחיצה, פונט בשני משקלים.
משקל הדף: כ-1.1MB. LCP: מתחת ל-2.5 שניות.
מה לא השתנה: העיצוב, התמונות, סדר המנות והמחירים. אותו דף בדיוק — רק בלי לשלם על מה שהלקוח לא רואה.
הרשימה שאני עובר עליה לפני שאתר עולה לאוויר
- כל תמונה הוקטנה לרוחב שבו היא באמת מוצגת, לא לרוחב שיצא מהמצלמה
- התמונות בפורמט WebP או AVIF, עם גיבוי JPEG לדפדפנים ישנים
- תמונת הראש מתחת ל-200KB, תמונת מנה מתחת ל-80KB
- לכל תמונה יש רוחב וגובה מוגדרים, כדי שהתפריט לא יקפוץ בטעינה
- התמונה הראשונה בראש העמוד לא מוגדרת כטעינה דחויה
- תמונה אחת בראש העמוד — בלי סליידר ובלי וידאו שמתנגן אוטומטית בנייד
- התפריט הוא עמוד HTML עם טקסט, וה-PDF הוא לכל היותר קישור להורדה
- כל ווידג'ט שנשאר באתר מצדיק את עצמו במספר פניות או הזמנות
- הפונט בשני משקלים, עם font-display:swap
- בדקתם את דף התפריט ב-PageSpeed Insights במצב Mobile, וקראתם את נתוני השדה
- פתחתם את האתר ברשת סלולרית, בגלישה פרטית, מחוץ לוויפיי של המסעדה
כמה שניות אתם מבזבזים ללקוח?
סמנו כל דבר שנכון לגבי האתר שלכם היום:
שאלות נפוצות
גוגל מודד שלושה מספרים, שנקראים Core Web Vitals: LCP — עד 2.5 שניות עד שהתוכן המרכזי בדף מופיע; INP — עד 200 אלפיות שנייה עד שהדף מגיב לנגיעה; ו-CLS — עד 0.1 תזוזה של התוכן בזמן הטעינה. כל אחד מהם נמדד על ביקורים אמיתיים, באחוזון ה-75 לאורך חלון נע של 28 יום, כלומר שלושה מכל ארבעה ביקורים צריכים לעמוד ביעד. בפועל, לאתר מסעדה זה אומר שדף התפריט צריך להיות קריא בפחות משתי שניות וחצי ברשת סלולרית. לפי נתוני ה-Web Almanac רק כ-48% מאתרי המובייל בעולם עוברים את שלוש המטריקות, כך שעמידה בהן כבר מקדמת אתכם מול חצי מהשוק.
כן, אבל זה לא הגורם המרכזי. Core Web Vitals הם אות דירוג אמיתי, והוא חלש בהרבה מרלוונטיות התוכן ומהאותות המקומיים כמו כרטיס העסק והביקורות. ההשפעה הגדולה יותר היא התנהגותית: מחקר The Need for Mobile Speed של גוגל מצא שכ-53% מהביקורים בנייד נוטשים דף שנטען יותר משלוש שניות, ולקוח שעזב גם לא הזמין וגם לא נתן לגוגל שום סימן שהדף שלכם ענה לו. מהירות לא תדחוף אתר חלש למעלה, אבל איטיות מפילה אתר טוב.
התמונות. כמעט בכל אתר מסעדה שאני פותח, התמונות הן 80 עד 90 אחוז ממשקל הדף, כי הן הועלו ישר מהטלפון — 3 עד 5 מגה-בייט לתמונה ורוחב של יותר מ-4,000 פיקסלים, שמוצג על מסך של 390 פיקסלים. הטיפול הוא להקטין את הצד הארוך לכ-1,600 פיקסלים לתמונת רקע ולכ-900 לתמונת מנה, ולשמור בפורמט מודרני: בבדיקות באיכות נתפסת זהה WebP קטן מ-JPEG בכשליש ו-AVIF בכמחצית. יעד מעשי — תמונת ראש מתחת ל-200KB ותמונת מנה מתחת ל-80KB. זה אחר צהריים אחד, והוא שווה יותר מכל השאר ביחד.
לא. אין הודעה של גוגל על מטריקה רביעית, על ציון מאוחד או על הקפדת היעדים — למשל טענות שה-LCP ירד ל-2 שניות. שלוש המטריקות והיעדים שלהן הם אותם שלושה מספרים, וגוגל עצמו מתעד שמטריקה יציבה לא משתנה יותר מפעם בשנה. השינוי האמיתי האחרון היה ב-12 במרץ 2024, כשמטריקת INP החליפה את FID כמדד התגובתיות הרשמי. אם מישהו מציע לכם לשלם על היערכות למטריקה חדשה של 2026 — בקשו קישור להודעה הרשמית.
רוצים אתר שנטען
לפני שהלקוח מתחרט?
שלחו הודעה בוואטסאפ עם כתובת האתר שלכם — נחמן יפתח אותו בנייד ברשת סלולרית, ויגיד לכם מה בדיוק מאט אותו ומה הצעד הראשון ששווה לעשות.
💬 דברו איתי בוואטסאפ השאירו פרטים 🍊