First, What’s a “One Page Web App”?
The user may perceive that they have “changed pages” when in fact they’re looking at a page that was updated dynamically by loading data from the server.
Also, by fetching data in a more low-level format instead of pre-rendered HTML you offload work from the server. Any client-side caching you do also means less work for the server, in theory.
It may take longer to load the page because you have more of your application loaded up front. You keep more loaded in memory (due to caches, copies of data, and invisible images/elements) and so your browser uses more memory on the end-user’s computer.
Browsers are really good at using their own cache to load new pages quickly if they contain many common elements, especially if the markup is simple, so you don’t see a huge performance boost for the end user from having images and CSS already loaded.
People have slow computers and you can’t upgrade everyone’s computer. You can upgrade your server, and if you throw a decent amount of money at it you should be able to serve up new pages super fast.
Adding a good cache on the server-side and pre-loading it a bit should allow you to serve many pages almost instantly.
Striking a Balance
Recent developments with HTML5 make it possible to do a bit of trickery where when a user navigates between pages you can send down just the differences and update the URL bar as if they’d really changed pages.
This may be more work for the server because it has to calculate those differences to some degree, but I think the page update will be faster than sending raw data down to some client-side JS or doing a full page transition.
For future apps this may be the approach that I would take.
If you’re a web developer, let me know your thoughts and experiences in the matter. Is this the direction highly responsive web apps are going?