---
title: "למה PageSpeed Insights וג'ימטריקס נותנים ציונים שונים, ומה זה אומר על האתר שלכם?"
url: "https://multinet.digital/pagespeed-insights/"
type: "post"
published: "2025-06-14T17:44:50+02:00"
modified: "2026-10-13T17:58:25+02:00"
author: "multinet"
---

בקצרה
- PageSpeed Insights בודק כברירת מחדל מובייל איטי ונשען על Core Web Vitals. GTmetrix בודק כברירת מחדל דסקטופ מהיר ומוסיף ציון Structure. לכן הציונים שונים.
- ציון 97 בגוגל ו-B בג'ימטריקס, או להפך, לא אומר שאחד הכלים טועה. כל אחד מודד משהו אחר.
- היעד: ירוק ב-Core Web Vitals (LCP מתחת ל-2.5 שניות, INP מתחת ל-200ms, CLS מתחת ל-0.1) לצד Grade A או B ב-GTmetrix.
- התהליך: בדיקה בארבעה כלים, יישום של עשרה טיפים (שרת, תמונות, Cache, JavaScript, פונטים) ובדיקה חוזרת.
- אופטימיזציה לאתרים היא מעגל קבוע של מדידה, שיפור ובדיקה, ולא פעולה חד פעמית.

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

במאמר הזה נצלול אל המדדים, נבין איך הם מחושבים, ונלמד לשפר את התוצאות בלי לשבור את העיצוב ובלי להקריב פונקציונליות.
 נרחיב גם את ארגז הטיפים המעשי: מבחירת שרת, דרך כיווץ תמונות נכון ועד אופטימיזציית JavaScript.
 בסוף המאמר תדעו לפרש LCP, TBT ו-CLS, להבין למה "90 ירוק" לא תמיד מספיק, ובעיקר איך לגרום לאתר שלכם לדלוק כמו מכונית מרוץ גם במובייל איטי.

## בדיקת מהירות של גוגל (PageSpeed Insights) – מה באמת מסתתר מאחורי הציון?

PageSpeed Insights בוחן שתי שכבות: נתוני שדה (Field Data), שמגיעים מדפדפני משתמשים, ונתוני מעבדה (Lab Data), שמתקבלים מסימולציית Lighthouse.
 השילוב נותן ציון של 0 עד 100, וגם מלמד היכן נחוו בעיות אמיתיות.
 רמות הירוק (90-100), הכתום (50-89) והאדום (0-49) נראות כמו רמזור פשוט, אבל הן נשענות על Core Web Vitals:

    2.5s **LCP** – Largest Contentful Paint צריך להיות מתחת ל-2.5 שניות   200ms **INP** – Interaction to Next Paint (היורש של FID) צריך לרדת מתחת ל-200ms   0.1 **CLS** – Cumulative Layout Shift צריך להישאר מתחת ל-0.1, כדי שהמסך לא "יקפוץ"

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

### GTmetrix – מעבדת ביצועים מלאה במבט אחד לאופטימיזציה לאתרים

GTmetrix מריץ גם הוא Lighthouse, אך מוסיף שכבת Structure המבוססת על YSlow. התוצאה היא אות בולטת, A עד F, שמסכמת Performance ו-Structure.
 היתרון הגדול הוא גרף Waterfall, שמראה כל בקשת HTTP, משך DNS, זמן TTFB ועצירות Blocking של JavaScript.
 בחירה מודעת של מיקום בדיקה, רוחב פס ודפדפן מאפשרת לדמות גלישה ישראלית אמיתית, ולא רק "נתוני גוגל".
 התמונה העמוקה הזו מגלה צווארי בקבוק ש-PageSpeed מסתיר מאחורי מספר ממוצע.

#### למה התוצאות שונות, ואיך לקרוא אותן נכון

PageSpeed מדמה כברירת מחדל מכשיר מובייל בינוני ברשת איטית, ונשען על Core Web Vitals. GTmetrix מציג כברירת מחדל דסקטופ מהיר, ומעניק ציון נפרד ל-Structure.

    Google PageSpeed Insights  מה נבדק נתוני שדה ממשתמשים אמיתיים, לצד נתוני מעבדה מסימולציית Lighthouse ברירת מחדל מובייל בינוני ברשת איטית (סימולציה של Lighthouse) הציון 0 עד 100: ירוק 90-100, כתום 50-89, אדום 0-49 דגש Core Web Vitals: מהירות טעינה, תגובתיות ויציבות תצוגה היתרון משקף את עמדת גוגל ואת חוויית המשתמש בפועל    GTmetrix  מה נבדק Lighthouse, בתוספת שכבת Structure המבוססת על YSlow ברירת מחדל דסקטופ מהיר, עם בחירה של מיקום בדיקה, רוחב פס ודפדפן הציון אות A עד F שמסכמת Performance ו-Structure דגש מספר הבקשות, DNS, TTFB וחסימות JavaScript היתרון גרף Waterfall שמראה כל בקשת HTTP וחושף צווארי בקבוק

