> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it.

How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?

> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.

In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).