اندازه‌گیری پیمایش‌های ملایم

Barry Pollard

Michal Mocny

تاریخ انتشار: ۱ فوریه ۲۰۲۳، آخرین به‌روزرسانی: ۲۰ سپتامبر ۲۰۲۶

از زمان راه‌اندازی، ابتکار «معیارهای کلیدی اصلی وب» به‌دنبال اندازه‌گیری تجربه واقعی کاربر از وب‌سایت بوده است، نه جزئیات فنی پشت نحوه ایجاد یا بارگیری وب‌سایت. سه سنجه «هسته‌های حیاتی وب» به‌عنوان سنجه‌های کاربرمحور ایجاد شدند—تحولی در سنجه‌های فنی موجود مانند DOMContentLoaded یا load که زمان‌بندی‌هایی را اندازه‌گیری می‌کردند که اغلب با نحوه درک کاربران از عملکرد صفحه بی‌ارتباط بودند. به‌همین دلیل، فناوری مورداستفاده برای ساخت سایت نباید بر امتیازدهی تأثیر بگذارد، مشروط بر اینکه سایت عملکرد خوبی داشته باشد.

واقعیت همیشه کمی پیچیده‌تر از حالت ایده‌آل است و معماری محبوب «برنامه تک‌صفحه‌ای» هرگز به‌طور کامل توسط سنجه‌های «معیارهای کلیدی اصلی وب» پشتیبانی نشده است. این برنامه‌های وب به‌جای بار کردن صفحات وب مجزا و جداگانه هنگام پیمایش کاربر در سایت، از چیزی به‌نام «پیمایش‌های نرم» استفاده می‌کنند که در آن محتوای صفحه توسط جاوا اسکریپت تغییر می‌کند. در این برنامه‌ها، توهم معماری صفحه وب معمولی با تغییر دادن نشانی وب و قرار دادن نشانی‌های وب قبلی در سابقه مرورگر حفظ می‌شود تا دکمه‌های عقب و جلو بتوانند طبق انتظار کاربر کار کنند.

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

تیم Chrome مدتی است که این چالش را درنظر گرفته است و به‌دنبال استانداردسازی تعریفی از «پیمایش نرم» و نحوه اندازه‌گیری Core Web Vitals برای آن است—به روشی مشابه با اندازه‌گیری وب‌سایت‌هایی که در معماری چندصفحه‌ای مرسوم (MPA) پیاده‌سازی شده‌اند.

براساس بازخورد توسعه‌دهندگان، چندین بهبود در پیشنهاد ایجاد کرده‌ایم و دو میانای برنامه‌سازی کاربردی عملکرد جدید راه‌اندازی کرده‌ایم تا به حل این مشکل از Chrome 151 کمک کنیم. علاوه‌براین، سنجه‌های پیمایش نرم را به‌عنوان سنجه‌های آزمایشی در «گزارش تجربه کاربری Chrome»‏ (CrUX) دردسترس قرار داده‌ایم.

پیمایش نرم چیست؟

به تعریف زیر برای پیمایش ملایم رسیده‌ایم:

• پیمایش با کنش کاربر آغاز می‌شود.
• پیمایش منجر به تغییر نشانی وب قابل‌مشاهده برای کاربر می‌شود.
• تعامل منجر به رنگ‌آمیزی قابل‌مشاهده می‌شود.

برای برخی‌از سایت‌ها، این تعریف ممکن است به مثبت کاذب (که کاربران واقعاً درنظر نمی‌گیرند «پیمایش» اتفاق افتاده باشد) یا منفی کاذب (که کاربر درنظر می‌گیرد «پیمایش» اتفاق افتاده است، بااینکه این معیارها برآورده نشده است) منجر شود. از بازخورد شما در مخزن مشخصات پیمایش نرم استقبال می‌کنیم.

پشتیبانی DevTools از پیمایش‌های ملایم

پشتیبانی از پیمایش‌های نرم را به پانل عملکرد DevTools در نمای سنجه‌های زنده و در نمای ردیابی با پشتیبانی از اطلاعات آماری و نشانگر اضافه کرده‌ایم:

‫Chrome چگونه پیمایش‌های نرم را برای توسعه‌دهندگان وب پیاده‌سازی می‌کند؟

