Real User Monitoring برای وردپرس چرا حیاتی است؟

Real User Monitoring (RUM) یا پایش کاربر واقعی، یک سیستم نظارتی است که تجربه کاربران واقعی را از داخل مرورگر آن‌ها جمع‌آوری می‌کند و تصویری دقیق از عملکرد سایت در شرایط واقعی — دستگاه، شبکه، موقعیت جغرافیایی و اپراتور — ارائه می‌دهد. برای وردپرس، RUM حیاتی است چون داده‌های آزمایشگاهی مثل Lighthouse و PageSpeed Insights فقط بخشی از تصویر را نشان می‌دهند و نمی‌توانند تنوع گسترده دستگاه‌ها و شبکه‌های کاربران ایرانی را بازتاب دهند. Core Web Vitals گوگل بر پایه داده‌های میدانی کاربران واقعی رتبه‌بندی می‌شود، نه داده‌های آزمایشگاهی. بدون RUM، بهینه‌سازی سایت مثل رانندگی در تاریکی است: ممکن است سریع به نظر برسید، اما نمی‌دانید واقعاً چقدر سریع هستید. این مقاله چارچوب کامل پیاده‌سازی RUM در وردپرس، از web-vitals library تا CrUX و GA4، را ارائه می‌دهد.

در یک پروژه فروشگاهی، Lighthouse نمره ۹۵ می‌داد و تیم فنی تصور می‌کرد مشکل عملکردی وجود ندارد. اما RUM نشان داد که ۴۰٪ کاربران موبایل، LCP بالای ۴ ثانیه تجربه می‌کنند. اختلاف بین دو داده، در یک کلمه خلاصه می‌شد: واقعیت. Lighthouse روی یک دستگاه شبیه‌سازی‌شده اجرا می‌شود، اما RUM روی هزاران دستگاه متنوع. آن تجربه، تفاوت بنیادین بین اندازه‌گیری و واقعیت را روشن کرد.

RUM چیست و چرا با Synthetic Monitoring تفاوت دارد؟

Real User Monitoring (RUM) مجموعه‌ای از تکنیک‌ها و ابزارها است که تجربه واقعی کاربران را از داخل مرورگر آن‌ها جمع‌آوری می‌کند. برخلاف Synthetic Monitoring که یک اسکریپت خودکار را روی یک سرور یا دستگاه شبیه‌ساز اجرا می‌کند، RUM داده‌ها را از دستگاه‌های واقعی، شبکه‌های واقعی و موقعیت‌های جغرافیایی واقعی جمع‌آوری می‌نماید. این تفاوت، در چند سطح قابل تحلیل است.

سطح اول، تنوع دستگاه: Lighthouse یک شبیه‌ساز موبایل با CPU throttling ۴x اجرا می‌کند. اما کاربران واقعی از دستگاه‌های متنوعی استفاده می‌کنند: از گوشی‌های پرچمدار تا گوشی‌های اقتصادی، از اینترنت 4G تا 3G، از مرورگرهای مدرن تا نسخه‌های قدیمی. RUM این تنوع را ثبت می‌کند و تصویری دقیق از توزیع تجربه ارائه می‌دهد.

سطح دوم، شرایط شبکه: در ایران، تنوع اپراتورها و کیفیت شبکه، تفاوت‌های محسوسی ایجاد می‌کند. یک سایت ممکن است برای کاربران فیبر نوری سریع باشد و برای کاربران موبایل با اپراتور خاص کند. RUM این تفاوت‌ها را قابل مشاهده می‌کند.

سطح سوم، رفتار کاربر: کاربران واقعی صفحات را به‌روش‌های غیرمنتظره مرور می‌کنند: Scroll سریع، کلیک زودهنگام، بازگشت سریع. RUM این رفتارها را ثبت می‌کند و نشان می‌دهد که کدام تعاملات کاربر، تجربه را مختل می‌کنند.

