کش عقب و جلو

فیلیپ والتون
بری پولارد

کش عقب/ جلو (یا bfcache) یک بهینه سازی مرورگر است که پیمایش فوری به عقب و جلو را امکان پذیر می کند. به طور قابل توجهی تجربه مرور را بهبود می بخشد، به خصوص برای کاربرانی که شبکه ها یا دستگاه های کندتر دارند.

این صفحه نحوه بهینه سازی صفحات خود را برای bfcache در همه مرورگرها شرح می دهد.

سازگاری با مرورگر

bfcache سال‌هاست که در فایرفاکس و سافاری ، در دسک‌تاپ و موبایل پشتیبانی می‌شود.

از نسخه 86، Chrome bfcache را برای پیمایش بین سایتی در اندروید برای درصد کمی از کاربران فعال کرد. در نسخه های بعدی، پشتیبانی اضافی به آرامی منتشر شد. از نسخه 96، bfcache برای همه کاربران Chrome در دسک‌تاپ و موبایل فعال است.

مبانی bfcache

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

ویدیوی زیر نشان می دهد که چقدر bfcache می تواند سرعت ناوبری را افزایش دهد:

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

داده‌های استفاده از Chrome نشان می‌دهد که از هر 10 پیمایش در دسک‌تاپ، 1 و در تلفن همراه 1 مورد به عقب یا جلو هستند. به همین دلیل، bfcache پتانسیل صرفه جویی زیادی در زمان و استفاده از داده دارد.

"کش" چگونه کار می کند

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

با این حال، ایجاد یک عکس فوری از یک صفحه در حافظه، شامل پیچیدگی هایی از نظر بهترین روش حفظ کد در حال پیشرفت است. به عنوان مثال، چگونه می‌توانید تماس‌های setTimeout() را در جایی که زمانی که صفحه در bfcache است، به زمان پایان رسیده است، مدیریت کنید؟

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

در برخی موارد، مانند وقفه ها و وعده ها، این خطر نسبتا کم است، اما در موارد دیگر می تواند منجر به رفتار گیج کننده یا غیرمنتظره شود. به عنوان مثال، اگر مرورگر وظیفه‌ای را که برای تراکنش IndexedDB لازم است متوقف کند، می‌تواند بر دیگر برگه‌های باز در همان مبدا تأثیر بگذارد، زیرا همان پایگاه‌های داده IndexedDB را می‌توان به‌طور همزمان توسط چندین تب دسترسی داشت. در نتیجه، مرورگرها معمولاً سعی نمی‌کنند صفحات را در وسط یک تراکنش IndexedDB یا در حین استفاده از APIهایی که ممکن است بر صفحات دیگر تأثیر بگذارد، کش کنند.

برای جزئیات بیشتر در مورد اینکه چگونه استفاده از API بر واجد شرایط بودن bfcache صفحه تأثیر می گذارد، به بهینه سازی صفحات خود برای bfcache مراجعه کنید.

bfcache و iframes

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

اگر یک iframe تعبیه‌شده از APIهایی استفاده کند که این را مسدود می‌کنند، فریم اصلی نیز می‌تواند از استفاده از bfcache مسدود شود. برای جلوگیری از این امر می توان از خط مشی مجوزهای تنظیم شده بر روی قاب اصلی یا استفاده از ویژگی های sandbox استفاده کرد.

bfcache و برنامه های تک صفحه ای (SPA)

از آنجا که bfcache با ناوبری های مدیریت شده توسط مرورگر کار می کند، برای "ناوبری نرم" در یک برنامه تک صفحه ای (SPA) کار نمی کند. با این حال، bfcache هنوز هم می تواند در هنگام خروج و بازگشت به SPA کمک کند.

API برای مشاهده bfcache

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

رویدادهای اصلی که برای مشاهده bfcache استفاده می‌شوند ، رویدادهای انتقال صفحه pageshow و pagehide هستند که توسط اکثر مرورگرها پشتیبانی می‌شوند.

رویدادهای جدیدتر Page Lifecycle ، freeze و resume ، همچنین هنگام ورود یا خروج صفحات از bfcache و همچنین در برخی موقعیت‌های دیگر ارسال می‌شوند، به عنوان مثال، هنگامی که یک برگه پس‌زمینه ثابت می‌شود تا استفاده از CPU به حداقل برسد. این رویدادها فقط در مرورگرهای مبتنی بر Chromium پشتیبانی می‌شوند.