وقتی ویژگی پیمایش نرم فعال شود (در بخش بعدی بیشتر درباره آن توضیح داده شده است)، Chrome نحوه گزارش برخی‌از سنجه‌های عملکرد را تغییر خواهد داد:

• پس‌از شناسایی هر پیمایش نرم، رویداد soft-navigation PerformanceTiming منتشر خواهد شد.
• این ورودی soft-navigation شامل navigationId، نشانی وب جدید در مشخصه name، و همچنین interactionId تعامل آغازین خواهد بود.
• یک یا چند ورودی interaction-contentful-paint پس‌از تعاملاتی که باعث رنگ‌آمیزی محتوادار می‌شوند منتشر خواهد شد. این شامل ورودی largestContentfulPaint خواهد بود که می‌تواند برای اندازه‌گیری بزرگ‌ترین رندر محتوایی اولیه (LCP) برای پیمایش‌های نرم استفاده شود.
• مشخصه navigationId به هریک از زمان‌بندی‌های عملکرد (first-paint، first-contentful-paint، largest-contentful-paint، interaction-contentful-paint، first-input-delay، event، و layout-shift) اضافه می‌شود. این مشخصه با ورودی پیمایشی که رویداد تحت آن صادر شده است مطابقت دارد. توجه داشته باشید که وقتی این ورودی‌ها شامل پیمایش‌های نرم باشند، ممکن است بسته به زمان انتشار ورودی، حاوی navigationId قبلی یا بعدی باشند. اطلاعات بیشتر در این مورد در بخش گزارش سنجه‌ها دربرابر نشانی وب مناسب.
• soft-navigation شامل تابع getLargestInteractionContentfulPaint() برای بازیابی بزرگ‌ترین ورودی interaction-contentful-paint برای آن پیمایش خواهد بود. سپس می‌توان از آن به‌عنوان LCP اولیه برای آن پیمایش استفاده کرد و سپس می‌توان آن LCP را با مشاهده ورودی‌های interaction-contentful-paint بیشتر برای آن تعامل به‌روز کرد. توجه داشته باشید که این جایگزین مشخصه largestInteractionContentfulPaint می‌شود که در آزمایش‌های معرفی ویژگی جدید قبلی دردسترس بود.
• احتمالاً برخی‌از ورودی‌های interaction-contentful-paint ممکن است قبل‌از انجام پیمایش نرم اتفاق افتاده باشند (اگر به‌روزرسانی نشانی وب تا بعداز آن رنگ‌آمیزی‌ها اتفاق نیفتد). در این موارد، تابع getLargestInteractionContentfulPaint() از نیاز به میان‌گیری و نگاه کردن به ورودی‌های قدیمی پس‌از نهایی شدن پیمایش نرم جلوگیری می‌کند. توجه داشته باشید که ورودی برگردانده‌شده توسط getLargestInteractionContentfulPaint() کپی دقیقی از بزرگ‌ترین ورودی interaction-contentful-paint در زمان انتشار آن است، بنابراین ممکن است آن ورودی از navigationId قبلی استفاده کرده باشد زیرا زمان وقوع رنگ‌آمیزی همان موقع بوده است، اما این رنگ‌آمیزی‌ها باید نسبت‌به navigationId جدید سنجیده شوند.
• ورودی soft-navigation همچنین شامل paintTime و presentationTime به‌عنوان FCP برای آن پیمایش خواهد بود.
• توجه داشته باشید که ورودی‌های interaction-contentful-paint نیز پس‌از تعاملات بیشتر منتشر خواهند شد، اما LCP برای یک نشانی وب باید به ورودی‌های interaction-contentful-paint که با پیمایش‌های نرم interactionId مطابقت دارند محدود شود تا این موارد مستثنی شوند و همچنین فقط به ویژگی‌های largestContentfulPaint درون آن محدود شود.

این تغییرات امکان اندازه‌گیری «معیارهای کلیدی اصلی وب» (و برخی‌از سنجه‌های تشخیصی مرتبط) را در هر پیمایش صفحه فراهم می‌کند، هرچند برخی تفاوت‌های ظریف وجود دارد که باید درنظر گرفته شود.

پیامدهای فعال کردن پیمایش‌های نرم در Chrome چیست؟

برخی‌از تغییراتی که مالکان سایت باید پس‌از فعال کردن این ویژگی درنظر بگیرند در زیر آمده است:

