بیاموزید که چرا ابزارهایی که معیارهای Core Web Vitals را رصد می‌کنند ممکن است اعداد مختلفی را گزارش کنند و چگونه این تفاوت‌ها را تفسیر کنید.
گوگل تعدادی ابزار برای کمک به صاحبان سایت برای نظارت بر امتیازات Core Web Vitals خود ارائه می دهد. این ابزارها به دو دسته اصلی تقسیم می شوند:
- ابزارهایی که داده‌های آزمایشگاهی را گزارش می‌کنند - داده‌هایی که در یک محیط کنترل‌شده با تنظیمات از پیش تعریف‌شده دستگاه و شبکه جمع‌آوری شده‌اند.
- ابزارهایی که داده های میدانی را گزارش می دهند — داده هایی که از کاربران واقعی بازدیدکننده از سایت شما جمع آوری شده اند.
مشکل این است که گاهی اوقات داده های گزارش شده توسط ابزارهای آزمایشگاهی می توانند کمی متفاوت از داده های گزارش شده توسط ابزارهای میدانی باشند! داده های آزمایشگاهی شما ممکن است نشان دهنده عملکرد عالی سایت شما باشد، اما داده های میدانی شما نشان می دهد که نیاز به بهبود دارد. از طرف دیگر، داده های میدانی شما ممکن است نشان دهد که همه صفحات شما خوب هستند، اما داده های آزمایشگاهی شما ممکن است امتیاز بسیار پایینی را گزارش کنند.
مثال واقعی زیر از گزارش PageSpeed Insights از web.dev نشان می‌دهد که در برخی موارد داده‌های آزمایشگاهی و میدانی می‌توانند در تمام معیارهای Core Web Vitals متفاوت باشند:
تفاوت بین ابزارها منبع قابل درک سردرگمی برای توسعه دهندگان است. این پست دلایل اصلی وجود این تفاوت‌ها را توضیح می‌دهد - با مثال‌های خاصی که هر یک از معیارهای Core Web Vitals را پوشش می‌دهند - و وقتی تفاوت‌هایی را در صفحات خود پیدا کردید چه کاری باید انجام دهید.
داده های آزمایشگاهی در مقابل داده های میدانی
برای درک اینکه چرا ابزارهای آزمایشگاهی و میدانی ممکن است مقادیر متفاوتی را گزارش کنند - حتی برای یک صفحه وب دقیقاً - باید تفاوت بین داده های آزمایشگاهی و میدانی را درک کنید.
داده های آزمایشگاهی
داده های آزمایشگاهی با بارگذاری یک صفحه وب در یک محیط کنترل شده با مجموعه ای از شرایط شبکه و دستگاه از پیش تعریف شده تعیین می شود. این شرایط به عنوان محیط آزمایشگاهی شناخته می شود که گاهی اوقات به عنوان محیط مصنوعی نیز شناخته می شود.
ابزارهای کروم که داده‌های آزمایشگاهی را گزارش می‌کنند معمولاً Lighthouse را اجرا می‌کنند.
هدف از آزمایش آزمایشگاهی این است که تا آنجا که می توانید عوامل زیادی را کنترل کنید، بنابراین نتایج (تا حد امکان) از اجرا تا اجرا سازگار و قابل تکرار باشند.
داده های میدانی
داده‌های میدانی با نظارت بر همه کاربرانی که از یک صفحه بازدید می‌کنند و اندازه‌گیری مجموعه معینی از معیارهای عملکرد برای هر یک از تجربیات فردی آن کاربران تعیین می‌شود. از آنجایی که داده های میدانی بر اساس بازدیدهای کاربر واقعی است، دستگاه های واقعی، شرایط شبکه و مکان های جغرافیایی کاربران شما را منعکس می کند.
داده های میدانی معمولاً به عنوان داده های نظارت بر کاربر واقعی (RUM) نیز شناخته می شوند. این دو عبارت قابل تعویض هستند.
ابزارهای Chrome که داده‌های میدانی را گزارش می‌کنند، معمولاً آن داده‌ها را از گزارش تجربه کاربر Chrome (CrUX) دریافت می‌کنند. همچنین برای صاحبان سایت رایج است (و توصیه می‌شود) که خودشان داده‌های میدانی را جمع‌آوری کنند، زیرا می‌تواند بینش عملی‌تری نسبت به استفاده از CrUX به تنهایی ارائه دهد.
مهمترین چیزی که باید در مورد داده های میدانی درک کرد این است که این فقط یک عدد نیست، بلکه توزیعی از اعداد است. یعنی برای برخی از افرادی که از سایت شما بازدید می کنند، ممکن است خیلی سریع بارگذاری شود، در حالی که برای برخی دیگر ممکن است بسیار کند بارگذاری شود. داده های میدانی برای سایت شما مجموعه کاملی از تمام داده های عملکرد جمع آوری شده از کاربران شما است.
به عنوان مثال، گزارش‌های CrUX توزیع معیارهای عملکرد را از کاربران واقعی Chrome در یک دوره 28 روزه نشان می‌دهد. اگر تقریباً به هر گزارش CrUX نگاه کنید، می بینید که برخی از کاربرانی که از یک سایت بازدید می کنند ممکن است تجربه بسیار خوبی داشته باشند در حالی که برخی دیگر ممکن است تجربه بسیار ضعیفی داشته باشند.
اگر ابزاری یک عدد واحد را برای یک متریک معین گزارش کند، به طور کلی نشان دهنده یک نقطه خاص در توزیع است. ابزارهایی که امتیازات فیلد Core Web Vitals را گزارش می‌کنند این کار را با استفاده از صدک 75 انجام می‌دهند.
با نگاهی به LCP از داده های میدانی در تصویر بالا، می توانید توزیعی را مشاهده کنید که در آن:
- 88٪ از بازدیدها LCP 2.5 ثانیه یا کمتر (خوب) را مشاهده کردند.
- 8٪ از بازدیدها LCP بین 2.5 تا 4 ثانیه مشاهده کردند (نیاز به بهبود دارد).
- 4٪ از بازدیدها LCP بیش از 4 ثانیه (ضعیف) مشاهده کردند.
در صدک 75، LCP 1.8 ثانیه بود:
داده های آزمایشگاهی از همان صفحه مقدار LCP 3.0 ثانیه را نشان می دهد. در حالی که این مقدار بیشتر از 1.8 ثانیه نشان داده شده در داده های میدانی است، هنوز یک مقدار LCP معتبر برای این صفحه است—این یکی از مقادیر زیادی است که توزیع کامل تجربیات بار را تشکیل می دهد.
چرا داده های آزمایشگاهی و میدانی متفاوت هستند
همانطور که بخش فوق توضیح می دهد، داده های آزمایشگاهی و داده های میدانی در واقع چیزهای بسیار متفاوتی را اندازه گیری می کنند.
داده های میدانی شامل طیف گسترده ای از شرایط شبکه و دستگاه و همچنین انواع بی شماری از رفتارهای کاربر است. همچنین شامل هر عامل دیگری است که بر تجربه کاربر تأثیر می‌گذارد، مانند بهینه‌سازی مرورگر مانند حافظه پنهان عقب و جلو (bfcache)، یا بهینه‌سازی پلتفرم مانند حافظه پنهان AMP .
در مقابل، داده های آزمایشگاهی عمداً تعداد متغیرهای درگیر را محدود می کند. یک آزمایش آزمایشگاهی شامل موارد زیر است:
- یک دستگاه …
- متصل به یک شبکه …
- از یک موقعیت جغرافیایی واحد اجرا شود.
مشخصات هر آزمایش آزمایشگاهی ممکن است به دقت نشان دهنده صدک 75 از داده های میدانی برای یک صفحه یا سایت معین باشد یا نباشد.
محیط کنترل‌شده آزمایشگاه هنگام اشکال‌زدایی مشکلات یا آزمایش ویژگی‌ها قبل از استقرار در تولید مفید است، اما وقتی این عوامل را کنترل می‌کنید، صراحتاً واریانسی را که در دنیای واقعی در تمام انواع شبکه‌ها، قابلیت‌های دستگاه یا دستگاه‌ها مشاهده می‌کنید، نشان نمی‌دهید. موقعیت های جغرافیایی همچنین معمولاً تأثیر عملکرد رفتار کاربر واقعی مانند پیمایش، انتخاب متن یا ضربه زدن روی عناصر صفحه را نمی‌بینید.
علاوه بر قطع ارتباط احتمالی بین شرایط آزمایشگاهی و شرایط اکثر کاربران دنیای واقعی، تعدادی تفاوت ظریف‌تر نیز وجود دارد که درک آنها برای استفاده بیشتر از داده‌های آزمایشگاهی و میدانی مهم است. به عنوان هر تفاوتی که ممکن است پیدا کنید.
چند بخش بعدی به تفصیل می‌پردازد و شایع‌ترین دلایلی را که ممکن است بین داده‌های آزمایشگاهی و داده‌های میدانی برای هر یک از معیارهای Core Web Vitals تفاوت وجود داشته باشد برجسته می‌کند:
LCP
عناصر مختلف LCP
عنصر LCP شناسایی شده در آزمایش آزمایشگاهی ممکن است همان عنصر LCP را که کاربران هنگام بازدید از صفحه شما می بینند نباشد.
اگر گزارش Lighthouse را برای یک صفحه مشخص اجرا کنید، هر بار همان عنصر LCP را برمی گرداند. اما اگر به داده‌های فیلد مربوط به یک صفحه نگاه کنید، معمولاً عناصر مختلف LCP را خواهید یافت که به تعدادی از شرایط خاص برای هر بازدید از صفحه بستگی دارد.
به عنوان مثال، عوامل زیر می توانند در تعیین یک عنصر LCP متفاوت برای یک صفحه نقش داشته باشند:
- اندازه‌های مختلف صفحه‌نمایش دستگاه باعث می‌شود که عناصر متفاوتی در نمای مشاهده شوند.
- اگر کاربر وارد سیستم شده باشد، یا اگر محتوای شخصی‌شده به نحوی نشان داده شود، عنصر LCP می‌تواند از کاربری به کاربر دیگر بسیار متفاوت باشد.
- مشابه نکته قبلی، اگر یک تست A/B در صفحه اجرا شود، می‌تواند منجر به نمایش عناصر بسیار متفاوت شود.
- مجموعه فونت های نصب شده بر روی سیستم کاربر می تواند بر اندازه متن در صفحه تأثیر بگذارد (و در نتیجه کدام عنصر عنصر LCP است).
- آزمایش‌های آزمایشگاهی معمولاً بر روی URL "پایه" صفحه اجرا می‌شوند—بدون هیچ گونه پارامتر پرس و جو یا قطعات هش اضافه شده. اما در دنیای واقعی، کاربران اغلب URL های حاوی شناسه قطعه یا قطعه متن را به اشتراک می گذارند، بنابراین عنصر LCP ممکن است در واقع از وسط یا پایین صفحه باشد (به جای "بالای تا").
از آنجایی که LCP در فیلد به عنوان صدک 75 تمام بازدیدهای کاربر از یک صفحه محاسبه می شود، اگر درصد زیادی از آن کاربران یک عنصر LCP داشته باشند که خیلی سریع بارگیری می شود - برای مثال یک پاراگراف از متن ارائه شده با یک فونت سیستمی - حتی اگر برخی از این کاربران یک تصویر بزرگ و کم بارگذاری را به عنوان عنصر LCP خود داشتند، اگر این اتفاق برای کمتر از 25 درصد بازدیدکنندگان رخ دهد، ممکن است بر امتیاز آن صفحه تأثیری نداشته باشد.
متناوبا، برعکس می تواند صادق باشد. یک آزمایش آزمایشگاهی ممکن است بلوکی از متن را به عنوان عنصر LCP شناسایی کند، زیرا در حال تقلید از تلفن Moto G4 است که دارای یک دید نسبتاً کوچک است و تصویر قهرمان صفحه شما در ابتدا خارج از صفحه نمایش داده می شود. با این حال، داده‌های میدانی شما ممکن است بیشتر شامل کاربران Pixel XL با صفحه‌نمایش بزرگتر باشد، بنابراین برای آنها تصویر قهرمان با بارگذاری آهسته عنصر LCP آنهاست .
اثرات حالت کش بر LCP
آزمایش‌های آزمایشگاهی معمولاً یک صفحه را با یک کش سرد بارگذاری می‌کنند، اما وقتی کاربران واقعی از آن صفحه بازدید می‌کنند، ممکن است برخی از منابع آن را در حافظه پنهان داشته باشند.
اولین باری که کاربر یک صفحه را بارگیری می کند ممکن است به کندی بارگیری شود، اما اگر صفحه ذخیره سازی مناسبی را پیکربندی کرده باشد، دفعه بعد که کاربر صفحه را برمی گرداند ممکن است بلافاصله بارگیری شود.
در حالی که برخی از ابزارهای آزمایشگاهی از چندین اجرا از یک صفحه پشتیبانی می‌کنند (برای شبیه‌سازی تجربه برای بازدیدکنندگان بازگشتی)، برای ابزار آزمایشگاهی امکان ندارد که بداند چند درصد از بازدیدهای دنیای واقعی از کاربران جدید در مقایسه با کاربران بازگشتی انجام می‌شود.
سایت‌هایی با پیکربندی‌های حافظه نهان به خوبی بهینه‌سازی شده و تعداد زیادی بازدیدکننده مکرر ممکن است متوجه شوند که LCP دنیای واقعی آنها بسیار سریع‌تر از داده‌های آزمایشگاهی آنها است.
بهینه سازی AMP یا Signed Exchange
سایت‌هایی که با AMP ساخته شده‌اند یا از صرافی‌های امضا شده (SXG) استفاده می‌کنند، می‌توانند توسط جمع‌آوری‌کننده‌های محتوا مانند جستجوی Google از قبل بارگیری شوند. این می تواند منجر به عملکرد بارگذاری قابل توجهی بهتر برای کاربرانی شود که از صفحات شما از آن پلتفرم ها بازدید می کنند.
علاوه بر بارگذاری اولیه متقاطع، خود سایت ها می توانند محتوا را برای صفحات بعدی در سایت خود از قبل بارگذاری کنند ، که می تواند LCP را برای آن صفحات نیز بهبود بخشد.
ابزارهای آزمایشگاهی دستاوردهای حاصل از این بهینه‌سازی‌ها را شبیه‌سازی نمی‌کنند، و حتی اگر شبیه‌سازی کنند، نمی‌توانند بدانند چند درصد از ترافیک شما از پلتفرم‌هایی مانند جستجوی گوگل در مقایسه با سایر منابع می‌آید.
اثرات bfcache بر LCP
هنگامی که صفحات از bfcache بازیابی می شوند، تجربه بارگیری تقریباً آنی است و این تجربیات در داده های فیلد شما گنجانده می شود .
تست‌های آزمایشگاهی bfcache را در نظر نمی‌گیرند، بنابراین اگر صفحات شما با bfcache سازگار هستند، احتمالاً منجر به امتیازات LCP سریع‌تر گزارش‌شده در این زمینه می‌شود.
اثرات تعامل کاربر بر LCP
LCP زمان رندر بزرگترین تصویر یا بلوک متن را در viewport مشخص می کند، اما این بزرگترین عنصر می تواند با بارگیری صفحه یا اگر محتوای جدید به صورت پویا به viewport اضافه شود تغییر کند.
در آزمایشگاه، مرورگر منتظر می ماند تا صفحه به طور کامل بارگیری شود و قبل از تعیین اینکه عنصر LCP چیست. اما در میدان، مرورگر نظارت بر عناصر بزرگتر را پس از پیمایش کاربر یا تعامل با صفحه متوقف خواهد کرد.
این منطقی است (و ضروری است) زیرا کاربران معمولاً منتظر می‌مانند تا با یک صفحه ارتباط برقرار کنند تا زمانی که صفحه بارگذاری شود، که دقیقاً همان چیزی است که معیار LCP تشخیص می‌دهد. همچنین منطقی نیست که عناصر اضافه شده به viewport را پس از تعامل کاربر در نظر بگیریم زیرا این عناصر ممکن است فقط به دلیل کاری که کاربر انجام داده بارگیری شده باشند.
با این حال، معنای این امر این است که داده‌های فیلد برای یک صفحه ممکن است زمان‌های LCP سریع‌تری را گزارش کنند، بسته به نحوه رفتار کاربران در آن صفحه.
INP
INP نیاز به تعامل با کاربر واقعی دارد
متریک INP میزان پاسخگویی یک صفحه به تعاملات کاربر را در زمانی که کاربران واقعاً تصمیم به تعامل با آن انتخاب کردند، اندازه گیری می کند.
بخش دوم این جمله بسیار مهم است زیرا تست‌های آزمایشگاهی، حتی آن‌هایی که از رفتار کاربر اسکریپت پشتیبانی می‌کنند، نمی‌توانند به‌طور دقیق پیش‌بینی کنند که کاربران چه زمانی را برای تعامل با یک صفحه انتخاب می‌کنند و بنابراین نمی‌توانند به‌طور دقیق FID را اندازه‌گیری کنند.
TBT رفتار کاربر را در نظر نمی گیرد
معیار آزمایشگاهی زمان مسدود کردن کل (TBT) برای کمک به تشخیص مشکلات INP در نظر گرفته شده است، زیرا میزان مسدود شدن رشته اصلی در طول بارگذاری صفحه را کمیت می‌کند.
ایده این است که صفحاتی با تعداد زیادی جاوا اسکریپت همزمان یا سایر وظایف رندر فشرده، احتمال بیشتری دارد که در اولین تعامل کاربر، یک رشته اصلی مسدود شده داشته باشند. با این حال، اگر کاربران برای تعامل با صفحه تا پایان اجرای جاوا اسکریپت منتظر بمانند، INP ممکن است بسیار پایین باشد.
زمانی که کاربران تصمیم می‌گیرند با یک صفحه تعامل داشته باشند تا حد زیادی به تعاملی بودن یا نبودن آن بستگی دارد، و این را نمی‌توان با TBT اندازه‌گیری کرد.
TBT تاخیر ضربه زدن را در نظر نمی گیرد
اگر سایتی برای مشاهده تلفن همراه بهینه نشده باشد، مرورگرها پس از هر ضربه‌ای قبل از اجرای کنترل‌کننده‌های رویداد ، ۳۰۰ میلی‌ثانیه تأخیر اضافه می‌کنند. آنها این کار را انجام می دهند زیرا باید تعیین کنند که آیا کاربر سعی می کند قبل از اینکه بتواند رویدادهای ماوس یا کلیک را فعال کند، دو بار برای بزرگنمایی ضربه بزند یا خیر.
این تأخیر در INP صفحه به حساب می‌آید زیرا به تأخیر واقعی ورودی که کاربران تجربه می‌کنند کمک می‌کند. اما از آنجایی که این تأخیر از نظر فنی یک کار طولانی نیست، بر TBT صفحه تأثیری نمی‌گذارد. این بدان معناست که یک صفحه ممکن است علیرغم داشتن امتیاز TBT بسیار خوب، INP ضعیفی داشته باشد.
اثرات حالت کش و bfcache بر INP
همانطور که کش مناسب می تواند LCP را در این زمینه بهبود بخشد، می تواند INP را نیز بهبود بخشد.
در دنیای واقعی، یک کاربر ممکن است جاوا اسکریپت یک سایت را از قبل در حافظه پنهان خود داشته باشد، بنابراین پردازش آن می تواند زمان کمتری را صرف کند و منجر به تاخیرهای کمتری شود.
همین امر برای صفحات بازیابی شده از bfcache نیز صادق است. در این موارد جاوا اسکریپت از حافظه بازیابی می‌شود، بنابراین زمان پردازش کمی وجود دارد یا اصلاً وجود ندارد.
CLS
اثرات تعامل کاربر بر CLS
CLS اندازه‌گیری شده در آزمایشگاه فقط تغییرات طرح‌بندی را در نظر می‌گیرد که در بالای تا و در حین بار رخ می‌دهد، اما این تنها زیرمجموعه‌ای از آن چیزی است که CLS در واقع اندازه‌گیری می‌کند.
در این زمینه، CLS همه تغییرات طرح‌بندی غیرمنتظره‌ای را که در طول عمر صفحه رخ می‌دهد، در نظر می‌گیرد، از جمله محتوایی که با اسکرول کاربر یا در پاسخ به درخواست‌های شبکه کند پس از تعامل کاربر تغییر می‌کند.
برای مثال، بارگذاری تنبلی تصاویر یا آیفریمهای بدون ابعاد در صفحات بسیار رایج است و این امر می‌تواند باعث تغییر طرح‌بندی زمانی که کاربر به آن بخش‌های صفحه پیمایش می‌کند، شود. اما این تغییرات ممکن است تنها در صورتی اتفاق بیفتد که کاربر به پایین پیمایش کند، که اغلب در یک آزمایش آزمایشگاهی مشخص نمی‌شود.
محتوای شخصی شده
محتوای شخصی شده - از جمله تبلیغات هدفمند و تست های A/B - بر عناصر بارگذاری شده در صفحه تأثیر می گذارد. همچنین بر نحوه بارگیری آنها تأثیر می گذارد زیرا محتوای شخصی شده اغلب بعداً بارگیری می شود و در محتوای اصلی صفحه درج می شود و باعث تغییر طرح بندی می شود.
در آزمایشگاه، یک صفحه معمولاً بدون محتوای شخصی‌شده یا با محتوایی برای یک «کاربر آزمایشی» عمومی بارگذاری می‌شود، که ممکن است تغییراتی را که کاربران واقعی مشاهده می‌کنند ایجاد کند یا نه.
از آنجایی که داده‌های میدانی شامل تجربیات همه کاربران می‌شود، میزان (و درجه) تغییرات طرح‌بندی تجربه شده در هر صفحه معین بسیار به محتوای بارگیری شده بستگی دارد.
اثرات حالت کش و bfcache در CLS
دو مورد از رایج‌ترین دلایل تغییر طرح‌بندی در حین بارگذاری، تصاویر و آیفریمهای بدون ابعاد (همانطور که در بالا ذکر شد) و فونت‌های وب با بارگذاری آهسته هستند، و هر دوی این مسائل به احتمال زیاد در اولین باری که کاربر از یک سایت بازدید می‌کند، روی تجربه تأثیر می‌گذارد. کش آنها خالی است
اگر منابع یک صفحه ذخیره شده باشد، یا اگر خود صفحه از bfcache بازیابی شود، مرورگر معمولاً می‌تواند تصاویر و فونت‌ها را فوراً نمایش دهد، بدون اینکه منتظر بارگیری آنها باشد. این می تواند منجر به مقادیر کمتر CLS در زمینه نسبت به آنچه که یک ابزار آزمایشگاهی ممکن است گزارش کند، شود.
وقتی نتایج متفاوت است چه باید کرد
به عنوان یک قاعده کلی، اگر هم داده های میدانی و هم داده های آزمایشگاهی برای یک صفحه مشخص دارید، داده های میدانی همان چیزی است که باید برای اولویت بندی تلاش های خود استفاده کنید. از آنجایی که داده‌های میدانی نشان‌دهنده آن چیزی است که کاربران واقعی تجربه می‌کنند، این دقیق‌ترین راه برای درک واقعی این است که کاربران شما با چه مشکلاتی دست و پنجه نرم می‌کنند و چه چیزی باید بهبود یابد.
از طرف دیگر، اگر داده‌های میدانی شما نمرات خوبی را در سراسر صفحه نشان می‌دهند، اما داده‌های آزمایشگاهی شما نشان می‌دهد که هنوز جایی برای بهبود وجود دارد، ارزش درک اینکه چه بهینه‌سازی‌های بیشتری را می‌توان انجام داد، دارد.
علاوه بر این، در حالی که داده‌های میدانی تجربیات کاربر واقعی را ثبت می‌کنند، این کار را فقط برای کاربرانی انجام می‌دهد که با موفقیت می‌توانند سایت شما را بارگیری کنند . داده‌های آزمایشگاهی گاهی اوقات می‌توانند به شناسایی فرصت‌هایی برای گسترش دامنه دسترسی سایت شما کمک کنند و آن را برای کاربرانی با شبکه‌های کندتر یا دستگاه‌های پایین‌تر در دسترس‌تر کنند.
به طور کلی، داده‌های آزمایشگاهی و داده‌های میدانی بخش‌های مهم اندازه‌گیری عملکرد مؤثر هستند. هر دوی آنها نقاط قوت و محدودیت های خود را دارند، و اگر فقط از یکی استفاده می کنید، ممکن است فرصتی را برای بهبود تجربه برای کاربران خود از دست بدهید.