معیار	Synthetic Monitoring	Real User Monitoring
منبع داده	دستگاه شبیه‌سازی‌شده	مرورگر کاربران واقعی
تعداد نمونه	محدود (چند اجرا)	هزاران یا میلیون‌ها
تنوع دستگاه	شبیه‌سازی‌شده	واقعی و متنوع
کاربرد اصلی	پایش پیشگیرانه	تحلیل تجربه واقعی
تأخیر داده	فوری	چند دقیقه تا چند ساعت
Core Web Vitals	Lab Data	Field Data

نکته کلیدی این است که گوگل برای رتبه‌بندی، بر پایه Field Data (داده‌های میدانی) تصمیم می‌گیرد، نه Lab Data. این یعنی داده‌های RUM، نه داده‌های Lighthouse، معیار واقعی موفقیت هستند. اگر با مفاهیم Core Web Vitals و اهمیت آن آشنا شده باشید، این تفاوت را به‌عنوان یک اصل بنیادین می‌شناسید.

«Lighthouse یک عکس است؛ RUM یک فیلم. عکس ممکن است زیبا باشد، اما فیلم واقعیت را نشان می‌دهد.»

CrUX و داده‌های میدانی گوگل

Chrome User Experience Report (CrUX) یک مجموعه داده عمومی است که گوگل از کاربران Chrome جمع‌آوری می‌کند و در اختیار توسعه‌دهندگان قرار می‌دهد. این داده‌ها شامل Core Web Vitals برای میلیون‌ها وب‌سایت است و در چند جا قابل دسترسی است: PageSpeed Insights، Search Console، BigQuery و CrUX API.

اهمیت CrUX در این است که داده‌های آن، معیار واقعی رتبه‌بندی گوگل هستند. اگر سایت شما در CrUX نمره ضعیف داشته باشد، ممکن است در نتایج جستجو افت کند، حتی اگر Lighthouse نمره ۱۰۰ بدهد. این تناقض، در بسیاری از پروژه‌های وردپرسی دیده می‌شود.

سه معیار اصلی در CrUX:

LCP (Largest Contentful Paint): زمان رندر بزرگ‌ترین عنصر قابل مشاهده
INP (Interaction to Next Paint): زمان پاسخ به تعامل کاربر
CLS (Cumulative Layout Shift): میزان جابجایی ناخواسته عناصر

برای دسترسی به داده‌های CrUX، سه راه وجود دارد. اول، PageSpeed Insights که داده‌های CrUX را در بخش «Field Data» نمایش می‌دهد. دوم، Search Console که در بخش «Core Web Vitals» گزارش می‌دهد. سوم، CrUX API که به‌صورت برنامه‌نویسی قابل دسترسی است:

GET https://chromeuxreport.googleapis.com/v1/records:queryRecord
     ?key=YOUR_API_KEY
     &origin=https://example.com

این API، داده‌های خام Core Web Vitals را برای یک URL یا یک Origin برمی‌گرداند. اگر با LCP و روش‌های بهینه‌سازی آن آشنا شده باشید، می‌دانید که این داده‌ها، نقطه شروع هر بهینه‌سازی جدی هستند.

Core Web Vitals و نقش RUM در رتبه‌بندی

گوگل از سال ۲۰۲۱ Core Web Vitals را به‌عنوان یکی از سیگنال‌های رتبه‌بندی معرفی کرد. این سیگنال، بر پایه داده‌های میدانی کاربران واقعی (CrUX) محاسبه می‌شود، نه داده‌های آزمایشگاهی. این یعنی RUM، نه فقط یک ابزار بهینه‌سازی، بلکه یک ابزار SEO است.

سه معیار Core Web Vitals در سطح میدانی، آستانه‌های مشخصی دارند:

معیار	خوب	نیازمند بهبود	ضعیف
LCP	≤ 2.5s	2.5s - 4.0s	> 4.0s
INP	≤ 200ms	200ms - 500ms	> 500ms
CLS	≤ 0.1	0.1 - 0.25	> 0.25

