safari bfcache disable

• Español – América Latina
• Português – Brasil
• Tiếng Việt

Back and forward cache

Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience, especially for users with slower networks or devices.

This page outlines how to optimize your pages for bfcache across all browsers.

Browser compatibility

bfcache has been supported in both Firefox and Safari for many years, across desktop and mobile.

Starting in version 86, Chrome enabled bfcache for cross-site navigations on Android for a small percentage of users. In subsequent releases, additional support slowly rolled out. Since version 96, bfcache is enabled for all Chrome users across desktop and mobile.

bfcache basics

bfcache is an in-memory cache that stores a complete snapshot of a page as the user navigates away. With the entire page in memory, the browser can quickly restore it if the user decides to return, instead of needing to repeat all the network requests necessary to load the page.

The following video shows just how much bfcache can speed up navigation:

Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. Because of this, bfcache has the potential to save a great deal of time and data usage.

How the "cache" works

The "cache" used by bfcache is different from the HTTP cache , which plays its own role in speeding up repeat navigations. bfcache is a snapshot of the entire page in memory, including the JavaScript heap, whereas the HTTP cache contains only the responses for previously made requests. Because it's very rare for all requests required to load a page to be fulfullable from the HTTP cache, repeat visits using bfcache restores are always faster than even the best-optimized non-bfcache navigations.

Creating a snapshot of a page in memory, however, involves some complexity in terms of how best to preserve in-progress code. For example, how do you handle setTimeout() calls where the timeout is reached while the page is in the bfcache?

The answer is that browsers pause any pending timers or unresolved promises for pages in bfcache, including almost all pending tasks in the JavaScript task queues , and resume processing tasks if the page is restored from the bfcache.

In some cases, such as for timeouts and promises, this is fairly low risk, but in other cases it can lead to confusing or unexpected behavior. For example, if the browser pauses a task that's required for an IndexedDB transaction , it can affect other open tabs in the same origin, because the same IndexedDB databases can be accessed by multiple tabs simultaneously. As a result, browsers usually won't try to cache pages in the middle of an IndexedDB transaction or while using APIs that might affect other pages.

For more details on how API usage affects a page's bfcache eligibility, see Optimize your pages for bfcache .

The bfcache and iframes

If a page contains embedded iframes, then the iframes themselves are not eligible for the bfcache. For example, if you navigate to another page within an iframe, but then go back, the browser will go "back" within the iframe rather than in the main frame, but the back navigation within the iframe won't use the bfcache.

The main frame can also be blocked from using the bfcache if an embedded iframe uses APIs that block this. The Permissions Policy set on the main frame or the use of sandbox attributes can be used to avoid this.

The bfcache and Single Page Apps (SPA)

Because bfcache works with browser-managed navigations, it doesn't work for "soft navigations" within a single-page app (SPA). However, bfcache can still help when leaving and returning to an SPA.

APIs to observe bfcache

Although bfcache is an optimization that browsers do automatically, it's still important for developers to know when it's happening so they can optimize their pages for it and adjust any metrics or performance measurement accordingly.

The primary events used to observe bfcache are the page transition events pageshow and pagehide , which are supported by most browsers .

The newer Page Lifecycle events, freeze and resume , are also dispatched when pages enter or leave bfcache, as well as in some other situations, for example, when a background tab gets frozen to minimize CPU usage. These events are only supported in Chromium-based browsers.

Observe when a page is restored from bfcache

The pageshow event fires right after the load event when the page is initially loading and any time the page is restored from bfcache. The pageshow event has a persisted property, which is true if the page was restored from bfcache and false otherwise. You can use the persisted property to distinguish regular page loads from bfcache restores. For example:

In browsers that support the Page Lifecycle API, the resume event fires when pages are restored from bfcache (immediately before the pageshow event) and when a user revisits a frozen background tab. If you want to update a page's state after it's frozen (which includes pages in the bfcache), you can use the resume event, but if you want to measure your site's bfcache hit rate, you'd need to use the pageshow event. In some cases, you might need to use both.

For details on bfcache measurement best practices, see How bfcache affects analytics and performance measurement .

Observe when a page is entering bfcache

The pagehide event fires either when a page unloads or when the browser tries to put it in the bfcache.

The pagehide event also has a persisted property. If it's false , you can be confident a that page isn't about to enter the bfcache. However, persisted being true doesn't guarantee that a page will be cached. It means the browser intends to cache the page, but there may be other factors that make it impossible to cache.

Similarly, the freeze event fires immediately after the pagehide event if persisted is true , but that only means the browser intends to cache the page. It might still have to discard it for a number of reasons explained later.

Optimize your pages for bfcache

Not all pages get stored in bfcache, and even when a page does get stored there, it won't stay there indefinitely. The following pages outline what make pages eligible for bfcache, and recommends best practices to maximize the browser's ability to cache your page for better cache-hit rates.

Use pagehide instead of unload

The most important way to optimize for bfcache in all browsers is to never use unload event listeners. Listen for pagehide instead, because it fires both when a page enters bfcache and any time unload fires.

unload is an older feature, originally designed to trigger any time a user navigated away from a page. This is no longer the case , but many web pages still operate on the assumption that browsers use unload in this way, and that after unload triggers, the unloaded page stops existing. This has the potential to break bfcache if the browser tries to cache an unloaded page.

On desktop, Chrome and Firefox make pages with unload listeners ineligible for bfcache, which reduces risk but also causes a lot of pages to not be cached and therefore reload much slower. Safari does try to cache some pages with unload event listeners, but to reduce potential breakage, it doesn't run the unload event when a user navigates away, which makes unload listeners unreliable.

On mobile, Chrome and Safari try to cache pages with unload event listeners, because unload 's unreliability on mobile makes the risk of breakage lower. Mobile Firefox treats pages that use unload as ineligible for the bfcache, except on iOS, which requires all browsers to use the WebKit rendering engine, so it behaves like Safari.

To determine whether any JavaScript on your pages uses unload , we recommend using the no-unload-listeners audit in Lighthouse .

For information on Chrome's plan to deprecate unload , refer to Deprecating the unload event .

Use Permission Policy to prevent unload handlers being used on a page

Some third-party scripts and extensions can add unload handlers to a page, slowing the site down by making it ineligible for bfcache. To prevent this in Chrome 115 and later, use a Permissions Policy .

Only add beforeunload listeners conditionally

The beforeunload event doesn't make your pages ineligible for bfcache. However, it's unreliable, so we recommend only using it when it's absolutely necessary.

An example use case for beforeunload is warning a user that they have unsaved changes they'll lose if they leave the page. In this case, we recommend adding beforeunload listeners only when a user has unsaved changes, and then removing them immediately after the unsaved changes are saved, as in the following code:

Minimize use of Cache-Control: no-store

Cache-Control: no-store is an HTTP header web servers can set on responses that instructs the browser not to store the response in any HTTP cache. It's used for resources containing sensitive user information, such as pages behind a login.

Although bfcache isn't an HTTP cache, browsers have historically excluded pages from bfcache when Cache-Control: no-store is set on the page resource (but not on any subresource). Chrome is working on changing this behavior while maintaining user privacy, but by default, pages using Cache-Control: no-store aren't eligible for bfcache.

To optimize for bfcache, use Cache-Control: no-store only on pages containing sensitive information that must not be cached.

For pages that want to always serve up-to-date content, but don't include sensitive information, use Cache-Control: no-cache or Cache-Control: max-age=0 . These tell the browser to revalidate the content before serving it, and they don't affect a page's bfcache eligibility because restoring a page from bfcache doesn't involve the HTTP cache.

If your content changes minute-by-minute, fetch updates using the pageshow event instead to keep your page up to date as described in the next section.

Update stale or sensitive data after bfcache restore

If your site keeps user state data, and especially if that data includes sensitive user information, it must be updated or cleared after a page is restored from bfcache.

For example, if a user signs out of a site on a public computer and the next user clicks the back button, the stale data from bfcache might include private data that the first user expected to be cleared when they logged out.

To avoid situations like this, always update the page after a pageshow event if event.persisted is true :

For some changes, you might want to force a full reload instead, preserving navigation history for forward navigations. The following code checks for the presence of a site-specific cookie in the pageshow event and reloads if the cookie isn't found:

Ads and bfcache restore

It can be tempting to try to avoid using bfcache so your page can serve a new set of ads on each back or forward navigation. However, this is bad for site performance, and doesn't consistently increase ad engagement. For example, a user might intend to return to a page to click an ad, but if the page is reloaded instead of restored from bfcache, it might show a different ad. We recommend using A/B testing to determine the best strategy for your page.

For sites that want to refresh ads on bfcache restore, you can refresh only the ads on the pageshow event when event.persisted is true without impacting the page performance, as in this Google Publishing Tag example . For more information about best practices for your site, check with your ad provider.

Avoid window.opener references

In older browsers, if a page was opened using window.open() from a link with target=_blank , without specifying rel="noopener" , the opening page would have a reference to the window object of the opened page.

In addition to being a security risk , a page with a non-null window.opener reference can't safely be put into bfcache, because it might break any pages that try to access it.

To avoid these risks, use rel="noopener" to prevent the creation of window.opener references. This is the default behavior in all modern browsers. If your site needs to open a window and control it using window.postMessage() or by directly referencing the window object, neither the opened window nor the opener are eligible for bfcache.

Close open connections before the user navigates away

As mentioned previously, when a page is put into bfcache, it pauses all scheduled JavaScript tasks and resumes them when the page is taken out of the cache.