• پایش ورودی‌های soft-navigation امکان «برش» ورودی‌های عملکرد را در هر «پیمایش» فراهم می‌کند.
• سنجه‌های CLS و INP را می‌توان ازقبل به‌دلخواه شما تقسیم کرد، به‌جای اینکه درطول کل چرخه حیات صفحه اندازه‌گیری شوند، اما ویژگی «پیمایش نرم» معیاری استاندارد از زمان وقوع این اتفاق ارائه می‌دهد، صرف‌نظر از فناوری زیربنایی مورداستفاده.
• ورودی largest-contentful-paint در یک تعامل (که برای شروع پیمایش ملایم ضروری است) نهایی می‌شود، بنابراین فقط می‌توان از آن برای اندازه‌گیری «بزرگ‌ترین نقاشی دارای محتوا» (LCP) پیمایش «سخت» اولیه استفاده کرد. این یعنی وقتی پیمایش‌های نرم اندازه‌گیری می‌شوند، این مقدار تغییر نخواهد کرد، بنابراین LCP برای بار شدن صفحه پیمایش سخت اولیه می‌تواند مانند همیشه اندازه‌گیری شود.
• ورودی جدید interaction-contentful-paint که از تعامل‌ها منتشر می‌شود می‌تواند برای اندازه‌گیری LCP برای پیمایش‌های نرم با نگاه کردن به ویژگی largestContentfulPaint در آن استفاده شود، اما ملاحظاتی برای نحوه استفاده از این ورودی وجود دارد که در این مقاله بحث خواهیم کرد.
• توجه داشته باشید که همه کاربران از این ویژگی پیمایش نرم پشتیبانی نخواهند کرد، به‌ویژه کاربرانی که از مرورگرهای دیگر یا نسخه‌های Chrome قبل‌از ۱۵۱ استفاده می‌کنند. توجه داشته باشید که برخی‌از کاربران ممکن است سنجه‌های مبتنی بر پیمایش نرم را گزارش نکنند، حتی اگر سنجه‌های Core Web Vitals را گزارش کنند.

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

برای اطلاعات بیشتر درباره نحوه اندازه‌گیری سنجه‌ها برای پیمایش‌های نرم، بخش «اندازه‌گیری معیارهای کلیدی اصلی وب» برای هر پیمایش نرم را ببینید.

چگونه پیمایش‌های نرم را در Chrome فعال کنم؟

ویژگی پیمایش‌های نرم به‌طور پیش‌فرض از Chrome 151 فعال است.

ویژگی تشخیص پشتیبانی از Soft Navigations API

می‌توانید از کد زیر برای آزمایش اینکه آیا API پشتیبانی می‌شود یا نه استفاده کنید:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

یا:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

چگونه می‌توانم پیمایش‌های ملایم را اندازه‌گیری کنم؟

درصورت پشتیبانی، سنجه‌ها را می‌توان بااستفاده از PerformanceObserver API مطابق با سنجه‌های دیگر گزارش کرد. بااین‌حال، ملاحظات اضافه‌ای وجود دارد که باید برای این سنجه‌ها درنظر گرفته شود.

گزارش کردن پیمایش‌های ملایم

می‌توانید از PerformanceObserver برای مشاهده پیمایش‌های نرم استفاده کنید. در زیر نمونه‌ای از تکه‌کد وجود دارد که ورودی‌های پیمایش نرم را در کنسول ثبت می‌کند—ازجمله پیمایش‌های نرم قبلی در این صفحه بااستفاده از گزینه buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

از این می‌توان برای نهایی کردن سنجه‌های صفحه تمام‌عمر برای پیمایش قبلی استفاده کرد.

سنجه‌ها را دربرابر نشانی وب مربوطه گزارش کنید

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

مشخصه name از ورودی مناسب soft-navigation حاوی نشانی وب جدیدی خواهد بود که سنجه‌ها برای آن گزارش می‌شود، و navigationId مرجع یکتایی برای این پیمایش خواهد بود (زیرا ممکن است درطول عمر یک برنامه تک‌صفحه‌ای، چندین بار از یک نشانی وب بازدید شود).

این باید به‌عنوان هر ورودی soft-navigation تنظیم شود و برای گزارش سنجه‌ها تا زمان دریافت ورودی soft-navigation بعدی استفاده شود.

گزارش کردن نشانی وب صحیح برای interaction-contentful-paint

