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

Barry Pollard

Michal Mocny

تاریخ انتشار: 1 فوریه 2023، آخرین به روز رسانی: 31 جولای 2025

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

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

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

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

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

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

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

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

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

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

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

• یک رویداد PerformanceTiming soft-navigation پس از شناسایی هر ناوبری نرم منتشر می شود.
• پس از فعل و انفعالاتی که باعث ایجاد رنگ معنی دار می شود، یک interaction-contentful-paint جدید منتشر می شود. این می تواند برای اندازه گیری بزرگترین رنگ محتوایی (LCP) برای پیمایش های نرم استفاده شود، زمانی که چنین رنگی یک ناوبری نرم را در بر می گیرد. توجه داشته باشید که اجرای اصلی این بازنشانی متریک largest-contentful-paint که امکان انتشار مجدد آن را فراهم می‌کند، اما ما برای سادگی و همچنین دامنه وسیع‌تر در آینده، روی این رویکرد جایگزین قرار گرفته‌ایم.
• یک ویژگی navigationId به هر یک از زمان‌بندی‌های عملکرد ( first-paint , first-contentful-paint , largest-contentful-paint , interaction-contentful-paint , first-input-delay , event , and layout-shift ) مطابق با مسیریابی ورودی که رویداد مربوط به آن بود (LCP Contentful Lair) مرتبط می شود. Shift (CLS) و Interaction to Next Paint (INP) محاسبه شود و به URL صحیح نسبت داده شود.

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

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

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

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

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

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

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

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

برای توسعه‌دهندگان، این می‌تواند با روشن کردن پرچم در chrome://flags/#soft-navigation-heuristics فعال شود. گزینه های "Enabled Advanced Paint Attribution (Eager Cached Pre-Paint Walk)" گزینه پیشنهادی است و به زودی به صورت پیش فرض تبدیل خواهد شد. یا می توان آن را با استفاده از آرگومان های خط فرمان --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution هنگام راه اندازی Chrome فعال کرد.

برای وب‌سایتی که می‌خواهد این تأثیر را برای همه بازدیدکنندگان خود فعال کند، یک آزمایش اولیه از Chrome 139 اجرا می‌شود که می‌تواند با ثبت‌نام برای آزمایشی و گنجاندن یک عنصر متا با نشانه آزمایشی مبدا در سرصفحه HTML یا HTTP فعال شود. برای اطلاعات بیشتر به پست شروع با آزمایشات مبدا مراجعه کنید.

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

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

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

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

می توانید از 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});

با آخرین تغییرات در API، پرچم includeSoftNavigationObservations دیگر ضروری نیست و احتمالاً در آینده حذف خواهد شد، اما در حال حاضر، علاوه بر فعال کردن ویژگی ناوبری نرم در Chrome ، به این انتخاب صریح در سطح ناظر عملکرد نیاز است.

زمان‌بندی‌ها همچنان نسبت به زمان شروع ناوبری "سخت" اصلی بازگردانده می‌شوند. بنابراین برای محاسبه LCP برای یک ناوبری نرم، به عنوان مثال، باید زمان‌بندی interaction-contentful-paint را در نظر بگیرید و زمان شروع ناوبری نرم مناسب را همانطور که قبلاً توضیح داده شد کم کنید تا زمان‌بندی نسبت به ناوبری نرم به دست آورید. به عنوان مثال، برای 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

LCP برای ناوبری های نرم (محاسبه شده از interaction-contentful-paint ) فقط رنگ های جدید را اندازه گیری می کند. این می تواند منجر به یک 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 را در آینده شکل دهید.

برای 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';

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 معیارهای زیر را برای ناوبری نرم گزارش می کند:

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

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

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

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

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

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

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

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

بازخورد

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

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

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

تغییرات

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

نتیجه گیری

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

قدردانی

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

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