בדיקת מהירות אתר: איך בודקים, קוראים את הדוח ובוחרים תיקונים

איך מבצעים בדיקת מהירות אתר ומזהים מה דורש תיקון

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

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

לפני שמתחילים, הכינו רשימת עמודים לבדיקה ומקום לשמירת התוצאות. לבדיקה הראשונית בכלי הציבורי נדרשת כתובת עמוד, בלי התקנה באתר. אם יש לכם גישה ל־Search Console, דוח מדדי חוויית המשתמש יוסיף תמונה של קבוצות עמודים עם בעיות דומות. המדדים והספים המובאים כאן אומתו בתיעוד הרשמי נכון ל־4 בנובמבר 2026.

שלב ראשון: בוחרים עמודים ומריצים בדיקה מתועדת

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

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

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

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

שלב שני: מפרידים בין נתוני גולשים לציון המעבדה

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

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

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

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

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

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

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

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

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

שלב רביעי: מתאימים את התיקון למדד שנפגע

כשזמן הופעת התוכן המרכזי גבוה

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

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

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

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

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

כשהתוכן קופץ בזמן הקריאה

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

שלב חמישי: מדרגים את המשימות ובודקים את התוצאה

מומלץ להתחיל בבעיה שאפשר לשחזר בעמוד משמעותי לעסק, ולבדוק אם היא חוזרת בעמודים בעלי מבנה דומה. דוח Core Web Vitals ב־Search Console מקבץ כתובות דומות לפי המדדים והמצב שלהן. אפשר להשתמש בקבוצות האלה כדי לבחור עמודים נוספים לבדיקה, בהתאם ל־הסבר הרשמי על הדוח.

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

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

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

רשימת השלמה: מה צריך להישאר בידיכם

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

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

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