לכן ייתכן שאתר קל משקל עם CLS גבוה יקבל A ב-GTmetrix אך רק 78 ב-PageSpeed.
 ולהפך: אתר כבד עם Lazy Load ישיג 92 ב-PageSpeed, אך יקבל C ב-GTmetrix בגלל עשרות קריאות DNS.
 **המסקנה:** היעד הוא ירוק ב-Core Web Vitals לצד Grade A או B ב-GTmetrix, ולא אחד על חשבון השני.

## למה מהירות קריטית להצלחה העסקית – מעבר למספרים

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

### המדדים שצריך להכיר לעומק

**LCP – Largest Contentful Paint** מודד את זמן הטעינה של העצם הגדול ביותר בפריים הראשון (תמונה, וידאו, גוש טקסט גדול). היעד: ≤ 1.2 שניות לקבלת חוויה "מהירה במיוחד".
 **TBT – Total Blocking Time** מצטבר בדוח GTmetrix, ומייצג את פרק הזמן שבו בלוקים של JavaScript מונעים מהדפדפן להגיב. יעד מומלץ: ≤ 150ms.
 **CLS – Cumulative Layout Shift** מודד את "קפיצות" הפריסה בזמן הטעינה. יעד: ≤ 0.1.
 שליטה בשלושת המדדים משיגה איזון: טעינה ויזואלית מהירה, תגובתיות ויציבות תצוגה.