If these scheduled JavaScript tasks access only DOM APIs, or other APIs isolated to the current page, pausing these tasks while the page isn't visible to the user doesn't cause problems.

However, if these tasks are connected to APIs that are also accessible from other pages in the same origin (for example: IndexedDB, Web Locks, and WebSockets), pausing them can break those pages by preventing code on those pages from running.

As a result, some browsers won't try to put a page in bfcache if it has one of the following:

• An open IndexedDB connection
• In-progress fetch() or XMLHttpRequest
• An open WebSocket or WebRTC connection

If your page is using any of these APIs, we strongly recommend closing connections and removing or disconnecting observers during the pagehide or freeze event. That allows the browser to safely cache the page without the risk of affecting other open tabs. Then, if the page is restored from the bfcache, you can reopen or reconnect to those APIs during the pageshow or resume event.

The following example shows how to ensure that pages using IndexedDB are eligible for bfcache by closing an open connection in the pagehide event listener:

Test to ensure your pages are cacheable

Chrome DevTools can help you test your pages to ensure they're optimized for bfcache, and identify any issues that might prevent them from being eligible.

To test a page:

• Navigate to the page in Chrome.
• In DevTools, go to Application > Back-forward Cache .
• Click the Run Test button. DevTools then tries to navigate away and back to determine whether the page can be restored from bfcache.

If the test is successful, the panel reports "Restored from back-forward cache". If it's unsuccessful, the panel indicates the reason why.

If the reason is something you can address as a developer, the panel marks it as Actionable .

In this image, the use of an unload event listener makes the page ineligible for bfcache. You can fix that by switching from unload to using pagehide :

Lighthouse 10.0 also added a bfcache audit , which performs a similar test. For more information, see the bfcache audit's docs .

How bfcache affects analytics and performance measurement

If you use an analytics tool to track visits to your site, you might notice a decrease in the total number of pageviews reported as Chrome enables bfcache for more users.

In fact, you're likely already underreporting pageviews from other browsers that implement bfcache, because most popular analytics libraries don't track bfcache restores as new pageviews.

To include bfcache restores in your pageview count, set listeners for the pageshow event and check the persisted property.

The following example shows how to do this with Google Analytics. Other analytics tools likely use similar logic:

Measure your bfcache hit ratio

To identify pages that don't yet use bfcache, measure the navigation type for page loads as follows:

Calculate your bfcache hit ratio using the counts for back_forward navigations and back_forward_cache navigations.

Reasons a back or forward navigation might not use bfcache include the following user behavior:

• Quitting and restarting the browser.
• Duplicating a tab.
• Closing and restoring a tab.

In some of these cases, the browser might preserve the original navigation type and show a type of back_forward despite these not being back or forward navigations. Even when navigation types are reported correctly, the bfcache is periodically discarded to save memory.

Because of this, website owners can't expect a 100% bfcache hit ratio for all back_forward navigations. However, measuring their ratio can help identify pages that prevent bfcache usage.

The Chrome team has added the NotRestoredReasons API to help expose the reasons why pages don't use bfcache, so developers can improve their bfcache hit rates.

Performance measurement

bfcache can also negatively affect performance metrics collected in the field , specifically metrics that measure page load times.

Because bfcache navigations restore an existing page, instead of starting a new page load, the total number of page loads collected decreases when bfcache is enabled. However, the page loads bfcache replaces were likely among the fastest page loads in your dataset, because repeat page loads, including back and forward navigations, and usually faster than first-time page loads because of HTTP caching . So enabling bfcache can cause your analytics to show slower page loading, in spite of improving site performance for the user.

There are a few ways to deal with this issue. One is to annotate all page load metrics with their respective navigation type : navigate , reload , back_forward , or prerender . This lets you continue to monitor your performance within these navigation types, even if the overall distribution skews negative. We recommend this approach for non-user-centric page load metrics like Time to First Byte (TTFB) .

For user-centric metrics like the Core Web Vitals , a better option is to report a value that more accurately represents what the user experiences.

Impact on Core Web Vitals

Core Web Vitals measure the user's experience of a web page across a variety of dimensions (loading speed, interactivity, visual stability). It's important that your Core Web Vitals metrics reflect the fact that users experience bfcache restores as faster navigations than default page loads.

Tools that collect and report on the Core Web Vitals metrics, like the Chrome User Experience Report , treat bfcache restores as separate page visits in their dataset. And while there aren't dedicated web performance APIs for measuring these metrics after bfcache restores, you can approximate their values using existing web APIs:

• For Largest Contentful Paint (LCP) , use the delta between the pageshow event's timestamp and the timestamp of the next painted frame, because all elements in the frame will be painted at the same time. In the case of a bfcache restore, LCP and FCP are the same.
• For Interaction to Next Paint (INP) , keep using your existing Performance Observer, but reset the current CLS value to 0.
• For Cumulative Layout Shift (CLS) , keep using your existing Performance Observer, but reset the current CLS value to 0.

For more details on how bfcache affects each metric, see the individual Core Web Vitals metric guides pages . For a specific example of how to implement bfcache versions of these metrics, refer to the PR adding them to the web-vitals JS library .

Additional Resources

• Firefox Caching (bfcache in Firefox)
• Page Cache (bfcache in Safari)
• Back/forward cache: web exposed behavior (bfcache differences across browsers)
• bfcache tester (test how different APIs and events affect bfcache in browsers)
• Performance Game Changer: Browser Back/Forward Cache (a case study from Smashing Magazine showing dramatic Core Web Vitals improvements by enabling bfcache)

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2024-04-23 UTC.

• Barry Pollard
• May 9, 2022

Performance Game Changer: Browser Back/Forward Cache

• 17 min read
• Caching , Browsers , Performance , Core Web Vitals
• Share on Twitter ,  LinkedIn

About The Author

Barry Pollard is a web developer who is obsessed with web performance. He is the author of the Manning book “ HTTP/2 In Action ” and is a one of the maintainers … More about Barry ↬

Email Newsletter

Weekly tips on front-end & UX . Trusted by 200,000+ folks.

First of all, it would be remiss of me to give the Chrome browser all the credit here, when the other two main browsers (Safari and Firefox) have had this concept for quite some time now, though there are some subtle differences in all three implementations .

So, Chrome was playing catch-up here. However, as the world’s most popular browser and the only browser feeding back the Core Web Vitals information for any search ranking boasting, Chrome getting this (finally, some might say) is important. Plus, they’ve created some more transparency about this, both in documentation and tooling. Not to mention the many other Chromium-based browsers (e.g. Edge, Opera, Brave) will now also have gotten this functionality too.

With that caveat out of the way, let’s get to the guts of the article: What is the Back/Forward Cache and why does it matter so much? As its name implies, this is a special cache used to remember the web page as you browse away from that web page, so if you browse back to it later, it can load a lot quicker .

Think about the number of times you visit a home page, click on an article, then go back to the home page to view another article? Or you click back, then realize you forgot to make a note of something on that article, so click forward again. Similarly from cross-site navigation — think Google search results or the like and then clicking back. All those navigations can benefit from the Back/Forward Cache to instantly restore the page.

Didn’t The HTTP Cache Do All That Anyway?

Browsers have lots of caches , the most well-known of which is the HTTP Cache that stores copies of downloaded resources on a local drive for later reuse. Ensuring your website caches most of its assets for future uses has long been touted as essential for web performance. Sadly, however, it is not yet universal , but there are plenty of other articles written about that.

Using the HTTP Cache can avoid the need to download the same resources over and over again. Going back to the example of visiting a home page and then going to an article page. There are likely lots of shared resources (site-wide CSS and JavaScript, logos, other images, etc.), so reusing them from that home page visit is a good saving. Similarly, before the Back/Forward Cache came along, being able to reuse these assets if going back to the home page was a good gain — even if it wasn’t instant.

Downloading resources is a slow part of browsing the web no doubt, but there is a lot more to do as well as that: parse the HTML, see and fetch what resources you need (even if they can be gotten relatively quickly from the HTTP Cache), parse the CSS, layout the page, decode the images, run the oodles of JavaScript we so love to load our pages with… etc.

WebPageTest is one of the few web performance testing tools that actually tests a reload of the page using a primed HTTP Cache — most of the other tools just flag if your HTTP resources are not explicitly set to be cached. So, running your site through WebPageTest will show the initial load takes some time, but the repeat view should be faster. But it still takes a little time, even if all the resources are being served from the cache. As an aside, that repeat view will likely not be fully representative anyway. Loading with an empty cache or a completely primed cache are the two extremes, but the reality is that you might have a semi-primed cache with some but not all of the resources cached already. Especially if you navigate from another page on the site.

Here’s an experiment for you. In another tab, load https://www.smashingmagazine.com . Loads pretty quickly, doesn’t it? The Smashing team has done a lot to make a fast website, so even a fresh load (though this experiment may not be a completely fresh load if you came to this article from the home page). Now close the tab. Now open another new tab and load https://www.smashingmagazine.com again. That’s the reload with a fully primed HTTP cache from that initial load. Even faster yeah? But not quite instant. Now, in that tab, click on an article link from https://www.smashingmagazine.com and, once it’s loaded, click back — much faster yeah? Instant, some might say.

You can also disable the Back/Forward Cache in Chrome at chrome://flags/#back-forward-cache if you want to experiment more, but the above steps should hopefully be a sufficient enough test to give a rough feel for the potential speed gains.

