Non-SSD disks are really slow for random accesses, like you might need if the cached files are not contiguous, and often congested due to background processes competing for their use. Meanwhile, the server most likely has those files in memory, ready to push them.

Yes, and it gets even worse if it's not the browser's disk cache, but the browser's RAM cache paged by the kernel to the swap.

Paging out RAM is fast, you just write pages to the disk in chunks that are contiguous on the disk. But the contiguous disk chunks don't correspond to contiguous virtual addresses, and when reading them back in, the order is just however the application chooses to access the pages, so it's quite random and hard to predict. And you can only buffer writes, not reads - you have to block reads until you get the data.

25 years ago you might have 4MB of swap, at 4KB page size that's 1000 pages, or 1000 potential individual points you may have to seek to.

Today 4GB of swap is sort of a minimum size that's not entirely useless, and that's 1 million pages, or 1 million potential seek points.

So IMHO putting swap on hard disks with 5-10 ms seek latency was very useful back in the day, but is pretty much obsolete now - if you need swap put it on flash based storage.

Disks are what, 10ms random seek? You'd need a good, nearby server to service in under that time. And that assumes you've got a connection already established. If not, then add another roundtrip. I'm not sure "often" is appropriate here.

That's best-case. (Well, not really. Best case is that your disk isn't doing anything, the data is in one contiguous region, the head is in the right position, and the data is about to pass under the head.)

In actuality, it can be a lot worse. I've seen latencies of 500ms+ before, when the disk is in "seek hell". And right now my laptop has a median (!) latency of ~100ms. Mind you I'm listening to music and copying files in the background. But still.

It's kind of a hyperbole, granted, but most of our assumptions about disk access being faster rely on only one piece of software accessing that disk. With modern multi-core processors, pre-fetching and caching both at the application and the kernel level that assumption is quickly proven to be faulty.

10ms random seek is fine when you're only accessing one thing. But when multiple things are loading and alternating between locations it becomes significantly slower. Windows startup can be a pretty good indicator of this. I've got one system with an SSD (containing the OS) and a spinning platter drive for data. When I start it up, I have to wait for more than a minute before clicking anything or I end up with an unresponsive application for 3+ minutes. It still induces a quiet, resigned rage that such a powerful system can be nigh-crippled on boot.

I'm not sure about the "often" either, but I don't find it absurd. A full page nowadays has 20-30 files, which might not get cached sequentially, so you're talking about a bunch of seeks. If half need to wait for some other application to read its stuff, you're already talking about a big increase in latency; on the other hand, the connection tax is only paid once per hostname.

It's plausible; I've been at a talk where they suggested checking the local cache and requesting it across the network in parallel. I'd thought maybe they were talking about, say, both people on a fast network, but digging into it, that's not the whole story.

Wikipedia [1] has 5,400rpm hard drives having average rotational latency of 5.56ms.

AT&T's real-time latency charts have a few spots with under 5ms latency, and that chart's just the average, I think, so these might be beatable.

[1] https://en.wikipedia.org/wiki/Hard_disk_drive_performance_ch...

[2] http://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html

There was a xkcd or something similar saying this, network round trip time was below hard drive on average.