בדיקת מהירות אתר: איך קוראים נכון את התוצאות

מה בודקת בדיקת מהירות אתר, ולמה ציון אחד לא מספיק?

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

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

מה ההבדל בין נתוני שטח לנתוני מעבדה ב-PageSpeed Insights?

PageSpeed Insights מציג שני סוגי נתונים, ורוב הבלבול סביב הכלי נובע מהערבוב ביניהם. נתוני השטח מגיעים מדוח חוויית המשתמש של Chrome, CrUX, שמרכז מדידות של משתמשים אמיתיים שהסכימו לשתף נתונים. נתוני המעבדה מגיעים מהרצה של Lighthouse, שטוען את העמוד פעם אחת בסביבה מדומה. לפי התיעוד של PageSpeed Insights, אלה ההבדלים המרכזיים ביניהם.

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

מה הספים של Core Web Vitals, ומה בדרך כלל גורם לכשל?

Core Web Vitals הם שלושה מדדים ש-Google מגדיר כמדדי הליבה של חוויית העמוד. ב-2024 INP החליף את FID כמדד התגובה, ולכן מדריכים שעדיין מזכירים את FID כבר לא מעודכנים. הספים בטבלה הם לפי web.dev ולפי התיעוד של PageSpeed Insights, נכון לאוקטובר 2026, והם נמדדים באחוזון ה-75 של הביקורים, בנפרד לנייד ולמחשב.

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

בנתוני השטח של PageSpeed Insights מופיעים גם שני מדדים שאינם חלק מ-Core Web Vitals, ושימושיים לאבחון. FCP מודד מתי מופיע התוכן הראשון על המסך, ו-TTFB, שמסומן בכלי כמדד ניסיוני, מודד כמה זמן עובר עד שהשרת מתחיל להחזיר תשובה. לפי התיעוד של הכלי, FCP טוב הוא עד 1.8 שניות ו-TTFB טוב הוא עד 800 אלפיות שנייה. כש-LCP נכשל ו-TTFB גבוה, כדאי להתחיל מהשרת לפני שנוגעים בתמונות.

איך קוראים את דוח Core Web Vitals ב-Search Console?

PageSpeed Insights בודק עמוד אחד בכל פעם, ודוח Core Web Vitals ב-Search Console מראה את התמונה של האתר כולו. גם הוא מבוסס על נתוני CrUX, ולכן הוא משקף משתמשים אמיתיים ולא בדיקת מעבדה. הדוח מקבץ כתובות שהחוויה בהן דומה לקבוצות, והסטטוס של כל קבוצה חל על כל הכתובות שבה. לפי מרכז העזרה של Search Console, הסטטוס של קבוצה נקבע לפי המדד הגרוע ביותר שלה, בנפרד לנייד ולמחשב.

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

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

איך בודקים מהירות אתר בנייד, ולא רק במחשב המשרדי?

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

• מתחילים בלשונית הנייד ב-PageSpeed Insights, ומסתכלים קודם על נתוני השטח אם יש כאלה
• בוחרים עמוד מכל תבנית: עמוד שירות, מאמר, עמוד מוצר או דף נחיתה, לפי סוג האתר
• מריצים את Lighthouse גם ב-Chrome DevTools, בחלון גלישה בסתר שבו תוספים לדפדפן בדרך כלל לא פעילים
• בודקים בטלפון אמיתי ברשת סלולרית: פותחים את התפריט, ממלאים טופס וגוללים עד סוף העמוד
• רושמים את התוצאות עם תאריך, כדי שתוכלו להשוות אחרי כל שינוי באתר

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

למה הציון משתנה בין בדיקה לבדיקה?

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

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

הפתרון שהתיעוד מציע הוא להסתכל על ערך מצטבר ולא על הרצה בודדת. לפי Lighthouse, החציון של חמש הרצות יציב פי שניים מהרצה אחת, ולכן כדאי להריץ כמה פעמים ולהשוות חציון מול חציון. משווים תמיד את אותו עמוד, באותו כלי ובאותם תנאים, כי ציון מ-DevTools וציון מ-PageSpeed Insights נמדדו על מכונות שונות.

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

אילו תיקונים באמת משנים, ומה אפשר להשאיר?

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

גם המטרה צריכה להיות מוגדרת נכון. לפי Google Search Central, מדדי Core Web Vitals משמשים את מערכות הדירוג, אבל ציון טוב לא מבטיח מיקום גבוה, ו-Google ממשיך להציג את התוכן הרלוונטי ביותר גם כשחוויית העמוד שלו לא מושלמת. התיעוד של Lighthouse מציין שציון מושלם של 100 קשה מאוד להשגה ואינו צפוי, ו-Google מוסיף שניסיון להגיע לציון מושלם רק משיקולי קידום עשוי לא להיות השימוש הטוב ביותר בזמן שלכם. יעד סביר הוא לעבור את הספים של נתוני השטח בעמודים שמביאים פניות, ולא להגיע ל-100 בכל עמוד.

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