نکته مهم: گوگل نمره هر صفحه را بر پایه صدک ۷۵ محاسبه می‌کند. یعنی اگر ۷۵٪ کاربران LCP زیر ۲.۵ ثانیه داشته باشند، آن صفحه «خوب» ارزیابی می‌شود. این یعنی تجربه ۲۵٪ کاربران بدتر، می‌تواند رتبه را تحت تأثیر قرار دهد. اگر با CLS و روش‌های کاهش آن آشنا شده باشید، می‌دانید که این صدک ۷۵، چالش اصلی بهینه‌سازی در مقیاس است.

RUM به شما اجازه می‌دهد که نه فقط میانگین، بلکه توزیع تجربه کاربران را ببینید. اگر ۹۰٪ کاربران LCP زیر ۲ ثانیه دارند اما ۱۰٪ بالای ۶ ثانیه، میانگین ممکن است خوب به نظر برسد اما صدک ۷۵ در وضعیت «نیازمند بهبود» باشد. این تفاوت، تنها با RUM قابل مشاهده است.

«میانگین دروغ می‌گوید، توزیع حقیقت را فاش می‌کند. RUM ابزار دیدن توزیع است.»

web-vitals Library و پیاده‌سازی در وردپرس

گوگل یک کتابخانه رسمی به‌نام web-vitals منتشر کرده که اندازه‌گیری Core Web Vitals را ساده می‌کند. این کتابخانه، حدود ۲ کیلوبایت حجم دارد و در مرورگرهای مدرن کار می‌کند. نصب آن با npm یا pnpm انجام می‌شود:

npm install web-vitals

استفاده پایه از این کتابخانه در یک فایل JavaScript:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
    const body = JSON.stringify({
        name: metric.name,
        value: metric.value,
        rating: metric.rating,
        id: metric.id,
        navigationType: metric.navigationType,
    });

    if (navigator.sendBeacon) {
        navigator.sendBeacon('/wp-json/my-plugin/v1/vitals', body);
    }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

برای ادغام با وردپرس، باید این اسکریپت در فرانت‌اند بارگذاری شود و یک Endpoint REST برای دریافت داده‌ها ایجاد گردد. بارگذاری اسکریپت باید به‌صورت defer یا async باشد تا بر عملکرد خود سایت اثر نگذارد:

add_action( 'wp_enqueue_scripts', 'my_plugin_enqueue_vitals' );

function my_plugin_enqueue_vitals() {
    wp_enqueue_script(
        'my-plugin-vitals',
        plugins_url( 'build/vitals.js', __FILE__ ),
        array(),
        '1.0.0',
        array( 'strategy' => 'defer' )
    );
}

Endpoint REST نیز با register_rest_route ساخته می‌شود و داده‌ها را در یک جدول سفارشی یا در wp_options ذخیره می‌کند:

add_action( 'rest_api_init', function() {
    register_rest_route( 'my-plugin/v1', '/vitals', array(
        'methods'  => 'POST',
        'callback' => 'my_plugin_store_vitals',
        'permission_callback' => '__return_true',
    ) );
} );

نکته مهم: permission_callback روی __return_true تنظیم می‌شود چون داده‌ها از سمت کلاینت ارسال می‌شوند و نیازی به احراز هویت ندارند. اما برای جلوگیری از سوءاستفاده، باید Rate Limiting و Validation اعمال شود. اگر با روش‌های امن‌سازی REST API آشنا شده باشید، این نکات برای شما آشناست.

ادغام با Google Analytics 4

Google Analytics 4 (GA4) از نسخه‌های اخیر، قابلیت ارسال داده‌های Core Web Vitals را به‌صورت بومی پشتیبانی می‌کند. این یعنی نیازی به Endpoint سفارشی نیست و می‌توانید داده‌ها را مستقیماً به GA4 ارسال کنید:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToGA4(metric) {
    if (typeof gtag === 'function') {
        gtag('event', metric.name, {
            value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
            event_category: 'Web Vitals',
            event_label: metric.id,
            non_interaction: true,
        });
    }
}

onLCP(sendToGA4);
onINP(sendToGA4);
onCLS(sendToGA4);

پس از ارسال داده‌ها، می‌توانید در GA4 یک گزارش سفارشی بسازید که Core Web Vitals را بر اساس دستگاه، مرورگر و صفحه نمایش دهد. این گزارش، تصویری دقیق از تجربه کاربران واقعی ارائه می‌دهد. اگر با تحلیل تجربه کاربر با Google Analytics آشنا شده باشید، این رویکرد را به‌عنوان یک گام تکاملی می‌شناسید.