برای محاسبه LCP از ورودی‌های interaction-contentful-paint، ملاحظات بیشتری لازم است، زیرا همه ورودی‌های interaction-contentful-paint نباید بااستفاده از navigationId نگاشت شوند و به‌عنوان LCP برای آن نشانی وب گزارش شوند:

• مشکل اول این است که اگر رنگ‌آمیزی قبل‌از به‌روزرسانی نشانی وب رخ دهد، ممکن است ورودی‌های interaction-contentful-paint قبل‌از وقوع پیمایش نرم منتشر شوند. در این موارد، navigationId برای نشانی وب قدیمی خواهد بود. اگر ابتدا نشانی وب به‌روز شود، سپس رنگ‌آمیزی پیمایش نرم را تکمیل می‌کند و در این صورت، ابتدا ورودی soft-navigation منتشر می‌شود و interaction-contentful-paint نشانی وب جدید را خواهد داشت.
• مشکل دوم این است که interaction-contentful-paint، ورودی‌ها همچنان برای تعاملات جدیدتر منتشر خواهند شد، زیرا دامنه این سنجه عملکرد فراتر از LCP برای پیمایش‌های نرم است. ما فقط می‌خواهیم رنگ‌های بارگذاری پیمایش نرم را برای LCP درنظر بگیریم و نه رنگ‌های مربوط به تعامل‌های بعدی.

بنابراین، برای نگاشت ورودی‌های interaction-contentful-paint به soft-navigation-entries باید از interactionId به‌جای navigationId استفاده شود تا نشانی وب صحیح به‌دست آید. این کار هرگونه ورودی با navigationId قدیمی را مدیریت می‌کند و همچنین هرگونه ورودی interaction-contentful-paint را که نباید برای LCP درنظر گرفته شود فیلتر می‌کند.

علاوه‌براین، ابتدا باید تابع getLargestInteractionContentfulPaint() ورودی‌های soft-navigation را پردازش کنید تا ورودی‌های interaction-contentful-paint را که قبل‌از انتشار soft-navigation entries رخ داده‌اند مدیریت کنید.

دریافت startTime پیمایش‌های ملایم

همه زمان‌بندی‌های عملکرد، ازجمله زمان‌بندی‌های مربوط به پیمایش‌های نرم، و ورودی‌های مورداستفاده برای محاسبه سنجه‌های «معیار کلیدی اصلی وب» به‌عنوان زمانی از زمان پیمایش اولیه «سخت» صفحه گزارش می‌شوند. بنابراین، زمان شروع پیمایش ملایم باید از زمان‌های سنجه بار کردن پیمایش ملایم (برای مثال LCP) کسر شود تا به‌جای آن، این زمان‌ها نسبت‌به این زمان پیمایش ملایم گزارش شوند.

زمان شروع ناوبری را می‌توان به روشی مشابه با نگاشت به ورودی soft-navigation مناسب و استفاده از startTime آن به‌دست آورد.

‫startTime زمان تعامل اولیه (برای مثال، کلیک روی دکمه) است که پیمایش نرم را آغاز کرده است. این تا حدودی با «پیمایش‌های سخت» متفاوت است، که در آن «زمان شروع» زمانی است که صفحه جدید به مرورگر «متعهد» می‌شود و پس‌از اجرای برخی‌از کدهای کنترل‌کننده رویداد است. زمان‌های شروع پیمایش ملایم شامل کد گرداننده رویداد نیز می‌شود، زیرا ما از زمان شروع تعامل اندازه‌گیری می‌کنیم.

اندازه‌گیری کردن Core Web Vitals به‌ازای هر پیمایش نرم

برای اندازه‌گیری «معیارهای کلیدی اصلی وب»، به ورودی‌های soft-navigation گوش دهید و سنجه‌ها را پس‌از دریافت این موارد بازنشانی کنید. FCP می‌تواند براساس presentationTime منتشر شود و LCP می‌تواند در ورودی getLargestInteractionContentfulPaint() مقداردهی اولیه شود. INP و CLS باید روی ۰ مقداردهی اولیه شوند، همان‌طور که برای بار کردن صفحه انجام می‌شود.

سپس می‌توان LCP،‏ INP، و CLS را طبق معمول اندازه‌گیری و پایش کرد (به‌استثنای استفاده از interaction-contentful-paint برای LCP که interactionId را ارائه می‌دهد). همان‌طور که قبلاً بحث شد، از interactionId می‌توان برای نام‌گذاری ورودی‌های نشانی وب استفاده کرد.

