آزمایش با اندازه گیری ناوبری نرم

بری پولارد
مایکل موکنی

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

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

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

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

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

ما بر اساس بازخورد توسعه‌دهندگان در آخرین نسخه آزمایشی origin، چندین بهبود در API ایجاد کرده‌ایم و اکنون از توسعه‌دهندگان می‌خواهیم که آخرین نسخه را امتحان کنند و قبل از عرضه این نسخه، بازخورد خود را در مورد این رویکرد ارائه دهند. ما کاملاً مطمئن هستیم که API در این نسخه‌های آزمایشی به کجا رسیده است و قصد داریم API را اواخر امسال، با توجه به بازخوردهای مربوط به این نسخه آزمایشی origin، راه‌اندازی کنیم.

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

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

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

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

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

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

یک نشانگر ناوبری نرم در پنل Performance با ردی از youtube.com.

می‌توانید نشانگرهایی برای ناوبری‌های نرم و LCP ببینید که هر دو با * مشخص شده‌اند تا به تمایز آنها از ورودی‌های ناوبری سخت معمول کمک کنند. این به طور پیش‌فرض فعال است و جدا از تغییرات عملکرد API است که در ادامه به آنها خواهیم پرداخت. این یک روش سریع برای آزمایش این است که آیا آزمایش ناوبری‌های نرم برای سایت شما به درستی کار می‌کند یا خیر.

در حال حاضر، این فقط پیمایش نرم و مهرهای زمانی LCP را در نمای ردیابی نشان می‌دهد. سایر معیارها (به عنوان مثال LCP) و پشتیبانی در نمای معیارهای زنده بعداً اضافه خواهند شد.

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

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

  • پس از شناسایی هر ناوبری soft-navigation یک رویداد PerformanceTiming ناوبری نرم منتشر خواهد شد.
  • این ورودی soft-navigation شامل یک navigationId ، آدرس اینترنتی جدید در ویژگی name ، و همچنین یک interactionId از تعامل آغازین خواهد بود.
  • یک یا چند ورودی interaction-contentful-paint پس از تعاملاتی که باعث ایجاد contentful paint می‌شوند، منتشر می‌شوند. این می‌تواند برای اندازه‌گیری 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 شامل یک ورودی largestInteractionContentfulPaint خواهد بود که شامل بزرگترین ورودی interaction-contentful-paint منتشر شده به عنوان بخشی از ناوبری است. سپس می‌توان از این ورودی به عنوان LCP اولیه برای آن ناوبری استفاده کرد و سپس آن LCP را می‌توان با مشاهده ورودی‌های interaction-contentful-paint بیشتر برای آن تعامل، به‌روزرسانی کرد.
  • به طور بالقوه ممکن است برخی از ورودی‌های interaction-contentful-paint قبل از انجام ناوبری نرم اتفاق افتاده باشند (اگر به‌روزرسانی URL تا بعد از آن رنگ‌آمیزی‌ها اتفاق نیفتد). در این موارد، بزرگترین ورودی largestInteractionContentfulPaint از نیاز به بافر کردن و نگاه کردن به ورودی‌های قدیمی جلوگیری می‌کند. توجه داشته باشید که largestInteractionContentfulPaint یک کپی دقیق از بزرگترین ورودی interaction-contentful-paint است، بنابراین آن ورودی از navigationId قبلی استفاده کرده است، زیرا زمانی که رنگ‌آمیزی اتفاق افتاده است، اما این رنگ‌آمیزی‌ها باید در مقایسه با navigationId جدید سنجیده شوند.
  • ورودی soft-navigation همچنین شامل paintTime و presentationTime به عنوان FCP برای آن ناوبری خواهد بود.
  • توجه داشته باشید که ورودی‌های interaction-contentful-paint پس از تعاملات بیشتر نیز منتشر می‌شوند، اما LCP برای یک URL باید به ورودی‌های interaction-contentful-paint که با منوی ناوبری soft interactionId مطابقت دارند، محدود شود تا این موارد حذف شوند.

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

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

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

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

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

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

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

