אתם מפרסים גרסה ב-2 בצהריים ביום שלישי. הכל נראה תקין. הבנייה עברה, הבדיקות ירוקות, והצוות ממשיך הלאה. אבל עד יום חמישי, משתמשים מתלוננים שדף הקופה מרגיש איטי. זמן הטעינה הממוצע טיפס מ-1.1 שניות ל-3.4 שניות - ואף אחד לא שם לב עד שאנשים אמיתיים התחילו לנטוש.
זה בדיוק התרחיש שניטור ביצועי אתר עם בדיקות סינתטיות נועד למנוע. וזה קורה הרבה יותר מכפי שרוב הצוותים מוכנים להודות.
מה זה בעצם ניטור סינתטי
ניטור סינתטי מריץ בדיקות אוטומטיות ומתוכנתות על האתר שלכם במרווחי זמן קבועים - לפני ואחרי פרסומים, וברקע כל הזמן. בניגוד לניטור משתמשים אמיתיים (RUM), שאוסף נתונים רק כשמבקרים מגיעים, בדיקות סינתטיות רצות לפי לוח זמנים קבוע ללא תלות בתנועה. כלומר, אתם מקבלים נתונים עקביים וניתנים להשוואה בכל פעם.
חשבו על זה כרובוט שמבקר באתר שלכם כל 60 שניות, טוען דפים ספציפיים, מודד כל מדד תזמון, ומיידע אתכם מיד אם משהו משתנה. לא אכפת לו אם זה 3 לפנות בוקר ביום ראשון. הוא בודק בכל מקרה.
ניטור סינתטי מול ניטור משתמשים אמיתיים: שניהם חשובים
RUM מצוין להבנת האופן שבו תנאים מגוונים מהעולם האמיתי - חיבורים סלולריים איטיים, דפדפנים ישנים, מרחק גיאוגרפי - משפיעים על המשתמשים שלכם. אבל יש לו נקודת עיוורון רצינית: הוא לא יכול לספר לכם שמשהו שבור עד שמשתמשים חווים את זה.
ניטור סינתטי ממלא את הפער הזה. הוא יוצר קו בסיס מבוקר וניתן לחזרה. כשנסיגה מתרחשת, אתם יודעים בדיוק מתי היא התחילה, ומכיוון שסביבת הבדיקה עקבית, תוכלו לבודד את הסיבה הרבה יותר מהר.
גישה טובה משתמשת בשניהם. בדיקות סינתטיות תופסות נסיגות מוקדם. נתוני RUM אומרים לכם מה ההשפעה בפועל.
המדדים שכדאי לעקוב אחריהם בבדיקה סינתטית
לא כל מדדי הביצועים שימושיים באותה מידה לזיהוי נסיגות. אלה הם המדדים שבאמת מאותתים על בעיה:
- Time to First Byte (TTFB): אם זה קופץ, הבעיה כמעט תמיד בצד השרת - שאילתת מסד נתונים איטית, קריאת API חדשה שאינה ב-cache, או הגדרת שרת שגויה. TTFB מעל 200ms בדף שמאוחסן ב-cache שווה בדיקה מיידית.
- Largest Contentful Paint (LCP): זהו המדד העיקרי של Google למהירות תחושתית של דף. שינוי ב-LCP בין שני פרסומים בדרך כלל מצביע על משאב חדש שחוסם רינדור, תמונה ראשית כבדה יותר, או רמז preload חסר. סקרנו את הקשר בין LCP ותשתית האחסון שלכם בפירוט באיך ציוני Largest Contentful Paint חושפים את צווארי הבקבוק האמיתיים בתשתית האחסון שלכם.
- משקל הדף הכולל: עלייה פתאומית כאן - אפילו 200KB - יכולה להצביע על נכס לא דחוס, סקריפט צד שלישי חדש, או צינור עיבוד תמונות שגוי.
- מספר הבקשות: אם מספר הבקשות קופץ אחרי פרסום, משהו חדש נטען שלא היה שם קודם.
- זמן הרצת JavaScript: חבילת JS כבדה יותר, ספרייה חדשה, או סקריפט שחוסם רינדור וכתוב בצורה גרועה יופיעו כאן לפני שהם פוגעים בציוני Core Web Vitals שלכם.
הגדרת קו בסיס לניטור סינתטי
הטעות הנפוצה ביותר של צוותים היא הגדרת ניטור סינתטי רק אחרי שהבעיה כבר קרתה. עד אז, אין לכם שום דבר להשוות מולו.
הריצו את הבדיקות הסינתטיות שלכם לפחות שבוע אחד לפני שאתם מתייחסים לתוצאה כלשהי כקו בסיס לנסיגה. זה מחליק חריגות - למשל הבהוב מבעיית רשת זמנית - ונותן לכם תמונה ריאלית של טווח הביצועים הרגיל שלכם.
מה חבילת הבדיקות שלכם צריכה לכלול
אל תסתפקו בדף הבית בלבד. הדפים החשובים ביותר לזיהוי נסיגות הם בדרך כלל אלה שעושים את הכי הרבה עבודה:
- דפי הנחיתה עם התנועה הגבוהה ביותר
- כל דף עם שאילתות כבדות למסד נתונים (חיפוש, דפי קטגוריה, לוחות מחוונים של חשבון)
- תהליכי קופה או המרה
- כל דף שלאחרונה קיבל פונקציונליות חדשה
לכל אחד מאלה, הריצו בדיקות מלפחות שני מיקומים גיאוגרפיים - אחד קרוב לשרת שלכם ואחד רחוק יותר. ההפרש בין התוצאות האלה אומר לכם עד כמה ה-CDN שלכם באמת עובד טוב.
איך להשתמש בנתונים סינתטיים כדי לאתר נסיגה
כשבדיקה מפעילה התראה, הדבר הראשון לעשות הוא לבדוק את חותמת הזמן ולהשוות אותה להיסטוריית הפרסומים שלכם. רוב הנסיגות מגיעות משינויי קוד, לא מבעיות תשתית.
תהליך עבודה מעשי לאיתור תקלות
הנה תהליך עבודה שעובד טוב בפועל:
- ודאו שהנסיגה עקבית. הריצו את הבדיקה 3-5 פעמים ידנית. אם היא לא יציבה, ייתכן שאתם רודפים אחרי חריגת רשת ולא בעיה אמיתית.
- זהו איזה מדד השתנה. קפיצה ב-TTFB מצביעה על השרת. שינוי ב-LCP מצביע על הצד הקדמי או הנכסים. קפיצה בסך הבקשות מצביעה על משאבים חדשים שנטענים.
- בדקו את לוח הזמנים של הפרסומים. האם משהו שוחרר ב-2-4 השעות האחרונות שנוגע לדף המושפע? התחילו שם.
- השתמשו בתרשים waterfall. כלים כמו WebPageTest נותנים לכם פירוט מלא בקשה-אחרי-בקשה. מצאו את הבקשה החדשה או המשתנה שמתואמת עם הנסיגה.
- בדקו את התיקון לפני פרסום. הריצו את הבדיקה הסינתטית על סביבת ה-staging קודם. זה כל הרעיון - לתפוס את הנסיגה לפני שהיא שוב מגיעה לייצור.
לצוותים שעובדים עם סביבות staging, הלולאה הזאת נהיית הרבה יותר הדוקה. אפשר להריץ את אותה חבילת בדיקות סינתטיות על staging כמו על ייצור, ולהשוות תוצאות זו לצד זו לפני שאפילו שורת קוד אחת יוצאת לאוויר.
כלים לניטור ביצועי אתר עם בדיקות סינתטיות
יש כמה כלים טובים שכדאי להכיר:
- WebPageTest: חינמי, מפורט להפליא, וסטנדרט הזהב לניתוח ביצועים חד-פעמי. יכולת הסקריפטינג שלו מאפשרת לבדוק תהליכים רב-שלביים כמו כניסה לחשבון וקופה.
- Lighthouse CI: הכלי הקוד-פתוח של Google שמשתלב ישירות בצינור CI/CD שלכם. הוא מריץ ביקורת Lighthouse על כל pull request ומכשיל את הבנייה אם הציונים יורדים מתחת לסף שקבעתם. זה הכי קרוב שאפשר להגיע למניעת נסיגה מלהגיע לייצור.
- Calibre, SpeedCurve, או Sentry Performance: כלים בתשלום שמוסיפים מעקב היסטורי, התראות, ולוחות מחוונים לצוות על גבי מנוע הבדיקות הסינתטיות. שווים את העלות לצוותים גדולים יותר שבהם המפתחים הבודדים לא בודקים ציונים ידנית.
- Datadog Synthetics: אפשרות ברמה ארגונית עם אינטגרציות התראות חזקות. שימושי אם אתם כבר משתמשים ב-Datadog לניטור תשתית ורוצים הכל במקום אחד.
שילוב בדיקות סינתטיות בצינור CI/CD שלכם
ההגדרה הכי עוצמתית מריצה בדיקות סינתטיות כשער חובה בצינור הפרסום שלכם. הנה הגדרת Lighthouse CI מינימלית שחוסמת פרסום אם הביצועים יורדים:
// lighthouserc.js module.exports = { ci: { collect: { url: ['https://staging.yoursite.com/', 'https://staging.yoursite.com/checkout/'], numberOfRuns: 3, }, assert: { assertions: { 'categories:performance': ['error', { minScore: 0.85 }], 'first-contentful-paint': ['warn', { maxNumericValue: 2000 }], 'largest-contentful-paint': ['error', { maxNumericValue: 2500 }], 'total-blocking-time': ['error', { maxNumericValue: 300 }], }, }, upload: { target: 'temporary-public-storage', }, }, };זה מריץ 3 ביקורות Lighthouse על כתובות ה-staging שלכם, מחשב ממוצע של התוצאות, וזורק שגיאה אם LCP עולה על 2.5 שניות או ציון הביצועים יורד מתחת ל-85. הפרסום לא ממשיך עד שהסף עובר.
ניטור ביצועי אתר רציף אחרי פרסום
גם עם בדיקות לפני פרסום, סביבת הייצור יכולה להתנהג שונה מ-staging. הגדרות CDN אמיתיות, עומס מסד נתונים חי, וסקריפטים של צד שלישי מכניסים משתנים שסביבת staging לא יכולה לשכפל בצורה מושלמת.
לכן ניטור ביצועי אתר רציף אחרי פרסום חשוב לא פחות. הגדירו את הבדיקות הסינתטיות שלכם לרוץ כל 5-10 דקות על הדפים הקריטיים שלכם, והגדירו התראות שיופעלו אם מדד כלשהו חורג ב-20% מקו הבסיס. סף של 20% הדוק מספיק כדי לתפוס נסיגות אמיתיות, אבל רחב מספיק כדי למנוע עייפות מהתראות בגלל תנודות קלות.
בצד השרת, זה גם עוזר כשהתשתית שלכם מנוטרת באופן פעיל. אנחנו עוקבים אחרי פסגות ביצועים ואירועי זמינות ברמת השרת, כך שקפיצות שמקורן בשכבת התשתית - ולא בקוד שלכם - גלויות בנפרד מהתוצאות הסינתטיות ברמת האפליקציה. ההפרדה הזאת מקלה מאוד לדעת היכן לחפש כשמשהו משתבש.
אם אתם רוצים להבין יותר על האופן שבו אותות ביצועים ברמת השרת מתחברים לאסטרטגיית הניטור הכוללת שלכם, הגדרת התראות ביצועים בזמן אמת לפני שהמשתמשים שלכם מרגישים בבעיה הוא קריאת השלמה טובה.
הערך האמיתי: ביטחון בזמן פרסום
ניטור סינתטי לא רק תופס נסיגות. הוא משנה את האופן שבו הצוות שלכם מפרסם. כשכל pull request מריץ בדיקת ביצועים וכל פרסום לייצור מנוטר על ידי בדיקות אוטומטיות, אתם מפסיקים לשלוח שינויים אל תוך החושך.
צוותים שעושים זאת באופן עקבי מדווחים על פחות תקריות ביצועים, זמן קצר יותר לפתרון הבעיה כשמשהו כן משתבש, ואולי הדבר השימושי ביותר - שפה משותפת לדיון בביצועים. כשכולם יכולים לראות את אותו מגמת המדדים לאורך זמן, ביצועים מפסיקים להיות תחושה מעורפלת ומתחילים להיות תכונה מדידה של קוד המקור.
השינוי התרבותי הזה שווה, בכנות, יותר מכל שיפור בודד. לעוד על התמונה הרחבה של שיפור מהירות אתר ואילו שינויים באמת עושים הבדל, הפוסט הזה שווה את הזמן שלכם.
התחילו עם קו בסיס. בחרו שניים או שלושה דפים קריטיים. קבעו סף. תנו לרובוטים לשמור על המצב כדי שתוכלו לישון.