زمان‌بندی‌ها همچنان نسبت به زمان شروع پیمایش «سخت» اصلی برگردانده خواهد شد. بنابراین برای محاسبه LCP برای ناوبری نرم، برای مثال، باید زمان‌بندی interaction-contentful-paint را بگیرید و زمان شروع ناوبری نرم مناسب را همان‌طور که قبلاً توضیح داده شد کم کنید تا زمان‌بندی نسبت به ناوبری نرم به‌دست آید.

برخی‌از سنجه‌ها به‌طور سنتی درطول عمر صفحه اندازه‌گیری شده‌اند: برای مثال، LCP می‌تواند تا زمانی که تعاملی رخ دهد تغییر کند. CLS و INP را می‌توان تا زمانی که صفحه پیمایش نشده است، صرف‌نظر از هرگونه تعامل، به‌روزرسانی کرد. بنابراین، با هر پیمایش نرم جدید، سنجه‌های پیمایش قبلی باید نهایی شود. این یعنی سنجه‌های پیمایش «سخت» اولیه ممکن است زودتر از حد معمول هنگام اندازه‌گیری «معیارهای کلیدی اصلی وب» با پیمایش‌های نرم نهایی شوند.

به‌طور مشابه، هنگام شروع اندازه‌گیری سنجه‌ها برای پیمایش نرم جدید این سنجه‌های طولانی‌مدت، سنجه‌ها باید «بازنشانی» یا «مجدداً مقداردهی اولیه» شوند و به‌عنوان سنجه‌های جدید درنظر گرفته شوند، بدون اینکه مقادیری را که برای «صفحه‌های» قبلی تنظیم شده بودند به‌خاطر بسپارند. یعنی درک اینکه «بزرگ‌ترین» ترسیم، تعامل تا ترسیم بعدی، یا تغییر چیدمان چیست بازنشانی می‌شود تا امکان اندازه‌گیری مجدد از ابتدا فراهم شود.

با محتوایی که بین پیمایش‌ها یکسان می‌ماند چگونه باید رفتار شود؟

LCP برای پیمایش‌های نرم (محاسبه‌شده از interaction-contentful-paint) فقط رنگ‌های جدید را اندازه‌گیری می‌کند و فقط رنگ‌های مرتبط با تعاملی که باعث پیمایش شده است. این امر می‌تواند منجر به LCP متفاوتی از بارگیری سرد آن پیمایش نرم به بارگیری نرم شود.

برای مثال، صفحه‌ای را درنظر بگیرید که شامل تصویر برنمای بزرگی است که عنصر LCP است، اما نوشتار زیر آن با هر پیمایش نرم تغییر می‌کند. بار کردن اولیه صفحه، تصویر برنما را به‌عنوان عنصر LCP پرچم‌گذاری می‌کند و زمان‌بندی LCP را براساس آن قرار می‌دهد. برای پیمایش‌های نرم بعدی، نوشتار زیر بزرگ‌ترین عنصر رنگ‌شده پس‌از پیمایش نرم خواهد بود و عنصر LCP جدید خواهد بود. اما اگر صفحه با پیوند عمیق در نشانی وب پیمایش نرم بار شود، تصویر برنما رنگ‌آمیزی جدیدی خواهد بود و بنابراین واجدشرایط درنظر گرفته شدن به‌عنوان عنصر LCP خواهد بود.

به‌طور مشابه، پویانمایی ممکن است بخشی از صفحه را به‌طور مداوم به‌روز کند—که به هیچ پیمایش نرمی که اتفاق می‌افتد مربوط نیست. هیچ‌کدام از نقاشی‌های جدید ناشی از آن پویانمایی پس‌زمینه برای «بزرگ‌ترین نقاشی دارای محتوا» در پیمایش نرم جدید درنظر گرفته نمی‌شود. اما اگر صفحه از این نشانی وب مجدداً بار شود، ممکن است برای LCP درنظر گرفته شود.

همان‌طور که این مثال‌ها نشان می‌دهند، عنصر LCP برای پیمایش نرم می‌تواند بسته به نحوه بار شدن صفحه به‌صورت متفاوتی گزارش شود—به همان روشی که بار کردن صفحه با پیوند ثابت در پایین صفحه می‌تواند به عنصر LCP متفاوتی برای پیمایش‌های سخت منجر شود.

