Safari is not robust against network and CPU/memory fluctuations

Safari 5 isn't robust against network fluctuations. I use an Apple router and I have a very consistent connection (which lets me keep a single TCP session open to the outside world for months at a time). Yet, when I restore a crashed Safari session with many pages, I'm told that Safari can't open the page because it can't establish a connection to the server. The server is there, but probably because Safari is using swap, the TCP connections are being delayed, and so Safari thinks that the server isn't there. I'd suggest a staggered reloading of pages from a previous session (this would also apply to the case where Safari loads a group of bookmarks). When Safari detects that it is using high proportions of CPU or memory, it can also suspect that a network connection is not working because the TCP session has timed out. In the case that slim resources are available (or conversely, when Safari anticipates higher resource requirements), the number of connections it attempts at the same time can be throttled. Also, when the server is presumed to be not responding (especially when it's known to work before!), then it can consider retrying a few seconds later. This is especially relevant in the situation of a recovery of a past Safari session (where the possibility of doubly loading a page is slim). Also, in the situation that a user actually has an unreliable network, a restore of the Safari session can turn all of the opened pages into pages that may not properly open in the next attempt. So they would in that case get a multitude of tabs that say that the page is unavailable. Then each of these would need to be reloaded in turn. Supposing Safari crashed, or the user quits Safari. Then would a subsequent attempt to reload that page work? What if the web page shown in the URL is not quite identical to the final page that is rendered? What about taking into account redirects or situations where data is once again POSTed to the web site? These situations could be tested to consider greater robustness. Also, a secondary copy of the Safari last session can be kept for backup. Especially when this (or another, perhaps unanticipated) situation comes up. The file doesn't consume too much space. There is also a possibility that Safari could crash in the process of recovering the session (if the same bug triggers the crash again), so there is a risk of the user's last session details being corrupted. Once before I've noticed a large set of completely blank tabs (presumably in place of what formerly consisted of legitimate pages that now do not load properly due to the lack of throttling or robustness of Safari session restoring). I'd also be interested in Safari keeping track of additional data, such as individual tab history, so that it is available for a restore. Even if Safari kept that in a file (but didn't yet make use of that information), then the information could still be available in some form for the advanced user to look through. That's lower priority compared to the other issues, however.