בדיקת מהירות אתר – איך בודקים נכון ומה המספרים אומרים (PageSpeed ו-GTmetrix)

בקצרה: בדיקת מהירות אתר נכונה משלבת נתוני שטח של גולשים אמיתיים (CrUX, ב-PageSpeed Insights וב-Search Console) עם בדיקת מעבדה שמסבירה למה (Lighthouse, GTmetrix או WebPageTest). הציון מ-0 עד 100 הוא סימן כללי בלבד. נכון לנובמבר 2026, גוגל בודקת אם 75% מהביקורים עומדים בספים: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1. TTFB מעל 0.8 שניות מצביע קודם על האחסון.

⏱ זמן קריאה: 20 דקות · זמן בדיקה: 20 דקות · רמת קושי: קל · נבדק לאחרונה: 06.11.2026 (מול התיעוד של Google ו-GTmetrix)

עובדות מפתח, נכון ל-6.11.2026:

• ספי Core Web Vitals באחוזון ה-75: LCP עד 2.5 שניות, INP עד 200 מילישניות, CLS עד 0.1. TTFB טוב: עד 0.8 שניות (web.dev, web.dev/ttfb).
• ציון PageSpeed: 90–100 טוב, 50–89 דורש שיפור, 0–49 גרוע. המשקלות ב-Lighthouse 10: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10% (Chrome for Developers).
• נתוני שטח ב-PageSpeed Insights מסכמים את 28 הימים האחרונים (Google).
• GTmetrix: 28 מיקומי בדיקה, אף אחד מהם בישראל. ה-Grade הוא 60% Performance ו-40% Structure (GTmetrix).
• מרכזי נתונים בתל אביב בקלאודוויז (Cloudways): AWS, Google Cloud ו-Vultr. ל-DigitalOcean ול-Linode אין (בדקנו ב-API של קלאודוויז, 6.11.2026).
• מדידה שלנו מישראל: ping לשרת Vultr בתל אביב 9 מילישניות בממוצע, מול 72 בפרנקפורט (6.11.2026, חיבור ביתי, אינדיקטיבי).

מה ההבדל בין בדיקת מעבדה לנתוני שטח?

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

נתוני שטח (Field Data) הם מדידות של גולשים אמיתיים, בדפדפן Chrome, על המכשירים והרשתות שלהם. הם אומרים מה הגולשים חוו בפועל. CrUX (Chrome User Experience Report) הוא מאגר הנתונים של גוגל שאוסף את המדידות האלה, וממנו מגיעים נתוני השטח ב-PageSpeed Insights, ב-Search Console וב-GTmetrix. ב-PageSpeed Insights הנתונים מסכמים את 28 הימים האחרונים.

נתוני מעבדה (Lab Data) הם טעינה אחת של העמוד בתנאים מבוקרים: מכשיר מדומה, מהירות רשת קבועה, בלי קאש בדפדפן. הם לא אומרים מה הגולשים חוו, אבל הם מסבירים למה העמוד איטי ומאפשרים לבדוק תיקון מיד. Lighthouse הוא כלי הקוד הפתוח של גוגל שמריץ את בדיקת המעבדה, והוא המנוע שמאחורי PageSpeed Insights ו-GTmetrix.

	נתוני שטח (CrUX)	נתוני מעבדה (Lighthouse)
מי נמדד	גולשים אמיתיים ב-Chrome	טעינה מדומה אחת
תקופה	28 הימים האחרונים	הרגע הזה
משפיע על גוגל	כן, דרך Core Web Vitals	לא ישירות
רואים שינוי אחרי תיקון	בהדרגה, תוך כמה שבועות	מיד
מתי חסר	באתר חדש או עם מעט תנועה	אף פעם

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

מה מראה PageSpeed Insights?

PageSpeed Insights (PSI) הוא כלי הבדיקה החינמי של גוגל בכתובת pagespeed.web.dev. הוא מציג באותו מסך גם נתוני שטח מ-CrUX וגם בדיקת מעבדה של Lighthouse, בנפרד למובייל ולמחשב.

החלק העליון: "גלו מה המשתמשים האמיתיים שלכם חווים"

