האתר איטי? איך בודקים מהירות אתר ומה באמת משפר אותה

בודקים מהירות אתר לפי נתונים של גולשים אמיתיים, לא לפי ציון של בדיקה אחת: הדוח ״מדדי חוויית משתמש״ בגוגל סרץ׳ קונסול והחלק העליון של PageSpeed Insights מראים מה קרה אצל המבקרים שלכם בחודש האחרון. את רוב האיטיות פותרים בחמישה מקומות קבועים: התמונה הראשית בראש העמוד, סקריפטים של צד שלישי, תוספים, גופנים, וזמן התגובה של השרת. המדריך הזה מסביר איך לקרוא את המדדים, איפה הזמן באמת הולך, ומתי הבעיה בכלל לא באתר אלא באחסון.

איך בודקים אם האתר באמת איטי?

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

יש שני כלים חינמיים של גוגל שעושים את זה. הראשון הוא PageSpeed Insights: מדביקים כתובת של עמוד ומקבלים שני חלקים, נתוני שטח למעלה וניתוח מעבדה למטה. השני הוא דוח מדדי חוויית המשתמש בגוגל סרץ׳ קונסול, שמראה את כל האתר בבת אחת, מקובץ לקבוצות של עמודים דומים ומופרד בין מובייל למחשב.

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

נתוני משתמשים אמיתיים מול בדיקת מעבדה

נתוני השטח מגיעים מדוח חוויית המשתמש של כרום, שאוסף מדידות אנונימיות מגולשים שהסכימו לשתף אותן. לפי התיעוד של PageSpeed Insights, נכון לאוקטובר 2026, הנתונים האלה מסכמים את 28 הימים האחרונים, ונמדדים באחוזון ה־75. כלומר, עמוד עובר רק אם שלושה מכל ארבעה ביקורים לפחות היו מהירים מספיק.

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

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

למה הציון ב־PageSpeed קופץ בין בדיקות

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

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

מה המדדים של גוגל (LCP, INP, CLS) אומרים בעברית פשוטה?

גוגל מודדת שלושה דברים, שנקראים ביחד מדדי ליבה של חוויית אתר. כל אחד עונה על שאלה אחרת שהגולש שואל בלי לשים לב: מתי אני רואה משהו, האם האתר מגיב לי, והאם הדברים קופצים מתחת לאצבע. הספים בטבלה לקוחים מהדוח בגוגל סרץ׳ קונסול ומ־web.dev, נכון לאוקטובר 2026.

מדד	מה הוא מודד	טוב	דורש שיפור	גרוע	מה בדרך כלל מקלקל אותו
LCP: טעינת התוכן הראשי	כמה זמן עובר עד שהאלמנט הגדול ביותר במסך הראשון, לרוב תמונה או כותרת, מופיע	עד 2.5 שניות	עד 4 שניות	מעל 4 שניות	תמונה ראשית כבדה, שרת שמגיב לאט, מסך פתיחה או אנימציה שמסתירה את הכותרת
INP: תגובה לפעולה	כמה זמן עובר מלחיצה, הקשה או הקלדה ועד שהמסך מגיב, לאורך כל הביקור	עד 200 אלפיות שנייה	עד 500 אלפיות שנייה	מעל 500 אלפיות שנייה	הרבה סקריפטים שרצים במקביל: צ׳אטים, פיקסלים, תוספים כבדים
CLS: יציבות העמוד	כמה התוכן זז ממקומו בזמן שהעמוד נטען	עד 0.1	עד 0.25	מעל 0.25	תמונות בלי מידות, באנר עוגיות או הודעה שנכנסים מאוחר ודוחפים את הטקסט

עמוד נחשב תקין רק כשכל שלושת המדדים טובים. בסרץ׳ קונסול, הסטטוס של קבוצת עמודים נקבע לפי המדד הגרוע ביותר שלה, כך ש־LCP מצוין לא מציל CLS גרוע.

מי שקרא מדריכים ישנים יפגוש מדד בשם FID. לפי ההודעה של גוגל ב־web.dev, נכון לאוקטובר 2026, המדד INP החליף אותו ב־12 במרץ 2024. ההבדל חשוב: FID מדד רק את הלחיצה הראשונה, ו־INP בודק את כל הפעולות בביקור. אתר שנטען מהר אבל נתקע כשפותחים בו תפריט או מסננים מוצרים, ייתפס עכשיו.

