3 ms·

For starters, that's not really on-topic here as this is a post about the server side's caching, having nothing to do really with any client issues. But regard

For starters, that's not really on-topic here as this is a post about the server side's caching, having nothing to do really with any client issues. But regardless, what does the second page load take? What does the 3rd take? For many people, they go on reddit and stay on there for a significant amount of time. So that first page load is much less impactful, especially if it can enable them to have faster "pageloads" while on the site. If the site is optimized for them, then having the image/text post load in a fraction of a second, and the comments in under a second (which it does for me) seems like a good bet. That being said, they really could spend some time reducing that impact. And just to throw my experience in with the others, I'm getting much faster load times. Timed using the chrome dev tools connected to my phone, it takes 2.76 seconds to the "load" event and about 3 seconds until it's fully usable. (cache disabled, 4g tmobile network, high-end android phone, obviously these will be much worse on slower phones, slower networks, etc...)

BoorishBears 10y ago
It's bad enough it takes several seconds of loading on my iPhone when the desktop version is near instant, it's utterly broken too. Most menus don't open for me on the first try (especially in landscape) or open in the wrong place with touch targets that are "off" so I have to rotate the phone a few times. The old iOS 6 style site didn't age well visually, but it sure was fast. I miss the days when mobile sites were the fast and light version meant to work over 2G. To me it's insane a non-SPA desktop site would become a SPA mobile site
- mschuster91 10y ago
  > To me it's insane a non-SPA desktop site would become a SPA mobile site Not to me. Yes, you might pay additional time on the first load, but you save massive amounts of data (and thus, due to TCP, highly latency bound packets) when you just transfer small bytes of JSON. Oh, and that saves battery too - mobile data transfer is the hugest drain on any phone's battery.
  - BoorishBears 10y ago
    How do you "save massive amounts of data"? The average Reddit page I visit's content is dominated by either an image, a video or the comments. All 3 of which have to get transferred with a SPA or normal site. And mobile radios don't immediately go to their lowest power state after transferring the data so I'd be shocked to see a SPA dynamically loading smaller pieces as you move about the comment section save battery over a static one that loads large amounts in one shot, sporadic small buts of data is much less efficient than large chunks on mobile in general. Not to mention the CPU overhead of the SPA's Js which is non-zero even if radio battery usage is a larger issue.
    - mschuster91 10y ago
      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.

BoorishBears 10y ago

It's bad enough it takes several seconds of loading on my iPhone when the desktop version is near instant, it's utterly broken too. Most menus don't open for me on the first try (especially in landscape) or open in the wrong place with touch targets that are "off" so I have to rotate the phone a few times. The old iOS 6 style site didn't age well visually, but it sure was fast. I miss the days when mobile sites were the fast and light version meant to work over 2G. To me it's insane a non-SPA desktop site would become a SPA mobile site

mschuster91 10y ago
> To me it's insane a non-SPA desktop site would become a SPA mobile site Not to me. Yes, you might pay additional time on the first load, but you save massive amounts of data (and thus, due to TCP, highly latency bound packets) when you just transfer small bytes of JSON. Oh, and that saves battery too - mobile data transfer is the hugest drain on any phone's battery.
- BoorishBears 10y ago
  How do you "save massive amounts of data"? The average Reddit page I visit's content is dominated by either an image, a video or the comments. All 3 of which have to get transferred with a SPA or normal site. And mobile radios don't immediately go to their lowest power state after transferring the data so I'd be shocked to see a SPA dynamically loading smaller pieces as you move about the comment section save battery over a static one that loads large amounts in one shot, sporadic small buts of data is much less efficient than large chunks on mobile in general. Not to mention the CPU overhead of the SPA's Js which is non-zero even if radio battery usage is a larger issue.
  - mschuster91 10y ago
    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.