مزیت GA4 این است که داده‌ها را با سایر متریک‌های کسب‌وکار ترکیب می‌کند: نرخ تبدیل، درآمد، و رفتار کاربر. این یعنی می‌توانید ببینید که کندی سایت، چگونه بر فروش اثر می‌گذارد. اگر با رابطه Core Web Vitals و نرخ تبدیل آشنا شده باشید، این همبستگی را به‌عنوان یک شاخص کلیدی می‌شناسید.

افزونه‌های RUM برای وردپرس

چند افزونه وردپرس وجود دارند که پیاده‌سازی RUM را ساده می‌کنند:

افزونه اول: Query Monitor. این افزونه در محیط توسعه، داده‌های دقیقی از کوئری‌ها، Hookها و تماس‌های HTTP ارائه می‌دهد. اگر با پروفایلینگ عملکرد وردپرس با Query Monitor آشنا شده باشید، می‌دانید که این ابزار برای تحلیل سمت سرور ایده‌آل است. اما برای RUM واقعی، نیازی به ابزار سمت کلاینت دارید.

افزونه دوم: New Relic Browser. اگر New Relic روی سرور نصب شده باشد، می‌توانید افزونه Browser را نیز فعال کنید. این افزونه، داده‌های RUM را از مرورگر کاربران جمع‌آوری می‌کند و در همان Dashboard سرور نمایش می‌دهد. اگر با پروفایلینگ وردپرس با New Relic آشنا شده باشید، این یکپارچگی را به‌عنوان یک مزیت می‌شناسید.

افزونه سوم: افزونه‌های تخصصی RUM. چند افزونه در مخزن رسمی وجود دارند که به‌صورت تخصصی RUM ارائه می‌دهند. اما قبل از نصب هر افزونه، باید سه چیز را بررسی کنید: تعداد نصب فعال، آخرین به‌روزرسانی، و حجم Assetهای اضافه‌شده. اگر با روش دانلود ایمن افزونه وردپرس آشنا شده باشید، این بررسی‌ها برای شما آشناست.

ابزار	نوع	کاربرد اصلی
web-vitals	کتابخانه	اندازه‌گیری CWV
GA4	سرویس تحلیل	گزارش‌گیری و همبستگی
CrUX	مجموعه داده گوگل	داده میدانی عمومی
New Relic Browser	APM کامل	RUM + سرور
SpeedCurve	سرویس تجاری	RUM + Synthetic

بخش‌بندی داده بر اساس دستگاه و جغرافیا

یکی از مزیت‌های اصلی RUM، امکان بخش‌بندی داده‌ها بر اساس پارامترهای مختلف است. این بخش‌بندی، تصویری دقیق‌تر از تجربه کاربران ارائه می‌دهد و به کشف مشکلات پنهان کمک می‌کند.

چهار محور اصلی بخش‌بندی:

محور اول: نوع دستگاه. تجربه موبایل و دسکتاپ می‌تواند کاملاً متفاوت باشد. اگر سایت شما در دسکتاپ سریع اما در موبایل کند است، RUM این تفاوت را فاش می‌کند.

محور دوم: مرورگر. برخی مشکلات فقط در مرورگرهای خاص ظاهر می‌شوند. RUM امکان تفکیک بر اساس Chrome، Firefox، Safari و Edge را فراهم می‌کند.

محور سوم: اتصال شبکه. تفکیک بر اساس 4G، 3G، Wi-Fi و اتصال کابل، تصویری دقیق از تجربه کاربران با کیفیت شبکه متفاوت ارائه می‌دهد.

محور چهارم: موقعیت جغرافیایی. در ایران، تفاوت کیفیت اینترنت بین شهرها و اپراتورها قابل توجه است. RUM امکان تفکیک بر اساس شهر و اپراتور را فراهم می‌کند.

برای پیاده‌سازی این بخش‌بندی، باید در اسکریپت RUM، پارامترهای اضافی ارسال شوند:

function sendToAnalytics(metric) {
    const body = JSON.stringify({
        name: metric.name,
        value: metric.value,
        rating: metric.rating,
        device: /Mobi|Android/i.test(navigator.userAgent) ? 'mobile' : 'desktop',
        connection: navigator.connection ? navigator.connection.effectiveType : 'unknown',
        page: window.location.pathname,
    });
    navigator.sendBeacon('/wp-json/my-plugin/v1/vitals', body);
}

پس از جمع‌آوری داده‌ها، می‌توانید در Dashboard یا در GA4، بر اساس این پارامترها فیلتر کنید و مشکلات خاص را شناسایی نمایید. اگر با مانیتورینگ سرور و روش‌های آن آشنا شده باشید، این لایه‌بندی را به‌عنوان بخشی از یک استراتژی جامع Observability می‌شناسید.

Attribution و یافتن ریشه کندی

Attribution یا انتساب، فرآیند یافتن ریشه یک مشکل عملکردی است. RUM فقط می‌گوید که سایت کند است، اما Attribution می‌گوید چرا. سه سطح Attribution در RUM:

سطح اول: Attribution عنصر. کتابخانه web-vitals با گزینه reportAllChanges و attribution می‌تواند بگوید که کدام عنصر مسئول LCP بزرگ بوده است:

import { onLCP } from 'web-vitals/attribution';

onLCP((metric) => {
    console.log('LCP element:', metric.attribution.element);
    console.log('LCP URL:', metric.attribution.url);
    console.log('LCP time:', metric.attribution.timeToFirstByte);
});

سطح دوم: Attribution منبع. با تحلیل داده‌های RUM، می‌توانید بفهمید که کندی از کدام منبع می‌آید: سرور، شبکه، یا رندر کلاینت. اگر TTFB بالا باشد، مشکل سمت سرور است. اگر زمان Download بالا باشد، مشکل شبکه. اگر زمان Render بالا باشد، مشکل JavaScript یا CSS.

سطح سوم: Attribution صفحه. با بخش‌بندی بر اساس URL، می‌توانید بفهمید که کدام صفحات کندتر هستند. اگر صفحه Checkout کند است، باید بهینه‌سازی روی همان صفحه تمرکز کند. اگر با TTFB و روش‌های کاهش آن آشنا شده باشید، این تحلیل را به‌عنوان یک گام اساسی می‌شناسید.

«RUM می‌گوید کجا درد می‌کند؛ Attribution می‌گوید چرا درد می‌کند. هر دو برای درمان لازم است.»

حریم خصوصی و انطباق با GDPR

پیاده‌سازی RUM با چالش‌های حریم خصوصی همراه است. اگر داده‌ها شامل اطلاعات قابل شناسایی کاربر (PII) باشد، باید با GDPR و سایر قوانین حریم خصوصی انطباق داشته باشد. سه اصل کلیدی:

اصل اول: حداقل‌سازی داده. فقط داده‌هایی را جمع‌آوری کنید که برای تحلیل عملکرد لازم هستند. IP کامل، User-Agent کامل و URL کامل ممکن است نیاز به Anonymization داشته باشند.

اصل دوم: رضایت کاربر. اگر از Cookie برای جمع‌آوری استفاده می‌کنید، باید رضایت صریح کاربر را دریافت نمایید. اگر از sendBeacon بدون Cookie استفاده می‌کنید، ممکن است نیازی به رضایت نباشد، اما این موضوع به قوانین محلی بستگی دارد.

اصل سوم: شفافیت. در سیاست حریم خصوصی سایت، باید شفاف توضیح دهید که چه داده‌هایی جمع‌آوری می‌شود و چگونه استفاده می‌شود.

در ایران، قوانین حریم خصوصی مشابه GDPR نیستند، اما رعایت اصول پایه، اعتماد کاربران را افزایش می‌دهد. اگر با GDPR و تأثیر آن بر وب‌سایت‌های ایرانی آشنا شده باشید، این موضوع را به‌عنوان یک الزام می‌شناسید.