זה החלק החשוב. הוא מציג את הערך באחוזון ה-75 של כל מדד: כלומר, 75% מהביקורים היו טובים ממנו או שווים לו. אם לכל שלושת מדדי הליבה (LCP, INP, CLS) הערך באחוזון ה-75 בטווח "טוב", העמוד עובר את הערכת Core Web Vitals.

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

החלק התחתון: ציון הביצועים

הציון מ-0 עד 100 מגיע מבדיקת Lighthouse אחת. לפי Chrome for Developers, 90–100 הוא "טוב" (ירוק), 50–89 "דורש שיפור" (כתום), ו-0–49 "גרוע" (אדום). הציון הוא ממוצע משוקלל של חמישה מדדים:

מדד	משקל בציון (Lighthouse 10 ומעלה)	מה הוא מודד
Total Blocking Time (TBT)	30%	כמה זמן הדפדפן "תקוע" בהרצת JavaScript
Largest Contentful Paint (LCP)	25%	מתי האלמנט הגדול בעמוד מופיע
Cumulative Layout Shift (CLS)	25%	כמה העמוד "קופץ" בזמן הטעינה
First Contentful Paint (FCP)	10%	מתי מופיע התוכן הראשון
Speed Index	10%	כמה מהר העמוד מתמלא ויזואלית

