‏سنتری حالا bfcache رو اندازه می‌گیره

سنتری تو نسخهٔ ۱۱ SDKهای جاوااسکریپتش یه اینتگریشن جدید به اسم bfcacheMetricsIntegration اضافه کرده. bfcache یا back/forward cache یعنی مرورگر کل صفحه رو (شامل DOM، حافظهٔ جاوااسکریپت و جای اسکرول) فریز می‌کنه و وقتی کاربر Back می‌زنه همونو برمی‌گردونه، پس برگشت تقریباً فوری‌ه. تو مقاله اومده که این اینتگریشن opt-in هست، یعنی پیش‌فرض خاموشه و باید خودت روشنش کنی.

نویسنده می‌گه مشکل اصلی دیده نشدنه: برای ابزارهای مانیتورینگ، یه bfcache hit با «هیچ اتفاقی نیفتاد» فرقی نداره، چون اصلاً page load ای رخ نمی‌ده. یه پارادوکس هم داره؛ هر چی bfcache بهتر کار کنه، داده کمتری جمع می‌شه. از اون طرف مرورگر با heuristic تصمیم می‌گیره و این قاعده‌ها مرتب عوض می‌شن، پس یه لیسنر unload، هدر Cache-Control: no-store، یه کانکشن باز یا بلاکری داخل iframe می‌تونه بی‌خبر صفحه‌ت رو از کش بیرون بندازه.

اینتگریشن سه متریک می‌سازه. browser.bfcache.navigation یه شمارنده‌ست برای هر رفت‌وبرگشت با نتیجهٔ hit یا miss. browser.bfcache.not_restored که فعلاً فقط روی Chromium کار می‌کنه، دلیل خام مرورگر (مثل unload-listener یا websocket) و محل بلاکر (top یا child) رو ثبت می‌کنه. browser.bfcache.reload.duration هم می‌گه اون miss چند میلی‌ثانیه برای کاربر آب خورده، یعنی می‌تونی بر اساس درد واقعی اولویت‌بندی کنی نه تعداد بلاکر.

روشن کردنش یه خطه:

Sentry.init({
  integrations: [
    // other integrations...
    Sentry.bfcacheMetricsIntegration(),
  ],
});

خروجی از جنس application metrics هست، پس داشبورد آمادهٔ از قبل چیده‌شده نمی‌گیری و خودت با داشبوردساز هوش مصنوعی سنتری می‌سازیش، مثلاً «نرخ کل hit تو یه ماه گذشته» یا «کدوم روت‌ها بیشترین miss رو دارن». hit و miss روی مرورگرهای مدرن کار می‌کنه و دلیل‌های دقیق وابسته به API ‌ای به اسم notRestoredReasons هست که هنوز همه‌جا نیومده. سنتری می‌گه Core Web Vitals رو هم داره به این ناوبری‌ها وصل می‌کنه، چون صفحهٔ برگشته page load نداشت و تو اون آمار غایب بود.

نکات کلیدی:

• اینتگریشن bfcacheMetricsIntegration تو SDKهای جاوااسکریپت سنتری نسخهٔ ۱۱ اومده و opt-in هست
• سه متریک: شمارندهٔ ناوبری با نتیجهٔ hit/miss، شمارندهٔ دلیل‌های not-restored، و توزیع مدت زمان reload بعد از miss
• دلیل‌های تفصیلی miss فعلاً فقط روی Chromium در دسترسه، چون به API notRestoredReasons وصله
• چیزهای ساده‌ای مثل لیسنر unload یا هدر Cache-Control: no-store می‌تونن صفحه رو از bfcache خارج کنن
• متریک browser.bfcache.reload.duration هزینهٔ واقعی miss رو نشون می‌ده، نه حدس سرعت حالت ایده‌آل