چگونه TTFB را اندازه‌گیری کنیم؟

زمان تا اولین بایت (TTFB) برای بار کردن صفحه معمولی نشان‌دهنده زمانی است که اولین بایت‌های درخواست اصلی برگردانده می‌شود.

برای ناوبری نرم، این سؤال پیچیده‌تری است. آیا باید اولین درخواست ایجادشده برای صفحه جدید را اندازه‌گیری کنیم؟ اگر همه محتوا ازقبل در برنامه وجود داشته باشد و درخواست دیگری وجود نداشته باشد چه؟ اگر آن درخواست ازقبل با پیش‌واکشی انجام شده باشد چه؟ اگر درخواستی از دیدگاه کاربر به پیمایش نرم مربوط نباشد (برای مثال، درخواست تجزیه‌وتحلیل باشد) چه می‌شود؟

روش ساده‌تر این است که TTFB را برای پیمایش‌های نرم ۰ گزارش کنید—به همان روشی که برای بازیابی‌های حافظه نهان ناوبری بین صفحات توصیه می‌کنیم. این روشی است که کتابخانه web-vitals برای پیمایش‌های نرم استفاده می‌کند و چیزی است که درحال‌حاضر برای این سنجه توصیه می‌کنیم.

آیا باید Core Web Vitals را با هر دو روش‌شناسی اندازه‌گیری کنید؟

درحالی‌که این میاناهای برنامه‌سازی کاربردی جدید فقط به مرورگرهای مبتنی بر Chromium محدود می‌شوند، سایت‌ها ممکن است بخواهند هر دو را با تقسیم‌بندی براساس پیمایش‌های نرم و با ادامه تقسیم‌بندی براساس پیمایش‌های سخت اندازه‌گیری کنند. این کار امکان مقایسه در مرورگرهای مختلف و روندهای گذشته را فراهم می‌کند.

برای LCP، این یعنی درنظر گرفتن فقط ورودی‌های largest-contentful-paint برای روش فعلی، و هر دو ورودی largest-contentful-paint و interaction-contentful-paint برای روش جدید.

برای CLS و INP، این یعنی اندازه‌گیری این سنجه‌ها در کل چرخه حیات صفحه (همان‌طور که در روش فعلی انجام می‌شود) و تقسیم جداگانه خط زمان براساس پیمایش‌های نرم برای اندازه‌گیری مقادیر CLS و INP جداگانه برای روش جدید.

سپس سنجه‌ها باید دو بار برای تجزیه‌وتحلیل ارسال و ذخیره شوند.

استفاده از کتابخانه web-vitals برای اندازه‌گیری Core Web Vitals برای پیمایش‌های نرم

ساده‌ترین راه برای درنظر گرفتن همه تفاوت‌های ظریف، استفاده از کتابخانه جاوا اسکریپت web-vitals است که از نسخه ۶.۰.۰ از پیمایش‌های نرم پشتیبانی می‌کند. این را می‌توان به روش زیر اندازه‌گیری کرد (doTraditionalProcessing و doSoftNavProcessing را به‌طور مناسب جایگزین کنید):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

کتابخانه web-vitals همچنین تضمین می‌کند که سنجه‌ها را دربرابر نشانی وب صحیح گزارش کنید همان‌طور که قبلاً ذکر شد، زیرا هم navigationId و هم navigationURL را در ورودی‌های ارائه‌شده به فراخوانی برگشتی شامل می‌شود.

کتابخانه web-vitals سنجه‌های زیر را برای پیمایش‌های نرم گزارش می‌کند:

آیا این تغییرات بخشی از اندازه‌گیری‌های Core Web Vitals خواهند شد؟

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

ناوبری‌های نرم چگونه در CrUX گزارش خواهند شد؟

نسخه‌های آزمایشی سنجه‌های «معیار کلیدی اصلی وب» را در CrUX راه‌اندازی کرده‌ایم. این موارد به CLS و INP «پیمایش سخت» پس‌از اولین پیمایش نرم پایان می‌دهند و همچنین شامل معیارهای اضافی LCP،‏ CLS، و INP برای هر پیمایش نرم می‌شوند. قصد داریم این سنجه‌های آزمایشی را در مه ۲۰۲۷ به سنجه‌های پایدار ارتقا دهیم. برای اطلاعات بیشتر، پست وبلاگ سنجه‌های ناوبری نرم آزمایشی اکنون در CrUX دردسترس است را ببینید.