It might not seem like that much of a difference, but repeat the experiment over a bad mobile connection, or using a heavier and slower website, and you’ll see a big difference. And if you browse a few articles on this site, returning to the home page each time, then the gains multiply.

Why is the Back/Forward Cache so much faster?

The Back/Forward Cache keeps a snapshot of the loaded page including the fully rendered page and the JavaScript heap. You really are returning to the state you left it in rather than just having all the resources you need to render the page.

Additionally, the Back/Forward Cache is an in-memory cache . The HTTP Cache is a disk cache. A disk cache is faster than having to fetch those resources from the network (though not always, oddly enough !), but there’s an extra boost from not even having to read them from disk. If you ever wondered why browsers need so much memory just to display a simple page — it’s partly for optimizations like this. And mostly, that’s a good thing.

Finally, not all resources are allowed to be cached in the HTTP Cache. Many sites don’t cache the HTML document itself, for example, and only the resources. This allows the page to be updated without waiting for a cache expiry (subresources normally handle this with unique cache-busting URLs , but that can’t be used on the main document, as you don’t want to change the URL each time), but at the cost of the page having to be fetched each time. Unless you’re a real-time news website or similar, I always recommend caching the main document resource for at least a few minutes (or even better hours) to speed up repeat visits. Regardless, the Back/Forward Cache is not limited to this as it is restoring a page, rather than reloading a page — so again another reason why it can be faster. However, this isn’t quite a clear cut, and there is still work going on in this space in Chrome , though Safari has had this for a bit now .

OK, But Is It Really That Much Faster For Most Web Browsing Or Are We Just Nitpicking Now?

The Core Web Vitals initiative gives us a way of seeing the impact on real user web browsing, and the Core Web Vitals Technology Report allows us to see these figures by site based on HTTP Archive monthly crawls. Some in the e-commerce web performance community noticed the unexplained improvement in January’s figures :

CRUX data for Jan-22 is out. Let's see how various eCommerce platforms did this month. #webperf #perfmatters . Change in % of Origins worldwide having good CWVs (compared to last month) @LightspeedHQ - 18% up @ShopifyEng - 9% up @opencart - 9% up @squarespace - 5% up pic.twitter.com/wbnDdGeRWl — Rockey Nebhwani (@rnebhwani) February 9, 2022

Annie from the Chrome team confirmed this was due to the Back/Forward Cache rollout and was a bit surprised just how noticeable it was:

This is a bit surprising, but the improvement is user-visible; it is caused by the bfcache rollout ( https://t.co/9raiXQaYwU ). What's happening is that when a web page is restored from cache instead of fully loading, it skips all the layout shifts from load. Big CLS improvement! — Annie Sullivan (@anniesullie) February 9, 2022

Although it is restoring the page from a previous state, as far as Core Web Vitals, as measured by Chrome, is concerned, this is still page navigation . So, the user experience of that load is still measured and counts as an additional page view — just with a much faster and more stable load!

Be aware, however, that other analytics may not see this as a page load and need to take extra efforts to also measure these. So for some of your tooling you may even have noticed a drop in visitor count and performance as these fast repeat views (which were measured), became even faster restores (but which potentially aren’t now measured), so your overall average page loads measured appear to have got slower. Again, I’ll refer you to Philip Walton’s article including a section on how bfcache affects analytics and performance measurement , for more information.

I’ve another more dramatic example, closer to home to share, but first a little more background.

Do I Need To Do Anything, Or Does My Site Just Get A Free Boost?

Well, this isn’t just some puff piece for the Chrome team — especially since they were late to the party! There is an action for sites to take to ensure they are benefiting from this speed gain because there are a number of reasons you may not be.

Implementing a Back/Forward Cache sounds simple, but there are a million things to consider that could go wrong. I’ve kept it reasonably light on technical details here (check out Philip Walton’s Back/forward cache article for more technical information), but there are many things that could go wrong with this.

Browser makers have to make sure it’s safe to just restore pages like this, and the problem is many sites are not written with the expectation that a page can be restored like this and think (not entirely unreasonably!) that when the page is navigated away from that the user isn’t coming back without a full page reload.

For example, some pages may register an unload event listener in JavaScript to perform some clean-up tasks under the assumption the user is finished with this page. That doesn’t work well if the page is then restored from the Back/Forward Cache. Now, to be honest, the unload event listener has been seen as a bad practice for a while now as it is not reliably fired (e.g. if the browser crashes, or the browser is backgrounded on a mobile and then killed), but the Back/Forward cache gives a more pressing reason why it should be avoided because browsers will not use the Back/Forward Cache if your page or any of its resources uses an unload event listener .

There are a number of other reasons why your page might not be eligible for the Back/Forward cache. Counterintuitively, for a web performance feature, some of these reasons are due to other web performance features:

• Unload listeners were (and in some cases still are) often used log data when the page was finished with. This is particularly useful for Real User Monitoring web performance tools — used by sites that obviously have an interest in ensuring the best performance! There are other better events now that should now be used instead that are compatible, including pagehide and freeze .
• Using a dedicated worker to offload work from the main thread is another performance technique that at the moment makes the website ineligible for the Back/Forward cache. This is used by some popular platforms like Wix, but a fix for sites using Web Workers is coming soon!
• Using an App Install Banner also makes a site ineligible, which affected smashingmagazine.com (we’ll get back to that momentarily), and again supporting App Banners is being actively worked on .

Those are some of the more common ones, but there are lots of reasons why a site may not be eligible. You can see the complete list of reasons for the Chrome source code , with a bit more explanation in this sheet .

Back/Forward Cache Testing Tool

Helpfully, rather than having to examine each one, the Chrome team added a test to Chrome Dev Tools under the Application tab:

Clicking on that inviting little blue button will run the test and should hopefully give you a successful message:

If you are getting an ineligibility message, with a reason then it’s well worth investigating if that reason can be resolved.

Third-party scripts might be making your page ineligible, even if you don’t use those features directly in your code. As I mentioned above, unload event listeners are particularly common to some third-parties. As well as the above test showing this, there’s a Lighthouse test for this. Running a query on the HTTP Archive data yielded a list of popular third-party scripts used by many sites that use unload event listeners .

I’ve heard the Chrome team has been reaching out to these companies to encourage them to solve this, and many of the scripts logged in the above spreadsheet are older versions, as many of the companies have indeed solved the issues. Facebook pixel, for example, is used by a lot of sites and has apparently recently resolved this issue, so I am expecting that to drop off soon if that is indeed the case.

Site owners may also have power here: if you are using a third-party service that uses an unload event listener , then reach out to them to see if they have plans to remove this, to stop making your website slow — especially if it’s a service you are paying for! I know some discussions are underway with some of the other names on that list for precisely this reason, and I’ve helped provide some more information to one of the companies on that list to help prioritize this work, so am hopeful they are working on a fix.

As I mentioned earlier, each browser has implemented the Back/Forward Cache separately, and the above test is only for Chromium-based browsers, so even if you pass that, you may still not be benefiting completely in the other browsers (or maybe you are, and it’s just Chrome that’s not using it!). Unfortunately, there is no easy way to debug this in Firefox and Safari, so my advice would be to concentrate on Chrome first using their tool and then hope that’s sufficient for the other browsers as they often are more permissive than Chrome. Manual testing may also show this, especially if you can slow down your network, but that is a little subjective, so can be prone to false positives and false negatives.

Impact On SmashingMagazine.com

As readers undoubtedly have noticed, the smashingmagazine.com website is already fast, and they’ve published a number of articles in the past on how they achieve this level of performance. In the last one, which I wrote, we documented how we spent a huge amount of time investigating a performance issue that was holding us back from meeting the Core Web Vitals .

Thanks to that investigation we had crossed into the green zone and stayed there, so we were reasonably happy, as we were consistently under the 2.5-second limit for LCP in CrUX for at least 75% of our visitors. Not by much admittedly, as we were getting 2.4 seconds, but at least we were not going over it. But never ones to rest on our laurels, we’re always on the lookout for further improvements. They delayed some of their JavaScript in January leading to some further improvements to an almost 2.2-second CrUX number.

This website was initially failing that test due to the fact it had an App Install Banner. SmashingMazgazine.com is a PWA that prompts you to install it on the home screen for browsers that support that (Chrome on Android devices primarily). When I highlighted to the team in early March that this was holding them back from benefiting from the Back/Forward Cache that had recently been launched, they decided to remove some key parts of manifest.json to prevent the App Install Banner from showing, to see if this feature was costing them performance and the results were dramatic:

We can see the impact of the December and January improvements were noticeable but started to tail off by the start of March, and then when we implemented the Back/Forward Cache fix the LCP numbers plummeted (in a good way!) all the way down to 1.7 seconds — the best number Smashing Magazine has ever seen since the Core Web Vitals initiative was launched.

In fact, if we’d known this was coming, and the impact it would have, we may not have spent so much time on the other performance improvements they did last year! Though, personally, I am glad they did since it was an interesting case study.

The above, was a custom chart created by measuring the CrUX API daily, but looking at the monthly CrUX dashboard (you can load the same for any URL) showed a similarly drastic improvement for LCP in the last two months, and the April numbers will shop a further improvement:

Across the web, CLS had a bigger improvement with the rollout of the Back/Forward Cache in Chrome, but Smashing saw the improvement in LCP as they had no CLS issues. When investigating the impact on your site look at all available metrics for any improvement.

Of course, if your site was already eligible for Back/Forward Cache then you will have already got that performance boost in your Core Web Vitals data when this was rolled out in Chrome to your users — likely in December and January. But for those that are not, there is more web performance here available to you — so look into why you are not eligible.

I honestly believe that sites that are ineligible for the Back/Forward Cache are giving up free web performance for their users, and making passing Core Web Vitals needlessly tough on themselves. “

Was there a downside to disabling the App Install Banner that was preventing this? That’s more difficult to judge. Certainly, we’ve had no complaints. Perhaps it’s even annoying some users less (I’m not an Android user, so can’t comment on whether it’s useful or annoying to have pop-ups on a site you visit encouraging you to install it). Hopefully, when Chrome fixes this blocker, Smashing can decide if they want both, but for now the clear benefits of the Back/Forward Cache mean they are prepared to give up this feature for those gains.

Other sites, that are more app-like, may have a different opinion and forgo the Back/Forward Cache benefits in favor of those features. This is a judgment call each site needs to make for any Back/Forward Cache blocking features. You can also measure Back/Forward Cache navigations in your site Analytics using a Custom Dimension to see if there are a significant number of navigation and so an expected significant gain. Or perhaps A/B test this? There are also a couple of interesting proposals under discussion to help measure some of this info to help websites make some of these decisions.

Test Your Website Today!

I strongly encourage sites to run the Back/Forward Cache test, understand any blockers leading to an unsuccessful test and seek to remove those blockers. It’s a simple test that literally only takes a couple of seconds, though the fix (if you are not eligible) might take longer! Also, remember to test different pages on your website in case they have different code and thus eligibility.

If it’s due to your code, then look at whether it’s giving the benefits over this. If it’s third-party code, then raise it to them. And if it’s for some other reason, then let the Chrome team know it’s important to you for them to solve it: Brower makers want user feedback to help prioritize their work.

If you don’t do this, then you’re leaving noticeable web performance improvements on the table and making your site slower for users, and failing to capitalize on any SEO benefit at the same time.

Many thanks to Philip Walton, Yoav Weiss, Dan Shappir, Annie Sullivan, Adrian Bece, and Giacomo Zecchini for reviewing the article for technical accuracy.

Smashing Newsletter

Tips on front-end & UX, delivered weekly in your inbox. Just the things you can actually use.

Front-End & UX Workshops, Online

With practical takeaways, live sessions, video recordings and a friendly Q&A.

TypeScript in 50 Lessons

Everything TypeScript, with code walkthroughs and examples. And other printed books.

What Does The Back/Forward Cache Mean For Site Speed?

Loading a new web page takes time, but about 20% of mobile navigations are actually initiated by the browser Back and Forward buttons.

The back/forward cache speeds up these navigation by restoring previously loaded page content.

What is the back/forward cache? ​

If a page supports the back/forward cache (also called BFCache), the browser saves the full page state in memory when navigating to a new page.

When a user then navigates back to a previous page, the browser restores the full page from a cache instead of reloading it. That way, page content can appear almost instantly.

You can see an example of that in this video.

When is a page served from the back/forward cache? ​

To benefit from the back/forward cache, a page needs to be eligible for it. Here are some common reasons why a page might not be eligible:

• It uses the unload event (as restoring the page after unload has been handled may break the page)
• It uses the beforeunload event (in Firefox)
• It uses the Cache-Control: no-store header that disables all caches

There are a wide range of reasons why a page might not support the back/forward cache, and you can find the full list here .

How can I check if my site can be served from the back/forward cache? ​

Chrome DevTools allows you to check whether your page is eligible for the back/forward cache.

• Right Click on the page and click Inspect to open Chrome DevTools
• Switch to the Application tab
• In the Cache section of the sidebar, select Back/forward cache
• Click Test back/forward cache

DevTools will then show you a status indicating whether your site can use the back/forward cache and, if it’s not eligible, what you could do to support it.

Successfully served from back/forward cache ​

In this case your page is eligible for the back/forward cache and you don’t need to do anything.

Actionable ​

This status shows that you should make a change to your website to support the back/forward cache.

Pending Support ​

Finally, this status shows that your page isn’t currently eligible for the back/forward cache, but Chrome may support it in a future version.

Lighthouse: Page prevented back/forward cache restoration ​

Lighthouse 10 added a new performance audit that checks whether the page supports the back/forward cache.

You can find it in the Performance section under Diagnostics .

If it passes the message will be "Page didn't prevent back/forward cache restoration".

How to see why a page wasn't restored from the back/forward cache for real users ​

Chrome reports a notRestoredReasons for back/forward navigations:

You can also view not restored reasons in DebugBear's real user monitoring feature .

How can you enable or disable Chrome's back/forward cache? ​

To configure the back/forward cache open chrome://flags/#back-forward-cache in Chrome to toggle the back-forward-cache flag.

How is the back/forward cache different from the HTTP cache? ​

The browser HTTP cache stores past responses to network requests to avoid having to redownload resources.

The back/forward cache is more comprehensive: the entire page state can be restored.

When only the HTTP cache is used some resources may still have to be redownloaded if they are not eligible for caching. After that the page still needs to run any on-page scripts and render the page contents. With the back/forward cache a lot of this work can be avoided.

What browsers support the back/forward cache? ​

Chrome, Safari, Firefox, and Edge all support the back/forward cache.

Impact on site speed metrics ​

If a page is loaded from the cache it can render extremely quickly, which is good for the Core Web Vitals of your website.

For example, here you can see that a page restored from the back/forward cache has a Largest Contentful Paint of just 100 milliseconds.

Compare that to a typical page load without caching, where it takes half a second to load the page.

The back/forward cache can also reduce layout shift . This was noticeable in Google’s Chrome User Experience Report after Chrome enabled the cache.

Monitor and optimize page speed ​

DebugBear can keep help you track the speed of your website over time. It's built on top of Google's Lighthouse tool but also provides in-depth custom reports.

Continuously monitor Lighthouse scores and get alerted when there's a problem.

Get a monthly email with page speed tips

• What is the back/forward cache?
• When is a page served from the back/forward cache?
• Successfully served from back/forward cache
• Pending Support
• Lighthouse: Page prevented back/forward cache restoration
• How to see why a page wasn't restored from the back/forward cache for real users
• How can you enable or disable Chrome's back/forward cache?
• How is the back/forward cache different from the HTTP cache?
• What browsers support the back/forward cache?
• Impact on site speed metrics
• Monitor and optimize page speed

Available on the biggest platforms.

Once you start with NitroPack, you can freely choose your integration platform.

NitroPack under the hood.

Everything you need to know about NitroPack features and compatibilities.

Discover more about NitroPack's features

Compatibilities

Use NitroPack with other plugins

Partnership options with NitroPack.

Whether you run a blog or an agency, we have a partnership opportunity for you!

Agency Program

Suitable for freelancers and agencies

Affiliate Program

Suitable for publishers, educators, and influencers.

NitroPack Resources

The place to learn how to improve your web performance, how to get the most out of NitroPack, and what is coming next to our product.

Best practices to elevate your web performance.

Help center

All your NitroPack questions answered in one place.

Behind-the-scene video series on all things NitroPack.

Back/Forward Cache: What It Is and How to Use It to Serve Content Immediately

Imagine this…

A user is browsing your website. They go to your product page. Then to your pricing page. Then back to your product page as they forgot to check if you offer that specific feature. Finally, they navigate forward to your pricing page and finish their order. 

As it turns out, it’s a pretty common scenario. 

Chrome usage data shows that 1 in 10 (10%) navigations on desktop and 1 in 5 (20%) on mobile are either back or forward.

Truly spectacular numbers. 

But…

The more important thing is - how can you guarantee that after navigating back and forward to your pages, they load immediately? 

Enter back/forward cache (or bfcache ).

In the following lines, you will learn everything about bfcache and how to implement it to improve speed and perceived performance.

Spoiler alert: it’s easier than you think. 

What is the back/forward cache?

Bfcache is a feature that allows browsers to create and store a snapshot of an already visited web page in their in-memory. So the next time a visitor navigates back or forward to it, the browser can display it immediately.

The whole behind-the-scene process looks like this…

When a visitor requests to load a specific page, the browser goes through the following process:

• Establishes a connection with the server
• Downloads and parses the information
• Constructs the Document Object Model (DOM) and CSS Object Model (CSSOM)
• Renders the content
• Makes the page interactive

If the back/forward cache isn’t enabled for the specific page, it means that every time you leave it and then navigate back to it, the browser will have to go through the whole 5-step process. 

And that takes time. 

On the contrary, with bfcache enabled, the browser “freezes” the page with all of its resources, so the next time you re-visit it, the browser won’t need to waste time rebuilding and will be able to load it instantly. 

The following Addy Osmani’s video illustrates best how fast a web page loads with and without bfcache:

As you can see from the video, the loading time is almost non-existent. On top of that, bfcache will reduce your visitors' data usage as they won’t have to re-download the same resources repeatedly. 

And while all of these benefits sound incredible, a certain question might still bother you:

I already have an HTTP cache set up for my website. Do I need bfcache as well? 

Here’s the answer…  

What is the difference between bfcache and HTTP cache?

Put simply, bfcache is a snapshot of the entire page stored in-memory (including the JavaScript heap ), whereas the HTTP cache includes only the previously requested resources. 

And as Google claims :

Not all resources are allowed to be cached in the HTTP Cache . For instance, some sites don’t cache the HTML document itself, but only the resources. As a result, every time a visitor loads a specific page, the browser needs to re-download the document. 

Another reason back/forward cache can be faster is the difference between in-memory and disk cache. 

It’s true that loading resources from the disk cache (HTTP cache) could be much faster than requesting them over the network. But there’s an extra boost from not even having to read them from disk and fetching the entire page directly from the browser’s in-memory.   

What browsers support the back/forward cache?

All of them - Chrome, Safari, Firefox, Opera, and Edge:

The truth is back/forward cache isn’t a new concept. Safari added support for this feature back in 2009. Firefox has supported it since version 1.5 .

Edge and Chrome were the latest to join the party, with the former introducing bfcache in 2020 , while the latter did it a year later. 

Now that you know that all major browsers support it let’s see how you can check if your page is served from the bfcache. 

How can I check if my site can be served from the back/forward cache?

The best thing about back/forward cache is that it just works  in the majority of cases because browsers automatically do all the work for you.

In some cases, however, your pages will not be restored by the bfcache. 

The easiest way to check if everything works correctly is to run a PageSpeed Insights audit. 

Using Google PageSpeed Insights

Since the release of Lighthouse v10 , there’s been a new PSI audit called “Page prevented back/forward cache restoration.”  

The audit will fail if the page you tested cannot be restored from bfcache for any reason. Clicking on the warning, a drop-down menu will open, and you’ll see a list with reasons and the frame(s) that caused the issue.

Failure reasons are separated into three categories :

• Actionable : You can fix these issues to enable caching.
• Pending Support : Chrome doesn't support these features yet, so they prevent caching. However, once supported, Chrome removes these limitations.
• Not Actionable : You can't fix these issues on this page. Something that is outside the page's control prevents caching.

Using Chrome DevTools

Another option is to use Chrome’s Developer Tools, following these steps:

1. Open Chrome DevTools on the page you want to test:

2. Navigate to Application > Cache > Back/forward cache:

3. Click Test back/forward cache

If bfcache works on your page, you’ll see this message:

If not, you will see a list of issues:

Now that you know how to test it, let’s see how you can optimize your pages for bfcache and fix PSI’s warning.   

How to fix the “Page prevented back/forward cache restoration” warning in PageSpeed Insights

Even if you don’t see the warning, meaning your page is eligible for bfcache, it’s good to know that it won’t stay there indefinitely.

That’s why it’s crucial to know how to optimize for back/forward cache.

Here are some best practices you can use to make it as likely as possible that browsers bfcache your pages:

1. Avoid using the unload event 

The most surefire way to optimize for bfcache is to avoid using the unload event at all costs. 

The unload event fires when the user navigates away from the page (by clicking on a link, submitting a form, closing the browser window, etc.).

On desktop, Chrome and Firefox consider a page ineligible for bfcache if it uses the unload event. Safari, on the other hand, will cache some pages that fire the unload event listener, but to reduce potential breakage, it will not run it when a user is navigating away.

On mobile, Chrome and Safari will cache a page that uses the event, but Firefox won’t. 

In general, avoid using the unload event and instead go for the pagehide event. Otherwise, you’re risking slowing down your site, and your code won’t even run most of the time in Chrome and Safari. 

Also, there’s an ongoing discussion between browsers to deprecate unload .   

2. Be careful with adding beforeunload listeners

It’s ok to use beforeunload events in Chrome and Safari, but keep in mind that Firefox will flag your pages as ineligible for bfcache. 

However, there are legitimate use cases for the beforeunload event, unlike the unload event. One example is when you must caution the user about losing unsaved changes if they exit the page. It's advisable to attach beforeunload event listeners only when there are unsaved changes and to remove them promptly after saving those changes.  

3. Use Cache-Control: no-store only with information-sensitive pages

If a page contains sensitive information and caching is inappropriate, then Cache-Control: no-store should be used to prevent it from being eligible for bfcache. On the other hand, if a page doesn't contain sensitive information and always requires up-to-date content, Cache-Control: no-cache or Cache-Control: max-age=0 can be used. These directives prompt the browser to revalidate the content before serving it and don't impact a page's eligibility for bfcache.  

4. Update sensitive data after bfcache restore

The bfcache isn’t supposed to work for pages that contain sensitive data. For instance, when a user signs out of a website on a public computer, the next user shouldn’t be able to sign back in just by hitting the back button. 

To achieve that, it's a good practice to update the page after a pageshow event if event.persisted is true.

Here’s a code from web.dev you can use:

5. Avoid window.opener references

Whenever possible, use rel="noopener" instead of window.opener references. The opened window or the opener won't be eligible for bfcache if your site opens windows and controls them through window.postMessage() .

• Always close connections and disconnect observers during the pagehide and freeze event

When the page is stored in the bfcache, all JavaScript tasks are paused and resumed as soon as it is taken out of the cache.

If these tasks only access APIs isolated to the current page, there won’t be any problems. 

However, if these tasks are connected to APIs that are also accessible from other pages in the same origin, then they may prevent code in other tabs from running properly.

If that’s the case, some browsers will not put a page in bfcache in the following scenarios:

• Pages with an open IndexedDB connection
• Pages with in-progress fetch() or XMLHttpRequest
• Pages with an open WebSocket or WebRTC connection

The best thing you can do is to permanently close connections and remove or disconnect observers during pagehide or freeze events if your page uses any of these APIs. By doing this, the browser can cache the page without worrying about other open tabs being affected.  

Check if your site can be instantly reloaded from bfcache

Most browsers are now able to instantly go back to previously visited pages without having to wait for them to load. This ability is powered by the back/forward cache (or bfcache). Firefox, Safari, and Chromium-based browsers support it, and it's massive performance boost when hitting the back button.

The way the bfcache works is by storing a snapshot of the page in memory, in a way that no work needs to be done when going back to it, other than displaying the pixels on the screen.

Not all web pages can be cached in bfcache though. Chrome and Edge have a new tool that lets you detect potential issues with a page that might prevent it from being bfcache'd.

To test if your page can be cached:

• Open the Application tool.
• Click Back/forward cache in the side bar.
• Click the Test back/forward cache button.

A report will be displayed, telling you whether your page can be cached, and if not, why.

Last edit: 3/15/2022 - Edit this page

How Single Page Apps and bfcache Impact the User Experience

• Web Development
• User Experience

21 January 2021

• Share on Twitter
• Share on LinkedIn
• Copy To Clipboard Copied to clipboard

Working within the constraints of a web browser is hard.

Did you know that around 20% of page visits (source: Google) on mobile are via the back and forward buttons? Today, hopefully, we can come to understand a bit more what happens when you hit the forward and back button in the browser. We will also think through how various constraints may affect your user’s experience depending on the type of technology you use.

We do have an ideal experience in mind when thinking about how a user should experience back or forward navigation - native applications. They do an extraordinary job of giving you content fast. However, their architectures lend themselves to a seamless experience. For example, Android maintains an “Activities” stack. When you navigate to another page, that stack item turns “off”. When navigating back, it is as simple as turning it back “on”. As a result, the state of that page is shown to the user in an extremely efficient manner.

Luckily, as web developers, we have various superpowers available to us as well. This is known as the bfcache (the colloquial name is said to be back forward cache). Here are some docs on Firefox’s implementation . If you haven’t heard of this, that is completely fine. Safari and Firefox have had this feature for much longer than Chrome. Only sometime in 2019 did Chrome come out with their own bfcache implementation.

Effectively, the browser will create a new frame for every navigation. Whether same-site or cross-origin, the browser will put the page on ice. This includes taking a snapshot of the page along with other metadata. Further, all work on that page, including any delayed tasks like setTimeout will be stopped in its tracks, only to be resumed if you reach that page again through the bfcache. When you navigate back to an item in the stack with the back or forward button, the browser takes it off ice and renders it to the user without refreshing the content. This includes all input element states that may have been left in flux. In other words, stateful browsing.

Making Compromises

As stated, we are bound to have some tradeoffs. Imagine you log out of your current session. What happens when you return? Well, your last stack item is taken off ice and rendered to the user. This can be very problematic for security reasons. There are solutions to get around this. However, I won’t present them here for the sake of potential changing browser heuristics or solutions conjured up by the community.

In addition, libraries like Phoenix Live View , Hotwire , or Turbolinks avoid putting their pages into bfcache. This may cause subtle bugs for users filling out large forms.

Lastly, when thinking about static sites versus dynamic sites, a back action may be taken after the app has sat idle for days! It is likely preferable that navigation back to a page not only takes it off ice, but also requests data and ensures you have the most up to date information presented to your user. Alas, another tradeoff.

Single Page Apps (SPAs)

Sadly, this cache space is not available to a single page app built with Ember.js or other client-side frameworks. That is because navigation to a new document doesn’t really take place when a user interacts with the back button. We interact with APIs like history.pushState and history.replaceState on window.onpopstate .

We noted some of the problems that may occur above with server-side applications and the bfcache. However, with SPAs, we easily subvert these issues. If you have properly manicured your local state with an SPA, you likely gain dynamic content by default plus avoid the pitfalls of a logged-out user seeing previous session history. Moreover, a framework like Ember.js has the pieces to render your page on the back button ready to go with very little initialization cost.

The downside to using the back and forward button with SPAs is the cost to paint the DOM and retrieve resources (likely) from the browser cache. Even retrieving resources from the browser cache can be costly if your document is quite large. Moreover, maintaining your previous scroll position can be quite tricky. In the Ember.js community, ember-router-scroll has become critical in helping SPAs implement this correctly. However, it also is tricky with lazy loaded DOM elements and large, content-heavy documents. Certainly, a frozen state of your previous page would help all SPAs restore your last scrolled position. However, this would require different browser APIs to solve some of the issues presented above.

Bfcache is a default setting provided by many of the modern browsers today that will aggressively cache your pages for future backward and forward navigations. However, this does not apply to Single Page Apps. SPAs interestingly solve some problems but creates others. Achieving native application user experience on backward and forward navigation is quite difficult without a construct like bfcache or activities stack that we can just take off ice and render for the user. It may require you to pull some tricks out of the bag such as a properly configured server to instruct the browser to cache assets or UI tricks to fade in the navigation to hide the reconstructing DOM.

As with all things in software development, tradeoffs abound. However, we can close the gap and continue improving on the user experience by choosing the right tool for the project. SPAs might be right for you, but they might not be. And if you don’t know where to begin or are lacking the expertise needed to complete your next app endeavor, we can help. Reach out to us .

DockYard is a digital product consultancy specializing in user-centered web application design and development. Our collaborative team of product strategists help clients to better understand the people they serve. We use future-forward technology and design thinking to transform those insights into impactful, inclusive, and reliable web experiences. DockYard provides professional services in strategy, user experience, design, and full-stack engineering using Ember.js, React.js, Ruby, and Elixir. From ideation to delivery, we empower ambitious product teams to build for the future.

Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

How to clear the cache of a website added to the home screen?

I am developing a simple web application. Users of the application can add the application to the home screen of their iOS device to be presented with a nice app icon and an almost app-like user experience. This approach has one problem though:

While developing I deploy a new version of the application rather often. I then open Safari on the iOS device, hit refresh, and all HTML-, JavaScript- and CSS-files are refreshed. So far everything works as designed.

But if I open the website using the shortcut added to the homescreen, old stylesheets are being loaded and no matter what I do, the website cannot be persuaded to discard its cached files and reload them.

Here is what I tried so far:

• I removed and recreated the shortcut.
• I cleared the history and browser data from Safari
• I cleared the history and all website data using the Settings app.
• I rebooted my device.
• I even added headers instructing the browser to not cache any files at all.
• I tried a whole bunch of combinations of the steps mentioned above.

The home screen web app did reload an HTML-file that had a single word changed, though - so something must be working correctly. Appending some suffix or parameter to the CSS file links is no option here. I am using Aurelia in combination with jspm - all stylesheets and script files are included automatically acoording to their names.

And to just repeat it: When opening the page using Safari (or any other brother on the iOS device) everything works as expected.

Could anybody point me in the right direction on how to fix this problem?

I found a workaround for this infuriating bug:

request = new XMLHttpRequest() request.open("GET", "url you want to reload") request.send()

This forces a refresh of the cache with the new file. If you look at the file in the Sources tab, you'll see its content being refreshed while executing this.

looks like a bug for me. I am also experiencing this problem.

I recently asked this same question here:

https://forums.developer.apple.com/thread/62464

And even referenced this thread. I haven't gotten any replies there, but for what it's worth I can offer further confirmation that this does seem to be an issue.

I filed a bug report just in case, but meanwhile I'm still looking for a solution. So, if anyone has any ideas or suggestions, please don't hesitate to share.

Has there been any workaorund on this issue since iOS 10.1.1 still shows issue?

I am have two units that are experiencing a similar problem; We have a website designed to have a sub-page saved to the home screen. On these two units it seems like an old version of code has been cached (or something), resulting in a bug being unable to be fixed.

Any workaround or solution would be very appreciated. Alternatively, any suggestions on how to troubleshoot, in order to help you possibly find the source of the problem.

I am having this problem as well. When I set <meta name="apple-mobile-web-app-capable" content="no"> a non-cached version loads in Safari and can be installed.

However, with content="yes" a non-cached version loads in Safari, but the original cached version is re-installed from Share > Add to Home Screen.

I have tried disabling the cache from Safari > Develop > Disable Caches, emtying the caches from Safari > Develop > Empty Caches, and hard reloading from the inspector with cmd+shift+r.

Also, clearing from iOS with Settings > Safari > Clear History and Website Data, as well as Settings > Safari > Advanced > Website Data > Edit > Remove.

It would be nice if the Develop > Empty Caches command would flush the entire cache on Safari iOS when mobile device is connected with cable.

Same here - absolutely anaoying - I tried some ways descripted above and nothings helps ... Not only the MacOS Sierra Safari is driving me nuts with its poor cache behavior since the init version of Sierra. Also this issue here on iOS is horrible as a Home Screen web app totally ignore any changes of ressources of an web app,

If you have a Mac, try this...

iOS: open settings -> safari -> advanced enable web inspector.

Mac open safari -> Preferences -> Advanced enable “Show Develop menu in menu bar"

connect iOS to Mac with cable.

Open offending web app on iOS device

Open Mac-Safari

Under “Develop” find the name of your iOS device, move to it. Should see the webpage name appear. click it.

This will open a safari Web Inspector. press the refresh button (arrow going in clockwise direction). Phone should refresh with new content.

I just discovered this today and after searching the web I discovered that most of the reports about it are as old as 2012.

Many of the suggestions are the same as reported here.

https://discussions.apple.com/thread/3802691?tstart=0

I tried everything suggested without any success.

The weird is that only my iPhone 6 has the problem.

My iPad air does update. I Use IOS 10.2 on both.

Has anyone created a bug report on this. It just weird that this bug has existed since 2012 without anyone doing something about it.

"Has anyone created a bug report on this."

I filed a bug report a while ago. I haven't tried it on 10.2 yet though, so I'm not sure what the current state of things is (aside from what's being reported here).

Just upgraded to 10.2 and am still having this problem.

The app will occasionally refresh (I think based on a timer), but behaviour is incredibly inconsistent and making it impossible to develop a web app on mobile devices.

Am having this problem on iPad 2 and iPhone 5 running iOS 9 and 10, respectively.

We have been building using a similar method to you guys and came across the same issue in iOS 10; just really unpredictable caching behaviour.

Eventually, our work around has been to strip back our manifest file and build it up item item.

The smaller the manifest file, the more predictable and reliable the caching behaviour.

So, suggest that if you can strip any fat out of your manifest and build it item by item, giving this a go.

Sorry it's not a 'proper' solution though!

I dont know how to fix the home screen problem, but 2 ways to force the page to reload once this happens are

1. Double click on refresh.

2. Load the page from a shortcut within Safari.

To avoid hair pulling you can put a false parameter name after the call to the css or js file you are trying to update/refresh. This works on Chrome too which also holds on to cache aggresively. Just put something like the following on the end of your script inclusion:

<link rel="stylesheet" href="mycssfile?id=12345.css">

or for js file

<script src="assets/js/myjsfile.js?id=1234”></script>

This forces Safari/Chrome into treating the file as ‘dynamic’ and it will update it each time. You can remove the ?id=12345 for production

‘id’ can be anything

‘12345’ can be anything

You don’t have to change the figure each time you make a change, but if your browser suddenly stops updating again you can just change the number by one digit for instance,

hope that helps,

Changing the stylesheet filename has worked for me in the past.

But even quicker on my IPhone 6, I was able to refresh to updated CSS data for a webpage-in-progress by holding down refresh (right side of address bar) until "Request Desktop Site" popped up. I clicked on it and the webpage completely updated, styles and all.

Subsequent loads from a blank browser page and simple refreshes are still using the updated CSS data.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an API to opt-out of back-forward cache? #5744

rakina commented Jul 20, 2020 • edited

• 👍 15 reactions

smaug---- commented Jul 20, 2020

Sorry, something went wrong.

mystor commented Jul 20, 2020

rakina commented Jul 21, 2020

annevk commented Jul 21, 2020

• 👍 2 reactions

mystor commented Jul 21, 2020

cdumez commented Jul 21, 2020 • edited

• 👍 4 reactions
• 👎 1 reaction

altimin commented Jul 21, 2020

geoffreygaren commented Jul 21, 2020

domenic commented Jul 21, 2020

Cdumez commented jul 21, 2020.

beidson commented Jul 21, 2020 • edited

• 👍 3 reactions

beidson commented Jul 21, 2020

Smaug---- commented jul 21, 2020, smaug---- commented jul 21, 2020 • edited.

• 👍 1 reaction

geoffreygaren commented Jul 22, 2020

Geoffreygaren commented jul 22, 2020 • edited, beidson commented jul 22, 2020, rakina commented jul 22, 2020, domenic commented jul 22, 2020.

jakub-g commented Nov 18, 2020 • edited

Geoffreygaren commented nov 19, 2020, rakina commented nov 19, 2020 • edited.

fergald commented Apr 1, 2021

Smaug---- commented apr 1, 2021 • edited.

This comment has been minimized.

Annevk commented may 6, 2021, jakearchibald commented may 6, 2021 • edited, fergald commented may 10, 2021, fergald commented jun 2, 2021 • edited.

No branches or pull requests

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

How to disable Safari Cache's ?

MacPro OS 10.6 , iPhone 3G

Posted on Dec 13, 2009 10:13 AM

Loading page content

Page content loaded

Dec 13, 2009 10:53 AM in response to JoeyG15

Dec 13, 2009 11:50 AM in response to JoeyG15

Dec 13, 2009 12:32 PM in response to JoeyG15

Dec 13, 2009 12:40 PM in response to JoeyG15

Dec 20, 2009 6:55 AM in response to JoeyG15

Dec 20, 2009 6:58 AM in response to JoeyG15

Dec 20, 2009 7:04 AM in response to JoeyG15

Dec 20, 2009 8:38 AM in response to V.K.

Dec 20, 2009 8:54 AM in response to JoeyG15

Your Guide to Private Browsing in Safari

Private browsing is often misunderstood, but it can be a helpful feature if you know what’s what.

Quick Links

What private browsing does in safari, how to use safari private browsing on iphone and ipad, how to use safari private browsing on a mac, how to disable safari private browsing on iphone and ipad, how to disable safari private browsing on a mac, key takeaways.

• Private Browsing in Safari hides browsing history, autofill details, downloads, and locks tabs after inactivity.
• Safari on Mac groups private and non-private tabs, while on iPhone it shows all tabs regardless of mode.
• To use Private Browsing in Safari, identify it by a dark address bar, "Private" indicator, or "Private" next to the site URL.

Most browsers offer a private browsing mode that aims to keep the websites you view off the record. But what exactly does it do in Safari and how do you get the best out of it?

First and foremost, Private Browsing keeps the website pages you visit out of your History . The aim is to prevent someone else from seeing which pages you have visited if they have access to your phone or computer.

In Safari, Private Browsing does a lot more than just hide URLs. It also:

• Prevents recent searches from showing up in your history.
• Stops remembering details you enter in forms for autofill.
• Keeps downloaded items from appearing in your Downloads list.
• Locks private tabs after a period of inactivity.
• Adds tracking and fingerprinting protection.

However, it’s important to note that Private Browsing does not stop you from being tracked altogether. Websites you visit will still be able to use various methods to track you, and will still have access to all data that you send them.

On macOS, iOS, and iPadOS, Safari groups private tabs together, and separates them from non-private tabs. On Mac, each Safari window is either private or non-private, and can have as many tabs as you want.

On iPhone, you can switch between private and non-private modes, each of which shows all tabs belonging to that mode.

You can spot when you’re viewing a private tab with these signs:

• The address bar has a dark background. This may be less noticeable if you’re using Dark Mode .
• On Mac, you’ll see a prominent Private indicator in the title bar.
• On iPhone, you’ll see Private alongside the site URL at the bottom of your screen.

The steps to enter Private Browsing mode are nearly identical on an iPhone and iPad. The only difference is that the tab icon is at the bottom of the screen on iOS and the top on iPadOS.

• Long-press the tab icon (two overlapping pages) on the bottom-right (iPhone) or top-right (iPad) of your screen.
• Tap the New Private Tab menu item.
• If locked, enter your passcode to unlock Private Browsing.

You can enter Private Browsing mode on macOS using either a menu item or a keyboard shortcut:

• Open the File menu and choose New Private Window .
• Alternatively, use the keyboard shortcut Shift + Cmd + n .
• Use the browser as you normally would. Any tabs you open from this window will open in the same window, in private mode.

You may want to prevent users of an iPhone or iPad from using Private Browsing mode at all. To do so:

• Open the Settings app.
• Tap on Screen Time .
• Under RESTRICTIONS , click on Content & Privacy Restrictions .
• If not already enabled, press the toggle next to Content & Privacy Restrictions to enable.
• Tap Content Restrictions .
• Change the Web Content setting to Limit Adult Websites .

The option to enter private mode will now be gone.

On macOS, the wording of certain options differs slightly, but the overall process is near-identical to iOS:

• Open System Settings via the Apple menu.
• Click on Screen Time in the left panel.
• Under the Restrictions section, click on Content & Privacy .
• Click Content Restrictions .
• Change the Access to Web Content setting to Limit Adult Websites .

Private Browsing will now be unavailable in Safari, although any existing private windows will stay open.

Of course, anyone can re-enable Private Browsing using the same process, in reverse. However, you can use Screen Time’s Lock Screen Time Settings option to set a passcode and enforce the setting permanently.

블로그 마켓 판매자의 이력 관리를 위해 블로그 주소 변경이 불가합니다.

블로그에서 진짜 나를 기록하고 다양한 이웃과 소식을 만나보세요. 지금 시작해볼까요?

• 설정한 아이디는 나중에 변경할 수 없으니 신중하게 입력해주세요.
• 변경 전 공유된 블로그/글/클립 링크는 연결이 끊길 수 있습니다.
• 네이버 아이디 또는 개인정보가 포함된 문자 사용 은 피해주세요.
• 블로그 도움말에서 아이디 변경 유의사항을 확인해보세요.

1. 이전 주소로 공유된 글은 3개월간 새로운 주소로 연결을 지원하며 이후 언제든 연결이 끊길 수 있습니다.

2. 블로그 아이디는 한번 변경하면 다시 변경이 불가능 합니다.

블로그 아이디는 한번 정하면 다시 변경이 불가능합니다.

이 아이디로 블로그를 만들까요?

환영합니다! 블로그 아이디가 만들어졌어요.

기본정보를 입력해주세요..

나중에 언제든지 변경할 수 있어요.

관심분야를 선택해주세요.

선택한 분야의 글과 이웃을 추천받을 수 있어요.

인기블로거와 이웃을 맺으세요.

이웃을 맺으면 이웃새글에서 글을 받아볼 수 있어요.

- navigation 속도를 높일 뿐만아니라 네트워크 요청을 덜하므로 데이터 사용을 줄일 수 있다.

- 크롬 사용 통계 데이터에 따르면, 데스크탑의 경우 10% 모바일의 경우 20%가 네비게이션에서 사용됨을 알 수 있다.

- bfcache 를 통해 데이터 전송과 페이지 로딩을 위한 시간을 줄일 수 있다.

BFCache vs HTTP Cache

- HTTP 캐시는 이전에 만들어진 요청에 대한 응답만 캐싱함.

- 페이지 로딩에 필요한 최적화를 HTTP캐시로 모두 하기는 어렵기 때문에

- BFCache를 사용하지 않고, 아무리 최적화를 잘 했다고 하더라도 BFCache를 사용한 경우가 무조건 빠르다.

브라우저별 BFCache 지원 상황

- Firefox, Safari → 몇 년전 부터 지원해 왔음(desktop, mobile 모두)

v86: Android(일부), cross-site navigation만 지원

v87: Android(전부), same-site navigation까지 지원 예정

BFCache 작동을 판단할 수 있는 API 🌟

pageshow / pagehide (Page Transition API)

- 거의 모든 브라우저에서 지원하는 이벤트(BFCache만큼 오래된 이벤트)

- 페이지가 처음 로드될 때, 그리고 bfcache에서 페이지가 복원 될 때 마다 load 이벤트가 불린 직후에 실행된다.

- persisted property를 이용해서 BFCache로 복구되었는지 확인 할 수 있다.

- 페이지가 정상적으로 로드되지 않거거나, 브라우저가 페이지를 bfcache에 저장하려고 할 때 발생한다.

- persisted property가 false면 bfcache에 저장되지 않았다는 뜻이다.

- 브라우저가 페이지를 캐시하려고 했지만 캐시할 수 없게 만드는 요인이 있을 수 있기 때문에,

- true라고 항상 bfcache에 캐싱되었다고 할 수는 없다. (=브라우저가 bf캐싱을 하려고 했다는 '의도'만 알 수 있다는 뜻)

​ freeze / resume (Page Lifecycle API)

아래 이미지는 페이지 라이프 사이클 이벤트(page lifecycle events) . 크롬에만 있는 이벤트라고 생각 하면 된다.

- 크롬 기반 브라우저에서만 지원되는 이벤트. (새로 생긴 이벤트)

- BFCache로 들어가고 나올때 호출되는 이벤트.(그 외의 상황에서도 호출되기도 함)

➡️ 어떤 상황에서도 호출될까? CPU 사용량을 최소화하기 위해 백그라운드 탭이 동결된 경우

- bfcache에서 페이지가 복원될 때(pageshow 이벤트 직전에), 그리고 사용자가 정지된 배경 탭을 다시 방문할 때도 실행된다.

- pagehide 이벤트의 presisted 값이 true일 경우에, pagehide이벤트 다음으로 호출됨.

- pagehide와 동일하게 브라우저가 bfcache를 하려고 했다는 '의도'만 알 수 있다.

BFCache를 위해 페이지 최적화 하는 팁 🌟

모든 페이지가 bfcache에 저장되는 것은 아니다. 또한 bfcache에 저장되었다고 하더라도 무한정 그곳에 머무르지는 않을 것이다. 개발자들이 캐시 적중률을 극대화하기 위해 페이지를 bfcache에 적격(eligible)하게, 혹은 부적격(ineligible)하게 만드는 이유를 이해하는 것이 중요하다.

1) unload 이벤트 사용하지 않기

모든 브라우저에서 bfcache를 최적화하는 가장 중요한 방법은 unload 이벤트를 절대로 사용하지 않는 것 이다. unload 이벤트는 bfcache 이전에 선행된다. 근데 unload 이벤트가 발생한 후에는 페이지가 더이상 존재하지 않을 것이라는 (합리적) 가정 하에 많은 페이지가 운영되기 때문에 브라우저를 개발하는 입장에서 unload가 있는 경우 bfcache를 할 지 말지가 큰 딜레마 였다고 한다.

그래서 브라우저는 페이지에 unload 이벤트 리스너가 추가되어 있는 경우 bfcache에 적합하지 않은 페이지로 판단 하는 경우가 많다.

- firefox, safari, chrome 등등 브라우저별로 어떻게 bfcache에 넣을건지에 대한 알고리즘은 차이가 있지만 일단 unload 이벤트 리스너가 있다면, bfcache를 고려하는 부분이 있다는 것이다.

- unload 이벤트 보다는 pagehide 이벤트를 사용하도록 하자!

- pagehide 이벤트는 unload가 불리는 모든 경우에 다 불린다.

- 심지어 Lighthouse v6.2.0 에서 no-unload-listeners-audit 까지 추가했다고 함!!

- 근데 정~ unload 이벤트 리스너를 추가해야한다면, beforeunload 이벤트 리스너를 추가 하도록 해라.

- beforeunload 이벤트 리스너는 브라우저가 bfcache에 부적격(ineligible)한 요소로 판단하지 않는다. ( 자세한 예시 )

2) window.opener 참조를 피해라

