מבקרים עוזבים אם אתר נטען לאט. גוגל מענישה על Core Web Vitals ירודים. לפי Google Search Central, מדדים אלה הם גורם דירוג ישיר. אנו מגדירים ניטור RUM כך שתראו מדדים אמיתיים ממשתמשים אמיתיים, לא נתונים סינתטיים. במשך 7+ שנים ביצענו אופטימיזציה ל-40+ פרויקטים — בכל פעם LCP ירד לפחות ב-30%, INP השתפר ב-25%, CLS התייצב לאזור הירוק. מקרה אחד: אתר מסחר אלקטרוני לאלקטרוניקה עם LCP של 4.5 שניות ו-CLS של 0.3. לאחר יישום ניטור ואופטימיזציה שלאחר מכן (טעינה עצלה, טעינה מוקדמת של משאבים קריטיים, תיקון תזוזת פריסה), LCP ירד ל-1.8 שניות, CLS ל-0.05. התנועה מגוגל גדלה ב-25% תוך חודש. חיסכון ברכישת תנועה: ROI מיישום RUM עולה על פי 5 על ידי הפחתת הפסדים בדפים איטיים. הפחתה של עד 30% בתקציב הפרסום היא תוצאה אמיתית עבור הלקוחות שלנו.
למה Core Web Vitals קריטיים ל-SEO
שלושה מדדים המשפיעים ישירות על הדירוג: LCP (Largest Contentful Paint — מהירות הצגת התוכן הראשי), INP (Interaction to Next Paint — היענות לפעולות משתמש), ו-CLS (Cumulative Layout Shift — יציבות פריסה). אם אפילו אחד נמצא באזור האדום, האתר מאבד מיקומים. מהפרויקטים שלנו, שיפור Core Web Vitals מתאם עם צמיחה של 20–40% בתנועה וירידה ממוצעת של 15% בשיעור הנטישה. שגיאות באתר עולות לעסקים עד 30% מהתנועה — ניטור עוזר לזהות אותן.
הבעיה היא שדפדפנים ומכשירים משתנים. על MacBook עם גיגה-ביט, המדדים מצוינים; על מובייל 3G בהודו, הם נוראיים. בדיקות סינתטיות לא יציגו את התמונה האמיתית. רק RUM (Real User Monitoring) מספק את האמת.
איך להגדיר ניטור RUM תוך שעה
התקינו את ספריית web-vitals ושלחו מדדים ל-endpoint שלכם. דוגמת קוד:
<script type="module">
import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js';
function sendToAnalytics({ name, value, rating, navigationType }) {
navigator.sendBeacon('/api/vitals', JSON.stringify({
metric: name,
value: Math.round(name === 'CLS' ? value * 1000 : value),
rating, // 'good' | 'needs-improvement' | 'poor'
url: location.pathname,
connection: navigator.connection?.effectiveType ?? 'unknown',
deviceMemory: navigator.deviceMemory ?? 0,
ts: Date.now(),
}));
}
onLCP(sendToAnalytics);
onsINP(sendToAnalytics);
onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);
</script>זוהי הבסיס. אבל אתם גם צריכים: endpoint לקבלה, אחסון ב-ClickHouse, דשבורדים ב-Grafana, התראות על הידרדרות. אנו מטפלים בכל זה במפתח פתוח.
פרטי אחסון מדדים
ClickHouse מצוין לנתוני סדרות זמן. אנו משתמשים במנוע MergeTree עם חלוקה יומית. דוגמת סכמה: ```sql CREATE TABLE vitals ( metric String, value Float32, rating String, url String, connection String, deviceMemory UInt8, ts DateTime ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(ts) ORDER BY (metric, ts); ``` אינדקסים על metric וזמן מאפשרים חישוב מהיר של p95 ו-p75.אילו בעיות הניטור פותר?
- שרת איטי — TTFB > 800 ms. RUM מראה היכן השרת איטי.
- תמונות לא מותאמות — הגורם העיקרי ל-LCP ירוד.
- סקריפטים של צד שלישי — אנליטיקה, מפות, ווידג'טים חוסמים רינדור.
- דליפות רינדור מחדש — עדכוני DOM מיותרים פוגעים ב-INP.
- תזוזות פריסה — תמונות ללא מידות, טעינת תוכן דינמי.
השוואת שיטות ניטור
| מאפיין | RUM (משתמש אמיתי) | סינתטי (Lighthouse) |
|---|---|---|
| נתונים | ממשתמשים אמיתיים | סימולציה בסביבה מבוקרת |
| כיסוי | כל המכשירים/החיבורים | מוגבל להגדרות |
| עדכניות | מצב נוכחי בייצור | תמונת מצב ברגע אחד |
| גרנולריות | לפי URL, פלח, זמן | מדד בודד לכל ריצה |
| מטרה | ניטור והתראות | ניפוי באגים ובדיקות |
RUM מדויק פי 5 בשיקוף חוויית המשתמש בפועל, ולכן התראות המבוססות על RUM מאפשרות תגובה מהירה יותר לבעיות.
מה כלול בעבודה?
- תיעוד ארכיטקטורת ניטור והנחיות לצוות.
- גישה לדשבורדים ולמערכת ההתראות.
- הדרכת צוות על עבודה עם מדדים ותגובה לאירועים.
- חודש תמיכה לאחר ההשקה: התאמת ספים, הוספת פלחים.
תהליך יישום ניטור במפתח פתוח
- בדיקת ארכיטקטורה ומדדים קיימים.
- התקנת סקריפט RUM עם חלוקה לדפים.
- פיתוח API endpoint עם אחסון ב-ClickHouse (או DB אחר).
- יצירת דשבורדים ב-Grafana עם p75, p95, חלוקה לפי מכשיר/חיבור.
- הגדרת התראות (Grafana Alerting) כשמדדים חורגים מהספים.
- שילוב הודעות (Telegram, Slack, PagerDuty).
- תיעוד והדרכת צוות.
- חודש תמיכה.
ספי מדדים:
| מדד | טוב | דורש שיפור | ירוד |
|---|---|---|---|
| LCP | ≤ 2500 ms | 2500–4000 ms | > 4000 ms |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| FCP | ≤ 1800 ms | 1800–3000 ms | > 3000 ms |
| TTFB | ≤ 800 ms | 800–1800 ms | > 1800 ms |
טעויות נפוצות ואיך להימנע מהן
רבים מתמקדים רק ב-LCP, ושוכחים את CLS ו-INP. טעות נפוצה נוספת היא חוסר חלוקה לדפים: הנתונים מתערבבים, ולא ברור היכן הבעיה. הגדירו התראות על p75 ו-p95, לא רק על ממוצעים — זה מאפשר לזהות הידרדרות מהר יותר.
צרו קשר לבדיקה — נראה לכם אילו מדדים שבורים ואיך לתקן אותם. הזמינו פריסת ניטור RUM עם אחריות לשיפור Core Web Vitals. קבלו ייעוץ על אופטימיזציה — נבחן את המחסנית הנוכחית שלכם ונציע תוכנית.