Safari reloading pages when going back

I agree. And I don't know why there is this sudden hysteria about the problem. SAFARI HAS ALWAYS BEEN LIKE THIS!!! I like very many things about Safari but I've always hated the way that a Go Back reloads a webpage, unlike Firefox, or just about any other browser, which return you instantly to the page as it was, from the cache.

There is one way to confirm this problem : go to a site that you know changes every day (e.g. a newspaper or a daily word game or something). Go to that site in both Safari and Firefox. Next day, launch both browsers and observe...

Safari will load TODAY'S page not yesterday's -

Firefox will load YESTERDAY'S page.

This is how Safari seems to work. It always reloads web pages when you do a Go Back. It's infuriating but it seems to be part of the design.

No it hasn't. And we are talking about two different Back Page motions. For mine clicking the actual back button would always reload from the cache. But suddenly last year the two finger swipe to Back Page started to reload completely, but the button still did the cache. I changed mine to a 3 finger swipe and it loads from the cache. Use 2 and its a complete reload. It's purely a bug that Apple is blind too or ignoring for whatever reason.

I'm not talking about gestures, as I disabled them following the loss of comments I was typing by picking up the mouse which was too sensitive, and went 'Back" when I didn't want it to.

I use Command-[ and have done for years and years, in many flavours of Safari. And certainly for the past few years (not recently) this has refreshed a webpage rather than reloading instantly from cache.

This is WHY Safari - when relaunched the day after you last use it, and your session with it - gives you the latest version of the tabs in that session. Whereas if you do the same thing in Firefox or Opera, you get YESTERDAY's page as it reloads everything from cache.

Try it, if you don't believe me.

The method suggested above involving the Debug menu does work for me. However, it disables the swipe feature so I must click the Back button. This is a non-solution.

This argument on refresh being there to save you from looking at yesterday's news reminds me of the "a feature not a bug" excuse we used in our college days when programming presentations went south!

I tried you guide and it does stop the refreshing on going back. But it disables two finger swiping so its no good as thats how i always navigate Safari.

Please keep psting yout findings people.

Pothetic that apple hasnt sortted it out yet!

Based on all above ideas here is what worked for me (just set this up so too early to say what else it breaks)..

Do the Debug step and check the "Use Single Process Window" (make sure you read this http://osxdaily.com/2011/09/20/stop-safari-auto-refreshing-web-pages-in-mac-os-x -lion/ - read the caveat at the bottom of the article and only select this option if the benefits outweigh the issues it may cause).

Yes I know this disables the two finger swipe back and forward..so a workaround is to use a tool like BetterTouchTool (http://www.bettertouchtool.net) and make a safari specific setting for 2 finger swipe left and right to enable the History Bk and Fwd as shown in the last two entries in the pic below:

The refreshing on swipe back REALLY is a pain when for example shopping on Amazon.com. When you go back from a product/item detail page to the product list page, it positions you BACK AT THE TOP of the list, not where you left off.

Really stupid how this works.

Bob H

P.S. I've tried the single process option thing ... but then you loose ability to swipe back. That is not an acceptable work around for me.

I find the pinch zoom and left/right scroll are not as precise when using Chrome. This is on a Macbook Air using the integrated track pad. Otherwise I do like Chrome and have used it extensively on other pc's but I find Safari works better on the MB Air.

Well we are all here for the same reason and have yet to find a viable solution except the single process mode which for me I don't find it a viable solution since it disables the swipe.

Honestly, at this point the best alternative is to download google chrome or firefox. Takes a few minutes and whammo don't have the problem anymore.

I know, I know. I like using Safari also and it doesn't hurt to have both browsers open and use Safari most the time and when you get on a site where you use the back button quite a bit and don't want it to refresh then just use Chrome.

So, almost a year later and still nothing to resolve this. Congratulations Apple for being all over this.

Imagine how infuriating this reloading behaviour is on slow broadband connections. Sadly some of us don't have access to fibre speeds.

Firefox and Chrome win again.

I really hope this issue is fixed in the next update coming with OS X Mavericks... I have no idea why it wouldn't be fixed, but apparenlty this issue has been going on for years accross multiple versions of Safari :/... Google Chrome until this ONE issue I have with Safari is fixed.

I'm experiencing the same bug here.

On some italian forums they say that this is normal, because Safari *have* to reload every page when you go back.

Since it sounded odd to me, I decided to make a research in English and here's the problem.

As I see, there is no solution.

It's very annoying, in particular when you visit heavy pages.

I was having the same problem. This is a percieved delay.

By default, Safari uses it's cached version of the previous page to refresh the window when navigating back, and when it's pulling from its cache, the refresh happens quickly enough that we don't really notice. When Safari refreshes the page from the server, we see a longer delay while it does so. We're used to both of these scenarios from pre-swipe-gesture days.

Under normal circumstances, Safari will only refresh the page from the server either because it's been told to do so by the webpage, or an extension requires it. For example:

Many web pages have a javascript onLoad call to refresh the page every time it's loaded (this includes when it's loaded from the cache). So when Safari reloads the page from its cache, the javascript in that page forces safari to do a refresh from the server. This is why disabling Java fixed it for some people.

Other web pages use HTML code to achieve the same onLoad server refresh or to prevent a web browser from caching the page in the first place. Since it's coded in HTML, nothing will disable this behavior, this may be why nothing works for some people.

Some individual extensions or plugins require a server refresh on page load, this is why disabling some or all extensions fixed it for some and disabling plugins fixed it for others.

FYI, (for testing) Gawker sites use one of these refresh-on-page-load strategies. In either of these cases, Safari is forced to refresh the page from the server.

When you use the swipe-back navigation, Safari performs the animation you see where the page slides off to the right, revealing the previous page below it. Safari does this by substituting the "live" webpage with a snapshot of both the current and the previous pages to perform the animation. Once the animation is complete, Safari then reloads the page from its cache, and if instructed by the webpage, refreshes it from the server. If the page included the HTML meta tag "NO-CACHE", then there is no page in Safari's cache to draw from and it has no choice but to refresh it from the server.

You can see this snapshot substitution happen via the Debug menu. (look back on this thread or google for how to enable it.) Select Debug > Miscillaneous Flags > Discolor Fluid Swipe Snapshots

Now navigate to a page and swipe back. You'll see the snapshot that Safari is using to show you both the page you're on and the previous page during the animation because it'll be grayed over with a dull brown-ish color. The discoloration shows you that you're not seeing the live webpage itself, but Safari's snapshot of it. Once the animation completes, you'll see the discoloration go away and the previous page is fully displayed. Safari then reloads it as explained above.

Now go to System Preferences > Trackpad > More Gestures, and change "Swipe between pages" to "Swipe with two or three fingers". Swiping with three fingers bypasses Safari's swipe-back animation. Now navigate using a three finger swipe and you'll see what Safari is doing without the animation, and it feels normal.

The percieved part:

The swipe-back animation makes you take notice of the fact that it's refreshing. Because you're seeing the page displayed underneath the one that's sliding out, you expect it to remain static once the animation finishes. Then it refreshes and you're like, "What the ****? it was just there, why did it have to refresh?" Without the animation, it feels normal.

To fix it, perhaps Apple could code Safari to keep recent history pages open and active in seperate processes (like it currently does with open tabs and windows) and display that at the end of the snapshot animation instead of pulilng from its cache. It might be a worthy memory trade-off. PSST - you listening, Apple? 🙂

As it sits, the animation is a cool idea, with a no-win implimentation.

Unfortunately, I have not found a way to disable the animation on a 2-finger swipe. So when I browse Gawker sites and other regulars such as Digg and Reddit, which I know force a refresh, I'll use a 3-finger swipe to navigate.

Hope this clears up some confusion.

Well... Your post makes a lot of sense, except for the fact that other browsers, chrome for example, don't refresh the whole page like Safari does... Why is that?

That's why I use chrome instead of safari.

I don't think it is a "perceived" thing. We noticed it cuz it didn't use to do it before, the proof? Other browsers don't do it.

My best guess is that Firefox and Chrome use a more aggressive caching strategy.

Historically, Apple writes Safari to adhere closely to the standards and protocols set forth by the W3C, and protocol says that a cached page be checked against the server version when it's referred so the user is seeing an accurate version of the page.

Web devs will tell you that Safari is a breath of fresh air when coding a website, because it follows all the rules and is usually among the first to impliment new upcoming standards that haven't yet been officially ratified by W3C (early support for color profiles, HTML5, etc).

While Chrome and Firefox may trade off protocol recommendations for more persistent caching, which usually (but not always) works well for the end user, this strategy may also occasionally show up as a bug and can be a major headache for web developers. Internet Explorer is a shining example of this. Us web devs can code a site and it'll work and display perfectly Safari, Chrome and all the rest, and then we have to recode it with hacks to work in IE, which doesn't adhere to standards, and to a lesser extent, Firefox. As a user, have have you ever had a site that will only work in IE? Yeah, frustrating. It's because the web dev coded it specifically for IE because IE writes their own standards and doesn't conform.

If it helps, just recognize that Safari is doing what it's supposed to be doing. The problem is in Apple's implimentation of the animation. Software development is often a trade-off between what's ideal and what can be done within external constraints. But yeah, I agree, Apple should find a way around this dilema.