몇몇 브라우저에서는(Chrome v86 포함) window.open() 이나, rel="noopener" 을 사용하지 않고 target=_blank 를 통해 새 창을 여는 코드를 작성한 경우, 열린 창에는 열게한 창의 window object에 대한 참조가 있다. 이렇게 window.opener가 null이 아닌 참조가 되어 있는 경우 bfcache에 안전하게 넣을 수 없다.왜냐하면 보안 문제가 있을 뿐만 아니라 bfcache에 액세스를 시도하는 모든 페이지가 깨질 수 있기 때문이다.

- 즉, rel="noopener"를 사용하여 target=_blank 를 통해 새 창을 열도록 하자! (window.opener reference를 만들지 않음)

- 만약에 새창을 열고, window.postMessage()를 통해 그것을 제어하거나 window object를 직접 참조할 필요가 있다면, 열린 창이나 열게한 창 모두 bfcache할 자격이 없다.

3) (navigate 하기 전에) 항상 open된 connection 닫기

setTimeout(), promise와 같이 아직 코드가 진행중(?) 인데, 다른 페이지로 이동한 경우에는 브라우저는 진행중인 setTimeout나 promise 코드를 일시정지하고 다시 BFCache에서 복원될 때, 진행 중이던 코드를 재개한다.

scheduled된 JavaScript task들이 단지 DOM API에 접근한다거나, 해당 페이지에만 영향을 주는 고립된 API라면 일시정지 했다가 다시 재개하는게 문제가 되지 않을 것이다. 그러나 scheduled된 task가 same-origin의 다른 페이지에서도 엑세스 할 수 있는 API의 경우(예: IndexedDB, Web Locks, WebSockets, etc.) 작업을 일시 중지했을때, 다른 탭의 코드가 실행되지 않을 수 있기 때문에 문제가 발생할 수 있다.