مشاهده کنید که یک صفحه از bfcache بازیابی می شود

رویداد pageshow درست بعد از رویداد load زمانی که صفحه در ابتدا بارگذاری می‌شود و هر زمانی که صفحه از bfcache بازیابی می‌شود فعال می‌شود. رویداد pageshow دارای یک ویژگی persisted است که اگر صفحه از bfcache بازیابی شود true است و در غیر این صورت false . می‌توانید از ویژگی persisted برای تشخیص بارگذاری‌های صفحه معمولی از بازیابی‌های bfcache استفاده کنید. مثلا:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

در مرورگرهایی که از Page Lifecycle API پشتیبانی می‌کنند، رویداد resume زمانی فعال می‌شود که صفحات از bfcache بازیابی می‌شوند (بلافاصله قبل از رویداد pageshow ) و زمانی که کاربر دوباره از یک برگه پس‌زمینه ثابت بازدید می‌کند. اگر می‌خواهید وضعیت صفحه را پس از ثابت شدن (که شامل صفحاتی در bfcache می‌شود) به‌روزرسانی کنید، می‌توانید از رویداد resume استفاده کنید، اما اگر می‌خواهید میزان بازدید bfcache سایت خود را اندازه‌گیری کنید، باید از رویداد pageshow استفاده کنید. در برخی موارد، ممکن است لازم باشد از هر دو استفاده کنید.

برای جزئیات بیشتر در مورد بهترین شیوه های اندازه گیری bfcache، ببینید چگونه bfcache بر تجزیه و تحلیل و اندازه گیری عملکرد تأثیر می گذارد .

مشاهده کنید که یک صفحه وارد bfcache می شود

رویداد pagehide یا زمانی که صفحه ای بارگیری می شود یا زمانی که مرورگر سعی می کند آن را در bfcache قرار دهد فعال می شود.

رویداد pagehide نیز دارای خاصیت persisted است. اگر false است، می توانید مطمئن باشید که آن صفحه قرار نیست وارد bfcache شود. با این حال، persisted true بودن، تضمینی برای ذخیره شدن یک صفحه در حافظه پنهان نیست. این بدان معناست که مرورگر قصد دارد صفحه را کش کند، اما ممکن است عوامل دیگری وجود داشته باشد که کش کردن آن را غیرممکن کند.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

به طور مشابه، رویداد freeze بلافاصله پس از رویداد pagehide فعال می‌شود، در صورت persisted true است، اما این فقط به این معنی است که مرورگر قصد دارد صفحه را کش کند. به دلایلی که بعداً توضیح داده شد، ممکن است همچنان مجبور باشد آن را کنار بگذارد.

صفحات خود را برای bfcache بهینه کنید

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

به جای unload از pagehide استفاده کنید

مهمترین راه برای بهینه سازی برای bfcache در همه مرورگرها این است که هرگز از شنوندگان رویداد unload استفاده نکنید. به جای آن به pagehide گوش دهید، زیرا هم زمانی که صفحه وارد bfcache می شود و هم در هر زمانی که unload فعال می شود.

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

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

در تلفن همراه، کروم و سافاری سعی می‌کنند صفحات را با unload شنوندگان رویداد ذخیره کنند، زیرا غیرقابل اعتماد بودن unload در تلفن همراه، خطر شکستگی را کاهش می‌دهد. Mobile Firefox صفحاتی را که از unload استفاده می کنند برای bfcache واجد شرایط نیستند، به جز در iOS که همه مرورگرها را ملزم به استفاده از موتور رندر WebKit می کند، بنابراین مانند Safari رفتار می کند.

برای تعیین اینکه آیا جاوا اسکریپت در صفحات شما از unload استفاده می کند یا خیر، توصیه می کنیم از ممیزی no-unload-listeners در Lighthouse استفاده کنید.

برای اطلاعات در مورد برنامه Chrome برای منسوخ کردن unload ، به لغو رویداد بارگیری مراجعه کنید.

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

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

Permission-Policy: unload()

فقط beforeunload شنوندگان را به صورت مشروط اضافه کنید

رویداد beforeunload صفحات شما را برای bfcache واجد شرایط نمی کند. با این حال، غیر قابل اعتماد است، بنابراین توصیه می کنیم فقط در مواقع ضروری از آن استفاده کنید.

