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

Barry Pollard

Michal Mocny

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

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

واقعیت همیشه کمی پیچیده‌تر از ایده‌آل است و معماری محبوب Single Page Application هرگز به طور کامل توسط معیارهای Core Web Vitals پشتیبانی نشده است. این برنامه‌های وب به جای بارگذاری صفحات وب مجزا و جداگانه هنگام پیمایش کاربر در سایت، از چیزی به نام "پیمایش‌های نرم" استفاده می‌کنند که در آن محتوای صفحه توسط جاوا اسکریپت تغییر می‌کند. در این برنامه‌ها، توهم معماری مرسوم صفحه وب با تغییر URL و قرار دادن URLهای قبلی در تاریخچه مرورگر حفظ می‌شود تا دکمه‌های عقب و جلو همانطور که کاربر انتظار دارد کار کنند.

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

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

ما بر اساس بازخورد توسعه‌دهندگان، چندین بهبود در این پیشنهاد ایجاد کرده‌ایم و دو API جدید برای بهبود عملکرد راه‌اندازی کرده‌ایم تا به حل این مشکل از کروم ۱۵۱ کمک کنیم.

ناوبری نرم چیست؟

ما تعریف زیر را از ناوبری نرم ارائه داده‌ایم:

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

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

پشتیبانی DevTools برای ناوبری‌های نرم

ما پشتیبانی از پیمایش‌های نرم را به پنل عملکرد DevTools در نمای Live Metrics و در نمای ردیابی با پشتیبانی از Insights و نشانگر اضافه کرده‌ایم:

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

زمانی که قابلیت ناوبری نرم فعال شود (در بخش بعدی بیشتر در این مورد صحبت خواهیم کرد)، کروم نحوه گزارش برخی از معیارهای عملکرد را تغییر خواهد داد:

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

این تغییرات به Core Web Vitals - و برخی از معیارهای تشخیصی مرتبط - اجازه می‌دهد تا در هر پیمایش صفحه اندازه‌گیری شوند، اگرچه برخی تفاوت‌های ظریف وجود دارد که باید در نظر گرفته شوند.

پیامدهای فعال کردن ناوبری نرم در کروم چیست؟

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

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

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

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

چگونه می‌توانم ناوبری‌های نرم را در کروم فعال کنم؟

قابلیت پیمایش نرم به طور پیش‌فرض از کروم ۱۵۱ فعال شده است.

پشتیبانی از API ناوبری نرم افزاری برای تشخیص ویژگی

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

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

یا به طور جایگزین:

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

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

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

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

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

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

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

گزارش معیارها در برابر URL مناسب

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

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

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

گزارش URL صحیح برای interaction-contentful-paint

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

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

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

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

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

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

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

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

اندازه‌گیری Core Web Vitals بر اساس ناوبری نرم

برای اندازه‌گیری Core Web Vitals، به ورودی‌های soft-navigation گوش دهید و معیارها را با دریافت این ورودی‌ها تنظیم مجدد کنید. FCP می‌تواند بر اساس presentationTime منتشر شود و LCP می‌تواند با ورودی getLargestInteractionContentfulPaint() مقداردهی اولیه شود. INP و CLS باید با 0 مقداردهی اولیه شوند، زیرا برای بارگذاری صفحه این مقداردهی می‌شوند.

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

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

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

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

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

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

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

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

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

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

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

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

یک روش ساده‌تر، گزارش TTFB برابر با ۰ برای پیمایش‌های نرم است - به روشی مشابه آنچه برای بازیابی‌های حافظه پنهان back/forward توصیه می‌کنیم. این روشی است که کتابخانه web-vitals برای پیمایش‌های نرم استفاده می‌کند و در حال حاضر برای این معیار توصیه می‌کنیم.

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

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

برای 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 همچنین تضمین می‌کند که شما گزارش می‌دهید معیارها در برابر URL صحیح گزارش می‌شوند، همانطور که قبلاً اشاره شد ، زیرا آنها شامل navigationId و navigationURL در ورودی‌های ارائه شده به callback هستند.

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

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

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

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

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

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

تشخیص ناوبری‌های نرم از طریق برنامه‌نویسی در مرورگرهایی که از API پشتیبانی نمی‌کنند، دشوار است - و به همین دلیل است که ما روی این API کار کرده‌ایم.

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

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

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

بازخورد

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

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

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

تغییرات

همزمان با توسعه این API، تعدادی تغییر در آن رخ داده است، که این تغییرات در مقایسه با APIهای پایدار بیشتر بوده است. برای جزئیات بیشتر می‌توانید به فهرست تغییرات Soft Navigations مراجعه کنید.

نتیجه‌گیری

ویژگی Soft Navigations رویکردی هیجان‌انگیز به چگونگی تکامل ابتکار Core Web Vitals برای اندازه‌گیری یک الگوی رایج در وب مدرن است که در معیارهای ما وجود ندارد. ما بازخوردهای قابل توجهی از جامعه وب گسترده‌تر جمع‌آوری کرده‌ایم و از پتانسیل این API دلگرم شده‌ایم.

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

تصویر بندانگشتی اثر جردن مادرید در Unsplash

این کار ادامه‌ی کاری است که اولین بار توسط یوآو وایس، زمانی که در گوگل بود، آغاز شد. از یوآو برای تلاش‌هایش در زمینه‌ی این API تشکر می‌کنیم.