מהירות אתר נמוכה היא בדרך כלל שילוב של כמה דברים, ולא תקלה אחת. מבקר שמחכה יותר מדי למסך לבן מוותר, ולכן כדאי להבין מה גורם לאיטיות. הבשורה הטובה היא שאפשר לאתר את הסיבות בעזרת בדיקה פשוטה, ושרובן חוזרות על עצמן מאתר לאתר.
במאמר נציג שבע סיבות נפוצות, נסביר איך מזהים כל אחת ומה אפשר לעשות, בלי להבטיח ציון מסוים. כרקע, לפי בדיקה וסקר שוק שעשינו (אוקטובר 2026), ממוצע ציון המהירות בנייד היה 60, ואף אחד מהאתרים שנבדקו לא הגיע ל-90. הנתון משוער, והוא אומר שאם הציון שלך נמוך, אתה לא לבד.
בקצרה:
- רוב המקרים נובעים משבע סיבות חוזרות: תמונות, קוד עודף, אחסון, פונטים, סקריפטים חיצוניים, תצוגה בנייד ועומס כללי על הדף.
- אפשר לזהות כל סיבה בבדיקה פשוטה של דוח המהירות.
- מתחילים מהסיבה שנותנת את הרווח הגדול ביותר, לא מהקלה ביותר לטיפול.
איך יודעים שמהירות האתר באמת נמוכה
בודקים בכלי בדיקה בנייד ומחכים לראות מה נטען ראשון. אם המסך נשאר ריק זמן ארוך, או שהכפתורים לא מגיבים אחרי שהתוכן כבר מוצג, זה סימן. הכלי החינמי של גוגל, PageSpeed Insights, מציג את זה במספרים ובמדדים, ומצביע על הגורמים.
איטי בעיניים או איטי במספרים
יש הבדל בין תחושה למדידה. אתה, כבעל האתר, מכיר אותו ולכן לא מרגיש בעיות: הדפדפן שלך שמר תמונות מביקורים קודמים, והחיבור שלך מהיר. מבקר חדש בטלפון, בחיבור סלולרי, חווה משהו אחר. לכן בדיקה בכלי נותנת תמונה אובייקטיבית יותר מהתחושה שלך. כדאי גם לפתוח את האתר בטלפון של מישהו אחר ולצפות בו.
מה נחשב נמוך
לפי בדיקה וסקר שוק שעשינו (אוקטובר 2026), ממוצע ציון הנייד הוא 60 ואף אתר לא הגיע ל-90, כך שציון נמוך הוא מצב נפוץ. אל תבהל ממספר אחד, אבל כן תתייחס אליו ברצינות. כדאי להבחין בין בעיות בתוכן שנטען לבין זמן ההמתנה לשרת, וזה יעזור לך להבין איפה לחפש. על ההשפעה האפשרית על פניות אפשר לקרוא במאמר על מהירות טעינת אתר, בלי הבטחות ובלי מספרי המרה.
בדיקות פשוטות שאפשר לעשות היום
לפני שמתחילים לחפש סיבות, שלוש בדיקות קצרות נותנות כיוון. הראשונה: פתח את האתר בטלפון בחיבור סלולרי ולא בוויפיי, וראה כמה זמן עד שמופיע תוכן. השנייה: הרץ את הבדיקה של גוגל בנייד ורשום את הציון. השלישית: גלול בדף ושים לב אם משהו קופץ או זז. שלוש הבדיקות האלה לוקחות דקות, והן מספרות לך אם יש בכלל בעיה ובאיזה כיוון כדאי לחפש.
תמונות כבדות שלא עברו הקטנה
זו הסיבה הראשונה והנפוצה. תמונה שצולמה במצלמה או בטלפון נשלחת לעיתים כמו שהיא, בגודל מלא, גם כשהמסך מציג אותה בקטן. הדפדפן צריך להוריד קובץ כבד, ואז להקטין אותו בעצמו. זה כמו לארוז מזוודה בכוח: הכול נכנס בסוף, אבל באיחור ובקושי.
איך מזהים
בדוח הבדיקה מופיעות אזהרות על גודל התמונות, כמו המלצה להקטין תמונות או להגיש אותן בפורמט יעיל יותר. הדוח מציין גם אילו תמונות הכבדות ביותר. אם בראש דף הבית יש תמונה גדולה, היא בדרך כלל זו שתופיע ברשימה.
מה עושים
- להקטין את המידות לגודל שהמסך באמת מציג.
- לדחוס את הקובץ, כך שהוא ישקול פחות בלי לפגוע בעין.
- לבחור פורמט יעיל, כמו webp.
- לטעון בהדרגה תמונות שנמצאות בהמשך הדף, ולא את כולן מיד.
דוגמה להמחשה בלבד: תמונת רקע גדולה בראש הדף שמעכבת את כל השאר. עד שהיא נטענת, המבקר רואה מסך ריק. הקטנה של התמונה היא לעיתים הצעד היחיד שנדרש כדי לשנות את התחושה.
דוגמה להמחשה: לפני ואחרי
דוגמה להמחשה בלבד: עסק מעלה תמונה אחת גדולה לדף הבית, מריץ בדיקה ומקבל אזהרה. הוא מקטין את התמונה, מעלה אותה שוב ומריץ בדיקה נוספת. ההבדל נראה בציון, ובעיקר ביכולת שלו לראות את הדף נטען מהר יותר בטלפון. זה לא נס, זה פשוט הסרה של עומס מיותר. לפעמים תיקון אחד מספיק כדי להרגיש שינוי, ולכן שווה להתחיל מהדברים הברורים.
קוד עודף ותוספים שנטענים בכל דף
הסיבה השנייה היא קוד שנטען גם כשהוא לא משמש את הדף. כל קובץ כזה עומד בתור לפני שהדף יכול להציג את מה שחשוב באמת, כמו משאיות לפני מנהרה צרה. מערכות עם תוספים עלולות לטעון קבצים רבים, לעיתים, תלוי בהגדרה, ולא תמיד חלקם נחוצים לדף הספציפי.
איך מזהים
בדוח יש אזהרות על קוד שלא בשימוש ועל קבצים שחוסמים את ההצגה. אם אתה רואה ברשימה אזהרות כאלה, ייתכן שיש באתר יותר קוד ממה שנחוץ. גם אתר שהוסיפו לו תוספים לאורך השנים נוטה לצבור עומס כזה.
למה זה קורה גם לאתרים מסודרים
קוד עודף לא מעיד על רשלנות. הוא נצבר טבעית: מישהו מוסיף תוסף לניסוי ושוכח להסיר אותו, כלי מעקב שהפסיקו להשתמש בו נשאר באתר, ועיצוב ישן משאיר אחריו קבצים. כדאי לעבור על האתר מדי פעם כמו על ארון, ולהוציא מה שכבר לא בשימוש.
מה עושים
להפחית ולהסיר מה שלא נחוץ. עוברים על התוספים ושואלים לגבי כל אחד: האם אני משתמש בו, האם הוא משרת את העסק, האם יש דרך פשוטה יותר לעשות את אותו דבר? אחרי כל הסרה מריצים בדיקה חדשה. אתר שנבנה עם פחות חלקים נעים נוטה לסבול פחות מהסיבה הזאת, ולכן אנחנו בונים ב-Astro, בלי תוספים ובלי לוח ניהול.
טעות נפוצה: להוסיף תוסף לכל בעיה
כשמשהו לא עובד, הנטייה היא להוסיף תוסף שפותר אותו. תוסף לגלריה, תוסף לטופס, תוסף לאנימציה. כל אחד מהם פותר בעיה קטנה, אבל מוסיף קבצים. עם הזמן האתר מצטבר עם פתרונות חלקיים רבים. אם אפשר לפתור בעיה בלי תוסף, כמו בעיצוב פשוט יותר, זו בדרך כלל הבחירה הנקייה יותר.
אחסון חלש ושרת שמגיב לאט
הסיבה השלישית אינה בדף עצמו אלא בשרת. אם השרת עונה באיטיות לבקשה הראשונה, כל השאר מתעכב, בלי קשר לכמה האתר מעוצב היטב. זה כמו צינור דק שנוטף לאט: אפשר להכין דלי גדול, אבל המים עדיין יגיעו בקצב של הצינור.
איך מזהים
בדוח מופיע זמן ההמתנה עד התגובה הראשונה מהשרת. אם הוא ארוך, החשד הראשון הוא האחסון. כדאי להריץ את הבדיקה כמה פעמים ובשעות שונות, כי שרת עמוס מתנהג אחרת מבדיקה לבדיקה.
אחסון משותף ואחסון ייעודי
ברמה כללית, באחסון משותף כמה אתרים חולקים אותם משאבים, ובאחסון ייעודי המשאבים שמורים לאתר אחד. לפי מה שמפורסם אצל הספקים, כדאי לבדוק מידע עדכני לפני בחירה. חשוב לדעת שאצלנו אין דמי אחסון, והגישות אצל הלקוח. מי שמתמודד עם אתר וורדפרס איטי יכול לקרוא על דרכי שיפור במאמר על שיפור מהירות באתר וורדפרס.
מתי להחליף אחסון
לא כל איטיות מצדיקה החלפת אחסון. קודם מוודאים שהתמונות והקוד תקינים, כי הם הנפוצים יותר. אם אחרי התיקונים זמן התגובה של השרת עדיין ארוך, ובדיקות חוזרות בשעות שונות מראות את אותו דבר, אז שווה לבדוק את האחסון. רצוי להשוות מחירים ותנאים אצל כמה ספקים ולקרוא מידע עדכני אצל כל ספק, לפני שמחליטים.
פונטים, סרטונים וסקריפטים חיצוניים
כאן נכללות שתי סיבות. הרביעית היא פונטים שנטענים מבחוץ. הדפדפן צריך להוריד אותם לפני שהוא מציג את הטקסט בעיצוב הרצוי, ובינתיים הטקסט נעלם או מופיע בצורה אחרת. החמישית היא סקריפטים של צד שלישי, כמו כלי מעקב, פרסום או צ'אט, שכל אחד מהם מוסיף בקשה חיצונית.
סקריפטים של צד שלישי
כל כלי חיצוני שמוסיפים לאתר עולה בזמן טעינה. כלי מעקב, כפתור צ'אט, ווידג'ט של רשת חברתית: כל אחד מהם נראה קטן, אבל יחד הם נוספים. המבקר לא מרוויח מהם ישירות, אבל הוא ממתין בגללם. כדאי לשאול לגבי כל כלי: מה אני מרוויח ממנו, ואם אפשר לוותר עליו.
סרטון בראש הדף
סרטון שמתחיל לטעון מיד הוא קובץ כבד שמתחרה על משאבים עם כל השאר. אפשר להשאיר אותו, אבל לטעון אותו רק אחרי לחיצה או אחרי שהדף כבר מוצג. מה שחשוב הוא לשאול האם הוא באמת עוזר למבקר להבין מה אתה מציע.
מה אפשר לוותר עליו ומה כדאי להשאיר
מה שמתחבר ישירות לפניות, כמו טופס ויכולת להתקשר, כדאי להשאיר. מה שאין לו תפקיד ברור, כמו ווידג'ט מעוטר או כלי שאיש לא משתמש בנתונים שלו, אפשר להסיר. כך נשארים עם פחות עומס ועם כל מה שעושה עבודה.
פונטים: כמה זה מספיק
אתר לא צריך הרבה סוגי כתב. שני פונטים, אחד לכותרות ואחד לטקסט, בדרך כלל מספיקים לעיצוב נקי. כל פונט נוסף הוא קובץ נוסף, וכל משקל של פונט, כמו עבה, דק ומודגש, מוסיף עוד אחד. אם אתה רואה בדוח המלצה על פונטים, בדוק קודם כמה אתה משתמש בהם ואם כולם נחוצים.
עיצוב שלא מתחשב בנייד
הסיבה השישית: עיצוב שנועד למסך גדול ומכווץ בכוח לטלפון. כל חלק שמתאים למחשב אך לא לנייד מוסיף עבודה לדפדפן. הוא צריך להוריד אלמנטים גדולים, לסדר אותם מחדש ולהסתיר חלקים. התוצאה היא איטיות, ולפעמים גם קפיצות בעיצוב.
איך מזהים
סימן אופייני הוא אלמנטים שקופצים בזמן הטעינה: כפתור שזז, תמונה שדוחפת טקסט למטה, תפריט שמופיע באיחור. בדוח זה מופיע כמדד יציבות העיצוב. גם הבדל גדול בין ציון המחשב לציון הנייד הוא סימן.
מה זה אתר רספונסיבי בקצרה
אתר רספונסיבי מסדר את עצמו לפי רוחב המסך, והוא נבנה כך מההתחלה. אי אפשר "להדביק" אותו אחר כך בקלות. מי שרוצה להבין את העיקרון יכול לקרוא את המאמר על אתר רספונסיבי, שמסביר מה משתנה בין מסך למסך ואיך בודקים.
בדיקה בטלפון: תרגיל קצר
נסה תרגיל פשוט. פתח את האתר בטלפון, נסה לבצע את הפעולה שאתה רוצה שמבקר יעשה, כמו להתקשר או למלא טופס, והתבונן במה שמפריע. האם הכפתור מופיע מהר? האם התמונה קפצה ודחפה אותו? האם הטקסט קריא בלי להגדיל? ההבחנות האלה לא דורשות כלים, והן חושפות בעיות שהמספרים לא תמיד מראים.
שבע הסיבות בטבלה אחת: מה לבדוק ומה לתקן
לא כל הסיבות יופיעו בכל אתר. לרוב יש שתיים או שלוש בולטות, והשאר משניות. הטבלה מרכזת את כולן, כולל הסיבה השביעית, עומס כללי על הדף, שהיא שילוב של המון אלמנטים בדף אחד.
| הסיבה | איך מזהים | מה בדרך כלל מתקנים |
|---|---|---|
| תמונות כבדות | אזהרות בדוח על גודל התמונות | הקטנה, דחיסה וטעינה בהדרגה |
| קוד עודף | אזהרות על קוד שלא בשימוש | הסרה של תוספים וקבצים מיותרים |
| אחסון איטי | זמן המתנה ארוך לתגובה הראשונה | בדיקת האחסון ושדרוג במידת הצורך |
| פונטים | טקסט שמופיע באיחור או משנה צורה | הפחתת מספר הפונטים וטעינה יעילה |
| סקריפטים חיצוניים | רשימת בקשות לשירותים אחרים | הסרת כלים שלא נחוצים ודחיית השאר |
| עיצוב שלא מותאם לנייד | פער גדול בין נייד למחשב, קפיצות | עיצוב רספונסיבי שנבנה כראוי |
| דף עמוס מדי | הרבה אלמנטים, סרטונים ואנימציות | צמצום לתוכן שמשרת את המטרה |
הערה על דף עמוס מדי
הסיבה השביעית נוצרת בהצטברות. תמונה אחת, סרטון אחד, אנימציה אחת, וגם מונה, גם צ'אט, גם בועה צפה. כל אחד מהם סביר בנפרד, אבל יחד הם הופכים את הדף לכבד. הפתרון כאן הוא לא טכני אלא מבני: לשאול מה באמת צריך להיות בדף כדי שמבקר יבין ויפנה.
סדר טיפול מומלץ
אחרי שזיהית כמה סיבות, צריך סדר. התחל מהתמונות, כי הרווח בדרך כלל גדול והתיקון פשוט. המשך לתוספים וקוד עודף. אחר כך בדוק סקריפטים חיצוניים ופונטים. רק אם הבעיה נמשכת, בדוק את האחסון ואת מבנה האתר. בכל שלב בדוק שוב לפני שאתה ממשיך, כדי שתדע מה עבד, ולא תבזבז זמן על תיקונים שלא נחוצים.
איך מחליטים אם להמשיך לתקן
אחרי כמה סבבי תיקון, שאל את עצמך שלוש שאלות. האם הציון והחוויה בנייד השתפרו? האם נשארו בעיות שחוזרות על עצמן? והאם עלות הזמן שאתה משקיע עדיין סבירה? אם התשובות מראות שהשיפור קטן והעבודה גדולה, זה סימן שאפשר לעצור ולבחון דרך אחרת. אין חובה להגיע לציון מושלם. מספיק אתר נוח, ברור ומהיר מספיק כדי שמבקר ישאר ויפנה.
מהירות אתר בגוגל: מה אפשר לתקן לבד
אפשר לתקן לא מעט בלי מפתח. הקטנת תמונות, הסרת תוספים שלא נחוצים והחלפת סרטון בתמונה קבועה הם צעדים שבעל עסק זהיר יכול לעשות לבד. זה יעבוד במיוחד אם האתר שלך נבנה במערכת עם לוח ניהול.
מה דורש בונה
שינויים בקוד, באחסון ובמבנה הדף דורשים בדרך כלל מי שמכיר את האתר מבפנים. אם אתה לא בטוח, אל תנסה. שינוי שגוי עלול לשבור את האתר. המלצה פרקטית: העתק את הפריטים מהדוח, שלח אותם לבונה ובקש הערכה לפני שמתחילים.
בדיקה מסודרת
כדי לקבל תמונה מלאה, אפשר להתחיל מעמוד בדיקת המהירות שלנו, ולהמשיך לקרוא את הדוח בצעדים. חשוב לזכור שמהירות היא רק חלק מהתמונה. אתר שגוגל לא מוצא או לא מבין לא יזכה לתנועה גם אם הוא מהיר, ולכן כדאי לקרוא גם על פתיחת אתר חדש בגוגל.
סיכום ביניים: מה לקחת מהמאמר
שבע הסיבות אינן רשימה מפחידה אלא רשימת בדיקה. רוב האתרים סובלים משתיים או שלוש מהן, והתיקון של הראשונות הוא בדרך כלל פשוט. הדבר החשוב הוא לא להתחיל בניחוש. מריצים בדיקה, קוראים אילו אזהרות מופיעות, מתקנים אחת, בודקים שוב וממשיכים. כך בונים שיפור יציב במקום לרדוף אחרי מספר.
בנייה נכונה: אתר שלא סובל מהבעיות האלה
הדרך הטובה ביותר להימנע מכל הסיבות האלה היא לבנות את האתר כך שהן לא יופיעו מלכתחילה. כך אנחנו עובדים: ציון מהירות מעל 90 ביום המסירה, אתר פשוט עם פחות חלקים נעים, ותמונות שהוקטנו לפני העלאה. זה לא קסם אלא סדר עבודה.
מה כלול
האתר נבנה ב-Astro: דפים מוכנים, אין לוח ניהול ותוספים, ופחות חלקים נעים. אנחנו נותנים 3 חודשי אחריות לתיקונים טכניים, אם הציון יורד בגלל תקלה שלא נגרמה משינוי של הלקוח בקוד. אין הבטחת השפעה על דירוג או על מכירות, ואנחנו אומרים את זה בגלוי.
למי זה מתאים
למי שמתלבט בין תיקון האתר הקיים לבין בנייה מחדש. אחרי שעברת על שבע הסיבות, אתה יודע כמה מהן רלוונטיות לך. אם רובן נוגעות במבנה של האתר, ייתכן שבנייה מחדש תחסוך לך זמן. אפשר לראות איך נראית הדרך שלנו בדף הבית של SZ בונה אתרים.
רוצה אתר מהיר מההתחלה? דבר איתנו
אם אתה רוצה לבדוק מה מאט את האתר שלך, או לשקול אתר חדש שנבנה עם מהירות כיעד, דבר איתנו. ספר מה האתר עושה היום, ונבדוק יחד מה כדאי לטפל בו קודם.
המאמר נכתב בעזרת בינה מלאכותית, ונערך ואושר על ידי סלבה זמסקי, המייסד של SZ.