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

Barry Pollard

Yoav Weiss

به‌روزرسانی آگوست 2024: دومین مسیر مبدأ Soft Navigations در 29 مه به پایان رسید. تیم Chrome برای بررسی بازخورد آزمایش و بررسی مراحل بعدی برای این API زمان می‌گذارد. ما می‌خواهیم به برخی از مشکلات دقت رسیدگی کنیم و معتقدیم قبل از آماده شدن ویژگی برای پیشرفت، به آزمایش اولیه دیگری نیاز است. در این میان، توسعه‌دهندگان همچنان می‌توانند با فعال کردن chrome://flags/#enable-experimental-web-platform-features این ویژگی را آزمایش کنند.

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

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

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

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

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

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

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

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

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

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

• یک رویداد PerformanceTiming soft-navigation پس از شناسایی هر ناوبری نرم منتشر می شود.
• API عملکرد دسترسی به ورودی زمان‌بندی soft-navigation را فراهم می‌کند، همانطور که توسط رویداد soft-navigation PerformanceTiming منتشر می‌شود.
• معیارهای First Paint (FP) ، First Contentful Paint (FCP) ، Largest Contentful Paint (LCP) بازنشانی می شوند و در موارد مناسب بعدی دوباره منتشر می شوند. (توجه: FP و FCP اجرا نمی شوند.)
• یک ویژگی navigationId به هر یک از زمان‌بندی‌های عملکرد ( first-paint , first-contentful-paint , largest-contentful-paint , first-input-delay , event , and layout-shift ) مطابق با ورودی پیمایشی که رویداد مرتبط بود اضافه می شود. به، اجازه می دهد تا تغییر چیدمان تجمعی (CLS) و تعامل با رنگ بعدی (INP) محاسبه شود.

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

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

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

• رویدادهای FP، FCP و LCP اضافی ممکن است برای پیمایش های نرم دوباره ارسال شوند. گزارش تجربه کاربر Chrome (CrUX) این مقادیر اضافی را نادیده می‌گیرد، اما ممکن است بر نظارت بر اندازه‌گیری کاربر واقعی (RUM) در سایت شما تأثیر بگذارد. اگر نگرانی دارید با ارائه دهنده RUM خود مشورت کنید که آیا این بر اندازه گیری ها تأثیر می گذارد. برای پیمایش های نرم به بخش اندازه گیری Core Web Vitals مراجعه کنید.
• ویژگی navigationID جدید (و اختیاری) در ورودی های عملکرد شما ممکن است لازم باشد در کد برنامه شما با استفاده از این ورودی ها در نظر گرفته شود.
• فقط مرورگرهای مبتنی بر Chromium از این حالت جدید پشتیبانی خواهند کرد. در حالی که بسیاری از معیارهای جدیدتر فقط در مرورگرهای مبتنی بر Chromium در دسترس هستند، برخی (FCP، LCP) در مرورگرهای دیگر در دسترس هستند و ممکن است همه به آخرین نسخه مرورگرهای مبتنی بر Chromium ارتقا داده نشده باشند. بنابراین توجه داشته باشید که برخی از کاربران ممکن است معیارهای ناوبری نرم را گزارش ندهند.
• به‌عنوان یک ویژگی آزمایشی جدید که به‌طور پیش‌فرض فعال نیست، سایت‌ها باید این ویژگی را آزمایش کنند تا مطمئن شوند که هیچ گونه عوارض جانبی ناخواسته دیگری وجود ندارد.

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

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

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

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

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

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

توجه: توجه: FP و FCP هنوز برای ناوبری نرم گزارش نشده اند .

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

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

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

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

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

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

ویژگی navigationId مربوط به PerformanceEntry را می توان برای پیوند دادن رویداد به 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;

این pageUrl باید برای گزارش معیارها در برابر URL صحیح استفاده شود، نه URL فعلی که ممکن است در گذشته استفاده کرده باشد.