چگونه می‌توان پیمایش‌های نرم را در مرورگرهای دیگر مدیریت کرد؟

تشخیص برنامه‌نویسی‌شده پیمایش‌های نرم در مرورگرهایی که از میانای برنامه‌سازی کاربردی پشتیبانی نمی‌کنند دشوار است—و دقیقاً به همین دلیل است که روی این میانای برنامه‌سازی کاربردی کار کرده‌ایم.

می‌توان از Navigation API برای نظارت بر تغییرات نشانی وب استفاده کرد که ممکن است امکان تقسیم INP براساس نشانی وب را فراهم کند (و به‌طور مشابه CLS، اگرچه درحال‌حاضر فقط برای Chromium است، بنابراین بدون توجه به آن اندازه‌گیری نمی‌شود). بااین‌حال، این موضوع به سنجه‌های رنگ (FCP و LCP) که فقط می‌توانند تخمین زده شوند نمی‌پردازد.

درعین‌حال، معتقدیم که اطلاعات آماری ارائه‌شده توسط این میانای برنامه‌سازی کاربردی بسیار ارزشمندتر از آن است که نادیده گرفته شود، هم در اندازه‌گیری زمان پیمایش‌های نرم و هم در نسبت دادن سنجه‌ها به پیمایش صحیح. توصیه می‌کنیم با وجود عدم پشتیبانی از مرورگرهای مختلف درحال‌حاضر، از این میانای برنامه‌سازی کاربردی جدید استفاده کنید. درست مثل زمانی که Core Web Vitals راه‌اندازی شد، مشکلات شناسایی‌شده و راه‌حل‌های عملکردی احتمالاً بر همه مرورگرها تأثیر می‌گذارند، حتی اگر درحال‌حاضر رؤیت‌پذیری فقط به مرورگرهای مبتنی بر Chromium محدود باشد.

ما به کار روی فرایند استانداردسازی ادامه خواهیم داد و با سایر فروشندگان مرورگر تعامل خواهیم داشت تا اهمیت این API را نشان دهیم.

بازخورد

ما فعالانه درحال دریافت بازخورد درباره این میانای برنامه‌سازی کاربردی در مکان‌های زیر هستیم:

• بازخورد درباره API باید به‌عنوان مشکلات در GitHub مطرح شود.
• اشکال‌های موجود در پیاده‌سازی Chromium باید در ردیاب مشکل Chrome مطرح شود، اگر این اشکال هنوز یکی از مشکلات شناخته‌شده نیست.
• بازخورد کلی درباره Web Vitals را می‌توانید در web-vitals-feedback@googlegroups.com هم‌رسانی کنید.

اگر شک دارید، زیاد نگران نباشید، ترجیح می‌دهیم بازخورد را در هر دو مکان بشنویم و با کمال میل مشکلات را در هر دو مکان اولویت‌بندی می‌کنیم و مشکلات را به مکان صحیح هدایت می‌کنیم.

گزارش تغییر

با توسعه این میانای برنامه‌سازی کاربردی، تغییرات متعددی در آن ایجاد شده است که بیشتر از تغییرات میاناهای برنامه‌سازی کاربردی پایدار است. برای جزئیات بیشتر، می‌توانید گزارش تغییرات پیمایش‌های نرم را ببینید.

نتیجه‌گیری

ویژگی «پیمایش‌های نرم» رویکردی هیجان‌انگیز برای نحوه تکامل ابتکار «معیارهای کلیدی اصلی وب» است تا الگوی رایجی را در وب مدرن اندازه‌گیری کند که در سنجه‌های ما وجود ندارد. بازخوردهای قابل‌توجهی از انجمن وب گسترده‌تر جمع‌آوری کرده‌ایم و پتانسیل این میانای برنامه‌سازی کاربردی ما را دلگرم کرده است.

تصدیق‌نامه‌ها

ریزعکس از جردن مادرید در Unsplash

این کار ادامه کاری است که ابتدا توسط Yoav Weiss زمانی که در Google بود شروع شد. از Yoav برای تلاش‌هایش در این API سپاس‌گزاریم.