پیمایش‌های نرم به طور پیش‌فرض در کروم فعال نیستند، اما با فعال کردن صریح این ویژگی، برای آزمایش در دسترس قرار می‌گیرند.

برای توسعه‌دهندگان، این قابلیت می‌تواند با فعال کردن پرچم chrome://flags/#soft-navigation-heuristics فعال شود. همچنین می‌توان آن را با استفاده از آرگومان‌های خط فرمان --enable-features=SoftNavigationHeuristics هنگام اجرای کروم فعال کرد. فعال کردن پرچم chrome://flags/#enable-experimental-web-platform-features نیز ناوبری‌های نرم را فعال می‌کند.

برای وب‌سایتی که می‌خواهد این قابلیت را فعال کند تا همه بازدیدکنندگانش تأثیر آن را ببینند، یک نسخه آزمایشی origin از کروم ۱۴۷ اجرا خواهد شد که می‌توان با ثبت‌نام در نسخه آزمایشی و گنجاندن یک عنصر متا با توکن origin trial در هدر HTML یا HTTP آن را فعال کرد. برای اطلاعات بیشتر به پست « شروع با origin trial» مراجعه کنید.

صاحبان سایت می‌توانند نسخه آزمایشی Origin را برای همه یا فقط برای زیرمجموعه‌ای از کاربران در صفحات خود قرار دهند. از بخش پیامدهای قبلی در مورد چگونگی تغییر نحوه گزارش معیارهای شما، به ویژه اگر این نسخه آزمایشی Origin را برای بخش بزرگی از کاربران خود فعال کنید، آگاه باشید. توجه داشته باشید که CrUX صرف نظر از این تنظیمات ناوبری نرم، به گزارش معیارها به روش موجود ادامه خواهد داد، بنابراین تحت تأثیر این پیامدها قرار نمی‌گیرد. همچنین باید توجه داشت که نسخه‌های آزمایشی Origin نیز به فعال کردن ویژگی‌های آزمایشی در حداکثر 0.5٪ از کل بارگذاری صفحات Chrome به عنوان میانگین بیش از 14 روز محدود می‌شوند، اما این فقط باید برای سایت‌های بسیار بزرگ مشکل‌ساز باشد.

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

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

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

توجه داشته باشید که supportedEntryTypes در اولین استفاده ثابت می‌ماند، بنابراین اگر پشتیبانی از soft navigations به صورت پویا توسط یک توکن آزمایشی origin که به صفحه تزریق شده است اضافه شود، ممکن است قبل از فعال شدن آن ویژگی، مقدار اصلی را برگرداند.

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

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 مشابه چندین بار در طول عمر یک برنامه تک صفحه‌ای بازدید شود). این را می‌توان با PerformanceEntry API جستجو کرد:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

گزارش 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 در نظر گرفته شود، فیلتر می‌کند.

علاوه بر این، شما باید پردازش largestInteractionContentfulPaint ورودی InteractionContentfulPaint از ورودی‌های 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 می‌تواند با largestInteractionContentfulPaint مقداردهی اولیه شود. INP و CLS باید با 0 مقداردهی اولیه شوند، زیرا برای بارگذاری صفحه این مقداردهی می‌شوند.

سپس می‌توان LCP، INP و CLS را طبق معمول اندازه‌گیری و پایش کرد (به استثنای استفاده از interaction-contentful-paint برای LCP که تطابق‌های interactionId را فراهم می‌کند). همانطور که قبلاً بحث شد، از interactionId و navigationId می‌توان برای نامگذاری ورودی‌های یک 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 را با هر دو روش اندازه‌گیری کنید؟

در طول این آزمایش، توصیه می‌شود که به اندازه‌گیری Core Web Vitals خود به روش فعلی، بر اساس پیمایش‌های "سخت" صفحه، ادامه دهید زیرا پیاده‌سازی جدید ممکن است قبل از انتشار نهایی، مشکلاتی داشته باشد یا تغییر کند. این همچنین با آنچه CrUX در حال حاضر اندازه‌گیری می‌کند مطابقت دارد (بعداً در این مورد بیشتر صحبت خواهیم کرد).

