האתר שלכם נטען היום תוך 1.8 שניות. זה טוב? אין לכם מושג, אלא אם אתם יודעים כמה זמן זה לקח לפני שבוע, לפני חודש, או לפני שהתוסף החדש ההוא עלה לאוויר. בלי בסיס ייחוס, כל מספר ביצועים שאתם רואים הוא סתם מספר שמרחף באוויר. עם בסיס ייחוס, הוא הופך לאות משמעותי.
ניטור ביצועי אתר עובד רק אם יש לכם משהו להשוות אליו. הפוסט הזה יסביר איך בונים בפועל נקודת ייחוס כזו, ואיך משתמשים בה כדי לתפוס בעיות לפני שהמשתמשים שלכם יבחינו בהן.
למה בסיס ייחוס חשוב יותר מבדיקה חד-פעמית
הרבה בעלי אתרים מריצים בדיקת PageSpeed אחת, רואים ציון ירוק, וממשיכים הלאה. הבעיה היא שביצועים לא נשארים קבועים. מסד הנתונים שלכם גדל. רשימת התוספים גדלה. דפוסי התנועה משתנים. תמונת מצב מלפני שלושה חודשים לא מספרת לכם כלום על היום.
בסיס ייחוס הוא דבר אחר לגמרי. זו מדידה מתועדת וניתנת לשחזור של איך האתר שלכם מתנהג בדרך כלל, על פני כמה מדדים, לאורך זמן. ברגע שיש לכם אותו, כל סטייה בולטת מיד. זו כל המטרה של ניטור ביצועי אתר: לא רק למדוד מהירות, אלא למדוד שינוי.
מה בעצם נחשב "נורמלי"
נורמלי זה לא מספר אחד. זה טווח. תנועה בבוקר יום שני נראית שונה מתנועה בליל שבת. בסיס הייחוס שלכם צריך לקחת בחשבון את השונות הזו, אחרת תרדפו אחרי אזעקות שווא כל הזמן.
- זמני תגובה ממוצעים ואחוזון 95, לא רק ממוצעים
- נפח תנועה טיפוסי לפי שעה ויום בשבוע
- מספר שאילתות מסד נתונים ומשכן תחת עומס רגיל
- שימוש במשאבי שרת (CPU, זיכרון, קלט/פלט של דיסק) בשעות שיא ומחוץ לשיא
המדדים המרכזיים שכדאי לעקוב אחריהם
אין צורך לעקוב אחרי הכל. צריך לעקוב אחרי כמה מדדים ספציפיים שבאמת מספרים לכם משהו כשהם משתנים.
Time to First Byte (TTFB)
המדד הזה מודד כמה מהר השרת שלכם מגיב עוד לפני שהדפדפן בכלל מתחיל לצייר משהו על המסך. TTFB בריא נמצא מתחת ל-200 מילישניות ברוב ההגדרות המותאמות היטב. אם ה-TTFB הבסיסי שלכם זוחל מ-180 מילישניות ל-600 מילישניות תוך כמה שבועות, משהו השתנה בצד השרת, אולי מסד נתונים מנופח, תהליך שיצא משליטה, או תוסף בעייתי.
Core Web Vitals
Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), ו-Interaction to Next Paint (INP) נותנים לכם מבט על המהירות מנקודת מבט של המשתמש. הסף שקבע Google הוא נקודת התחלה סבירה:
- LCP מתחת ל-2.5 שניות נחשב טוב
- CLS מתחת ל-0.1 נחשב טוב
- INP מתחת ל-200 מילישניות נחשב טוב
אבל בסיס הייחוס שלכם צריך להתבסס על המספרים האמיתיים שלכם, לא רק על סף העובר/נכשל. אם ה-LCP שלכם עומד באופן עקבי על 1.2 שניות והוא קופץ ל-2.1 שניות, זו נסיגה אמיתית למרות שהיא עדיין "טובה" טכנית לפי הסטנדרט של Google.
שימוש במשאבי שרת
עומס ה-CPU, צריכת הזיכרון, וקלט/פלט הדיסק מספרים לכם מה קורה מתחת למכסה המנוע. בסיס ייחוס כאן עוזר לכם לתפוס דברים כמו דליפת זיכרון בסקריפט מותאם אישית או משימת cron שאוכלת יותר ויותר משאבים כל שבוע.
איך אוספים את הנתונים בפועל
אתם צריכים שני סוגי מדידה שעובדים ביחד.
ניטור סינתטי (Synthetic Monitoring)
זה מריץ בדיקות מתוכנתות ממיקומים קבועים במרווחי זמן קבועים, תחשבו על זה כמו רובוט שמבקר באתר שלכם כל כמה דקות ומתעד מה שהוא רואה. כלים כמו GTmetrix, WebPageTest, ו-Pingdom נכנסים לקטגוריה הזו. היתרון הוא עקביות. אותם תנאים, אותה בדיקה, בכל פעם, מה שהופך אותו למושלם לבניית בסיס ייחוס.
ניטור משתמשים אמיתיים (RUM)
זה אוסף נתוני ביצועים אמיתיים ממבקרים אמיתיים, עם המכשירים, החיבורים, והמיקומים האמיתיים שלהם. Chrome User Experience Report (CrUX) של Google וכלים כמו New Relic Browser או סקריפטי RUM שמאוחסנים עצמאית נותנים לכם את המבט הזה. הנתונים פחות מסודרים מנתונים סינתטיים, אבל הם מספרים לכם מה הקהל האמיתי שלכם חווה בפועל.
אתם רוצים את שניהם. ניטור סינתטי נותן לכם בסיס ייחוס נקי וניתן לשחזור. RUM מספר לכם אם בסיס הייחוס הזה תואם למציאות.
קבעו קצב מדידה
הריצו בדיקות סינתטיות לפחות כל 15-30 דקות עבור דפים קריטיים. אספו נתוני RUM באופן רציף מכיוון שהם פסיביים. סקרו את שניהם מדי שבוע כדי לעדכן את בסיס הייחוס ככל שהאתר שלכם גדל או משתנה באופן לגיטימי.
הפיכת בסיס הייחוס להתראות
בסיס ייחוס שיושב בגיליון אלקטרוני לא עוזר לאף אחד ב-2 בלילה. הערך האמיתי מגיע מקביעת ספים שמפעילים התראה כשמשהו סוטה יותר מדי מהנורמלי.
- התראה כאשר TTFB חורג מהממוצע הבסיסי שלכם ביותר מ-50% למשך 10 דקות ומעלה
- התראה כאשר שיעורי שגיאות (תגובות 4xx/5xx) קופצים מעל השיעור הבסיסי הרגיל שלכם
- התראה כאשר CPU השרת נשאר מעל 80% לזמן ארוך יותר מחלון השיא הטיפוסי שלכם
כאן ניטור זמינות וביצועים הופך לשימושי באמת ולא רק לקישוט. אם אתם על אחסון מנוהל, סוג כזה של התראות אמור כבר לפעול ברקע, כך שבעיה אמיתית תסומן לפני שהמבקרים שלכם מתחילים לברוח מהאתר.
בנו מחדש את בסיס הייחוס אחרי שינויים גדולים
השקתם פיצ'ר חדש? עברתם לשרת חדש? הוספתם המון תוכן חדש? בסיס הייחוס הישן שלכם כבר לא תקף. תנו לאתר כמה ימים להתייצב במצב הנורמלי החדש שלו, ואז מדדו מחדש. התייחסות לבסיס ייחוס מיושן כאילו הוא עדכני היא אחת הטעויות הנפוצות ביותר שאנחנו רואים, זה מוביל לאזעקות שווא מתמידות או לפספוס נסיגות בביצועים כי הסף נקבע לגרסה של האתר שכבר לא קיימת.
רשימת בדיקה פשוטה להתחלה
- בחרו 3-5 מדדים מרכזיים: TTFB, LCP, CLS, INP, ושיעור שגיאות
- הריצו בדיקות סינתטיות במשך שבועיים מלאים לפני שאתם קוראים למשהו בסיס ייחוס
- הוסיפו שכבה של נתוני RUM כדי לאמת מה שהבדיקות הסינתטיות מראות לכם
- קבעו ספי התראה על בסיס סטייה באחוזים, לא מספרים קבועים
- בנו בסיס ייחוס מחדש אחרי כל שינוי משמעותי באתר או בתשתית
אם אתם רוצים להעמיק במדדים הספציפיים עצמם, כיסינו בפוסטים אחרים בבלוג את הנושא של קריאת דוח Core Web Vitals שלכם ואת למה TTFB חשוב להמרות בפירוט רב יותר. ואם ניטור סינתטי הוא נושא חדש עבורכם, איך ניטור סינתטי תופס נסיגות בביצועים הוא קריאה טובה להמשך.
לסיכום
בסיס ייחוס לביצועים הוא לא משימת הקמה חד-פעמית, זו נקודת ייחוס חיה שגדלה יחד עם האתר שלכם. ברגע שיש לכם אותו, אתם מפסיקים לנחש אם משהו מרגיש איטי ומתחילים לדעת, עם מספרים, בדיוק מתי ואיפה משהו השתבש. זה ההבדל בין להגיב לתלונת לקוח לבין לתפוס את הבעיה לפני שמישהו בכלל שם לב.