מה מאט את רוב האתרים? הסיבות לפי סדר השפעה

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

1. התמונה או הסרטון בראש העמוד. קובץ ענק, טעינה מושהית שהופעלה בטעות דווקא עליו, או תמונה שמוגדרת כרקע בעיצוב ולכן הדפדפן מגלה אותה מאוחר.
2. סקריפטים של צד שלישי. צ׳אט, וידג׳ט וואטסאפ, פיקסלים של פרסום, מפות, תוספי ביקורות. כל אחד נראה קטן, וביחד הם תוקעים את הדפדפן.
3. תוספים ובוני עמודים. תוסף שטוען את הקוד שלו בכל עמוד, גם בעמודים שבהם אין לו שום תפקיד.
4. גופנים. יותר מדי משקלים, קבצים מלאים במקום חיתוך לעברית ולאנגלית, וטעינה משרת חיצוני בלי הכנה מראש.
5. זמן התגובה של השרת. אין מטמון עמודים, גרסה ישנה של שפת השרת, או אחסון עמוס מדי.

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

תמונות וסרטונים: מה עושים כדי שלא יכבידו?

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

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

• פורמט מודרני: ווב־פי או AVIF במקום JPG ו־PNG כבדים, עם דחיסה שנבדקה בעין.
• מידות אמיתיות: תמונה שמוצגת ברוחב של כרטיס לא צריכה להיות ברוחב של מסך קולנוע. תמונות שנוצרו בכלי בינה מלאכותית מגיעות לעיתים קרובות ברזולוציה עצומה, וחייבות הקטנה לפני העלאה.
• כמה גדלים לכל תמונה: הטלפון מקבל גרסה קטנה, המסך הגדול גרסה גדולה. וורדפרס יוצרת את הגרסאות האלה, בתנאי שהתבנית משתמשת בהן.
• רוחב וגובה מוגדרים: כך הדפדפן שומר מקום לתמונה מראש, והטקסט לא קופץ כשהיא מגיעה.
• טעינה מושהית מתחת לקפל: כל תמונה שלא נראית במסך הראשון נטענת רק כשמתקרבים אליה.
• סרטון רקע קצר ושקט: כמה שניות, בלי פס קול, דחוס, ובטלפון שוקלים תמונה במקומו. סרטון מיוטיוב מוטמע עדיף שייטען רק אחרי לחיצה, עם תמונה מקדימה.

תוספים, סקריפטים של צד שלישי וגופנים: איפה הזמן הולך?

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

תוספים

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

סקריפטים של צד שלישי

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

גופנים

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

מטמון, רשת הפצה ואחסון: מתי הבעיה בשרת ולא באתר?

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

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

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

האם מהירות משפיעה על הדירוג בגוגל ועל המכירות?

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

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

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

איך בונים אתר שנשאר מהיר גם אחרי שנה?

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

רשימת בדיקה: 10 דברים לבדוק לפני שמחליפים אחסון

• הרצתם את העמודים החשובים ב־PageSpeed Insights במובייל, והסתכלתם קודם על נתוני השטח ולא על הציון.
• בדקתם בסרץ׳ קונסול איזה מדד נכשל, ובאילו קבוצות עמודים.
• זיהיתם מה האלמנט הראשי בכל עמוד, וווידאתם שהוא לא נטען בטעינה מושהית.
• התמונה הראשית בפורמט מודרני, דחוסה ובמידות שמתאימות למסך.
• לכל התמונות מוגדרים רוחב וגובה, ואין באנר שדוחף את התוכן אחרי הטעינה.
• עשיתם רשימה של כל הסקריפטים החיצוניים, והסרתם את מה שלא בשימוש.
• אין שני תוספים שעושים את אותה עבודה, ואין תוספים שאף אחד לא יודע למה הם שם.
• הגופנים: רק המשקלים שבשימוש, מאוחסנים על השרת, עם טקסט שמוצג מיד.
• יש מטמון עמודים פעיל, ואתם יודעים איך מנקים אותו אחרי שינוי.
• מדדתם את זמן התגובה של השרת כמה פעמים, בשעות שונות, וגם בעמוד שלא נשמר במטמון.

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