منتشر شده: ۲۱ اکتبر ۲۰۲۴، آخرین بهروزرسانی: ۹ سپتامبر ۲۰۲۵
کروم در حال ایجاد تغییری است تا امکان استفاده از حافظه پنهان (bfcache) را برای صفحاتی که از Cache-Control: no-store استفاده میکنند، در مواقعی که استفاده از آن ایمن است، فراهم کند. ببینید این برای توسعهدهندگان به چه معناست.
پیشینه
تنظیم Cache-Control: no-store به عنوان HTTP Header نشانهای است که صفحه نباید در حافظه پنهان HTTP ذخیره شود. این باید برای صفحاتی که حاوی دادههای حساس هستند - به عنوان مثال، برای صفحاتی که کاربر وارد سیستم میشود - استفاده شود، اما دستورالعمل no-store اغلب در صفحاتی بدون دادههای حساس استفاده میشود.
با bfcache، به جای اینکه وقتی کاربر از صفحه خارج میشود، صفحه را از بین ببریم، تخریب را به تعویق میاندازیم و اجرای JS را متوقف میکنیم. اگر کاربر به زودی برگردد، صفحه را دوباره قابل مشاهده میکنیم و اجرای JS را از حالت مکث خارج میکنیم. این منجر به پیمایش تقریباً فوری صفحه برای کاربر میشود.
اگرچه طبق مشخصات HTML الزامی نیست، مرورگرها معمولاً Cache-Control: no-store به عنوان سیگنالی برای جلوگیری از قرار دادن صفحه در bfcache در نظر میگیرند. این بزرگترین دلیل عدم استفاده از bfcache است ، برای حدود ۱۷٪ از پیمایشهای تاریخچه در موبایل و ۷٪ از پیمایشهای تاریخچه در دسکتاپ. این بدان معناست که این صفحات از بازیابی سریع بهرهمند نمیشوند و باید صفحه را به طور کامل، از جمله هرگونه فراخوانی شبکه، اجرای جاوا اسکریپت و رندر، مجدداً بارگذاری کنند.
اغلب Cache-Control: no-store برای جلوگیری از مشکلات ذخیرهسازی در هنگام تغییر سایت تنظیم میشود، اما این دلیل هنگام استفاده از bfcache اهمیت کمتری دارد، زیرا کل صفحه تقریباً طوری بازیابی میشود که انگار از ابتدا باز بوده است.
چگونه کروم این رفتار را تغییر میدهد
کروم اعلام کرده است که قصد دارد این رفتار را تغییر دهد، اما رویکردی محتاطانه نسبت به این تغییر در پیش گرفته است. ما از زمان کروم ۱۱۶ آزمایشهایی را انجام دادهایم که به تدریج درصد بارگذاری صفحات را افزایش میدهد و انتظار میرود این میزان در مارس و آوریل ۲۰۲۵ به ۱۰۰٪ برسد.
دادههای حساس
اگرچه تحلیل ما نشان میدهد که اکثر پیمایشهای برگشتی یا رو به جلو شامل دادههای حساس نیستند و بنابراین باید واجد شرایط bfcache باشند، مواردی وجود دارد که صفحات نباید در bfcache قرار گیرند. به عنوان مثال، هنگام خروج از سیستم، نباید بتوان با پیمایش به جلو یا عقب، صفحهای را که وارد سیستم شده است، بازیابی کرد.
برای جلوگیری از این امر، کروم در صورت تغییر در کوکیها یا سایر روشهای احراز هویت، صفحه را از bfcache حذف میکند.
علاوه بر این، استفاده از API های زیر برای صفحاتی که از Cache-Control: no-store استفاده میکنند، همچنان آن صفحات را برای bfcache واجد شرایط نمیکند:
علاوه بر این، اگر یک صفحه Cache-control: no-store درخواست fetch یا XHR ارسال کند و آن صفحه در پاسخ خود Cache-control: no-store را برگرداند، این امر باعث حذف صفحه نیز میشود زیرا ممکن است حاوی دادههای حساس باشد.
توجه داشته باشید که این لیست جامعی از APIهایی که از استفاده bfcache جلوگیری میکنند نیست، بلکه APIهایی هستند که bfcache را در صفحات Cache-Control: no-store مسدود میکنند، حتی اگر در زمان ترک صفحه مورد استفاده قرار نگیرند.
همچنین مدت زمان bfcache برای صفحات Cache-Control: no-store به ۳ دقیقه کاهش یافته است (از ۱۰ دقیقه برای صفحاتی که از Cache-Control: no-store استفاده نمیکنند) تا ریسک بیشتر کاهش یابد.
انصراف سازمانی
شرکتها اغلب نرمافزارها و دستگاههای اشتراکی دارند که بهروزرسانی آنها دشوار است. سیاست AllowBackForwardCacheForCacheControlNoStorePageEnabled را میتوان غیرفعال کرد تا همچنان از استفاده bfcache برای صفحات Cache-Control: no-store جلوگیری شود.
آزمایش تغییر
توسعهدهندگان میتوانند این تغییر را با پرچم زیر آزمایش کنند:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
اگر هر یک از استثنائات قبلی اعمال شود - برای مثال، تغییر کوکیها - این امر مانع از استفاده صفحه از bfcache با دلیل "صفحاتی که منبع اصلی آنها دارای Cache-Control: no-store نمیتواند حافظه پنهان عقب/جلو را وارد کند" میشود که در تستر bfcache ابزار توسعه کروم نشان داده میشود.
شما میتوانید از این صفحه تست bfcache برای آزمایش با و بدون این پرچم استفاده کنید.
آنچه توسعهدهندگان باید بدانند
اگرچه توسعهدهندگان برای بهرهمندی کاربرانشان از این افزایش استفاده از bfcache نیازی به ایجاد هیچ تغییری نخواهند داشت، اما مواردی وجود دارد که ممکن است در نتیجه این امر لازم باشد در نظر بگیرند. این موارد، ملاحظات مشابهی بودند که سایر سایتها ممکن است در راهاندازی اولیه bfcache در دسامبر 2021 تجربه کرده باشند.
آیا توسعهدهندگان هنوز هم باید هدف خود را کاهش استفاده از Cache-Control: no-store قرار دهند؟
bfcache برای Cache-Control: no-store تحت شرایط محدود ذکر شده قبلی و فقط برای کروم فعال است. سایر مرورگرها ممکن است همچنان هنگام استفاده Cache-Control: no-store استفاده از bfcache را مسدود کنند.
بهترین روش همچنان به حداقل رساندن استفاده از Cache-Control: no-store .
تأثیر بر عملکرد
دلیل ایجاد این تغییر، بهبود تجربه کاربری صفحات برای کاربران وب است. ما در اولین راهاندازی bfcache شاهد بهبودهای قابل توجهی در Core Web Vitals بودیم و اکنون میخواهیم همین بهبودها را به سایتهای بیشتری ارائه دهیم.
صاحبان سایت ممکن است با انتشار این بهروزرسانی، شاهد بهبود در Core Web Vitals خود باشند و بتوانند میزان استفاده از bfcache را در CrUX، از جمله در CrUX Vis، اندازهگیری کنند .
تحلیل تأثیر
صفحات بازیابیشده از 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 ما مراجعه کنید.
بازخورد
ما مشتاق شنیدن بازخورد در مورد این تغییر هستیم که میتواند در ردیاب مشکل کروم با استفاده از کامپوننت bfcache ارائه شود.
نتیجهگیری
ما هیجانزدهایم که میتوانیم از bfcache برای صفحات بیشتری استفاده کنیم تا تجربه کاربری صفحات را برای کاربران بهبود بخشیم. ما این تغییر را با دقت بررسی کردهایم و رویکرد ما این است که این تغییر را تا حد امکان ایمن اجرا کنیم. امیدواریم اطلاعات ارائه شده در اینجا به توسعهدهندگان کمک کند تا این تغییر را درک کنند و هرگونه تغییر لازم را برای جلوگیری از مشکلات هنگام وقوع آن انجام دهند.