اتصال RUM به Performance Budget

Performance Budget یک محدودیت قابل اندازه‌گیری است که تیم توسعه را ملزم می‌کند تا عملکرد سایت را در سطح مشخصی نگه دارد. RUM، ابزار اندازه‌گیری این بودجه است. بدون RUM، Performance Budget فقط یک عدد در سند است؛ با RUM، یک شاخص قابل پایش.

نمونه‌ای از Performance Budget برای یک سایت وردپرسی:

معیار	هدف	هشدار
LCP (صدک ۷۵)	≤ 2.5s	> 3.0s
INP (صدک ۷۵)	≤ 200ms	> 300ms
CLS (صدک ۷۵)	≤ 0.1	> 0.15
TTFB (صدک ۷۵)	≤ 800ms	> 1.2s

این بودجه باید در چند جا اعمال شود. اول، در CI/CD: هر Commit باید تست‌های عملکردی را اجرا کند و در صورت نقض بودجه، Build را متوقف کند. دوم، در داشبورد RUM: نمودارهای زنده باید نشان دهند که آیا سایت در محدوده بودجه است. سوم، در جلسات تیم: داده‌های RUM باید در جلسات هفتگی بررسی شوند.

اگر با Performance Budget در وردپرس و ضرورت آن آشنا شده باشید، این اتصال را به‌عنوان یک اصل مدیریتی می‌شناسید. RUM بدون Performance Budget، فقط داده است؛ Performance Budget بدون RUM، فقط آرزو.

اشتباهات رایج در پیاده‌سازی RUM

اشتباه اول: استفاده از localStorage یا sessionStorage برای ذخیره داده‌ها. این روش، حجم داده را افزایش می‌دهد و ممکن است با سیاست‌های حریم خصوصی تداخل داشته باشد. راه‌حل: ارسال مستقیم داده‌ها با sendBeacon.

اشتباه دوم: نادیده گرفتن sendBeacon و استفاده از fetch معمولی. fetch ممکن است در زمان beforeunload لغو شود، در حالی که sendBeacon تضمین می‌کند که داده‌ها ارسال شوند، حتی اگر کاربر صفحه را ببندد.

اشتباه سوم: ارسال داده‌ها به‌صورت جداگانه برای هر متریک. این کار، تعداد درخواست‌های شبکه را افزایش می‌دهد و بر عملکرد اثر می‌گذارد. راه‌حل: Batch کردن داده‌ها و ارسال یک‌باره.

اشتباه چهارم: عدم فیلتر کردن داده‌های تکراری. اگر کاربر یک صفحه را چند بار بارگذاری کند، داده‌های تکراری جمع‌آوری می‌شوند و تحلیل را مختل می‌کنند. راه‌حل: استفاده از metric.id برای Deduplication.

اشتباه پنجم: نادیده گرفتن Sample Rate. اگر سایت ترافیک بالایی دارد، ارسال داده برای تمام کاربران می‌تواند بار سرور را افزایش دهد. راه‌حل: استفاده از Sample Rate (مثلاً ۱۰٪) و تحلیل داده‌های نمونه.

اشتباه ششم: عدم همبستگی با داده‌های سمت سرور. RUM فقط تجربه کاربر را نشان می‌دهد، اما دلیل را نشان نمی‌دهد. برای یافتن دلیل، باید RUM را با داده‌های سرور (مثل New Relic یا Query Monitor) ترکیب کرد. اگر با عملکرد بلاک‌های وردپرس و دلایل کندی آشنا شده باشید، این همبستگی را به‌عنوان یک ضرورت می‌شناسید.

اشتباه هفتم: نادیده گرفتن کاربران بدون JavaScript. اگر سایت شما به JavaScript وابسته باشد و کاربر آن را غیرفعال کرده باشد، داده‌های RUM ناقص خواهند بود. راه‌حل: استفاده از Server-Timing Header برای ارسال داده‌های سمت سرور به RUM.

اشتباه هشتم: عدم مستندسازی. اگر داده‌های RUM جمع‌آوری می‌شوند اما مستند نمی‌شوند، تیم توسعه نمی‌داند که چه چیزی اندازه‌گیری می‌شود. راه‌حل: مستندسازی متریک‌ها، اهداف، و روش‌های تحلیل.

