It doesn't feel faster to me. And that's the case with Ajax in general - in principle, it can allow for snappier, faster experience. In practice, it rarely does.
I just measured it: switching between "drafts" and "inbox" on the new gmail takes ~15 ms, while on the simple HTML view, it takes 3-500ms per load.
Its literally 20 times faster, and importantly, cuts across the human visual perception boundary, which is at ~200ms. So the old HTML version is human perceptible, while the new version renders in ~1 frame.
Fair enough. On a fast enough machine. This is off-topic, but while on my beefy dev desktop I get similar times to you, this was absolutely not the case on a much weaker laptop I used sometimes during travel - and the latter is more representative of how regular people experience things.
(Also, FWIW, loading delay of HTML pages on said beefy desktop, as tested right now, are consistently about 750-1500ms for me.)
More on-topic, these times apply only when the pages are hot in the browser cache. On my desktop, the first-time switch between "drafts", "sent" and "inbox" takes around 3 seconds each, and only then it is instantaneous. So regular users are likely to experience these long Ajax delays more often than not.
It depends on the application though. Mapping apps (e.g google maps) without ajax are awful.
Even basic UIs like filtering can be bad if you want to change multiple filters, and you have to wait for a whole page load in between each change (page load times for pages with filters are often slow as they're performing complex queries).
It's a case of different things being appropriate for different use cases I think. There definitely are still times when plain HTML is best, but it's also not always faster.
I've built a React app that's under 300kb (cached with a service worker for subsequent page loads) that loads almost instantly and works offline. On the other hand, plenty of plain HTML sites include heavy CSS frameworks, or 5mb images, gifs, etc and load pretty slowly, especially on poor connections.
TBH, that's a side effect of "EVERYthing is a webpage, because that's the way it is!" Of course a map application is SLOOOOOOW when forced to go through all the intermediate steps to resemble a web page. Mapping apps that forgo this convention are snappy; but no: a chat client is a web browser, a map client is a web browser, the "show me two lines of text" notification bar is a God-damned webbrowser.