علاوه بر این موارد، باید پیمایش‌های نرم نیز اندازه‌گیری شوند تا به شما امکان دهند ببینید که چگونه ممکن است در آینده اندازه‌گیری شوند و به شما این فرصت را بدهند که در مورد نحوه عملکرد این پیاده‌سازی در عمل، به تیم کروم بازخورد ارائه دهید. این به شما و تیم کروم کمک می‌کند تا API را در آینده شکل دهید.

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

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

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

ساده‌ترین راه برای در نظر گرفتن تمام تفاوت‌های ظریف، استفاده از کتابخانه جاوا اسکریپت web-vitals است که پشتیبانی آزمایشی برای ناوبری‌های نرم در یک soft-navs branch دارد (که در npm و unpkg نیز موجود است). این را می‌توان به روش زیر اندازه‌گیری کرد (جایگزین کردن 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 معیارهای زیر را برای پیمایش‌های نرم گزارش می‌دهد:

متریک جزئیات
TTFB به صورت 0 گزارش شده است.
اف سی پی زمان اولین نمایش محتوا، نسبت به زمان شروع ناوبری نرم، از تعاملی که ناوبری نرم را فعال کرده است. نمایش‌های موجود از ناوبری قبلی یا مواردی که با تعامل مرتبط نیستند، در نظر گرفته نمی‌شوند.
ال سی پی زمان بزرگترین ترسیم محتوایی، نسبت به زمان شروع پیمایش نرم، از تعاملی که پیمایش نرم را فعال کرده است. ترسیم‌های موجود از پیمایش قبلی یا آنهایی که با تعامل مرتبط نیستند، در نظر گرفته نمی‌شوند. طبق معمول، این مورد هنگام یک تعامل یا زمانی که صفحه پس‌زمینه می‌شود گزارش می‌شود، زیرا تنها در آن زمان می‌توان LCP را نهایی کرد.
سی ال اس بزرگترین پنجره‌ی جابجایی بین زمان‌های پیمایش. طبق معمول، این زمانی است که صفحه در پس‌زمینه قرار دارد، زیرا تنها در آن زمان است که CLS می‌تواند نهایی شود. اگر جابجایی وجود نداشته باشد، مقدار 0 گزارش می‌شود.
آی ان پی INP بین زمان‌های پیمایش. طبق معمول، این مورد هنگام تعامل یا زمانی که صفحه در پس‌زمینه قرار می‌گیرد گزارش می‌شود، زیرا تنها در آن زمان است که INP می‌تواند نهایی شود. اگر تعاملی وجود نداشته باشد، مقدار 0 گزارش نمی‌شود.

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

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

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

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

اینکه در صورت موفقیت‌آمیز بودن این آزمایش، ناوبری‌های نرم دقیقاً چگونه در CrUX گزارش خواهند شد، هنوز مشخص نیست. لزوماً مشخص نیست که با آنها مانند ناوبری‌های «سخت» فعلی رفتار خواهد شد.

در برخی صفحات وب، ناوبری‌های نرم تقریباً از نظر کاربر با بارگذاری کامل صفحه یکسان هستند و استفاده از فناوری Single Page Application فقط یک جزئیات پیاده‌سازی است. در برخی دیگر، ممکن است بیشتر شبیه بارگذاری جزئی محتوای اضافی باشند.

بنابراین، ممکن است تصمیم بگیریم این ناوبری‌های نرم را به طور جداگانه در CrUX گزارش دهیم، یا شاید هنگام محاسبه Core Web Vitals برای یک صفحه یا گروهی از صفحات، به آنها وزن بدهیم. همچنین ممکن است بتوانیم ناوبری نرم با بارگذاری جزئی را به طور کامل حذف کنیم، همانطور که روش اکتشافی تکامل می‌یابد.

این تیم بر روی پیاده‌سازی اکتشافی و فنی تمرکز دارد که به ما امکان می‌دهد در مورد موفقیت این آزمایش قضاوت کنیم، بنابراین هنوز در این زمینه‌ها تصمیمی گرفته نشده است.

بازخورد

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

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

تغییرات

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

نتیجه‌گیری

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

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

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

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