Every single resource/asset, including logos, CSS, webfonts etc. will be fetched from the server. The server will answer with a 304 Not Modified, but still it's one round-trip per resource, and more if SSL is involved.
On a 2G or nasty 3G link all that latency adds up. Oh and please don't mention "but clients should cache stuff"... caching stuff on clients is broken beyond repair, buggy as f..k (hello iPhone, hello Firefox, hello Chrome - honestly, I haven't been able to get ALL major clients on ALL OSes to properly use caching!) and if you expect half of your userbase likely has a totally-broken-caching client (i.e. old Android phones) you better build your infrastructure to require as few requests as possible => SPA route.
> And mobile radios don't immediately go to their lowest power state after transferring the data
Now imagine me reading a typical reddit thread on the front page. Takes me about 30 seconds before I am disgusted by some troll comment, and I go back to /r/cats. In the non-SPA case I'd have 2x approx. 10s of the radio blasting at full power, in the SPA case I'd have 1x 10s for the initial load of the app and maybe 2s for the second load of the 30 posts of /r/cats. Oh, and not to mention I, like many other people, like to reddit while on the train - which means in any case that 20 kbytes/data for a simple JSON is better than 2 MByte for each simple request. That small JSON can be transferred via EDGE if the signal is as bad as it usually is but good luck for your nerves if you have to wait ages for every website.
> Not to mention the CPU overhead of the SPA's Js which is non-zero even if radio battery usage is a larger issue.
Yeah but unlike broken browser caching this one is something YOU can influence, not having to hope your users some day have enough cash to buy a phone with proper up-to-date software.
Edit: missed yet another thing. An SPA can request thumbnails matching for the device display resolution dynamically whereas a non-SPA solution (usually!) has only one thumbnail size.
HTTP/2 doesn't require a separate connection per resource if they are served from a few domains.
Also, do you really have a problem where an asset falls out of cache from one page view to the next? If so, the server wouldn't be returning a 304 in that case.
>In the non-SPA case I'd have 2x approx. 10s of the radio blasting at full power, in the SPA case I'd have 1x 10s for the initial load of the app and maybe 2s for the second load of the 30 posts of /r/cats.
Taking that example the radio would be at it's full power state for 20 seconds in the second case and 15 seconds in the first, not 12 as you'd expect. And as soon as the connection isn't so horrible that it takes 10 seconds just to get back everything is cached the 5 seconds of high power state starts to look less and less likely, and in most cases you'll be at parity if not using more power.
The number I've optimized/seen optimized around in the past is assuming it takes about 5 seconds of inactivity for the radio to go back to low power state (It was taken from the 3G days but is still what Google's Android documentation bases it's recommendations for efficent downloads on: http://www.research.att.com/articles/featured_stories/2011_0...), so each request gives at least 5 seconds of high power usage.
Of course this just goes back to what I meant about other content dominating load times, if your connection is so bad that getting back responses for cached items takes 10 seconds, I'm sure the download time for those images and videos will be through the roof.
Reddit solved the problem of reddit on a bad connection like that long ago with .compact. Before the "mobile" reddit links were .compact links (which is why there's now an annoying banner pushing you towards the SPA). .compact links being the non-SPA version for mobile/low-bandwidth.
It had hardly any assets to load and did tiny thumbnails on the subreddit's page, and comment page, instead of trying to load a giant image of the content.
The moment you click on the SPA link it takes a whopping 30 seconds to load a preview image of the GIF. It also takes an entire minute just to load the code and assets for the SPA itself if it hasn't been cached. Compare that to 2 seconds for the .compact link's document + styling. If you're visiting that SPA on a bad connection you'd better hope those browser caches do their job, and that ProductionClient.js hasn't changed recently...
.compact worked well on the kind of connection where bandwidth was so low you'd want to evaluate content before dedicating to a 30 second wait because you clicked on "Show Comments", which used to be any mobile connection in general.
>Yeah but unlike broken browser caching this one is something YOU can influence, not having to hope your users some day have enough cash to buy a phone with proper up-to-date software.
That'd be fine if it hadn't been chugging on an iPhone 6 plus while scrolling since it's beta til now. An iPhone 6 might not be the newest hardware, but at launch (and even now), it's what most mobile developers would treat as "modern hardware" and "modern up-to-date software". Code size doesn't need to equate to how CPU intensive a script is, but it's not exactly a mystery that the SPA chugs while .compact is fast when the SPA has three times the Js and twice the CSS just for it's "core". .compact looks dated because of the few assets it uses (and trying to look like an iPhone app). Nothing would stop Reddit from making .compact links look modern, except they're clearly trying to drive .compact users to the SPA (they were much more aggressive about it back when it was in "beta")
On a 2G or nasty 3G link all that latency adds up. Oh and please don't mention "but clients should cache stuff"... caching stuff on clients is broken beyond repair, buggy as f..k (hello iPhone, hello Firefox, hello Chrome - honestly, I haven't been able to get ALL major clients on ALL OSes to properly use caching!) and if you expect half of your userbase likely has a totally-broken-caching client (i.e. old Android phones) you better build your infrastructure to require as few requests as possible => SPA route.
> And mobile radios don't immediately go to their lowest power state after transferring the data
Now imagine me reading a typical reddit thread on the front page. Takes me about 30 seconds before I am disgusted by some troll comment, and I go back to /r/cats. In the non-SPA case I'd have 2x approx. 10s of the radio blasting at full power, in the SPA case I'd have 1x 10s for the initial load of the app and maybe 2s for the second load of the 30 posts of /r/cats. Oh, and not to mention I, like many other people, like to reddit while on the train - which means in any case that 20 kbytes/data for a simple JSON is better than 2 MByte for each simple request. That small JSON can be transferred via EDGE if the signal is as bad as it usually is but good luck for your nerves if you have to wait ages for every website.
> Not to mention the CPU overhead of the SPA's Js which is non-zero even if radio battery usage is a larger issue.
Yeah but unlike broken browser caching this one is something YOU can influence, not having to hope your users some day have enough cash to buy a phone with proper up-to-date software.
Edit: missed yet another thing. An SPA can request thumbnails matching for the device display resolution dynamically whereas a non-SPA solution (usually!) has only one thumbnail size.