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

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

למה למדוד ולא לסמוך על התחושה?

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

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

באילו כלים בודקים?

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

PageSpeed Insights

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

Search Console

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

WebPageTest ו-DevTools

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

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

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

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

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

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

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

מה עושים עם מדד אדום?

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

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

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

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

איך יודעים שהתיקון עבד?

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

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

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

בשורה התחתונה

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

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