یک مثال مورد استفاده برای beforeunload ، هشدار دادن به کاربر است که تغییرات ذخیره نشده ای دارد که در صورت خروج از صفحه، آنها را از دست خواهند داد. در این مورد، توصیه می‌کنیم فقط زمانی که کاربر تغییرات ذخیره‌نشده‌ای دارد، beforeunload شنونده‌ها را اضافه کنید و بلافاصله پس از ذخیره تغییرات ذخیره‌نشده، آن‌ها را حذف کنید، مانند کد زیر:

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

استفاده از Cache-Control: no-store

Cache-Control: no-store یک هدر HTTP است که سرورهای وب می‌توانند روی پاسخ‌هایی تنظیم کنند که به مرورگر دستور می‌دهد پاسخ را در هیچ حافظه پنهان HTTP ذخیره نکند. این برای منابع حاوی اطلاعات حساس کاربر، مانند صفحات پشت ورود به سیستم استفاده می شود.

اگرچه bfcache یک کش HTTP نیست، مرورگرها از لحاظ تاریخی صفحات را از bfcache حذف می‌کنند، زمانی که Cache-Control: no-store در منبع صفحه تنظیم شده باشد (اما نه در هیچ منبع فرعی). Chrome با حفظ حریم خصوصی کاربر روی تغییر این رفتار کار می‌کند، اما به‌طور پیش‌فرض، صفحاتی که از Cache-Control: no-store استفاده می‌کنند برای bfcache واجد شرایط نیستند.

برای بهینه سازی برای bfcache، از Cache-Control: no-store فقط در صفحات حاوی اطلاعات حساس که نباید در حافظه پنهان ذخیره شوند، استفاده کنید.

برای صفحاتی که می‌خواهند همیشه محتوای به‌روز ارائه کنند، اما اطلاعات حساسی را شامل نمی‌شوند، از Cache-Control: no-cache یا Cache-Control: max-age=0 استفاده کنید. اینها به مرورگر می‌گویند که قبل از ارائه محتوا، آن را مجدداً تأیید کند و بر واجد شرایط بودن bfcache صفحه تأثیری نمی‌گذارد زیرا بازیابی صفحه از bfcache شامل حافظه پنهان HTTP نمی‌شود.

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

پس از بازیابی bfcache، داده های قدیمی یا حساس را به روز کنید

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

به عنوان مثال، اگر کاربر از یک سایت در یک رایانه عمومی خارج شود و کاربر بعدی دکمه بازگشت را کلیک کند، داده های قدیمی از bfcache ممکن است شامل داده های خصوصی باشد که اولین کاربر انتظار داشت هنگام خروج از سیستم پاک شود.

برای جلوگیری از چنین موقعیت‌هایی، اگر event.persisted true است، همیشه صفحه را بعد از یک رویداد pageshow به‌روزرسانی کنید:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

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

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

بازیابی تبلیغات و bfcache

می‌تواند وسوسه‌انگیز باشد که از استفاده از bfcache خودداری کنید تا صفحه شما بتواند مجموعه‌ای از تبلیغات جدید را در هر پیمایش عقب یا جلو ارائه دهد. با این حال، این برای عملکرد سایت بد است و به طور مداوم تعامل تبلیغات را افزایش نمی دهد. به عنوان مثال، یک کاربر ممکن است قصد داشته باشد به صفحه ای بازگردد تا روی تبلیغ کلیک کند، اما اگر صفحه به جای بازیابی از bfcache دوباره بارگیری شود، ممکن است تبلیغ دیگری را نشان دهد. توصیه می کنیم از تست A/B برای تعیین بهترین استراتژی برای صفحه خود استفاده کنید.

برای سایت‌هایی که می‌خواهند آگهی‌ها را در بازیابی bfcache بازیابی کنند، می‌توانید فقط آگهی‌ها را در رویداد pageshow زمانی که event.persisted true است، بدون تأثیر بر عملکرد صفحه، مانند این مثال برچسب Google Publishing، بازخوانی کنید. برای اطلاعات بیشتر در مورد بهترین شیوه ها برای سایت خود، با ارائه دهنده تبلیغات خود تماس بگیرید.

از مراجع window.opener اجتناب کنید

در مرورگرهای قدیمی‌تر، اگر صفحه‌ای با استفاده از window.open() از پیوندی با target=_blank ، بدون تعیین rel="noopener" باز می‌شود، صفحه باز شده به شی پنجره صفحه باز شده ارجاع می‌دهد.

