پایش کاربر واقعی (RUM) و Core Web Vitals
سایت را روی لپ‌تاپتان باز می‌کنید، در یک ثانیه می‌آید. ابزار سنجش هم نمرهٔ ۹۴ می‌دهد. و بعد مشتری می‌گوید سایتتان کند است.
هر دو راست می‌گویید. شما روی دستگاهی با پردازندهٔ قوی، پشت اینترنت ثابت، با حافظهٔ نهانِ پر تست کرده‌اید. او روی گوشی میان‌رده، روی اینترنت همراه، بار اول.
RUM — پایش کاربر واقعی — یعنی به‌جای شبیه‌سازی، از خودِ مرورگرِ کاربر بپرسید چه چیزی دید. یک قطعهٔ کوچک جاوااسکریپت اندازه می‌گیرد و می‌فرستد. همین.
سه عددی که استاندارد شده‌اند
خوبی این حوزه این است که برخلاف خیلی جاهای دیگر، یک استاندارد واقعی و همه‌پذیرفته دارد: Core Web Vitals. گوگل تعریفشان کرده، خودش هم با همان‌ها سایت‌ها را می‌سنجد، و هر ابزاری همان سه را گزارش می‌دهد:
LCP — بزرگ‌ترین عنصر صفحه کی دیده شد. یعنی «کی به نظر آمد که آمد». معمولاً تصویر بنر یا تیتر اصلی است.
INP — از لحظه‌ای که کاربر کلیک یا لمس کرد تا لحظه‌ای که صفحه واکنش نشان داد. این جانشین FID شده و سخت‌گیرتر است، چون کلِ تعامل را می‌سنجد نه فقط اولینش.
CLS — چقدر محتوا زیر دست کاربر جابه‌جا شد. همان تجربهٔ آزاردهنده‌ای که می‌خواهید روی یک دکمه بزنید و تبلیغ دیرآمده هلش می‌دهد پایین.
هر سه‌شان عمداً چیزی را می‌سنجند که کاربر حس می‌کند، نه چیزی را که سرور انجام می‌دهد. و این تفاوت کل ماجراست.
چرا داده از دستگاه واقعی فرق دارد
وقتی برای اولین بار RUM روی یک سایت ایرانی می‌گذارید، معمولاً سه چیز را می‌بینید که در آزمون آزمایشگاهی دیده نمی‌شد.
اول، توزیع دستگاه‌ها. سهم گوشی‌های میان‌رده و پایین‌رده همیشه بیشتر از تصور تیم است. کدی که روی گوشی پرچم‌دار روان است، روی پردازنده‌ای با یک‌سوم توان، سه برابر طول می‌کشد — و جاوااسکریپت دقیقاً همان چیزی است که این تفاوت را بزرگ می‌کند.
دوم، شبکه. اینترنت همراه فقط کند نیست؛ بی‌ثبات است. تأخیر برقراری ارتباط اولیه روی اتصال ضعیف می‌تواند از کل زمان پردازش سرور بیشتر باشد.
سوم — و این آن چیزی است که معمولاً کسی انتظارش را ندارد — تفاوت بین صفحات. صفحهٔ اصلی معمولاً بهینه است چون همه نگاهش می‌کنند. صفحهٔ نتایج جست‌وجو یا سبد خرید، که تبدیل آنجا اتفاق می‌افتد، اغلب دو برابر بدتر است.
RUM جای آزمون مصنوعی را نمی‌گیرد
این را صریح بگوییم چون فروش هر دو ابزار با ادعای جانشینی انجام می‌شود.
RUM فقط وقتی داده دارد که کاربری آمده باشد. اگر صفحه‌ای ماهی ده بازدید دارد، RUM دربارهٔ آن چیزی نمی‌داند. و اگر سایت پایین باشد، هیچ مرورگری چیزی نمی‌فرستد — یعنی RUM قطعی را گزارش نمی‌کند، فقط ساکت می‌شود.
آزمون مصنوعی برعکس است: زمان‌بندی‌شده، قابل تکرار، و قبل از اینکه کاربری ببیند خبر می‌دهد. تفکیک کاملشان در آزمون مصنوعی در برابر کاربر واقعی است.
قاعدهٔ عملی ما: مصنوعی برای اینکه بفهمید چیزی خراب شد، RUM برای اینکه بفهمید برای چه کسی خراب بود.
عددها را چطور بخوانید
سه اشتباه رایج، که هر سه را دیده‌ایم:
میانگین گرفتن. باز هم. LCPِ میانگینِ ۲٫۱ ثانیه می‌تواند یعنی همه ۲٫۱ ثانیه دیده‌اند، یا یعنی نیمی ۱٫۲ و نیمی ۳ ثانیه. صدک ۷۵ عددی است که گوگل خودش با آن قضاوت می‌کند؛ با همان قضاوت کنید.
نگاه کردن به کل سایت به‌جای صفحه. میانگین کل سایت را صفحهٔ اصلی می‌سازد و مسئله جای دیگری است.
و مهم‌ترینش: تفکیک نکردن. عدد را بر اساس نوع دستگاه، نوع اتصال و صفحه بشکنید. تقریباً همیشه معلوم می‌شود مشکل کل سایت نیست؛ مشکل یک صفحهٔ مشخص روی یک دستهٔ مشخص از دستگاه‌هاست. و آن، مسئله‌ای است که می‌شود در یک هفته حلش کرد.
بعد از اندازه‌گیری
RUM به شما نمی‌گوید چه کار کنید؛ می‌گوید کجا را نگاه کنید. ترتیب کارهایی که معمولاً بیشترین اثر را دارند در بهینه‌سازی سرعت سایت آمده و اینجا تکرارش نمی‌کنیم.
فقط یک نکته که مستقیماً به پایش مربوط است: قبل و بعد را اندازه بگیرید. تیم‌هایی که بدون داده بهینه‌سازی می‌کنند، معمولاً چیزی را بهتر می‌کنند که کسی حسش نمی‌کرده و شش هفته وقت می‌گذارند. با RUM می‌فهمید کدام تغییر واقعاً روی صدک ۷۵ اثر گذاشت.
گزینه‌ها، با یک هشدار محلی
بیشتر سرویس‌های شناخته‌شدهٔ RUM میزبانی‌شده‌اند و از ایران قابل ثبت‌نام یا پرداخت نیستند. توصیه‌شان بی‌فایده است.
چیزی که عملی است: مرورگر خودش این عددها را می‌دهد. واسط برنامه‌نویسی
PerformanceObserver در هر مرورگر مدرنی هست و کتابخانهٔ رسمی گوگل برای خواندن
Core Web Vitals هم کوچک است. یعنی می‌توانید همان سه عدد را جمع کنید و به مقصد
خودتان بفرستید — یک نقطهٔ پایانی ساده و یک جدول. برای بیشتر سایت‌ها این کافی است
و کل کارش یک روز است.
اگر می‌خواهید بعداً به پشتهٔ استاندارد وصل شوید، OpenTelemetry برای مرورگر هم وجود دارد، ولی بدانید که بلوغش در سمت مرورگر به اندازهٔ سمت سرور نیست.
برای اپلیکیشن موبایل ماجرا فرق دارد و آنجا AppMetrica گزینهٔ رایگان و در دسترسی است؛ تفصیلش در گزارش خرابی.
یک سنجهٔ ساده که پیشنهاد می‌کنیم از همان هفتهٔ اول نگاهش کنید: درصد بازدیدهایی که هر سه Core Web Vital را در محدودهٔ خوب گذرانده‌اند. یک عدد، قابل فهم برای مدیر، و برخلاف نمرهٔ ابزارهای آزمایشگاهی، از واقعیت می‌آید.