בדיקת מהירות אתר, איך לבדוק את מהירות האתר בגוגל ולשפר ביצועים

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

רוצים לבדוק את האתר עכשיו? היכנסו ל-Google PageSpeed Insights, הזינו את כתובת האתר וקבלו בדיקת ביצועים למובייל ולמחשב.

בדיקת מהירות נכונה אינה מסתכמת בציון אחד בין 0 ל-100. PageSpeed Insights משלב בדיקות מעבדה המבוססות על Lighthouse, ובמקרים שבהם קיימים מספיק נתונים, גם נתוני משתמשים אמיתיים מתוך Chrome UX Report, הידוע בשם CrUX. לכן חשוב להבין לא רק כמה קיבל האתר בבדיקה, אלא גם מה עומד מאחורי הנתונים והאם המשתמשים בפועל מקבלים חוויה מהירה ויציבה.

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

איך מבצעים בדיקת מהירות אתר בגוגל?

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

• נכנסים ל-Google PageSpeed Insights.
• מדביקים בשדה הבדיקה את כתובת ה-URL המדויקת של העמוד שרוצים לבדוק.
• מפעילים את הבדיקה וממתינים לסיום הניתוח.
• בודקים בנפרד את התוצאות עבור Mobile ועבור Desktop.
• עוברים על מדדי הביצועים, Core Web Vitals וההמלצות הטכניות שמציג הכלי.
• לאחר ביצוע שינויים באתר, מריצים את אותה כתובת שוב ומשווים את התוצאות.

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

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

נקודה חשובה לפני שמסתכלים על הציון

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

מה זה Google PageSpeed Insights ומה בעצם הכלי בודק?

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

כדי להבין נכון את הדוח, חשוב להפריד בין שני סוגי נתונים:

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

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

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

מהו ציון Performance שמופיע ב-PageSpeed?

ציון ה-Performance שמופיע ב-Lighthouse נע בין 0 ל-100 ומסכם מספר מדדי ביצועים לכדי ציון אחד שקל לקרוא.

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

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

מה הקשר בין בדיקת מהירות אתר ל-GEO?

GEO, או Generative Engine Optimization, מתייחס להתאמת האתר והתוכן לעולם שבו משתמשים מקבלים תשובות גם באמצעות מנועי חיפוש וממשקי AI גנרטיביים, כמו AI Overviews ו-AI Mode של Google.

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

Google מציינת במפורש שאין דרישות SEO מיוחדות כדי להופיע ב AI OverviewsAI Overviews הן תשובות מסכמות שגוגל מציגה בחלק מתוצאות החיפוש, ונוצרות בעזרת בינה מלאכותית. או ב AI Mode. אותם עקרונות בסיסיים של SEO ממשיכים להיות רלוונטיים גם לחוויות החיפוש הגנרטיביות.

אז למה מהירות וביצועי האתר עדיין רלוונטיים ל-GEO?

הקשר הוא בעיקר עקיף.

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

ביצועים טובים משתלבים בתוך התמונה הזו.

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

לכן, מבחינת GEO נכון יותר לחשוב כך:

תוכן טוב + נגישות למנועי החיפוש + מבנה ברור + סמכות + נתונים מובנים מתאימים + חוויית משתמש טובה = בסיס נכון גם לעולם החיפוש הגנרטיבי.

מהירות האתר היא רכיב בתוך המכלול הזה, לא קיצור דרך להופעה בתשובות AI.

האם צריך Schema מיוחד עבור GEO?

לא.

נכון להיום Google מציינת שאין Schema מיוחד שצריך להוסיף כדי להופיע ב-AI Overviews או ב-AI Mode. גם אין צורך ליצור markup ייעודי עבור מנועי AI.

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

Article או BlogPosting

BreadcrumbList

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

העיקרון החשוב הוא שהנתונים המובנים צריכים להתאים למה שהמשתמש רואה בפועל. Google ממליצה במפורש לשמור על התאמה בין Structured Data לבין התוכן המוצג בעמוד.

נקודה חשובה ל-GEO: אין צורך "להמציא Schema ל-AI". עדיף להשקיע בתוכן שקל להבין, מבנה כותרות ברור, תשובות ישירות לשאלות, מקורות אמינים וישויות שמוסברות היטב.

מהם Core Web Vitals ולמה הם חשובים?

Core Web Vitals הם קבוצת מדדים של Google שנועדה למדוד חלקים מרכזיים מחוויית המשתמש בעולם האמיתי. כיום שלושת המדדים המרכזיים הם LCP, INP ו-CLS.

מדד	מה הוא מודד	ערך שנחשב טוב
LCP	מהירות הצגת התוכן המרכזי	עד 2.5 שניות
INP	מהירות התגובה לאינטראקציות	פחות מ-200 מילישניות
CLS	יציבות חזותית של העמוד	עד 0.1

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

LCP, כמה מהר מופיע התוכן המרכזי?

LCP, קיצור של Largest Contentful Paint, מודד את הזמן עד להצגת אלמנט התוכן הגדול המרכזי שנמצא באזור הנראה של העמוד.

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

Google ממליצה לשאוף ל-LCP של עד 2.5 שניות.

כאשר ה-LCP גבוה, כדאי לבדוק בין היתר תמונות גדולות מדי, זמני תגובה של השרת, קבצים שחוסמים את הצגת העמוד, CSS ו JavaScript כבדיםג'אווה סקריפט (JavaScript) היא שפת תכנות דינמית המשמשת בעיקר לפיתוח אתרים ואפליקציות אינטראקטיביות. או טעינה לא יעילה של משאבים.

INP, כמה מהר האתר מגיב למשתמש?

INP, קיצור של Interaction to Next Paint, מודד את תגובתיות העמוד לפעולות של המשתמש.

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

ערך INP טוב הוא פחות מ-200 מילישניות.

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

CLS, למה התוכן זז בזמן הטעינה?

CLS, קיצור של Cumulative Layout Shift, מודד את היציבות החזותית של העמוד.

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

Google מגדירה CLS של עד 0.1 כתוצאה טובה.

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

מהו TTFB ובמה הוא שונה מ-Core Web Vitals?

TTFB, או Time to First Byte, מודד את הזמן שעובר מרגע שהדפדפן מבקש את העמוד ועד לקבלת הבית הראשון של התגובה מהשרת.

בניגוד ל-LCP, INP ו-CLS, TTFB אינו אחד משלושת מדדי Core Web Vitals המרכזיים. עם זאת, הוא יכול להשפיע בצורה משמעותית על שרשרת הטעינה כולה.

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

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