Chrome 151’s Soft Navigations API بالاخره به اپلیکیشن‌های تک‌صفحه‌ای (SPAs) اجازه می‌دهد Core Web Vitals را برای هر ناوبری درون‌برنامه‌ای گزارش کنند، اما مجموعه داده‌های CrUX گوگل همچنان فقط اولین بارگذاری سخت (hard load) را ثبت می‌کند و توسعه‌دهندگان را با دو تصویر متفاوت از عملکرد مواجه می‌سازد.

چرا معیارهای SPA عقب مانده‌اند

Core Web Vitals شامل Largest Contentful Paint (LCP)، Interaction-to-Next-Paint (INP) و Cumulative Layout Shift (CLS) بر اساس hard navigations تعریف شده‌اند. یک hard navigation یک سند کاملاً جدید را واکشی کرده و وضعیت صفحه قبلی را از بین می‌برد.

اپلیکیشن‌های SPA که با React، Vue، Next.js یا فریم‌ورک‌های مشابه ساخته شده‌اند، به‌ندرت hard navigations را فعال می‌کنند. کلیک کردن روی یک لینک، URL را از طریق History API به‌روزرسانی می‌کند، داده‌ها را در پس‌زمینه واکشی می‌کند و محتوا را بدون بارگذاری مجدد کامل (full reload) جایگزین می‌کند. Performance API فعلی فقط بارگذاری اولیه صفحه را ثبت می‌کند، بنابراین LCP و INP هرگز تأخیری (latency) را که کاربران هنگام جابجایی از یک مسیر (route) به مسیر دیگر حس می‌کنند، مشاهده نمی‌کنند.

این نقطه کور باعث می‌شود داشبوردهایی که داده‌ها را از Performance Timeline یا Chrome User Experience Report (CrUX) گوگل دریافت می‌کنند، دچار خطا شوند. این داشبوردها اغلب یک LCP عالی برای صفحه «shell» نشان می‌دهند، در حالی که بارگذاری‌های کندتر در بخش‌های عمیق‌تر اپلیکیشن را نادیده می‌گیرند و این باعث ایجاد حس کاذب از سلامت عملکرد می‌شود.

Chrome’s Soft Navigations API

کروم ۱۵۱ از Soft Navigations API رونمایی کرد؛ مجموعه‌ای از روش‌های اکتشافی (heuristics) که برخی تعاملات SPA را به عنوان ناوبری‌های واقعی در نظر می‌گیرد. این API سه سیگنال را زیر نظر می‌گیرد:

  • یک تعامل توسط کاربر (کلیک، ضربه، رویداد صفحه‌کلید)
  • تغییر URL از طریق History API
  • رویدادهای paint بعدی که محتوای جدید را رندر می‌کنند

وقتی هر سه مورد با هم همسو باشند، کروم یک soft navigation را در Performance Timeline ثبت می‌کند و Core Web Vitals برای آن انتقال، دقیقاً مانند یک hard navigation محاسبه می‌شوند. کتابخانه متن‌باز web-vitals در تاریخ ۲۱ جولای از این قابلیت پشتیبانی کرد، بنابراین توسعه‌دهندگان می‌توانند با استفاده از همان API که در حال حاضر استفاده می‌کنند، شروع به استخراج این اعداد کنند.

در عمل، اکنون شما برای هر تغییر مسیر (route change) یک مقدار LCP، یک INP که نشان‌دهنده تأخیر واقعی آخرین ورودی کاربر است، و یک CLS که تغییرات چیدمان (layout shifts) پس از یک soft navigation را ثبت می‌کند، مشاهده خواهید کرد.

شکاف داده‌ها: Chrome در مقابل CrUX

سرویس CrUX گوگل (Chrome User Experience Report) قدرت‌بخش PageSpeed Insights، Search Console و به‌طور غیرمستقیم، سیگنال‌های رتبه‌بندی است. CrUX همچنان فقط داده‌های مربوط به hard-navigation را تجمیع می‌کند.

در نتیجه، شما با دو جریان داده‌ی سازگار اما متفاوت روبرو هستید:

  • ابزارهای داخلی که Performance Timeline را می‌خوانند، اکنون LCP، INP و CLS را در سطح مسیر (route-level) نشان می‌دهند و دیدگاهی واقع‌بینانه از آنچه کاربران در یک SPA تجربه می‌کنند، ارائه می‌دهند.
  • مجموعه داده‌های عمومی گوگل همچنان فقط معیارهای مربوط به اولین بارگذاری صفحه را نشان می‌دهند، که همان چیزی است که Search Console گزارش می‌دهد و الگوریتم‌های رتبه‌بندی گوگل به آن استناد می‌کنند.

هر دو درست هستند؛ آن‌ها فقط لحظات متفاوتی را اندازه‌گیری می‌کنند. تکیه کردن صرف به Search Console می‌تواند باعث پنهان ماندن افت عملکرد (performance regressions) شود که پس از بارگذاری اولیه رخ می‌دهد، در حالی که داشبوردهای داخلی به تنهایی بازتاب‌دهنده معیار پایه (baseline) مورد استفاده گوگل برای SEO نخواهند بود.

مواردی که توسعه‌دهندگان باید مراقب آن‌ها باشند

  • پشتیبانی مرورگر – در حال حاضر Soft Navigations API فقط در مرورگرهای مبتنی بر Chromium وجود دارد. Safari و Firefox فاقد معادل آن هستند، بنابراین باید منطق جایگزین (fallback logic) را برای بخشی از مخاطبان خود حفظ کنید.
  • محدودیت‌های اکتشافی (Heuristic limits) – این API بر اساس مجموعه‌ای از نشانه‌ها، یک soft navigation را تشخیص می‌دهد. اگر اپلیکیشن شما محتوا را بدون تغییر URL به‌روزرسانی کند (مثلاً مودال‌ها یا اسکرول بی‌نهایت)، ممکن است این API آن انتقال‌ها را از دست بدهد و باعث ایجاد شکاف در داده‌ها شود.
  • تست کردن قبل از اعتماد کردن – از آنجایی که تشخیص بر اساس روش‌های اکتشافی است، مجموعه‌ای از تعاملات دنیای واقعی را روی اپلیکیشن خود اجرا کنید و معیارهای گزارش‌شده را با زمان‌بندی دستی (مثلاً با استفاده از performance.mark) مقایسه کنید. تنها پس از تأیید دقت، باید تصمیمات بهینه‌سازی خود را بر اساس اعداد جدید اتخاذ کنید.

خلاصه کلام

کروم ۱۵۱ به توسعه‌دهندگان SPA این قابلیتِ مدت‌ها منتظر مانده را می‌دهد که LCP، INP و CLS را برای هر تغییر مسیر درون‌برنامه‌ای اندازه‌گیری کنند، اما داده‌های رتبه‌بندی گوگل همچنان فقط اولین بارگذاری سخت را منعکس می‌کند. تا زمانی که CrUX خود را با این تغییر هماهنگ کند، تیم‌ها باید با دو مجموعه داده موازی دست و پنجه نرم کنند: یکی که داستان واقعی کاربر را روایت می‌کند و دیگری که رتبه‌بندی‌های جستجو را هدایت می‌کند. ایجاد تعادل بین هر دو — و آماده شدن برای پشتیبانی گسترده‌تر مرورگرها — کلید حفظ SPAهای «عملکرد-محور» در یک اکوسیستم وب رقابتی خواهد بود.