توضیحات
این افزونه قبلاً با نام «No-cache BFCache» شناخته میشد که باید اعتراف کنیم نامی تخصصی و نامناسب بود و دامنه آن بیش از حد محدود بود.
این افزونه پیمایش فوری بازگشت/پیشروی را از طریق bfcache مرورگر فعال میکند. این کار با حذف دستورالعمل no-store از سرآیند پاسخ Cache-Control انجام میشود، که وردپرس به طور پیشفرض هنگام فراخوانی nocache_headers() ارسال میکند. این اتفاق عمدتاً زمانی رخ میدهد که کاربر وارد شده باشد، اما برخی افزونهها ممکن است این سرآیندهای «عدم کش» (no-cache) را در صفحاتی مانند سبد خرید یا تسویه حساب در یک سایت تجارت الکترونیک ارسال کنند. پس از فعالسازی، برای مشاهده تأثیر، باید از وردپرس خارج شوید و دوباره وارد شوید و اطمینان حاصل کنید که گزینه «مرا به خاطر بسپار» تیک خورده است. با این حال، ممکن است افزونه، پوسته یا پیکربندی سرور دیگری فعال باشد که صفحات را به دلیل سایر دلایل مسدودکننده، واجد شرایط bfcache نداند. با این وجود، حذف no-store همچنان پیمایشهای بازگشت/پیشروی را سرعت میبخشد زیرا صفحات ممکن است از کش HTTP مرورگر ارائه شوند و نیاز به دانلود مجدد HTML از سرور را از بین ببرند. این یک افزونه ویژگی (feature plugin) برای پیادهسازی #63636 در هسته وردپرس است.
پست وبلاگ: ناوبری بازگشت/پیشروی فوری در وردپرس
سرعت پیمایش صفحات در وردپرس در نسخه ۶.۸ با معرفی بارگذاری پیشدستانه (Speculative Loading) جهش بزرگی داشت. با این حال، به طور پیشفرض بارگذاری پیشدستانه در وردپرس برای فعالسازی بارگذاریهای فوری پیکربندی نشده است، که نیازمند اشتیاق غیرمحافظهکارانه با حالت پیشرندر (prerender) است؛ همه سایتها حتی نمیتوانند به دلیل مشکلات سازگاری، مانند ابزارهای تحلیلگر (analytics)، و نگرانیهای مربوط به پایداری با پیشرندرهای استفاده نشده (مثلاً افزایش بار سرور و فشار بر پهنای باند/پردازنده کاربر) در پیشرندر شرکت کنند. در حالی که بارگذاری پیشدستانه (یعنی Speculation Rules API) نسبتاً جدید است و در حال حاضر فقط در مرورگرهای کرومیوم (مانند کروم و اج) پشتیبانی میشود، فناوری وب پلتفرم بسیار قدیمیتری وجود دارد که پیشرندر را فعال میکند و در همه مرورگرها پشتیبانی میشود: کش بازگشت/پیشروی (bfcache). این بارگذاری فوری شامل هیچ ترافیک شبکه و بار پردازنده نمیشود، زیرا صفحات قبلاً بازدید شده در حافظه ذخیره میشوند. طبق مقاله web.dev در مورد کش بازگشت/پیشروی:
دادههای استفاده از کروم نشان میدهد که ۱ مورد از هر ۱۰ پیمایش در دسکتاپ و ۱ مورد از هر ۵ پیمایش در موبایل، بازگشت یا پیشروی هستند. با فعال بودن bfcache، مرورگرها میتوانند انتقال داده و زمان صرف شده برای بارگذاری میلیاردها صفحه وب را در هر روز حذف کنند!
همچنین از طریق ویدیوی زیر بیشتر بیاموزید:
به طور معمول، وردپرس یک سرآیند Cache-Control با دستورالعمل no-store را زمانی که کاربر وارد شده است ارسال میکند. این کار باعث از کار افتادن bfcache مرورگر میشود، به این معنی که پیمایش به عقب یا جلو در مرورگر مستلزم دریافت مجدد صفحات از سرور و اجرای مجدد جاوا اسکریپت روی صفحه است. نتیجه میتواند تجربهای کند در ناوبری باشد، نه تنها هنگام پیمایش در مدیریت وردپرس (ویدیوی دمو جتپک و ویدیوی دمو زیر را ببینید) بلکه هنگام پیمایش در بخش کاربری سایت. علاوه بر این، عدم وجود bfcache میتواند باعث از دست رفتن دادهها شود زمانی که دادهها از طریق رابط کاربری ساخته شده با جاوا اسکریپت وارد شدهاند، زیرا این وضعیت هنگام بازیابی نشدن صفحه از طریق bfcache از دست میرود (ویدیوی دمو ووکامرس و ویدیوی دمو زیر را ببینید).
دلیل اصلی اضافه شدن دستورالعمل no-store در ابتدا به دلیل نگرانی حفظ حریم خصوصی بود که در آن یک کاربر احراز هویت شده ممکن است از وردپرس خارج شود و شخص دیگری به رایانه دسترسی پیدا کند و روی دکمه بازگشت کلیک کند تا محتوای صفحه احراز هویت شده بارگذاری شده از bfcache یا کش HTTP را مشاهده کند. (تیکت #21938 را ببینید.) در عمل، این موضوع به کاربر در یک رایانه اشتراکی بستگی دارد که از مرورگر خارج نشده باشد و نیاز دارد که کاربر مخرب قبل از حذف صفحه از bfcache اقدام کند (مثلاً کروم دارای مهلت زمانی ۱۰ دقیقهای است).
برای رسیدگی به این نگرانی حریم خصوصی، یک محافظ برای جلوگیری از بازیابی صفحات از bfcache و کش HTTP پس از خروج کاربر در نظر گرفته شده است:
هنگام احراز هویت در وردپرس، یک کوکی «توکن نشست bfcache» همراه با سایر کوکیهای احراز هویت تنظیم میشود. این کوکی HTTP-only نیست تا بتوان آن را در جاوا اسکریپت خواند؛ این یک رشته تصادفی است که برای هیچ هدف دیگری استفاده نمیشود. هنگامی که یک صفحه احراز هویت شده ارائه میشود، این توکن نشست bfcache در HTML و همچنین اسکریپتی که مقدار این کوکی را میخواند گنجانده میشود. هنگامی که کاربر از صفحه خارج میشود و سپس به آن باز میگردد، اسکریپتی در صفحه بررسی میکند که آیا توکن نشست فعلی در کوکی با توکن نشست اولیه ارسال شده با صفحه مطابقت دارد یا خیر. اگر آنها مطابقت نداشته باشند (مثلاً به دلیل اینکه کاربر خارج شده یا کاربر دیگری وارد شده است)، محتویات صفحه پاک میشود و صفحه دوباره بارگذاری میشود تا محتوا در دسترس نباشد.
از آنجا که برای نامعتبر کردن صفحات کش شده به جاوا اسکریپت نیاز است، فرم ورود توسعه داده شده تا وضعیت فعال بودن اسکریپت را ارسال کند. تنها زمانی که JS فعال باشد، دستورالعمل no-store از سرآیند پاسخ Cache-Control حذف میشود. این اطمینان میدهد که کاربرانی که جاوا اسکریپت را غیرفعال کردهاند، پس از خروج از سیستم، حفاظت از حریم خصوصی را حفظ میکنند. در نهایت، no-store تنها در صورتی حذف میشود که کاربر تیک گزینه «مرا به خاطر بسپار» را در فرم ورود زده باشد. از آنجا که بسیار بعید است کاربری در یک رایانه اشتراکی این گزینه را تیک بزند، این یک لایه محافظتی اضافی فراهم میکند (که البته ممکن است در نهایت زیادهروی به نظر برسد). یک ایموجی ✨ در کنار چکباکس در دکمهای نمایش داده میشود که یک پاپاور (popover) را باز میکند و این قابلیت را تبلیغ میکند. اگر میخواهید از این حالت اختیاری (و آن درخشش) انصراف دهید تا همه کاربران وارد شده از bfcache بهرهمند شوند، میتوانید از فیلتر nocache_bfcache_use_remember_me_as_opt_in در یک افزونه سفارشی یا پوسته خود استفاده کنید:
add_filter( 'nocache_bfcache_use_remember_me_as_opt_in', '__return_false' );
هنگامی که این افزونه دستورالعمل no-store را حذف میکند، همچنین اطمینان میدهد که دستورالعمل private به جای آن ارسال میشود: «دستورالعمل پاسخ private نشان میدهد که پاسخ میتواند فقط در یک کش خصوصی (مانند کشهای محلی در مرورگرها) ذخیره شود.» وردپرس از تیکت #57627 به بعد دستورالعمل private را ارسال میکند. این دستورالعمل تضمین میکند که پروکسیها صفحات احراز هویت شده را کش نکنند. علاوه بر اطمینان از وجود private، این افزونه همچنین no-cache، max-age=0 و must-revalidate را اضافه میکند و در عین حال از حذف public اطمینان حاصل میکند، همه اینها برای محافظت بیشتر در برابر هرگونه پروکسی با پیکربندی نادرست که ممکن است پاسخ خصوصی را کش کند.
دمو: پیمایش در مدیریت وردپرس
بدون bfcache:
با bfcache:
دمو: پیمایش در بخش کاربری وردپرس
بدون bfcache: پیشنویس بهروزرسانی فعالیت بادیپرس هنگام خروج از صفحه قبل از ارسال، از دست میرود. فید فعالیت و توییت باید با هر پیمایش بازگشت/پیشروی بازسازی شوند.
با bfcache: پیشنویس بهروزرسانی فعالیت بادیپرس هنگام خروج از صفحه بدون ارسال، حفظ میشود. فید فعالیت و توییت هنگام پیمایش به صفحات بازدید شده قبلی از طریق دکمههای بازگشت/پیشروی، نیازی به بازسازی ندارند.
عکسهای صفحه
چکباکس «مرا به خاطر بسپار» اکنون دارای یک دکمه ✨ است که یک پاپاور را باز میکند. 
پاپاور مزایای کلیک روی چکباکس «مرا به خاطر بسپار» را توضیح میدهد. 
صفحات از bfcache ارائه میشوند، در حالی که قبلاً با مشکلی مانند MainResourceHasCacheControlNoStoreکه در پنل «Back/forward cache» در تب Application ابزارهای توسعهدهنده کروم نمایش داده میشد، شکست میخوردند.
نصب
نصب از طریق وردپرس
- در مدیریت وردپرس به افزونهها > افزودن بروید.
- عبارت Instant Back/Forward را جستجو کنید.
- افزونه بازگشت/پیشروی فوری را نصب و فعال کنید.
- از وردپرس خارج شوید و دوباره با تیک زدن گزینه «مرا به خاطر بسپار» وارد شوید.
همچنین میتوانید از طریق Git Updater با استفاده از نشانی گیتهاب افزونه نصب و بهروزرسانی کنید.
نصب دستی
- فایل ZIP افزونه را از WordPress.org دانلود کنید. (همچنین میتوانید یک نسخه توسعه ZIP از گیتهاب دانلود کنید؛ یا اگر یک کلون محلی از مخزن دارید، دستور
npm run plugin-zipرا اجرا کنید.) - در مدیریت وردپرس به افزونهها > افزودن افزونه تازه بروید.
- روی بارگذاری افزونه کلیک کنید.
- فایل
nocache-bfcache.zipرا از سیستم خود که در مرحله ۱ دانلود کردید انتخاب کنید و روی نصب کن کلیک کنید. - روی دکمه فعالسازی افزونه کلیک کنید.
- از وردپرس خارج شوید و دوباره با تیک زدن گزینه «مرا به خاطر بسپار» وارد شوید.
سوالات متداول
-
در مورد ارائه محتوای قدیمی در صفحات کش شده چطور؟
-
لطفاً بخش محتوای قدیمی در کش صفحات در پست وبلاگ بالا را ببینید.
-
این افزونه به کدام تیکتهای هسته وردپرس مربوط میشود؟
-
عملکرد این افزونه برای هسته وردپرس در تیکت ترک #63636 پیشنهاد شده است: فعالسازی پیمایش فوری صفحات از تاریخچه مرورگر از طریق bfcache هنگام ارسال سرآیندهای «nocache».
سایر تیکتهای هسته مرتبط که این مورد بازبینی میکند:
- #21938: افزودن «no-store» به سرآیند
Cache-Controlبرای جلوگیری از کش شدن تاریخچه منابع مدیریت - #55491: جایگزینی مدیریتکننده رویداد
unloadاز هسته - #57627: سرآیند Cache-Control برای صفحات وارد شده باید شامل
privateباشد - #61942: افزودن «no-store» به سرآیند
Cache-Controlبرای جلوگیری از رفتار غیرمنتظره کش
- #21938: افزودن «no-store» به سرآیند
-
چرا از سرآیند Clear-Site-Data استفاده نمیکنید؟
-
به جای استفاده از مدیریتکننده رویداد
pageshow، یک روش جایگزین برای حذف صفحات از bfcache، ارسالClear-Site-Data: "cache"هنگام خروج است. طبق مستندات MDN، این سرآیند «سیگنالی به کلاینت میفرستد که باید تمام دادههای مرورگر از انواع خاص (کوکیها، ذخیرهسازی، کش) مرتبط با وبسایت درخواستکننده را حذف کند.» طبق Can I Use…، این سرآیند ظاهراً توسط بیش از ۹۱٪ کاربران پشتیبانی میشود و به عنوان «Baseline 2023 Newly available» شناخته میشود اما با یک ستاره. در آزمایشها، به نظر میرسد تنها مرورگرهای مبتنی بر کرومیوم (مانند کروم و اج) هنگام ارسال این سرآیند صفحات را از bfcache حذف میکنند، اما در حال حاضر یک باگ (40233601) وجود دارد که در آن پاسخهای دارای این سرآیند ممکن است ۱۰ تا ۳۰ ثانیه طول بکشد تا بارگذاری شوند. علاوه بر این، فایرفاکس در حال حاضر با این سرآیند صفحات را از bfcache حذف نمیکند، اما مانند مرورگرهای کرومیوم، صفحات را از کش HTTP حذف میکند، به این معنی که صفحات احراز هویت شده هنگام باز کردن مجدد تبهای بسته شده مرورگر در دسترس نخواهند بود. سافاری، با این حال، به نظر نمیرسد صفحات را از bfcache یا کش HTTP حذف کند. در نهایت،Clear-Site-Dataفقط در یک زمینه امن (یعنی روی HTTPS) کار میکند، به این معنی که سایتهای ناامن که هنوز روی HTTP هستند، نگرانی دیگری خواهند داشت.به تمام این دلایل،
Clear-Site-Dataهنوز روش قابل اعتمادی برای نامعتبر کردن صفحات از bfcache نیست. امیدواریم باگ کرومیوم در آینده نزدیک برطرف شود.سرآیند
Clear-Site-Dataهمچنین در تیکتهای ترک (Trac) شماره #49258 و #57627 ذکر شده بود. -
چرا bfcache در کروم کار میکند با وجود اینکه سایت من از Cache-Control: no-store استفاده میکند؟
-
کروم حتی اکنون ممکن است صفحاتی که با
no-storeارائه میشوند را در bfcache ذخیره کند، اگرچه هنوز سناریوهای شکستی وجود دارد که در آنها bfcache همچنان مسدود خواهد شد. این موارد را میتوان به عنوان مثال در پنل «Back/forward cache» در تب Application ابزارهای توسعهدهنده کروم (Chrome DevTools) مشاهده کرد:JsNetworkRequestReceivedCacheControlNoStoreResource: جاوا اسکریپت در یک صفحه درخواستی به یک منبع ارائه شده با دستورالعملno-storeارسال میکند (مانند REST API یا admin-ajax).CacheControlNoStoreCookieModified: جاوا اسکریپت در یک صفحه کوکیها را تغییر میدهد.
این سناریوها اغلب هنگام مرور مدیریت وردپرس رخ میدهند و همچنین هنگام استفاده از افزونههایی مانند ووکامرس یا بادیپرس در بخش کاربری نیز شایع هستند. چنین شکستهای bfcache همچنین میتواند زمانی رخ دهد که به وردپرس وارد نشدهاید، زیرا هر زمان که سایتی
nocache_headers()را فراخوانی کند، ممکن است اتفاق بیفتد. برای مثال، ووکامرس در حال حاضر زمانی که یک کاربر احراز هویت نشده در صفحات سبد خرید، تسویه حساب یا حساب کاربری من باشد،nocache_headers()را فراخوانی میکند (اما woocommerce#58445 را ببینید که از نسخه ۱۰.۱ برای حذف این مورد ادغام شده است). این سناریوهای شکست زمانی که دستورالعملno-storeاز سرآیندCache-Controlحذف شود، رخ نمیدهند. -
چه چیزی مانع از کارکرد bfcache میشود؟
-
مقاله کش بازگشت/پیشروی در web.dev را برای دلایلی که ممکن است bfcache مسدود شود، ببینید. همچنین لیست دلایل مسدودکننده در MDN را مشاهده کنید. همچنین ویدیوی یوتیوب در مورد اشکالزدایی bfcache، بارگذاری فوری صفحه خود را بسازید را ببینید.
اگر میتوانید افزونه یا پوستهای را که
Cache-Control: no-storeرا تنظیم میکند یا کار دیگری انجام میدهد که bfcache را مسدود میکند (مانند افزودن یک مدیریتکننده رویدادunload) شناسایی کنید، لطفاً مشکل را در انجمن پشتیبانی مربوط به آن افزونه/پوسته گزارش دهید.افزونه آزمایشگاه عملکرد همچنین شامل یک تست سلامت سایت برای بررسی اینکه آیا سرور سرآیند
Cache-Control: no-storeرا ارسال میکند یا خیر، میباشد. -
چرا bfcache در سایت من که در Pantheon میزبانی میشود کار نمیکند؟
-
سایتهای پانتئون (Pantheon) دارای یک افزونه ضروری (must-use) هستند که شامل برخی قابلیتهای کش صفحه است. هنگامی که کاربر وارد شده است، در حال حاضر یک سرآیند پاسخ
Cache-Control: no-cache, no-store, must-revalidateارسال میکند. این مانع از کارکرد bfcache میشود. یک پول ریکوئست (pull request) برای رفع این مشکل باز شده است، اما در این فاصله میتوانید با جلوگیری از ارسال این سرآیند با کد افزونه زیر، مشکل را برطرف کنید:// Workaround for Pantheon MU plugin sending Cache-Control: no-store which prevents bfcache. // See https://github.com/pantheon-systems/pantheon-mu-plugin/pull/94 add_filter( 'pantheon_skip_cache_control', static function (): bool { return is_admin() || is_user_logged_in(); } );
نقد و بررسیها
توسعه دهندگان و همکاران
“بازگشت/پیشروی فوری” نرم افزار متن باز است. افراد زیر در این افزونه مشارکت کردهاند.
مشارکت کنندگان
“بازگشت/پیشروی فوری” به 3 زبان ترجمه شده است. با تشکر از مترجمین برای همکاری و کمکهایشان.
ترجمه “بازگشت/پیشروی فوری” به زبان شما.
علاقه مند به توسعه هستید؟
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
گزارش تغییرات
1.3.1
- تغییر نام افزونه به «Instant Back/Forward» (https://github.com/westonruter/nocache-bfcache/pull/49)
1.3.0
- افزودن فیلتر
nocache_bfcache_use_remember_me_as_opt_inبرای انصراف از انتخاب اختیاری (#29) - اطمینان از وجود تابع
is_user_logged_in()قبل از استفاده (#37) - بهروزرسانی plugin-check به نسخه ۱.۶ و استفاده مجدد از مجموعه قوانین PHPCS (#27)
1.2.0
- افزودن داده مسیر برای فایل CSS (#15)
- اجرای update-dotorg-assets فقط به صورت دستی در workflow_dispatch (#16)
- بررسی استفاده از سرآیند
Clear-Site-Dataبرای نامعتبرسازی bfcache، اما در نهایت به دلیل ناسازگاریهای مرورگر حذف شد (#17, #20) - حذف روش اخراج از bfcache با Broadcast Channel (#18)
- ادغام با فرمهای ورود بخش کاربری (#19)
- بهبود پایداری تشخیص ارسال فرم ورود (#21)
- پیادهسازی نامعتبرسازی کش HTTP (#23)
1.1.0
- افزودن گردشکار GHA (#1)
- ادغام با مودال ورود موقت (wp-auth-check) (#2)
- ثبت هشدار هنگام خروج وقتی ناوبری صفحه از bfcache بازیابی نمیشود زمانی که
WP_DEBUGفعال است (#3) - حفظ CCNS زمانی که کاربر جاوا اسکریپت را غیرفعال کرده است (#4)
- بهبود نامعتبرسازی bfcache از طریق BroadcastChannel، ذخیره توکن در نشست کاربر، تبلیغ ویژگی در ورود (#5)
- آمادهسازی برای انتشار در دایرکتوری dotorg (#6)
- رفع سازگاری با افزونه Two-Factor و هر افزونهای با صفحات ورود میانی (#7)
- رفع نامعتبرسازی bfcache از طریق Broadcast Channel (#8)
- بهبود مستندات با اطلاعاتی درباره جتپک و افزودن سوال متداول (#9)
- افزودن سوال متداول برای اینکه چرا bfcache ممکن است در Pantheon کار نکند (#10)
- افزودن فایلهای (assets) دایرکتوری افزونه dotorg (#11)
- پیکربندی Dependabot (#12)
- افزودن گردشکارهای استقرار (#14)
1.0.0
- انتشار اولیه.