تست سرعت سایت: تفاوت PageSpeed، Lighthouse و CrUX
چرا نتایج تست سرعت سایت با هم نمیخوانند؟ آنچه PageSpeed، Lighthouse و CrUX میسنجند، تفاوت داده میدانی و آزمایشگاهی و ترتیب درست خواندن.
نوشته Roozbeh Nazari · CEO
هر کسی که تست سرعت سایت انجام میدهد همان سردرگمی را تجربه میکند: PageSpeed Insights ۶۲ میدهد، Lighthouse ۹۱ میدهد، گزارش Core Web Vitals در Search Console میگوید «نیازمند بهبود» و هر سه به نظر میرسد یک صفحه را سنجیدهاند. این ناسازگاری نیست؛ سه ابزار سه چیز متفاوت را میسنجند و پاسخ هر یک به پرسش متفاوتی تعلق دارد. این مقاله توضیح میدهد PageSpeed Insights، Lighthouse و گزارش تجربه کاربری Chrome (CrUX) چه چیزی را، از چه کسی و در چه شرایطی میسنجند؛ سپس میگوید یک تست سرعت سایت باید با چه ترتیبی خوانده شود و کدام عدد میتواند مبنای کدام تصمیم باشد. هدف بهبود سرعتی است که کاربر واقعاً تجربه میکند، نه «بالا بردن امتیاز».
داده آزمایشگاهی در برابر داده میدانی
تمایز پایه این است: داده آزمایشگاهی (lab) شبیهسازی بارگذاری است که همین حالا روی یک دستگاه مجازی واحد با شرایط شبکه ثابت اجرا میشود. داده میدانی (field) مجموع تجربهای است که کاربران واقعی با دستگاهها و اتصالهای واقعی در دورهای گذشته داشتهاند. مستندات PageSpeed Insights از Google این مرز را روشن میکشد: داده میدانی تجربههای FCP، INP، LCP و CLS کاربران را به صورت گذشتهنگر گرد میآورد؛ داده آزمایشگاهی شبیهسازی روی یک دستگاه استاندارد است و به همین دلیل این دو میتوانند نتیجه متفاوتی بدهند. داده آزمایشگاهی تکرارپذیر و مناسب اشکالزدایی است؛ داده میدانی واقعیت کاربر است و همان سمتی است که Google در ارزیابی تجربه صفحه به کار میبرد. اولین پرسش هنگام خواندن تست سرعت سایت باید این باشد: عددی که به آن نگاه میکنم شبیهسازی است یا کاربر؟
سه ابزار چه چیزی را میسنجند
Lighthouse ابزار ممیزی متنبازی است که داخل Chrome تعبیه شده؛ صفحه را از صفر بارگذاری میکند و در کنار عملکرد در دستههایی مثل دسترسپذیری و سئو هم امتیاز تولید میکند. امتیاز عملکردی که تولید میکند کاملاً داده آزمایشگاهی است و بر حسب دستگاه، افزونهها و شبکهای که روی آن اجرا میکنید تغییر میکند؛ دو سنجش پشت سر هم روی یک صفحه میتواند متفاوت درآید. CrUX مجموعه دادهای است که از تجربه واقعی کاربران Chrome گردآوری شده؛ فقط برای مبدأها و صفحههای عمومی با ترافیک کافی داده دارد و برای همین به صفحههای تازه یا کمترافیک میگوید «داده کافی نیست». PageSpeed Insights هر دو را در یک صفحه نشان میدهد: بالا داده میدانی آمده از CrUX (اگر باشد)، پایین نتیجه آزمایشگاهی Lighthouse که همان لحظه اجرا شده. یعنی بخش بالای PageSpeed بر همان منبعی تکیه دارد که گزارش Core Web Vitals در Search Console؛ بخش پایین خود Lighthouse است. دلیل این که سه ابزار «برای یک صفحه سه امتیاز متفاوت» میدهند همین است: در واقع دو منبع داده و دو قالب خلاصه متفاوت وجود دارد.
آستانههای Core Web Vitals و ترتیب درست خواندن
سه معیار اصلی که در داده میدانی نگاه میشود Core Web Vitals است. بر اساس تعریف فعلی web.dev، برای تجربه خوب LCP باید در ۲٫۵ ثانیه باشد، INP در ۲۰۰ میلیثانیه یا کمتر بماند و CLS از ۰٫۱ فراتر نرود؛ ارزیابی روی صدک ۷۵ کاربران انجام میشود. ترتیب درست خواندن چنین است: اول به داده میدانی نگاه کنید؛ اگر صفحه در CrUX آستانهها را رد میکند، حتی اگر امتیاز آزمایشگاهی پایین باشد مشکل کاربر وجود ندارد و اولویت بهبود در صفحه دیگری است. اگر داده میدانی آستانه را رد نمیکند ببینید در کدام معیار مانده؛ اگر مشکل LCP است دنبال تصویر بزرگ، زمان پاسخ سرور یا منبع مسدودکننده رندر بگردید؛ اگر INP است اسکریپتهایی که رشته اصلی را مشغول میکنند؛ اگر CLS است تصاویر بدون ابعاد و بلوکهای دیر بارشونده. تنها در این نقطه به Lighthouse بروید: گزارش آزمایشگاهی خط به خط نشان میدهد چه چیزی معیاری را که داده میدانی به آن اشاره کرده خراب میکند. تیمهایی که برعکس، یعنی از امتیاز Lighthouse شروع میکنند، میتوانند هفتهها صرف رفع مشکلاتی کنند که کاربران تجربه نمیکنند. لایه سومی هم هست: گزارش Core Web Vitals در Search Console همان داده CrUX را در گروههای صفحه نشان میدهد و در یک نگاه آشکار میکند کدام قالب (صفحه محصول، پست وبلاگ، دسته) مشکل دارد؛ نگاه کردن به این گزارش پیش از تست تکتک صفحهها کار را به قالب درست هدایت میکند. در خدمت سئوی فنی ما ممیزی سرعت با همین ترتیب انجام میشود و در گزارش هر یافته با برچسب «میدانی» یا «آزمایشگاهی» جدا میشود.
نکتههای اضافی برای سایتهای چندزبانه و موبایل
داده CrUX بر حسب نوع دستگاه تفکیک میشود و در بیشتر سایتهای ترکیه بخش موبایل بهوضوح بدتر از دسکتاپ است؛ خواندن تست سرعت سایت فقط روی دسکتاپ یعنی نادیده گرفتن بخش بزرگی از کاربران. در سایتهای چندزبانه دام دومی هست: CrUX داده را در سطح مبدأ (origin) و در سطح صفحه میدهد؛ صفحههای عربی و فارسی به دلیل فایلهای فونت جداگانه و چیدمان راستبهچپ میتوانند LCP و CLS متفاوتی از صفحههای ترکی تولید کنند، اما چون کمترافیکاند شاید در سطح صفحه دادهای نشان داده نشود. در این حالت داده سطح مبدأ وزن صفحههای ترکی را حمل میکند و مشکل پنهان میماند. راهحل، پایش جداگانه گروههای صفحه بر اساس زبان در گزارش Core Web Vitals در Search Console و تکرار منظم سنجش آزمایشگاهی با همان پروفایل دستگاه برای زبانهایی است که داده ندارند. مقاله Core Web Vitals برای بیمار بینالمللی ما این تمایز را با مثال سایتهای کلینیک بررسی میکند.
کدام عدد مبنای کدام تصمیم است
عددی که وارد گزارش مدیریتی میشود باید داده میدانی باشد: مثلاً «درصد صفحههایی که LCP آنها در موبایل از ۲٫۵ ثانیه فراتر میرود». عددی که وارد وظیفه توسعهدهنده میشود داده آزمایشگاهی است: مثلاً «۳ اسکریپت مسدودکننده رندر در این صفحه». اگر آژانس یا برنامهنویس با عبارت «امتیاز PageSpeed را به ۹۰ رساندیم» از شما تأیید میخواهد بپرسید از کدام بخش حرف میزند؛ امتیاز آزمایشگاهی میتواند در یک روز تغییر کند، اما داده میدانی در پنجره ۲۸ روزه انباشته میشود و بهبود تنها چند هفته بعد دیده میشود. این تأخیر عیب نیست، بهای تکیه اندازهگیری بر کاربر واقعی است. تیمهایی که تست سرعت سایت را نه به عنوان مسابقه امتیاز بلکه به عنوان ابزار تشخیص دولایه میخوانند، سرعتی را که هم کاربر و هم موتور جستوجو میبینند بهبود میدهند؛ تیمهایی که امتیاز را بالا میبرند و کاربر را همانجا رها میکنند فقط اسکرینشات تولید میکنند.
پروتکل پنجدقیقهای تست سرعت سایت
تشخیص سریع برای یک صفحه چنین انجام میشود. آدرس صفحه را در PageSpeed Insights وارد کنید و اول به بخش بالای تب موبایل نگاه کنید: اگر داده میدانی هست، وضعیت قبول یا رد سه معیار Core Web Vitals را یادداشت کنید؛ اگر نیست به داده سطح مبدأ بروید و در گزارش قید کنید که این میانگین سایت است نه صفحه. سپس از ممیزیهای Lighthouse در بخش پایین فقط آنهایی را بخوانید که به معیار ردشده تعلق دارند؛ بزرگترین عنصر محتوا و زمان پاسخ سرور برای LCP، وظایف طولانی برای INP، عناصر بدون ابعاد برای CLS. یافتهها را نه با عبارت «امتیاز را بالا ببر» بلکه با نام معیار و عنصر به توسعهدهنده منتقل کنید. پس از انتشار اصلاح، Lighthouse را همان روز و داده میدانی را چهار هفته بعد دوباره بخوانید؛ بهبود هر دو دستاوردی واقعی است، بهبود فقط اولی تغییری است که هنوز به کاربر نرسیده است.