دادهٔ واقعی و آزمایشگاهی هرکدام چه تصمیمی را کمک می‌کنند؟
آزمون آزمایشگاهی موبایل یک دستگاه و شبکهٔ انتخابی را بازسازی می‌کند تا اثر تغییر قابل‌بررسی باشد. دادهٔ کاربران واقعی، بازدیدها با دستگاه، اتصال، محل و تعامل متفاوت را نشان می‌دهد. هر دو لازم‌اند. پیش از مقایسه، آدرس، دامنهٔ گزارش، دستهٔ دستگاه و بازهٔ زمانی را ثبت کنید.
دامنهٔ گزارش PageSpeed را درست بخوانید
بخش دادهٔ واقعی PageSpeed از Chrome UX Report در بازهٔ شناور ۲۸روزه استفاده می‌کند. ممکن است نتیجهٔ همان URL یا در نبود دادهٔ کافی، نتیجهٔ کل مبدأ سایت را نمایش دهد. نتیجهٔ مبدأ شامل صفحه‌های واجد شرایط دیگر هم هست؛ آن را به یک راهنما نسبت ندهید. Search Console نیز آدرس‌های با تجربهٔ مشابه را گروه‌بندی می‌کند و سنجش مستقل تک‌تک صفحات نیست.
CrUX نمایندهٔ کاربران و بازدیدهای واجد شرایط Chrome است، نه تمام مرورگرها و همهٔ بازدیدکنندگان. گوگل یک حداقل عمومی و قطعیِ بازدید روزانه برای ورود به این داده منتشر نکرده است. «داده موجود نیست» ثابت نمی‌کند صفحه سریع، کند یا غیرقابل‌ایندکس است. سنجش RUM خود سایت می‌تواند پوشش را تکمیل کند، به شرط ثبت محدودیت نمونه‌گیری و پیاده‌سازی.
صدک ۷۵ را کنار میانگین ببینید
- LCP خوب: حداکثر ۲٫۵ ثانیه برای نمایش محتوای اصلی قابل‌مشاهده.
- INP خوب: حداکثر ۲۰۰ میلی‌ثانیه برای پاسخ‌گویی به تعامل.
- CLS خوب: حداکثر ۰٫۱ برای جابه‌جایی غیرمنتظرهٔ صفحه.
برای نمونهٔ آموزشیِ هشت LCP مرتب‌شدهٔ ۱٫۰، ۱٫۱، ۱٫۳، ۱٫۵، ۱٫۸، ۲٫۴، ۴٫۰ و ۵٫۰ ثانیه، صدک ۷۵ با روش رتبهٔ نزدیک برابر مقدار ششم یعنی ۲٫۴ است. شش بازدید از هشت بازدید زیر آستانه‌اند، اما دو نفر تجربهٔ کندتری دارند. تجمیع واقعی ممکن است روش محاسبهٔ صدک دیگری داشته باشد و نمونهٔ کم نیز عدم‌قطعیت دارد. دستگاه‌ها و گروه صفحات را ثابت نگه دارید و بازدیدهای ناهمگون را در یک میانگین خوش‌بینانه مخلوط نکنید.
یک پروندهٔ سنجش قابل‌استفاده بسازید
- گروه صفحه مثل خانه، محصول یا راهنما را انتخاب و موبایل را از دسکتاپ جدا کنید.
- URL یا مبدأ بودن دادهٔ CrUX و بازهٔ ۲۸روزه را ثبت کنید.
- آزمون آزمایشگاهی را با آدرس، دستگاه و شرایط کش یکسان تکرار کنید؛ همهٔ نتایج و میانه را نگه دارید.
- زمان انتشار و اصلاح واقعی را ثبت و خطا، جابه‌جایی و کارکرد را هم کنترل کنید.
- با ورود بازدیدهای جدید، روند دادهٔ واقعی را ببینید؛ پنجرهٔ شناور فوراً به آزمایش تمیزِ قبل و بعد تبدیل نمی‌شود.
در ۱۰ اکتبر ۲۰۲۶، گزارش آزمایشگاهی خانهٔ ServerNet، LCP برابر ۲٫۷۶۲ ثانیه داشت و بخش واقعیِ مبدأ موبایل ۲٫۶ ثانیه را نشان می‌داد. این‌ها جامعه و بازهٔ متفاوت‌اند، نه تناقض. گزارش تاریخ‌دار مثال مشخصی است. بهبود آزمایش بعدی، فوراً به معنی بهبود تجربهٔ واقعی یا رتبهٔ گوگل نیست.
RUM اختصاصی را با دقت جمع‌آوری کنید
کتابخانهٔ رسمی web-vitals callbackهایی مثل onLCP، onINP و onCLS دارد. دستور ادغام و پشتیبانی API نسخهٔ مورداستفاده را بررسی کنید. بازدید بدون تعاملِ اندازه‌گیری‌شده ممکن است INP نداشته باشد؛ مقدار غایب یا API پشتیبانی‌نشده را صفر فرض نکنید.
تجمیع را بر پایهٔ قالب صفحه، دستهٔ کلی دستگاه و مقدار معیار طراحی کنید. URL کامل دارای Query، شناسهٔ حساب، محتوای فرم و مقادیر ورود را ارسال نکنید. رضایت، مدت نگه‌داری، نمونه‌گیری و حجم انتقال را مطابق سیاست سایت تعیین و نمونه‌های غایب را ثبت کنید. صرفاً برای ساخت نمودار، سرویس جمع‌آوری شخص ثالث اضافه نکنید. TBT آزمایشگاهی برای بررسی کار نخ اصلی مفید است اما جای INP واقعی را نمی‌گیرد.
نتیجه را به یک اصلاح مشخص تبدیل کنید
برای LCP، زمان پاسخ سرور، کشف منبع، انتقال و تأخیر نمایش از جمله فونت متن را بررسی کنید. برای INP، انتظار ورودی، پردازش رویداد و نمایش را جدا کنید. برای CLS، عنصر جابه‌جاشونده را بیابید و فضای تصویر و بلوک پویا را از قبل رزرو کنید. نمونه‌های هم‌شرایط را مقایسه کنید؛ درصد اختلاف مجاز و عمومی میان دادهٔ واقعی و آزمایشگاهی وجود ندارد.
از راهنمای تشخیص کندی برای یافتن انتظار و راهنمای کش برای تفکیک بازدید سرد و گرم استفاده کنید. منابع: آستانه‌های Core Web Vitals، روش‌شناسی CrUX و منابع دادهٔ PageSpeed.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!