علاوه بر این که یک خطر امنیتی است ، یک صفحه با مرجع window.opener غیر تهی را نمی توان با خیال راحت در bfcache قرار داد، زیرا ممکن است صفحاتی را که سعی در دسترسی به آن داشته باشند، خراب کند.

برای جلوگیری از این خطرات، از rel="noopener" برای جلوگیری از ایجاد مراجع window.opener استفاده کنید. این رفتار پیش فرض در تمام مرورگرهای مدرن است. اگر سایت شما نیاز به باز کردن پنجره و کنترل آن با استفاده از window.postMessage() یا با ارجاع مستقیم به شی پنجره دارد، نه پنجره باز شده و نه بازکننده برای bfcache واجد شرایط نیستند.

قبل از اینکه کاربر حرکت کند، اتصالات باز را ببندید

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

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

با این حال، اگر این وظایف به APIهایی متصل شوند که از صفحات دیگر در همان مبدا نیز قابل دسترسی هستند (به عنوان مثال: IndexedDB، Web Locks، و WebSockets)، توقف موقت آنها می تواند با جلوگیری از اجرای کد روی آن صفحات، آن صفحات را خراب کند.

در نتیجه، برخی از مرورگرها در صورت داشتن یکی از موارد زیر سعی نمی‌کنند صفحه‌ای را در bfcache قرار دهند:

اگر صفحه شما از هر یک از این APIها استفاده می‌کند، اکیداً توصیه می‌کنیم که اتصالات را ببندید و ناظران را در طول رویداد pagehide یا freeze حذف یا قطع کنید. این به مرورگر اجازه می‌دهد تا به‌طور ایمن صفحه را بدون خطر تأثیرگذاری بر سایر برگه‌های باز ذخیره کند. سپس، اگر صفحه از bfcache بازیابی شد، می‌توانید در طول رویداد pageshow یا resume دوباره آن APIها را باز کنید یا دوباره به آن متصل شوید.

مثال زیر نشان می دهد که چگونه می توان با بستن یک اتصال باز در شنونده رویداد pagehide ، اطمینان حاصل کرد که صفحاتی که از IndexedDB برای bfcache استفاده می کنند، واجد شرایط هستند:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

تست کنید تا مطمئن شوید صفحات شما قابل کش هستند

Chrome DevTools می‌تواند به شما کمک کند صفحات خود را آزمایش کنید تا مطمئن شوید برای bfcache بهینه هستند و هر مشکلی را که ممکن است مانع از واجد شرایط بودن آنها شود را شناسایی کنید.

برای تست یک صفحه:

  1. به صفحه کروم بروید.
  2. در DevTools، به Application > Back-Forward Cache بروید.
  3. روی دکمه Run Test کلیک کنید. سپس DevTools سعی می‌کند به دور و برگردد تا تعیین کند آیا صفحه را می‌توان از bfcache بازیابی کرد یا خیر.
پنل کش عقب به جلو در DevTools
پانل Cache Back-Forward در DevTools.

اگر آزمایش موفقیت آمیز باشد، پانل "بازیابی از حافظه پنهان عقب به جلو" را گزارش می دهد. اگر ناموفق باشد، پانل دلیل آن را نشان می دهد.

اگر دلیل آن چیزی است که می توانید به عنوان یک توسعه دهنده به آن بپردازید، پانل آن را به عنوان Actionable علامت گذاری می کند.

DevTools گزارش شکست در بازیابی صفحه از bfcache
یک تست bfcache ناموفق با یک نتیجه قابل اجرا.

در این تصویر، استفاده از یک شنونده رویداد unload باعث می شود صفحه برای bfcache واجد شرایط نباشد . می‌توانید این مشکل را با تغییر از unload به استفاده از pagehide برطرف کنید:

انجام دادن
window.addEventListener('pagehide', ...);
نکن
window.addEventListener('unload', ...);

Lighthouse 10.0 همچنین یک حسابرسی bfcache اضافه کرد که آزمایش مشابهی را انجام می دهد. برای اطلاعات بیشتر، به اسناد حسابرسی bfcache مراجعه کنید.

چگونه bfcache بر تجزیه و تحلیل و اندازه گیری عملکرد تأثیر می گذارد

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

در واقع، احتمالاً در حال حاضر بازدیدهای صفحه از سایر مرورگرهایی که bfcache را پیاده‌سازی می‌کنند، کمتر گزارش می‌دهید، زیرا اکثر کتابخانه‌های تحلیلی محبوب، بازیابی‌های bfcache را به‌عنوان بازدید از صفحه جدید ردیابی نمی‌کنند.

