מהירות אתר: מה זה ואיך יודעים אם האתר שלכם איטי

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

מהירות אתר היא לא שניות בודדות על שעון עצר. Google מודדת אותה בשלושה מדדים שנקראים Core Web Vitals: כמה זמן לוקח לתוכן המרכזי להופיע (עד 2.5 שניות נחשב טוב), כמה מהר העמוד מגיב ללחיצה (עד 200 אלפיות השנייה), וכמה העמוד קופץ תוך כדי טעינה (עד 0.1). אתר שעומד בשלושתם אצל רוב המבקרים הוא מהיר לפי ההגדרה של Google, וכל חריגה מצביעה על הבעיה שכדאי לטפל בה קודם.

מה בעצם נחשב "מהירות אתר"

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

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

שלושת המדדים שעליהם מסתכלים

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

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

איך זה נראה בפועל

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

איך בודקים: צעד אחר צעד

  1. היכנסו ל-PageSpeed Insights של Google והדביקו כתובת של עמוד מרכזי: דף הבית, דף שירות ודף שמביא לכם פניות. בדיקה של דף הבית בלבד לא מספרת את כל הסיפור.
  2. בחרו בלשונית של מובייל. Google משתמשת בגרסה הניידת של האתר לאינדוקס ולדירוג, ו-PageSpeed Insights מציג את המובייל והמחשב בנפרד.
  3. הסתכלו קודם על החלק העליון, "נתוני משתמשים אמיתיים", ורק אחר כך על ציון המעבדה.
  4. רשמו את שלושת הערכים (LCP, INP, CLS) לפני שנוגעים בשום דבר. בלי נקודת התחלה לא תדעו אם תיקון עזר.
  5. חזרו על הבדיקה בכמה עמודים, ובימים שונים. תוצאה בודדת יכולה להשתנות מריצה לריצה.

נתוני אמת מול נתוני מעבדה

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

  • נתוני שטח (field data): מגיעים ממשתמשי Chrome אמיתיים שביקרו באתר שלכם, ומצטברים על פני 28 ימים אחרונים. אלה הנתונים ש-Google מסתמכת עליהם כשהיא מעריכה את חוויית העמוד.
  • נתוני מעבדה (lab data): בדיקה חד-פעמית של Lighthouse בסביבה מדומה, עם מכשיר ורשת סטנדרטיים. מתאימה כדי לאתר בעיות ולבדוק תיקון מיד, אבל לא מייצגת את כל המבקרים שלכם.

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

איך קוראים את הציון

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

דוגמה: איך קוראים תוצאה

נניח שבדקתם עמוד שירות וקיבלתם את התוצאות הבאות (המספרים כאן להמחשה בלבד): LCP של 4.1 שניות, INP של 150 אלפיות השנייה ו-CLS של 0.05. שניים מהמדדים בסדר, והבעיה היא אחת: התוכן הראשי מגיע מאוחר.

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

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

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

מה פירוש "עובר" ב-Core Web Vitals

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

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

כמה פעמים כדאי לבדוק

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

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

מתי האתר נחשב איטי

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

מה עושים עם התוצאות

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

שאלות נפוצות

מה נחשב מהירות אתר טובה?

לפי Google, עמוד טוב מציג את התוכן המרכזי תוך 2.5 שניות (LCP), מגיב ללחיצה תוך 200 אלפיות השנייה (INP) ומחזיק יציבות של 0.1 ומטה (CLS), ב-75% מהביקורים.

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

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

למה הציון במעבדה שונה מנתוני המשתמשים האמיתיים?

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

כמה זמן לוקח לראות שיפור בנתוני האמת אחרי תיקון?

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

האם ציון 100 ב-PageSpeed הוא מטרה?

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

מקורות

רוצה לשתף את המאמר?

מאמרים דומים