그러므로 대부분 브라우저에서 아래와 같이 connection이 open된 경우에는 bfcache에 해당 페이지를 넣으려고 하지 않는다.

- Pages with an unfinished IndexedDB transaction

- Pages with in-progress fetch() or XMLHttpRequest

- Pages with an open WebSocket or WebRTC connection

pagehide나 freeze 이벤트에서 항상 connection을 close하고, observer를 제거하거나 연결을 끊는 것이 좋다. 이렇게 하면 다른 열린 탭에 영향을 미치지 않고 페이지를 안전하게 캐시할 수 있다. (당연하겠지만, pageshow나 resume 이벤트에서 bfcache로 부터 복구됬을때 커넥션을 다시 연결 해주도록 하면 된다.)

현재 Chrome에서는 페이지를 bfcache에 최대 3분 동안 유지할 수 있다. 테스트(Puppeteer or WebDriver)를 하기 충분한 시간이다. 테스트는 navigating 후 페이지 뒤로 가기를 했을 때, pageshow 이벤트의 persisted 속성 값이 true인지 확인하면 된다.

정상적인 조건에서 페이지는 테스트를 실행할 수 있을 만큼 충분히 오랫동안 캐시에 남아있겠지만, 시스템 메모리가 부족한 경우 캐시된 데이터가 조용히 지워질 수 있다. 즉, 테스트 실패가 반드시 페이지를 캐시할 수 없다는 것을 의미하지는 않으므로 테스트 실패 기준을 적절하게 구성해야 한다.

