Safari and it's greedy greedy cache

Question

Now this has come up a fair bit on here so I guess I'm looking for an explanation rather than a fix (though that would be ace), but Safari's back / forwards cache is horrifically greedy.

I've got an issue where a form submits, but loads an interstitial modal window before moving on to the form action page. On Safari the cache is so strong that the back button has the modal open still which is making my soul very sad.

I'm hacking around it by dismissing the modal and then submitting the form. On back the browser has a half closed modal (it's Bootstrap so it fades) which then just carries on dismissing.

Now I know about onunload="" but refreshing the page just seems crazy. The cache is a good thing and something you want, specially on mobiles.

I guess my question is:

Why is it so much more intense than say Chrome and is there anyway of forcing the browser to cache a state instead of just the last state?

Thanks

Answer 1

Hah, greedy is an understatement! Honestly though, 99% of the time, the caching design behind Safari is the ideal way to handle page transitions on a mobile device.

When you go from Page A to Page B, and then back to Page A, you don't want to burden the device (bandwidth, battery life) with fetching resources and assets, when you could just "paused" the state between interactions, and then "continue" it when you navigate back.

That's effectively what Safari Mobile does. They use a concept of Page Cache, which keeps the entire page live in memory, when you navigate from one to another. This reduces the need to fetch those resources, and allows for a snappy interaction when clicking back.

That's great and all...but it does lead to problems (such as the one you brought up) - Specifically, how do you distinguish between a page that was suspended and one that should have been destroyed?

Thankfully, WebKit provides a pageshow and pagehide event that tap into Page Cache. In addition to firing when the page shows or hides (similar to onunload), it has the nifty ability to indicate whether a page was persisted - or placed into the Page Cache.

While it's not a perfect solution, you could check the pageshow event for persistence, and then handle the modal more directly (since you know it was cached) like immediately hiding it.

If you haven't already, take a look at these two links here:

https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/ https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/

They do a great job explaining the Page Cache and include code samples of the pageshow and pagehide event I referenced earlier.

Hope this helps!