کش عقب/ جلو (یا BFCache) یک بهینه سازی مرورگر است که پیمایش فوری به عقب و جلو را امکان پذیر می کند. ما در حال ایجاد تغییراتی در Chrome BFCache هستیم که به طور بالقوه بر افزونه ها با استفاده از درگاه های پیام تأثیر می گذارد. اگر یک برنامه افزودنی Chrome دارید که از پیام‌رسانی برای برقراری ارتباط بین اسکریپت‌های محتوا و برنامه‌های افزودنی خود استفاده می‌کند، برای آشنایی با نحوه آزمایش و تطبیق برنامه‌های افزودنی خود، ادامه مطلب را بخوانید.
پورت پیام افزودنی
برنامه های افزودنی از طریق ارسال پیام با اسکریپت محتوا یا سایر برنامه های افزودنی ارتباط برقرار می کنند. پیام‌ها را می‌توان با استفاده از درخواست‌های یک‌باره با فراخوانی runtime.sendMessage() و tabs.sendMessage() یا با استفاده از یک پورت پیام قابل استفاده مجدد ارسال کرد. تا زمانی که پورت فعال است، هم اسکریپت محتوا و هم اسکریپت پس‌زمینه افزونه می‌توانند از پورت برای ارسال پیام به یکدیگر استفاده مجدد کنند.
برای اطلاعات بیشتر، به ارسال پیام مراجعه کنید.
کش عقب / جلو
وقتی از صفحه‌ای که برای BFCache واجد شرایط است حرکت می‌کنید، مرورگر به صفحه اجازه می‌دهد تمام وضعیت آن در حافظه باقی بماند اما در حالت غیرفعال باقی بماند. اگر کاربر یک پیمایش تاریخچه (به عقب یا جلو) به صفحه ذخیره شده انجام دهد، مرورگر سعی می کند صفحه را از BFCache بازیابی کند. این باعث می شود که ناوبری سریعتر شود و تجربه مرور کاربر را بهبود بخشد.
در حالی که صفحه در BFCache است، در حالت منجمد است که در آن هیچ اجرای جاوا اسکریپت مجاز نیست. این بدان معناست که نمی تواند پیام هایی را که دریافت می کند پردازش کند.
برای اطلاعات بیشتر، حافظه پنهان عقب/ جلو را ببینید.
تاثیر درگاه های پیام افزودنی بر BFCache
به طور خلاصه، ارسال پیام های افزودنی به یک صفحه در BFCache ممکن است باعث حذف حافظه پنهان شود و بر عملکرد تأثیر بگذارد.
هنگامی که صفحه ای با یک پورت پیام پسوند باز در BFCache ذخیره می شود، درگاه باز می ماند. هنگامی که صفحه از BFCache بازیابی شد، مرجع قدیمی درگاه پیام همچنان می‌تواند توسط کارکنان خدمات افزونه برای ارسال پیام‌ها به اسکریپت محتوا استفاده شود.
با این حال، اگر برنامه افزودنی در حالی که صفحه هنوز در BFCache است، سعی کند پیامی را از طریق آن پورت پیام ارسال کند، پیام ارسال می‌شود اما به طور کامل تحویل نمی‌شود زیرا کنترل‌کننده ثابت است. استدلال و رسیدگی به این وضعیت برای برنامه افزودنی چالش برانگیز است، زیرا هر دو صف و حذف پیام مشکلات خاص خود را دارند.
برای جلوگیری از وارد شدن به مشکلات مربوط به پیام‌های از دست رفته، در پیاده‌سازی فعلی کروم، صفحه میزبان را از BFCache خارج می‌کند و پیام را نادیده می‌گیرد. اگر کاربر به صفحه بازگردد، صفحه جدید بارگیری می‌شود و به برنامه افزودنی اجازه می‌دهد اتصال جدیدی را راه‌اندازی کند.
از سوی دیگر، این پیاده‌سازی سناریوهایی را که در آن BFCache اعمال می‌شود، محدود می‌کند و دستاوردهای عملکرد را محدود می‌کند، به ویژه برای برنامه‌های افزودنی با مکانیسم‌های پخش یا ضربان قلب که به طور منظم پیام‌ها را به همه اتصالات ارسال می‌کنند. علاوه بر این، زمانی که برنامه افزودنی پیامی به اسکریپت محتوا ارسال می‌کند، اخراج ایجاد می‌شود، توسعه‌دهندگان وب هیچ ابزاری برای جلوگیری از تخلیه صفحات خود ندارند.
برای بهبود عملکرد کلی، قصد داریم یک رفتار پورت پیام جدید را معرفی کنیم.
رفتار جدید: بستن کانال پیام هنگامی که صفحه در BFCache ذخیره می شود
با شروع در Chrome 123، هنگامی که صفحه‌ای با درگاه پیام برنامه افزودنی باز در BFCache ذخیره می‌شود، کانال پیام زیربنایی به طور فعال از سمت اسکریپت محتوا بسته می‌شود. در نتیجه، تمام پورت های پیام بسته می شوند و برنامه افزودنی یک رویداد onDisconnect را دریافت می کند.
از آنجایی که کانال بسته است، تا زمانی که صفحه در BFCache است، هیچ پیامی به آن ارسال نخواهد شد. بنابراین، صفحه به دلیل پسوند حذف نخواهد شد.
حتی پس از بازیابی صفحه از BFCache، کانال پیام بسته دوباره باز نمی شود. روش توصیه شده برای نویسندگان برنامه های افزودنی این است که به رویدادهای چرخه عمر صفحه گوش دهند و هنگامی که صفحه از BFCache بازیابی می شود، یک اتصال جدید راه اندازی کنند، همانطور که در مثال زیر نشان داده شده است.
// content script
let port;
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// The page is restored from BFCache, set up a new connection.
port = chrome.runtime.connect();
}
});
درباره مکالمه WECG از نمایندگان مرورگرهای مختلف (تحت شماره 474) بیشتر بخوانید.
آیا من تحت تاثیر قرار گرفته ام؟
رفتار جدید پشت پرچمی در Chrome 123 در دسترس خواهد بود تا بتوانید کد خود را آزمایش کنید. برای اطلاعات بیشتر جدول زمانی را ببینید. از مراحل زیر برای آزمایش برنامه افزودنی خود استفاده کنید. توجه داشته باشید که این فقط یک آزمایش ساده را ارائه می‌کند، و ما شما را تشویق می‌کنیم که Chrome را با این ویژگی برای مدتی فعال اجرا کنید، زیرا پیش‌بینی اینکه چه ویژگی‌هایی در برنامه افزودنی ممکن است باعث ایجاد مشکل شوند دشوار است.
- مطمئن شوید که نسخه کروم حداقل 123 باشد. در حالت ایده‌آل، از Chrome Canary استفاده کنید که یک هشدار اضافی برای آسان‌تر کردن آزمایش دارد.
Chrome را با پرچم زیر راه اندازی کنید:
--disable-features=DisconnectExtensionMessagePortWhenPageEntersBFCacheبه صفحه‌ای بروید که بدون اجرای برنامه افزودنی برای BFCache واجد شرایط است (به عنوان مثال، برخی از سایت‌های ساده مانند https://example.com/ ). برای اطمینان از بازیابی آن از BFCache ، آموزش BFCache را دنبال کنید.
برنامه افزودنی را نصب و فعال کنید و دوباره واجد شرایط بودن BFCache را آزمایش کنید. می‌توانید به‌صورت دستی از آنجا خارج شوید، مدتی صبر کنید که به اندازه کافی طولانی باشد تا برنامه افزودنی شما پیامی به صفحه BFCached ارسال کند و به عقب برگردید.
اگر به دلیل اخراج صفحه باید به‌جای BFCache بارگیری می‌شد، و مشکلی که مانع بازیابی می‌شود «ExtensionSentMessageToCachedFrame» است، ممکن است برنامه افزودنی تحت تأثیر این تغییر قرار گیرد.
در Chrome Canary 124.0.6315.0 و جدیدتر، هشدار زیر را نیز در صفحه مشاهده خواهید کرد:
هنگامی که صفحه ای از BFCache بازیابی نمی شود، هشدار نشان داده می شود.
هنگامی که تأیید شد که برنامه افزودنی در حال ارسال پیام به صفحه BFCache است، می‌توانید این مراحل را دنبال کنید تا آزمایش را اجباری فعال کنید و مشاهده کنید که آیا منطقی شکست می‌خورد.
Chrome را با پرچم زیر راه اندازی کنید:
--enable-features=DisconnectExtensionMessagePortWhenPageEntersBFCacheبه صفحه ای بروید که به دلیل "ExtensionSentMessageToCachedFrame" از BFCache بازیابی نشده است.
دور و برگردید. صفحه باید اکنون بازیابی شود، اما کانال پیام بین اسکریپت محتوا و سرویس دهنده باید قطع شود.
آزمایش کنید که آیا برنامه افزودنی همچنان طبق معمول کار می کند، اگر نه، باید به صورت دستی همانطور که در بخش قبل نشان داده شد دوباره وصل شوید.
جدول زمانی انتشار
ما قصد داریم به تدریج رفتار جدید را با شروع Chrome 123 افزایش دهیم. در اینجا طرح دقیق آمده است:
| تاریخ | نقطه عطف برنامه ریزی شده |
|---|---|
| 15 فوریه | آزمایش رفتار جدید را در Chrome Canary و Dev شروع کنید. |
| 1 مارس | آزمایش رفتار جدید در Chrome Beta را شروع کنید. |
| 18 مارس | رفتار جدید را برای 4 درصد از کاربران در Chrome Stable منتشر کنید. |
| 25 مارس | رفتار جدید را برای 50 درصد از کاربران در Chrome Stable منتشر کنید. |
| 2 آوریل | آزمایش به پایان می رسد و رفتار جدید را به عنوان پیش فرض تبدیل می کند. |