chrome에서 bfcache 테스트

현재 크롬에서는 mobile에서만 bfcache 사용 가능함. desktop에서 bfcache 테스트를 하고 싶다면 #back -forward-cache flag를 켜라.

BFCache 사용 안하는 법

최상위 페이지 응답 헤더의 Cache-Control을 no-store로 설정. 아래와 같이 설정해주는 것이 아닌, 다른 캐싱 설정은 bfcache 자격을 판단 하는 데에는 전혀 영향을 미치지 않음. 그러니까 bfcache를 안하고 싶으면 아래와 같이 설정해줘야함.

ㅋㅋ 그치만 위의 설정이 다른 캐싱 성능에 영향을 줄 수는 있다.

bfcache를 사용하면 성능 측정이 덜 될 수 있음

사이트 방문을 추적하기 위해서 분석도구를 이용하는데, bfcache로 인해 전체 페이지뷰 수가 감소하는 것을 발견할 수 있었다고 함. 대부분의 인기있는 분석 라이브러리는 bfcache 복원을 새로운 페이지뷰로 추적하지 않기 때문이다. 이것까지 새로운 페이지뷰로 추가하려면 pageshow 이벤트의 persisted 속성을 이용해서 처리해주면 된다.

성능 지표에 부정적인 영향을 미칠 수 있음

