Chrome در حال ایجاد تغییری است تا امکان استفاده از حافظه پنهان (bfcache) به عقب/ جلو برای صفحاتی که از Cache-Control: no-store استفاده می‌کنند، در صورتی که انجام این کار ایمن باشد، ایجاد می‌کند. معنی آن برای توسعه دهندگان را بیابید.
پس زمینه
تنظیم Cache-Control: no-store به عنوان سربرگ HTTP سیگنالی است که نشان می دهد صفحه نباید در حافظه پنهان HTTP ذخیره شود. این باید برای صفحات حاوی داده های حساس استفاده شود - به عنوان مثال، برای صفحاتی که کاربر وارد سیستم شده است - اما دستورالعمل no-store اغلب در صفحات بدون داده های حساس استفاده می شود.
با bfcache، به‌جای تخریب صفحه‌ای که کاربر از آن خارج می‌شود، تخریب را به تعویق می‌اندازیم و اجرای JS را متوقف می‌کنیم. اگر کاربر به زودی به عقب بازگردد، صفحه را دوباره قابل مشاهده می کنیم و اجرای JS را لغو مکث می کنیم. این منجر به یک ناوبری صفحه تقریباً فوری برای کاربر می شود.
در حالی که مشخصات HTML نیازی به آن ندارد، مرورگرها معمولاً Cache-Control: no-store را به عنوان سیگنالی برای جلوگیری از قرار دادن صفحه در bfcache می گیرند. این بزرگترین دلیلی است که از bfcache استفاده نمی شود ، برای حدود 17٪ از پیمایش های تاریخچه در تلفن همراه و 7٪ از ناوبری های تاریخچه در دسکتاپ. این بدان معناست که این صفحات از بازیابی سریع سود نمی برند و باید صفحه را به طور کامل بارگیری مجدد کنند، از جمله تماس های شبکه، اجرای جاوا اسکریپت و رندر.
اغلب Cache-Control: no-store برای جلوگیری از مشکلات مربوط به کش کردن هنگام تغییر سایت تنظیم می شود، اما این دلیل زمانی که از bfcache استفاده می شود کمتر مرتبط است، زیرا صفحه کامل تقریباً به گونه ای بازیابی می شود که گویی در تمام مدت باز مانده است.
چگونه Chrome این رفتار را تغییر می‌دهد
Chrome اعلام کرده است که قصد دارد این رفتار را تغییر دهد ، اما رویکرد محتاطانه ای را برای این تغییر در پیش گرفته است. ما آزمایش‌هایی را از Chrome 116 اجرا کرده‌ایم و تا همین اواخر این آزمایش‌ها روی 5 درصد بارگیری‌های صفحه اجرا می‌شدند.
ما این میزان بارگیری صفحه را در 2 اکتبر به 10 درصد افزایش دادیم و در نظر داریم این میزان را به 20 درصد از بارگیری صفحه در نوامبر، 50 درصد در اوایل سال آینده افزایش دهیم، و بلافاصله پس از آن، این مورد را به طور کامل راه اندازی کنیم، با انصراف های خاصی که در ادامه مورد بحث قرار خواهد گرفت.
داده های حساس
در حالی که تجزیه و تحلیل ما نشان می‌دهد که اکثر پیمایش‌های عقب یا جلو شامل داده‌های حساس نیستند و بنابراین باید برای bfcache واجد شرایط باشند، مواردی وجود دارد که صفحات نباید در bfcache قرار داده شوند. به عنوان مثال در هنگام خروج از سیستم، نمی توان با پیمایش به عقب یا جلو، یک صفحه وارد شده را بازیابی کرد.
برای جلوگیری از این امر، Chrome صفحه‌ای را از bfcache در مورد تغییرات کوکی‌ها یا سایر روش‌های مجوز حذف می‌کند.
علاوه بر این، استفاده از API های زیر برای صفحاتی که از Cache-Control: no-store همچنان آن صفحات را برای bfcache واجد شرایط نمی کند:
توجه داشته باشید که این لیست جامعی از APIهایی نیست که از استفاده از bfcache جلوگیری می کند، بلکه APIهایی است که bfcache را در Cache-Control: no-store حتی اگر در زمان خروج از صفحه استفاده نمی شوند.
مهلت زمانی bfcache برای Cache-Control: no-store نیز به 3 دقیقه کاهش می یابد (از 10 دقیقه استفاده شده برای صفحاتی که از Cache-Control: no-store ) برای کاهش بیشتر خطر.
شرکتی انتخاب می کند
شرکت‌ها اغلب نرم‌افزارها و دستگاه‌های مشترک به‌روزرسانی سختی دارند. خط مشی AllowBackForwardCacheForCacheControlNoStorePageEnabled را می توان برای جلوگیری از استفاده از bfcache برای صفحات Cache-Control: no-store غیرفعال کرد.
آزمایش تغییر
توسعه دهندگان می توانند این تغییر را با پرچم زیر آزمایش کنند:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
اگر هر یک از استثناهای قبلی اعمال شود - به عنوان مثال، تغییر کوکی ها - این باعث می شود صفحه از bfcache استفاده نکند با دلیل "صفحاتی که منبع اصلی آنها Cache-Control: no-store نمی تواند حافظه پنهان را به عقب و جلو وارد کند." در آزمایش‌کننده bfcache Chrome DevTools نشان داده می‌شود.
می توانید از این صفحه آزمایشی bfcache برای آزمایش با و بدون این پرچم استفاده کنید.
آنچه توسعه دهندگان باید بدانند
در حالی که توسعه دهندگان برای بهره مندی کاربران از این استفاده بیشتر از bfcache نیازی به ایجاد هیچ تغییری نخواهند داشت، مواردی وجود دارد که ممکن است در نتیجه این امر لازم باشد آنها را در نظر بگیرند. اینها ملاحظات مشابهی بود که سایر سایت ها ممکن است در راه اندازی اولیه bfcache در دسامبر 2021 تجربه کرده باشند.
تاثیر بر عملکرد
دلیلی که ما این تغییر را انجام می دهیم بهبود تجربه صفحه برای کاربران در وب است. هنگامی که برای اولین بار bfcache را راه اندازی کردیم، شاهد پیشرفت های قابل توجهی در Core Web Vitals بودیم، و اکنون می خواهیم همان پیشرفت ها را به سایت های بیشتری بیاوریم.
صاحبان سایت ممکن است با انتشار این برنامه شاهد بهبودی در Core Web Vitals خود باشند و می توانند میزان استفاده از bfcache را در CrUX از جمله در داشبورد CrUX اندازه گیری کنند .
تجزیه و تحلیل تاثیر
صفحات بازیابی شده از bfcache به جای بارگیری مجدد صفحه، صفحه قدیمی (از جمله پشته جاوا اسکریپت) را "بازیابی" می کنند. بسیاری از ارائه‌دهندگان محبوب تجزیه و تحلیل، بازیابی‌های bfcache را به‌عنوان بازدیدهای صفحه جدید اندازه‌گیری نمی‌کنند، زیرا این بازیابی‌ها تنها زمانی که در ابتدا بارگیری می‌شوند، باعث ایجاد بازدید از صفحه می‌شوند.
بنابراین ممکن است سایت ها با شروع استفاده از bfcache برای اولین بار، کاهش بارگذاری صفحه را در تجزیه و تحلیل خود مشاهده کنند. توصیه می‌کنیم با تنظیم شنونده‌ها برای رویداد pageshow و بررسی ویژگی‌های persisted ، این موارد را به‌عنوان بازدید از صفحه در نظر بگیرید:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
مدیریت به‌روزرسانی‌ها در بازیابی صفحه
از آنجایی که ممکن است سایت‌ها اکنون استفاده از bfcache را ببینند، زمانی که قبلاً این مورد را ندیده‌اند و زمانی که صفحه به‌طور کامل با داده‌های تازه بارگیری می‌شود، ممکن است توسعه‌دهندگان بخواهند داده‌ها را در یک بازیابی bfcache تازه‌سازی کنند.
به‌روزرسانی‌ها می‌توانند به روشی مشابه ثبت نماهای صفحه اضافی برای تجزیه و تحلیل با استفاده از رویداد pageshow و بررسی ویژگی‌های persisted فعال شوند.
توجه داشته باشید که همه محتواها نیازی به به‌روزرسانی ندارند و کاربران ممکن است ترجیح دهند به محتوایی که قبلاً دیده‌اند «برگردند». به عنوان مثال، بازخوانی فهرستی از مقالات ممکن است به این معنی باشد که کاربر دیگر مقاله ای را که برای مشاهده آن بازگشته است، نمی بیند.
تاثیر بر تبلیغات
مشابه تاثیر تجزیه و تحلیل، اگر تبلیغات فقط در بارگذاری صفحه بارگیری شود، سایت ها ممکن است کاهش در نمایش تبلیغات را مشاهده کنند. تبلیغات را می توان به صورت برنامه نویسی در بازیابی bfcache به روز کرد تا از برابری با بارگذاری کامل صفحه اطمینان حاصل شود، دوباره با استفاده از رویداد pageshow و بررسی ویژگی های persisted ، اما ممکن است همیشه کار درستی نباشد . به مستندات ارائه دهنده آگهی خود در مورد نحوه راه اندازی بارگیری مجدد آگهی مراجعه کنید.
اطلاعات بیشتر در مورد bfcache
برای اطلاعات بیشتر در مورد bfcache، راهنمای فنی جامع bfcache ما را ببینید.
بازخورد
ما مشتاق شنیدن بازخورد در مورد این تغییر هستیم که می تواند در ردیاب مشکل Chrome با استفاده از مؤلفه bfcache ارائه شود.
نتیجه گیری
ما هیجان زده هستیم که مزایای bfcache را به صفحات بیشتری برای بهبود تجربه صفحه برای کاربران بیاوریم. ما این تغییر را به دقت در نظر گرفته‌ایم و رویکرد ما به دنبال آن است که این تغییر را تا حد امکان به صورت ایمن اجرا کنیم. ما امیدواریم که اطلاعات ارائه شده در اینجا به توسعه دهندگان کمک کند تا این تغییر را درک کنند و هر گونه تغییر لازم را برای جلوگیری از بروز مشکلات در هنگام وقوع آن انجام دهند.