שימו לב: TBT, שמקבל 30% מהציון, הוא לא מדד שטח. הוא מדד מעבדה שקשור ל-INP. לכן אתר עם הרבה JavaScript (בוני עמודים, צ'אטים, פיקסלים) יקבל ציון נמוך גם אם הגולשים מרוצים, ולהפך.

למה המובייל תמיד נמוך יותר: בדיקת המובייל מדמה טלפון בינוני ברשת סלולרית איטית, בכוונה. ציון 60 במובייל ו-90 במחשב הוא מצב נפוץ מאוד באתרי וורדפרס, ולא בהכרח סימן לבעיה באחסון.

מה נותן GTmetrix שאין ב-PageSpeed?

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

• ציון GTmetrix (Grade) הוא אות מ-A עד F. לפי GTmetrix, הוא ממוצע משוקלל של Performance Score (60%), שמבוסס על אותם מדדי Lighthouse, ושל Structure Score (40%), הערכה של GTmetrix עצמה לבעיות מבנה בעמוד.
• מיקומי בדיקה: נכון לנובמבר 2026, GTmetrix מפעילה שרתי בדיקה ב-28 מיקומים. אין ביניהם מיקום בישראל. הקרובים יחסית הם למשל דובאי, ורשה ופרנקפורט. חלק מהמיקומים דורשים חשבון בתשלום.
• לשונית CrUX: GTmetrix מציג גם את נתוני השטח של גוגל, כשיש מספיק נתונים.

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

איך קוראים דוח GTmetrix, לשונית אחרי לשונית

הדוח של GTmetrix מחולק ללשוניות. זה הסדר שבו אנחנו קוראים אותו:

1. Summary: בראש הלשונית מופיע Speed Visualization, רצף צילומים של הטעינה עם סימון של כל מדד ברגע שבו הוא קרה. מתחתיו נמצא Top Issues: בעיות המבנה שהשפיעו הכי הרבה על הציון. מתחילים מהן.
2. Structure: כל בדיקות המבנה, מהגרועה ביותר ומטה. לכל בדיקה יש דירוג Impact, הערכה של GTmetrix לכמה היא פגעה בציון. לחיצה על בדיקה פותחת את הקבצים שגרמו לה, למשל קובצי CSS שחוסמים את הרינדור.
3. Waterfall: פירוק של הטעינה בקשה אחרי בקשה. הבקשה הראשונה היא מסמך ה-HTML, וזמן ההמתנה שלה הוא בפועל ה-TTFB מהמיקום שבחרתם. אם הוא ארוך, הבעיה מתחילה בשרת. אם הוא קצר והעמוד עדיין איטי, חפשו קבצים כבדים או שרשראות של בקשות שמחכות אחת לשנייה.
4. CrUX: נתוני השטח של גוגל ל-28 הימים האחרונים, עם עבר או נכשל לכל מדד והערכה כוללת של Core Web Vitals.
5. Video ו-History: וידאו של הטעינה (צריך להפעיל Video ב-Analysis Options לפני הבדיקה), וגרפים של בדיקות קודמות שמראים מגמה לאורך זמן.

מיקום ותוכניות: את מיקום הבדיקה בוחרים ב-Analysis Options, ואפשר לקבוע מיקום ברירת מחדל בהגדרות החשבון. לפי עמוד המחירים של GTmetrix, נכון ל-6.11.2026, מספר המיקומים תלוי בתוכנית: Lite (החל מ-4.99$ לחודש) כוללת 5 מיקומים, Core כוללת 10, ו-Advanced את כל ה-28. לפני שאתם בונים על מיקום מסוים, ודאו שהוא פתוח בחשבון שלכם. מדריך מפורט יותר: המדריך ל-GTmetrix.

מתי צריך את WebPageTest?

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

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

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

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

בדיקה ראשונה ב-WebPageTest, צעד אחר צעד

1. בחרו מיקום מהרשימה או מהמפה. לא כל מיקום תומך בכל דפדפן, ואם הדפדפן שרציתם חסר, בחרו מיקום אחר.
2. בחרו Chrome. לפי התיעוד של WebPageTest, זה הדפדפן שמחזיר הכי הרבה מידע. לבדיקת מובייל בחרו מכשיר מדומה, שמוסיף גם האטה של המעבד.
3. סמנו בדיקת ביקור חוזר (Repeat View), כדי לראות כמה הקאש בדפדפן חוסך לגולש שחוזר.
4. הריצו את הבדיקה. המדדים מוצגים לפי הרצת החציון.
5. פתחו את ה-Filmstrip. למעלה רואים את הטעינה פריים אחרי פריים, ולמטה מפל טעינה עם קו אדום שזז יחד עם הפריים. כך רואים מה הדפדפן עשה בכל רגע שבו המסך עוד היה לבן.
6. להשוואת לפני ואחרי, הציגו פילמסטריפים של כמה בדיקות זה מתחת לזה.

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

איזה כלי לבדיקת מהירות אתר לבחור?

לרוב האתרים מספיקים שניים: PageSpeed Insights כדי לדעת מה גוגל רואה, ו-GTmetrix או WebPageTest כדי להבין למה. הטבלה מסכמת מתי כל כלי מתאים:

כלי	נתוני שטח	בחירת מיקום	הכי טוב בשביל
PageSpeed Insights	כן (CrUX)	לא	לדעת מה גוגל רואה
Search Console (דוח Core Web Vitals)	כן, לכל האתר	לא רלוונטי	למצוא קבוצות של עמודים בעייתיים
GTmetrix	כן (לשונית CrUX)	כן, 28 מיקומים	מפל טעינה ובדיקה ממיקום קרוב לקהל
WebPageTest	חלקי	כן	ניתוח עמוק, Filmstrip, השוואות
Lighthouse בכלי המפתחים של Chrome	לא	מהמחשב שלכם	בדיקה מהירה של עמוד שעוד לא פורסם

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

לפי גוגל, נכון לנובמבר 2026: LCP עד 2.5 שניות, INP עד 200 מילישניות, CLS עד 0.1 ו-TTFB עד 0.8 שניות, כולם באחוזון ה-75 של הביקורים. הטבלה המלאה, לפי התיעוד של PageSpeed Insights ו-web.dev:

מדד	טוב	דורש שיפור	גרוע	מדד ליבה?
LCP	עד 2.5 שניות	2.5–4 שניות	מעל 4 שניות	כן
INP	עד 200 מ"ש	200–500 מ"ש	מעל 500 מ"ש	כן
CLS	עד 0.1	0.1–0.25	מעל 0.25	כן
FCP	עד 1.8 שניות	1.8–3 שניות	מעל 3 שניות	לא
TTFB	עד 0.8 שניות	0.8–1.8 שניות	מעל 1.8 שניות	לא (ניסיוני)

הסבר מלא על שלושת מדדי הליבה ואיך משפרים כל אחד בוורדפרס נמצא במדריך Core Web Vitals בעברית. על זמן התגובה של השרת יש מדריך נפרד: TTFB גבוה – מה זה ולמה האחסון הוא החשוד הראשון.

איך עושים בדיקת מהירות אתר נכון?

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

1. בחרו 3–4 עמודים מייצגים: דף הבית, עמוד תוכן או מוצר, עמוד קטגוריה, ובחנות גם את העגלה. כל סוג עמוד נבנה אחרת ומתנהג אחרת.
2. התחילו מנתוני השטח: הריצו PageSpeed Insights וב-Search Console פתחו את דוח Core Web Vitals. רשמו אם האתר עובר או לא, ואיזה מדד נכשל.
3. הריצו כל בדיקת מעבדה 3 פעמים לפחות וקחו את האמצעית. התוצאות משתנות מהרצה להרצה בגלל רשת, פרסומות ועומס. גוגל עצמה מתעדת את התנודתיות הזו.
4. בדקו בלי להיות מחוברים לוורדפרס, בחלון גלישה בסתר. משתמש מחובר עוקף את קאש העמודים ומקבל תוצאה איטית בהרבה ממה שגולש רגיל רואה.
5. בחרו ב-GTmetrix מיקום קבוע וקרוב לקהל שלכם, ותמיד אותו מיקום. השוואה בין בדיקה מוונקובר לבדיקה מפרנקפורט היא השוואה בין שני דברים שונים.
6. הסתכלו על ה-TTFB במפל הטעינה של הבקשה הראשונה. אם הוא גבוה, הבעיה מתחילה בשרת, ושום אופטימיזציית תמונות לא תפתור אותה.
7. תעדו: שמרו צילום מסך או קישור לכל בדיקה, עם תאריך. בלי זה אי אפשר לדעת אם תיקון עזר.

איך בודקים Staging, משתמש מחובר ועגלת ווקומרס?

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

סביבת Staging

בקלאודוויז סביבת Staging מוגנת בסיסמה כברירת מחדל (htpasswd.), כדי שמנועי חיפוש לא יאנדקסו אותה. PageSpeed Insights ו-GTmetrix לא יכולים לעבור את הסיסמה. אפשר לכבות את ההגנה לזמן הבדיקה ולהחזיר אותה מיד אחרי, או להריץ Lighthouse מכלי המפתחים של Chrome בחלון שבו כבר הזנתם את הסיסמה. זכרו שלסביבת בדיקות אין נתוני שטח, ושכתובת זמנית בדרך כלל לא עוברת דרך ה-CDN של האתר החי. הפרטים: המדריך לסביבת Staging.

עמוד של משתמש מחובר

גולש מחובר, כמו מנהל או לקוח עם חשבון, בדרך כלל לא מקבל את קאש העמודים. ב-Breeze, קאש למשתמשים מחוברים פועל רק אם הפעלתם את Cache Logged-in Users, לכל תפקיד בנפרד, וגם אז חלק מבוני העמודים לא עובדים איתו טוב. לכן עמוד של משתמש מחובר מראה את המהירות האמיתית של השרת ושל וורדפרס. בודקים אותו ב-Lighthouse מכלי המפתחים כשאתם מחוברים, ומסתכלים בעיקר על ה-TTFB של מסמך ה-HTML.

עגלה וקופה בווקומרס

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

האם מיקום השרת משפיע על מהירות אתר ישראלי?

כן. במדידה שלנו מחיבור ביתי בישראל (6.11.2026, אינדיקטיבית), שרת בתל אביב ענה ל-ping תוך 9 מילישניות בממוצע, מול 72 מילישניות בפרנקפורט. לכן גם מיקום הבדיקה צריך להיות קבוע וקרוב לקהל שלכם.

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

• ב-PageSpeed Insights אי אפשר לבחור מיקום, ולכן משתמשים בו בעיקר לנתוני השטח, שמגיעים מהגולשים האמיתיים שלכם בישראל.
• ב-GTmetrix וב-WebPageTest בחרו את המיקום הקרוב ביותר לישראל שזמין לכם, והשוו תמיד מאותו מקום.
• מיקום השרת: שרת באירופה (למשל פרנקפורט) מחזיר תשובה לישראל מהר יותר משרת בארצות הברית. ב-CDN, הקבצים הסטטיים מוגשים מנקודה קרובה, אבל עמודים דינמיים (עגלה, קופה, משתמש מחובר) עדיין מגיעים מהשרת. האפשרויות בקלאודוויז: מיקומי שרתים. נכון לנובמבר 2026 יש בקלאודוויז מרכזי נתונים בתל אביב אצל AWS, Google Cloud ו-Vultr: שרת בתל אביב.

האחסון או האתר: מי אשם באיטיות?

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

מה רואים	הסיבה הסבירה	מה עושים
TTFB מעל 0.8 שניות, גם בבדיקות חוזרות	שרת איטי, אין קאש עמודים, שרת רחוק	קאש בצד השרת, שרת קרוב יותר, אחסון חזק יותר
TTFB טוב, LCP גרוע	תמונה ראשית כבדה, פונטים, CSS חוסם	אופטימיזציית תמונות ו-preload
TBT גבוה, INP גרוע	הרבה JavaScript: בונה עמודים, צ'אט, פיקסלים	דחיית סקריפטים, הסרת תוספים
CLS גבוה	תמונות בלי מידות, באנרים, פונטים מתחלפים	מידות קבועות ושמירת מקום
מהיר בבדיקה, איטי לגולשים	קאש עובד רק לחלק, תוספים שרצים לגולשים מחוברים	בדיקה כמשתמש מחובר ובעגלה

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

איך משווים מהירות לפני ואחרי מעבר אחסון?

באותו כלי, מאותו מיקום ועל אותם עמודים, עם 3 הרצות וחציון, ומשווים קודם את ה-TTFB. נתוני השטח יראו את השינוי במלואו רק אחרי 28 ימים. זה הפרוטוקול שלנו:

1. לפני המעבר: בחרו 3–4 עמודים (בית, תוכן, קטגוריה, עגלה). לכל אחד הריצו 3 בדיקות באותו כלי, מאותו מיקום ובאותו מכשיר, ורשמו את החציון של TTFB, LCP ו-TBT. צלמו גם את דוח Core Web Vitals ב-Search Console.
2. על השרת החדש, לפני החלפת DNS: העבירו עותק ובדקו את אותם עמודים באותה דרך. הריצו קודם טעינה אחת לחימום הקאש.
3. השוו קודם את ה-TTFB. זה המספר שהאחסון אחראי עליו ישירות. LCP ו-TBT מושפעים גם מהתבנית ומהתוספים, שלא השתנו.
4. אחרי החלפת DNS: חזרו על הבדיקות אחרי יום, ושוב אחרי שבוע.
5. נתוני השטח: חכו 28 ימים, עד שנתוני CrUX ישקפו רק את השרת החדש, ואז השוו את Search Console לצילום מלפני המעבר.

כמה מזה הוא מרחק? חלק מה-TTFB הוא פשוט זמן הנסיעה של הבקשה. במדידה אינדיקטיבית שעשינו ב-6.11.2026 מחיבור ביתי בישראל (ערב אחד, מקום אחד), זמן פתיחת החיבור לשרת של AWS בתל אביב היה כ-30 מילישניות בחציון, מול כ-82 מילישניות ל-AWS בפרנקפורט. בעמוד שדורש כמה סבבים עד הבייט הראשון, ההפרש מצטבר. הוא לא מחליף קאש או CDN, אבל הוא חלק מהתמונה כשבוחרים שרת בתל אביב. השיטה המלאה: בדיקת זמני תגובה לשרתים מישראל.

למה כל כלי נותן ציון אחר?

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

• מכשיר מדומה שונה: PageSpeed מדמה טלפון במובייל, GTmetrix מדמה כברירת מחדל Chrome במחשב (לפי GTmetrix, ברירת המחדל היא Chrome Desktop, והמיקום הוא סיאטל). אלה שתי בדיקות שונות.
• מיקום שונה: כל אלפית שנייה של מרחק נכנסת ל-TTFB ומשם לכל שאר המדדים.
• נוסחה שונה: ה-Grade של GTmetrix כולל 40% של ציון מבנה, שאין לו מקבילה ב-PageSpeed.
• תנודתיות: פרסומות, בדיקות A/B וניתוב רשת משתנים בין הרצות. לכן תמיד 3 הרצות.

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

איך עוקבים אחרי מהירות האתר באופן קבוע?

הדרך הפשוטה היא לפתוח את דוח Core Web Vitals ב-Search Console פעם בחודש. למעקב אוטומטי יש את הניטור של GTmetrix, את PageSpeed Insights API ואת Lighthouse CI. ארבע הרמות, מהפשוטה למתקדמת:

• Search Console פעם בחודש. פתחו את דוח Core Web Vitals וחפשו קבוצות כתובות שעברו ל-Poor או ל-Need improvement. זה חינמי ומבוסס על הגולשים האמיתיים.
• ניטור ב-GTmetrix. בתוכניות בתשלום מגדירים כתובות למעקב קבוע עם התראות. נכון ל-6.11.2026: Lite כוללת כתובת אחת למעקב, Core שלוש ו-Advanced עשר, ומעקב כל שעה מתחיל רק מ-Advanced. כל כתובת עם הגדרות בדיקה (מיקום, מכשיר) תופסת מקום מעקב אחד.
• PageSpeed Insights API. אותה בדיקה, דרך כתובת שאפשר להריץ מסקריפט או ממשימה מתוזמנת (Cron) ולשמור את התוצאות. ברירת המחדל היא בדיקת מחשב, אז הוסיפו strategy=MOBILE. גוגל מסבירה בתיעוד איך להוציא מפתח API (key) ולצרף אותו לבקשה.
• Lighthouse CI למפתחים. כלי קוד פתוח של Google שמריץ Lighthouse בכל שינוי בקוד, למשל ב-GitHub Actions, מריץ כל בדיקה כמה פעמים כדי לצמצם תנודות, ומתריע כשעברתם תקציב ביצועים שהגדרתם. מתאים לסוכנויות ולמפתחים שמנהלים את התבנית בגיט.

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.co.il/&strategy=MOBILE&key=YOUR_API_KEY"

# Lighthouse CI
npm install -g @lhci/cli
lhci autorun

ניטור מהירות הוא לא ניטור זמינות. כדי לדעת מיד כשהאתר נופל, צריך כלי נפרד: ניטור זמינות לאתר.

אילו טעויות נפוצות מעוותות בדיקת מהירות?

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

בודקים מיד אחרי ניקוי קאש: הבדיקה הראשונה אחרי ניקוי בונה את הקאש מחדש ותהיה איטית. הריצו פעם אחת "לחימום" ורק אז מדדו.

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

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

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

שאלות נפוצות

מדריכים קשורים

• Core Web Vitals בעברית: LCP, INP ו-CLS
• TTFB גבוה – מה זה ולמה האחסון הוא החשוד הראשון
• איך לשפר את מהירות אתר הוורדפרס
• בדיקות מהירות לפני ואחרי מעבר לקלאודוויז
• אחסון אתרים מהיר: המדריך המלא
• כל המדריכים בתחום: ביצועים ומהירות

מקורות

• About PageSpeed Insights (Google)
• PageSpeed Insights API (Google)
• Lighthouse performance scoring (Chrome for Developers)
• Web Vitals ו-Time to First Byte (web.dev)
• The GTmetrix Report, Test Server Locations ו-Pricing (GTmetrix)
• WebPageTest: Getting Started (Catchpoint)
• Lighthouse CI (GoogleChrome, GitHub)
• How to create a staging environment ו-How to configure Breeze (Cloudways Knowledge Base)
• מרכזי נתונים בתל אביב: בדיקה שלנו ב-API של קלאודוויז, 6.11.2026
• מדידת זמני תגובה מישראל: מדידה שלנו, 6.11.2026 (השיטה והנתונים)

מקורות רשמיים: About PageSpeed Insights (Google), Lighthouse performance scoring (Chrome for Developers), Web Vitals ו-Time to First Byte (web.dev), The GTmetrix Report ו-GTmetrix Test Server Locations, GTmetrix Pricing, PageSpeed Insights API (Google), Lighthouse CI (GoogleChrome), WebPageTest: Getting Started (Catchpoint), How to create a staging environment ו-How to configure Breeze (Cloudways Knowledge Base). כל הנתונים נבדקו ב-06.11.2026. נכתב ונבדק על ידי עשהאל דרייר · עודכן: 06.11.2026

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