پرسش‌های پرتکرار درباره RUM وردپرس

RUM چیست و چرا برای وردپرس حیاتی است؟

RUM (Real User Monitoring) مجموعه‌ای از تکنیک‌ها برای جمع‌آوری داده‌های عملکردی از مرورگر کاربران واقعی است. برای وردپرس، RUM حیاتی است چون گوگل بر پایه داده‌های میدانی (CrUX) رتبه‌بندی می‌کند، نه داده‌های آزمایشگاهی. بدون RUM، بهینه‌سازی سایت بر پایه فرضیات است، نه واقعیت.

تفاوت RUM و Synthetic Monitoring چیست؟

Synthetic Monitoring از یک دستگاه شبیه‌سازی‌شده استفاده می‌کند و داده‌ها را در شرایط کنترل‌شده جمع‌آوری می‌نماید. RUM از دستگاه‌های واقعی کاربران استفاده می‌کند و تنوع گسترده‌ای از تجربه‌ها را ثبت می‌کند. Synthetic برای پایش پیشگیرانه و RUM برای تحلیل تجربه واقعی استفاده می‌شود.

چگونه RUM را در وردپرس پیاده‌سازی کنم؟

سه گام اصلی: اول، کتابخانه web-vitals را با npm نصب کنید و در فرانت‌اند با defer بارگذاری نمایید. دوم، یک Endpoint REST با register_rest_route بسازید که داده‌ها را دریافت و ذخیره کند. سوم، در اسکریپت، داده‌ها را با sendBeacon به Endpoint ارسال کنید. برای ادغام با GA4، از gtag استفاده کنید.

آیا RUM بر سرعت سایت تأثیر می‌گذارد؟

اگر به‌درستی پیاده‌سازی شود، تأثیر RUM کمتر از ۱٪ است. کتابخانه web-vitals حدود ۲ کیلوبایت حجم دارد و با sendBeacon ارسال می‌شود که بر رندر صفحه اثر نمی‌گذارد. اما اگر Sample Rate بالا باشد یا داده‌ها به‌صورت جداگانه ارسال شوند، می‌تواند بار سرور را افزایش دهد.

آیا RUM با GDPR سازگار است؟

بله، اگر اصول حریم خصوصی رعایت شود: حداقل‌سازی داده، Anonymization IP، شفافیت در سیاست حریم خصوصی، و در صورت نیاز، دریافت رضایت کاربر. اگر با GDPR و تأثیر آن بر وب‌سایت‌های ایرانی آشنا شده باشید، این الزامات برای شما آشناست.

چگونه داده‌های RUM را با داده‌های سرور همبسته کنم؟

از Server-Timing Header استفاده کنید تا زمان‌های سمت سرور به کلاینت ارسال شوند. کتابخانه web-vitals می‌تواند این داده‌ها را با داده‌های کلاینت ترکیب کند و تصویری کامل از تجربه کاربر ارائه دهد. همچنین می‌توانید داده‌های RUM را با داده‌های New Relic یا Query Monitor ترکیب کنید.

چند نمونه داده برای RUM کافی است؟

حداقل ۱۰۰ نمونه برای تحلیل پایه و ۱۰۰۰ نمونه برای تحلیل دقیق. اگر سایت ترافیک بالایی دارد، Sample Rate ۱۰٪ کافی است. اگر ترافیک پایین است، باید ۱۰۰٪ نمونه‌ها جمع‌آوری شوند.

آیا RUM با کش CDN سازگار است؟

بله، RUM مستقل از کش است چون در مرورگر کاربر اجرا می‌شود. اگر با Edge Caching و آینده کش در وردپرس آشنا شده باشید، می‌دانید که RUM می‌تواند نشان دهد که کش لبه چقدر بر تجربه کاربر اثر می‌گذارد.

چگونه RUM را در CI/CD ادغام کنم؟