برای گنجاندن بازیابی‌های bfcache در تعداد بازدید از صفحه خود، شنوندگان را برای رویداد pageshow تنظیم کنید و ویژگی persisted را بررسی کنید.

مثال زیر نحوه انجام این کار را با Google Analytics نشان می دهد. سایر ابزارهای تحلیلی احتمالاً از منطق مشابهی استفاده می کنند:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

نسبت ضربه bfcache خود را اندازه گیری کنید

برای شناسایی صفحاتی که هنوز از bfcache استفاده نمی کنند، نوع پیمایش را برای بارگذاری صفحه به صورت زیر اندازه گیری کنید:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

نسبت ضربه های bfcache خود را با استفاده از تعداد پیمایش های back_forward و back_forward_cache محاسبه کنید.

دلایلی که ممکن است پیمایش به عقب یا جلو از bfcache استفاده نکند شامل رفتار کاربر زیر است:

  • خروج و راه اندازی مجدد مرورگر
  • کپی کردن یک برگه
  • بستن و بازیابی یک برگه

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

به همین دلیل، صاحبان وب‌سایت‌ها نمی‌توانند انتظار 100% نسبت ضربه bfcache را برای همه پیمایش‌های back_forward داشته باشند. با این حال، اندازه گیری نسبت آنها می تواند به شناسایی صفحاتی که از استفاده از bfcache جلوگیری می کنند کمک کند.

تیم Chrome API NotRestoredReasons را اضافه کرده است تا به افشای دلایل عدم استفاده صفحات از bfcache کمک کند تا توسعه دهندگان بتوانند نرخ بازدید bfcache خود را بهبود بخشند.

اندازه گیری عملکرد

bfcache همچنین می تواند بر معیارهای عملکرد جمع آوری شده در این زمینه تأثیر منفی بگذارد، به ویژه معیارهایی که زمان بارگذاری صفحه را اندازه گیری می کنند.

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

چند راه برای مقابله با این موضوع وجود دارد. یکی این است که تمام معیارهای بارگذاری صفحه را با نوع پیمایش مربوطه آن ها حاشیه نویسی کنید: navigate ، reload ، back_forward یا prerender . این به شما امکان می دهد عملکرد خود را در این انواع پیمایش نظارت کنید، حتی اگر توزیع کلی منحرف شود. ما این رویکرد را برای معیارهای بارگذاری صفحه غیر کاربر محور مانند زمان تا اولین بایت (TTFB) توصیه می کنیم.

برای معیارهای کاربر محور مانند Core Web Vitals ، گزینه بهتر این است که مقداری را گزارش کنید که با دقت بیشتری آنچه را که کاربر تجربه می کند، نشان دهد.

تاثیر بر Core Web Vitals

Core Web Vitals تجربه کاربر از یک صفحه وب را در ابعاد مختلف (سرعت بارگذاری، تعامل، ثبات بصری) اندازه گیری می کند. مهم است که معیارهای Core Web Vitals شما منعکس کننده این واقعیت باشد که کاربران بازیابی bfcache را به عنوان ناوبری سریعتر از بارگذاری صفحه پیش فرض تجربه می کنند.

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

  • برای بزرگترین رنگ محتوایی (LCP) ، از دلتا بین مهر زمانی رویداد pageshow و مهر زمانی فریم نقاشی شده بعدی استفاده کنید، زیرا همه عناصر در قاب به طور همزمان نقاشی می شوند. در مورد بازیابی bfcache، LCP و FCP یکسان هستند.
  • برای Interaction to Next Paint (INP) ، به استفاده از Performance Observer موجود خود ادامه دهید، اما مقدار CLS فعلی را به 0 بازنشانی کنید.
  • برای تغییر چیدمان تجمعی (CLS) ، به استفاده از مشاهده عملکرد موجود خود ادامه دهید، اما مقدار CLS فعلی را به 0 بازنشانی کنید.

برای جزئیات بیشتر در مورد اینکه چگونه bfcache بر هر متریک تأثیر می گذارد، به صفحات راهنمای متریک Core Web Vitals فردی مراجعه کنید. برای مثالی خاص از نحوه پیاده‌سازی نسخه‌های bfcache این معیارها، به PR مراجعه کنید که آنها را به کتابخانه web-vitals JS اضافه می‌کند .

منابع اضافی