4 ms·

> "What about load times and performance?!?!" If you're rendering everything on the client like that, how many HTTP requests are you making, other than the ini

> "What about load times and performance?!?!" If you're rendering everything on the client like that, how many HTTP requests are you making, other than the initial 3 (stylesheet + javascript + html document)? I'm especially focusing on mobile performance, here. On 3G you have 200-2500ms latency on the control plane, 200ms latency for dns lookup, 200ms latency on establishishing a tcp connection, your TLS handshake will have a latency anywhere from 200-400ms and the actual http request will have a latency of 200ms. That's 1000-2900ms per http request, minus 100 if your client can cache DNS responses (and everything is on the same domain). Sometimes these will be multiplexed. You can't count on it though. 4G is only marginally better: you have an overhead of 240-500ms on 4G. And none of that takes into account the time it takes your server to process a request, or the time it takes for the client to parse and execute your rendering codebase. If you're aiming for sub-1000ms request-to-glass, you can't follow the advice of this book (don't render anything on the server ever) - unless you don't mind the client showing a loading animation for the 2-15 seconds it'll take to load your "app." (good luck with that mobile bounce rate) 0. https://www.youtube.com/watch?v=Il4swGfTOSM https://www.youtube.com/watch?v=Il4swGfTOSM

HenrikJoreteg 12y ago
Yup, I don't disagree, this fact sucks. If you keep reading you'll notice I suggest not doing this for apps that aren't behind a login. You can use login pages to prime caches, pre-render, etc. That's certainly not a panacea, but can help. With the right cache headers on the main application assets and a primed cache you can start executing code immediately and eliminate all but your data calls on a good portion of app loads. From my experience, with a primed cache it's not too difficult to get comparable load times to opening a native app. I'm hoping ServiceWorkers, Improved local databases, and HTTP 2.0 can help us out here. There's also the option of trying to do the initial render server-side. I've experimented a bit with this, and have some more thoughts and approaches I want to try for this. But, I have yet to see someone do this is a way that didn't add a significant amount of complexity to the codebase :-/
- warfangle 12y ago
  Yup. For those of us working on highly dynamic non-app sites things are a bit more difficult. I only had time to skim the introductions earlier - I'll have to give it a full read.

HenrikJoreteg 12y ago

Yup, I don't disagree, this fact sucks. If you keep reading you'll notice I suggest not doing this for apps that aren't behind a login. You can use login pages to prime caches, pre-render, etc. That's certainly not a panacea, but can help. With the right cache headers on the main application assets and a primed cache you can start executing code immediately and eliminate all but your data calls on a good portion of app loads. From my experience, with a primed cache it's not too difficult to get comparable load times to opening a native app. I'm hoping ServiceWorkers, Improved local databases, and HTTP 2.0 can help us out here. There's also the option of trying to do the initial render server-side. I've experimented a bit with this, and have some more thoughts and approaches I want to try for this. But, I have yet to see someone do this is a way that didn't add a significant amount of complexity to the codebase :-/

warfangle 12y ago
Yup. For those of us working on highly dynamic non-app sites things are a bit more difficult. I only had time to skim the introductions earlier - I'll have to give it a full read.