RUM به‌طور معمول در CI/CD ادغام نمی‌شود چون داده‌های آن از کاربران واقعی می‌آید. اما می‌توانید RUM را با Performance Budget ترکیب کنید: اگر داده‌های RUM از بودجه تعیین‌شده عبور کنند، یک هشدار به تیم ارسال شود. اگر با Performance Budget در وردپرس آشنا شده باشید، این اتصال را به‌عنوان یک رویکرد مؤثر می‌شناسید.

آیا RUM برای سایت‌های کوچک هم ضروری است؟

بله، حتی برای سایت‌های کوچک. RUM نشان می‌دهد که کاربران واقعی چه تجربه‌ای دارند، حتی اگر تعداد آن‌ها کم باشد. این داده‌ها می‌توانند به کشف مشکلات پنهان کمک کنند که با ابزارهای آزمایشگاهی قابل مشاهده نیستند.

نگاه فنی سطح ارشد

از منظر معماری نرم‌افزار، RUM یک سیستم Distributed Observability است که در آن، داده‌ها از هزاران یا میلیون‌ها نقطه انتهایی جمع‌آوری، نرمال‌سازی، و تحلیل می‌شوند. چالش اصلی این معماری، Cardinality است: هر ترکیب منحصربه‌فرد از دستگاه، مرورگر، شبکه، جغرافیا و URL، یک Dimension جدید ایجاد می‌کند. اگر تعداد Dimensionها بالا باشد، حجم داده به‌صورت نمایی افزایش می‌یابد. راه‌حل استاندارد، Sketching Algorithms مثل HyperLogLog و t-digest است که داده‌ها را با دقت تقریبی اما حجم کم ذخیره می‌کنند. گوگل در CrUX از همین تکنیک‌ها استفاده می‌کند تا داده‌های میلیون‌ها کاربر را در چند صد کیلوبایت خلاصه کند.

چالش دوم، Attribution در سیستم‌های توزیع‌شده است. وقتی یک کاربر تجربه کندی را گزارش می‌دهد، این کندی می‌تواند ناشی از ده‌ها عامل باشد: کندی سرور، کندی CDN، کندی DNS، کندی ISP، کندی دستگاه، یا ترکیبی از آن‌ها. راه‌حل، استفاده از Distributed Tracing است که یک Trace ID منحصربه‌فرد از مرورگر تا سرور ایجاد می‌کند و تمام لایه‌ها را به هم مرتبط می‌سازد. استاندارد OpenTelemetry، چارچوب مشترکی برای این رویکرد فراهم کرده و ابزارهایی مثل New Relic و Datadog از آن پشتیبانی می‌کنند. اگر با پروفایلینگ وردپرس با New Relic آشنا شده باشید، این یکپارچگی را به‌عنوان یک مزیت می‌شناسید.

چالش سوم، Sampling Bias است. اگر داده‌ها فقط از بخشی از کاربران جمع‌آوری شوند، ممکن است تصویر ناقصی ارائه دهند. مثلاً اگر Sample Rate بر اساس نوع دستگاه متفاوت باشد، کاربران موبایل ممکن است کمتر نمایندگی شوند. راه‌حل، Stratified Sampling است که نمونه‌ها را به‌صورت متوازن از تمام گروه‌ها انتخاب می‌کند. این تکنیک، در سیستم‌های RUM پیشرفته مثل SpeedCurve و Calibre استفاده می‌شود.

در نهایت، RUM یک Investment in Observability است: هزینه اولیه پیاده‌سازی، اما سود بلندمدت در قالب تصمیمات دقیق‌تر، بهینه‌سازی مؤثرتر، و تجربه کاربری بهتر. تیم‌هایی که RUM را از ابتدا در معماری خود لحاظ می‌کنند، در فضای رقابتی وب، مزیت محسوسی نسبت به رقبا خواهند داشت. اگر با طراحی معماری وب مقیاس‌پذیر آشنا شده باشید، این رویکرد را به‌عنوان یک گام بلوغ می‌شناسید.

اگر این تجربه را در یک پروژه واقعی داشته‌اید، جالب است بدانید کدام بخش از RUM بیشترین بینش را برای شما ایجاد کرد. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 📊