![הנתונים הכי חשובים במהירות אתרים: LCP, TBT ו-CLS](https://multinet.digital/wp-content/uploads/2025/06/הנתונים-הכי-חשובים-במהירות-אתרים.png)

#### משיכת קו בין UX, SEO וניצול משאבים

UX מהיר משפר את זמן השהייה באתר, מגביר אינטראקציות ומקטין עומס תמיכה.
 מבחינת SEO, Core Web Vitals ירוקים הם אות דירוג. הם גם מקטינים את עלות הסריקה (Crawl Budget), ומאפשרים לגוגל לאנדקס יותר עמודים בזמן קבוע.
 בצד התשתית נחסכות בקשות, והשרת צורך פחות CPU ורוחב פס על אותה צמיחה ב-Traffic. השורה התחתונה: פחות הוצאות על אחסון ועל CDN.

## טיפים מעשיים לאופטימיזציה לאתרים – שלב אחר שלב עד 100 ירוק

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

### שלב ראשון – בדיקה מקיפה

התחילו בארבעה כלים משלימים:

    Lighthouse ב-Chrome DevTools מדמה מובייל ישירות מהדפדפן. הריצו בחלון גלישה בסתר, כדי שתוספים לא יעוותו את התוצאה.   PageSpeed Insights נותן ציון נפרד למובייל ולדסקטופ, עם הסברים מפורטים.   Pingdom Tools בחרו שרת בדיקה קרוב לאחסון, כדי לאמוד TTFB.   GTmetrix מציג Waterfall מפורט. בדיקה ממכשיר מובייל מדומה זמינה בתוכניות בתשלום.

הריצו את כל הבדיקות ותעדו את המדדים המרכזיים: LCP, TBT, CLS, TTFB ו-Fully Loaded Time. זה יהיה קו הבסיס.

### שלב שני – יישום המסקנות (10 טיפים זהב)

    שרתי אחסון נכונים בחרו שרת במדינה שבה נמצא הקהל העיקרי: ישראלים, Data Center בישראל. אמריקאים, US East Coast. ודאו ש-HTTP/2 ו-TLS 1.3 מופעלים, והוסיפו [CDN גלובלי](https://multinet.digital/cdn/) (Cloudflare, BunnyCDN או AWS CloudFront) עם Edge Cache.   TTFB מתחת ל-200ms אופטימיזציית DB, אובייקט Cache (Redis או Memcached) ושימוש ב-PHP 8.2 מורידים CPU ו-TTFB. באתרי WooCommerce הפעילו "Load Only WooCommerce CSS On Shop Pages", כדי לדלל קריאות מיותרות.   כיווץ תמונות לגודל אופטימלי תמונת Web באורך 1920px אמורה לשקול מתחת ל-150kB. ב-WordPress הפעילו Imagify או ShortPixel. הגדירו Lazy-Load מובנה (loading="lazy"), כך שמדיה מחוץ לקפל לא תנפח את ה-LCP.   פורמטים חדשים עברו ל-WebP עבור תמונות ול-AVIF או H.265 (HEVC) לסרטונים קצרים. הוסיפו srcset לתמונות רספונסיביות, כך שמובייל מקבל גרסה של 0.5×.   זיכרון מטמון (Cache) אגרסיבי ב-WordPress התקינו WP Rocket (בתשלום) או LiteSpeed Cache (אם השרת תומך). הפעילו CSS/JS Minify, Combine, Delay JS Execution ו-Critical CSS. התוסף יוצר קבצים סטטיים שמוגשים ישירות מה-Edge, ומשפר את ה-LCP וה-TTFB.   הפחתת JavaScript חוסם אתרו סקריפטים כבדים (Maps, ChatBot, Facebook Pixel) בעזרת ה-Waterfall של GTmetrix. טענו אותם ב-async, ב-defer או ב-requestIdleCallback. ב-Elementor הפעילו "Load Font Awesome Locally", כך שהאייקונים לא יחסמו את ה-Head.   מחיקת תוספים לא רלוונטיים הסירו תוספים לא פעילים, וכאלה שאפשר להחליף בקוד קצר (למשל הפניית 301, הוספת Header Code או כפתור Tel). כל תוסף הוא קובץ PHP שנטען בכל בקשה ומכביד על ה-CPU.   אופטימיזציית פונטים הורידו את Google Fonts לשרת המקומי (Self-Host), הפעילו font-display:swap והוסיפו preload. כך תמנעו Flash of Invisible Text ותשפרו את ה-CLS.   Early Hints (103) ו-Preconnect אם אתם משתמשים ב-Cloudflare Enterprise או ב-Fastly, הפעילו Early Hints: הדפדפן יתחיל להוריד CSS עוד לפני שה-HTML הגיע. הוסיפו preconnect לפונט ול-CDN Domain, כדי לחסוך DNS.   בדיקות רבעוניות והגנה מתמשכת שלבו Lighthouse CI Pipeline ב-Git, הגדירו סף כישלון של 90+ לכל Pull Request, וצרו התראה אוטומטית ל-Slack כש-LCP מהשדה עולה על 2.5 שניות. כך האתר לא יידרדר עם כל תוסף חדש.

### שלב שלישי – בדיקה חוזרת ומדידה מתמשכת

הריצו שוב את ארבעת הכלים והשוו מול קו הבסיס: ה-LCP אמור לרדת, ה-CLS להתייצב, ה-TBT לרדת אל מתחת ל-150ms, ו-GTmetrix Grade לטפס לאות A.
 אם אתם מפספסים יעד, בצעו Fine-Tuning: בדקו שוב את ה-Waterfall, סגרו קריאות של AdSense או של CSS חיצוני, והריצו את הבדיקה מחדש.
 זה תהליך מחזורי של מדידה, שיפור ובדיקה, ולא פעולה חד פעמית.

מהירות וסריקה תקינה הן גם הבסיס להופעה ב-AI Overviews, כי גוגל יכולה לצטט רק עמודים שהיא מצליחה לסרוק ולהבין.
 על שאר הגורמים תקראו ב[מדריך לקידום בגוגל עם בינה מלאכותית](https://multinet.digital/google-ai-promotion/).

## סיכום: לשלב שני כלים, לשפר UX ו-SEO, ולשמור על מעגל אופטימיזציה לאתרים מתמיד

PageSpeed Insights ו-GTmetrix אינם מתחרים. הם שני צידי אותה מטבע.
 הראשון משקף את עמדת גוגל ואת מדדי השטח האמיתיים, והשני משרטט מפת דרכים מדויקת לטיפול בצווארי בקבוק.
 כשאתם משיגים ירוק ב-Core Web Vitals ואות A או B ב-GTmetrix, אתם לא רק עוברים "מבחן". אתם מבטיחים חוויית משתמש חלקה, זמנים מהירים ודירוג אורגני בריא.
 השקיעו בתשתית נכונה, בכיווץ נכסים, במטמון אגרסיבי ובבדיקות רציפות, ותראו איך הנתונים בירוק מתורגמים לביצועים עסקיים אמיתיים: יותר גולשים, יותר המרות ופחות נטישה.

### רוצים להבין איך אנחנו עושים את זה?

כנסו לקרוא יותר על השירות שלנו: [אופטימיזציה לאתרים](https://multinet.digital/services/optimization-and-security-services/) – הגדילו מהירות, דירוגים ורווחיות.

   גם האתר שלכם יכול לקבל ציון 100 ולהיות מהיר באמת דברו איתנו. נבדוק יחד מה מאט את האתר שלכם ב-PageSpeed Insights וב-GTmetrix, ומה כדאי לתקן קודם. [לבדיקת מהירות לאתר](https://multinet.digital/contact/)[חייגו: 054-925-7550](tel:+972549257550)