RUM לאפליקציות אינטרנט: הגדרת Core Web Vitals והתראות

מדוע real user monitoring ללא Core Web Vitals מטעה

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

Real user monitoring ללא core web vitals מניב זרם של מדידות גולמיות שקשה להפיק מהן החלטה. החציון של זמן הטעינה נראה אחיד, כי אותו מושכים כלפי מעלה ביקורים מהירים, והזנב האיטי בדגם מכשיר מסוים או ברשת מסוימת לא נכנס אליו. המספרים קיימים, אבל איפה בדיוק המשתמש מאבד סבלנות — לא רואים.

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

השילוב של real user monitoring ו-core web vitals סוגר את הפער: מדדי הפרונטאנד נאספים מסשנים אמיתיות, מפולחים לפי סוג דף, מכשיר וגיאוגרפיה, והתראות לפי מדדים מגיבות להידרדרות של הזנב, ולא של הממוצע. להלן — כיצד להגדיר איסוף וספים כך שזה יהפוך לאות עבודה, ולא לעוד לוח תצפית.

מה נותן איסוף מדדים מסשנים אמיתיות של משתמשים

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

איסוף מדדים ממשתמשים, או real user monitoring, סוגר את הפער הזה: הדפדפן של כל אורח מחזיר ערכי שדה של Core Web Vitals — זמן ציור התוכן הראשי, היענות לפעולה, תזוזות פריסה — בצירוף לדף, למכשיר, לאזור ולגרסת המהדורה.

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

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

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

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

אפשרויות איסוף נתונים: סוכן, סינתטיקה, מצב היברידי

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

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

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

שלבי הטמעה: ממלאי דפים ועד נהלים

הטמעת ניטור משתמשים אמיתיים (RUM) מתחילה לא בלוח עם גרפים, אלא במלאי: אילו תבניות דפים נושאות עומס, אילו תרחישים מובילים ליעד והיכן Core Web Vitals יורדים במכשירים אמיתיים. לאחר מכן בונים את העבודה כך שעד להתראה הראשונה יהיו מוכנים ספים, מסלולים ונוהל תגובה.

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

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

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

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

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

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

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

תצורות איסוף, לוחות מחוונים ונהלי תגובה

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

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

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

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

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

מה הראתה המדידה לפי סשנים חיים

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

מה שינו

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

שיעור הסשנים האיטיות ירד מ-21% ל-7% — פי שלושה, וזמן התגובה לתקרית הצטמצם משעות אחדות ל-10-15 דקות. המדד הפסיק להיות דוח למראית עין: הרגרסיה נראית בהעלאה ומתגלגלת לאחור לפני שהקונים מבחינים בה.

במה real user monitoring שונה מבדיקות סינתטיות?

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

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

נוח לסכם את השוואת הגישות בטבלה אחת:

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

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

ספקות טכניים לפני הפעלת איסוף מדדים

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

האם נדרשים שינויים בקוד האפליקציה?

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

איך מסננים בוטים וחריגות במדדים?

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

מה עם דרישות לנתונים ולאחסון?

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

נדון במשימה: מה לשלוח ואיך נתחיל לעבוד

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

• רשימת דפים ותרחישים מרכזיים — ביצוע הזמנה, קטלוג, תשלום: לפיהם ניקח קודם כל מדדי real user monitoring, ולא "לכל האתר".
• ספי יעד למדדים: מהירות ציור התוכן הראשי, היענות ללחיצה, יציבות חזותית. מספיק לנסח דרישה עסקית ("שיעור הסשנים עומד בלא פחות מ..."), ואת הערכים המדויקים נבחר יחד.
• מה כבר מוגדר: בדיקות סינתטיות, מדידות מעבדה, מוני אנליטיקה — כדי לא לכפול איסוף ולא להתנגש עם דוחות קיימים.
• הרשאות: קריאה לחשבון ניטור ואנליטיקה, סביבת בדיקה לאימות הסימון, איש קשר של האחראי על הפרונטאנד.
• ערוצי התראות ומשמרות: לאן מגיע אות על ירידה (מסנג'ר, דואר, מערכת משמרות) ומי מגיב לו בשעות העבודה ומחוצה להן.
• חתכים שחשובים לניתוח: מכשירים, דפדפנים, אזורים, סוג חיבור — מהם תלוי היכן לחפש את סיבת ההידרדרות.
• לוח העלאות ושינויים גדולים בפרונטאנד — כדי להבחין בין רגרסיית מהדורה לרעש רקע של הרשת.

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