دریافت startTime ناوبری های نرم

زمان شروع ناوبری را می توان به روشی مشابه بدست آورد:

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

startTime زمان تعامل اولیه (به عنوان مثال، یک کلیک دکمه) است که ناوبری نرم را آغاز کرد.

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

اندازه گیری حیاتی وب اصلی در هر ناوبری نرم

برای گنجاندن ورودی‌های متریک ناوبری نرم، باید includeSoftNavigationObservations: true در فراخوان observe عملکرد خود وارد کنید.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

پرچم اضافی includeSoftNavigationObservations در روش observe علاوه بر فعال کردن ویژگی پیمایش نرم در Chrome مورد نیاز است. این انتخاب صریح در سطح ناظر عملکرد برای اطمینان از این است که ناظران عملکرد موجود از این ورودی‌های اضافی غافلگیر نمی‌شوند ، زیرا هنگام تلاش برای اندازه‌گیری Core Web Vitals برای ناوبری نرم، باید ملاحظات اضافی در نظر گرفته شود.

زمان‌بندی‌ها همچنان با توجه به زمان شروع ناوبری "سخت" اصلی بازگردانده می‌شوند. بنابراین برای محاسبه LCP برای یک ناوبری نرم، به عنوان مثال، باید زمان بندی LCP را بگیرید و زمان شروع ناوبری نرم مناسب را همانطور که قبلا توضیح داده شد کم کنید تا زمان بندی نسبت به ناوبری نرم به دست آورید. به عنوان مثال، برای LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

FP، FCP، و LCP برای ناوبری نرم فقط رنگ‌های جدید را اندازه‌گیری می‌کنند. این می تواند منجر به یک LCP متفاوت شود، برای مثال، از یک بار سرد از آن ناوبری نرم به یک بار نرم.

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

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

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

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

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

یک روش ساده‌تر، گزارش TTFB 0 برای پیمایش‌های نرم‌افزار است - به روشی مشابه که برای بازیابی حافظه پنهان به عقب/ جلو توصیه می‌کنیم. این روشی است که کتابخانه web-vitals برای ناوبری نرم استفاده می کند.

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

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

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

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

برای اندازه‌گیری هر دو، باید از رویدادهای جدیدی که ممکن است در حالت ناوبری نرم (به عنوان مثال، چندین رویداد FCP و LCP اضافی) منتشر شوند، آگاه باشید و با نهایی کردن این معیارها در زمان مناسب، و در عین حال نادیده گرفتن آینده، به طور مناسب با آن‌ها رفتار کنید. رویدادهایی که فقط برای ناوبری های نرم اعمال می شوند.

از کتابخانه 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';

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});

اطمینان حاصل کنید که معیارها در برابر URL صحیح همانطور که قبلا ذکر شد گزارش شده است.

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

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

اخطار: پیاده سازی web-vitals در حال توسعه فعال است و با انتشار تغییرات جدید در آن شعبه در معرض تغییر است. از FCP در پیمایش‌های نرم‌افزار پشتیبانی نمی‌کند، زیرا به کار اساسی بیشتری در Chrome نیاز دارد. کسانی که از کتابخانه جاوا اسکریپت web-vitals استفاده می کنند، اگر به دنبال استفاده از این کتابخانه در سایت های تولیدی هستند، باید از این موضوع آگاه باشند و باید یک نسخه محلی بگیرند و آن نسخه را آزمایش کنند و شعبه را برای تغییرات نظارت کنند.

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

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

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

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

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

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

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

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

بازخورد

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

• اکتشافی ناوبری نرم و استانداردسازی .
• مشکلات پیاده سازی کروم مربوط به آن اکتشافی ها.
• بازخورد کلی موارد حیاتی وب در [e-mail] .

تغییرات

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

نتیجه گیری

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

قدردانی ها

تصویر کوچک توسط جردن مادرید در Unsplash