특히 페이지 로드 시간을 측정하는 지표에 부정적인 영향을 미칠 수 있다.

bfcache 네비게이션은 새로운 페이지 로드를 하지 않고 기존 페이지를 복원하므로, 수집된 페이지 로드의 총 수가 감소 한다. 그리고 bfcache를 이용하여 페이지를 복원한 속도를 가장 빠른 속도로 판단 할 수 있다.

이런 부분은 navigation 타입 을 잘 분기처리(navigate, reload, back_forward, or prerender)하여 판단하면 된다.

https://web.dev/bfcache/

안녕하세요. 이 포스트는 네이버 블로그에서 작성된 게시글입니다. 자세한 내용을 보려면 링크를 클릭해주세요. 감사합니다.

글 보내기 서비스 안내

2009년 6월 30일 네이버 여행 서비스가 종료되었습니다. 네이버 여행 서비스를 이용해 주신 여러분께 감사드리며, 더 좋은 서비스로 보답할 수 있도록 노력하겠습니다.

악성코드가 포함되어 있는 파일입니다.

백신 프로그램으로 치료하신 후 다시 첨부하시거나, 치료가 어려우시면 파일을 삭제하시기 바랍니다.

고객님의 PC가 악성코드에 감염될 경우 시스템성능 저하, 개인정보 유출등의 피해를 입을 수 있으니 주의하시기 바랍니다.

작성자 이외의 방문자에게는 이용이 제한되었습니다.

{ALERTMESSAGE}

이용제한 파일 : {FILENAME}

네이버는 블로그를 통해 저작물이 무단으로 공유되는 것을 막기 위해, 저작권을 침해하는 컨텐츠가 포함되어 있는 게시물의 경우 글보내기 기능을 제한하고 있습니다.

상세한 안내를 받고 싶으신 경우 네이버 고객센터로 문의주시면 도움드리도록 하겠습니다. 건강한 인터넷 환경을 만들어 나갈 수 있도록 고객님의 많은 관심과 협조를 부탁드립니다.

주제 분류 제한 공지

네이버는 블로그를 통해 저작물이 무단으로 공유되는 것을 막기 위해, 저작권을 침해하는 컨텐츠가 포함되어 있는 게시물의 경우 주제 분류 기능을 제한하고 있습니다.

작성하신 게시글 에 사용이 제한된 문구가 포함 되어 일시적으로 등록이 제한됩니다.

이용자 분들이 홍보성 도배, 스팸 게시물로 불편을 겪지 않도록 다음과 같은 경우 해당 게시물 등록이 일시적으로 제한됩니다.

• 특정 게시물 대량으로 등록되거나 해당 게시물에서 자주 사용하는 문구가 포함된 경우
• 특정 게시물이 과도하게 반복 작성되거나 해당 게시물에서 자주 사용하는 문구가 포함된 경우

스팸 게시물이 확대 생성되는 것을 방지하기 위하여 문구 및 사용 제한기간을 상세하게 안내해 드리지 못하는 점 양해 부탁 드립니다. 모두가 행복한 인터넷 문화를 만들기 위한 네이버의 노력이오니 회원님의 양해와 협조 부탁드립니다.

더 궁금하신 사항은 고객센터 로 문의하시면 자세히 알려드리겠습니다.

수정하신 후 다시 등록해 주세요.

회원님의 안전한 서비스 이용을 위해 비밀번호를 확인해 주세요.

다시 한번 비밀번호 확인 하시면 이용중인 화면으로 돌아가며, 작성 중이던 내용을 정상적으로 전송 또는 등록하실 수 있습니다.

공감을 삭제하시겠습니까?

이 글의 공감수도 함께 차감됩니다.

작성하신 에 이용자들의 신고가 많은 표현이 포함 되어 있습니다.

다른 표현을 사용해주시기 바랍니다. 건전한 인터넷 문화 조성을 위해 회원님의 적극적인 협조를 부탁드립니다.

블로그 마켓 가입 완료

내 상품 관리에서 배송비 설정 후 상품 판매를 시작해보세요!