For apple defenders, the answer is bad apple coding....
Web pages just aren't that big.
Try this:
- Install and launch Fiddler (or your favorite web debugger) on your desktop
- Clear your browser cache
- Visit 5 or 6 of your favorite sites
- Examine Fiddler to see how much stuff was downloaded.
I just did this for:
- nin.com (just cuz I heard it was a problem site -- indeed it's ~23.5 MB itself)
- macrumors.com
- reddit.com
- yahoo.com
- huffingtonpost.com
- slate.com
- theverge.com
I got a total of about 41 MB.
Hmm... seems pretty likely Safari could hold every single resource downloaded by all of these sites in memory pretty easily, even with *just* 1024 MB RAM.
"Wait a minute," the astute reader might exclaim, "web sites aren't static -- once their javascript is loaded and starts executing, the page gets modified in memory.. you have to save that state, too, to avoif a refresh."
Good point. Let's dig deeper and see if we can analyize this further, shall we?
Here's a breakdown of what was downloaded by type of resouce:
- 27 MB of images (nin.com was over hald of that)
- 5 MB audio (nin.com was almost all of this)
- 4 MB javascript
- 1.7 MB flash
- 1.5 MB html
- 0.6 MB headers
- 0.5 MB css
- 0.5 MB fonts
- ~0.5 MB other
Interesting.
Flash isn't going to load in iOS at all so we can ignore that.
Images and audio are static, so those can be retained in memory as-downloaded. Likewise for headers and fonts.
I'm going to ignore other because it's small.
Now, I realize that images are quite possibly loaded into memory uncompressed, while those download sizes are for compressed images. However, keep in mind, Safari only needs the images in uncompressed form for the ones it is drawing to screen. It would only need to reatain the compressed images for ones that aren't on the current tab (or even for ones that are scrolled far off screen on the current tab.
So now we're looking at about 33.5 MB static resources and 6 MB of more dynamic HTML, Javascript, and CSS content.
The dynamic stuff is presumably needs to stay loaded in meory and probably takes up a lot more bytes parsed and loaded than on the wire. Let's just say 4 times more.
So now we're at 33.5 MB static resources plus 24 MB page state.
Then there's whatever memory the executing code allocates for its own purposes. Now, arbitrary Javascript code can allocate arbitrary amounts of memory. But give the kinds of web pages these are, the Javascript code would have to be pretty horribly written to consume more more than, say the size of everything else combined, or ~ 58 MB. While it's true that if there's some page with a voracious memory leak, it may try to allocate a lot more memory (not sure Safari would allow it), but then, even 2 GB or 4 GB, etc. isn't safe from an out-of-control memory leak.
So:
For seven decent sized sites:
... we're at about 116 MB RAM... or about 11% of 1 GB RAM
to maintain these sites off screen so that switching back to them does not requre a refresh.
I know this analysis isn't irrefutable.
E.g., I pulled that 4 x number regarding loaded page state size vs. download size out of thin air.
But just looking at the size of the numbers involved, RAM is not the first thing I would look at when figuring out how to get Safari to refresh tabs less.