6 ms·
I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first pag
by kraftman 9y ago
I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
- deleted 9y ago[deleted]
- nathan_long 9y agoSure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
- kraftman 9y agoBut they're going to have to wait for the initial page load either way, whether it's rendered server side and sent over or they're shown some static content until its rendered client side?
- pmontra 9y agoThey do, but the load will be spread among clients. The issue here is the load on the server.
- kraftman 9y agoI guess it depends on which direction you're coming from. From a traditional server side point of view, you're reducing the server work to just that first page load and making the client do the rest.
- nathan_long 9y agoTrue. But making all server-side renders really efficient and fast is an option, too. http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-lists-in-phoenix/ http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io...
- deleted 9y ago[deleted]
- scyber 9y agoIf the Server rendered page is not user specific and is generic for all users then it can be cached and served quickly. Then only potentially one user would experience a slowdown and you can serve much faster. Of course then you get into the fun of cache management and invalidation.
- nathan_long 9y agoElixir Phoenix has a game-changing approach here because of how it compiles templates. Effectively, the static part is always cached (until the template changes), but the dynamic part is never cached. Nothing to manage. See http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-lists-in-phoenix/ http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io... for explanation.
- _greim_ 9y agoCorrect, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.
- Swizec 9y agoIf all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?
- wickedlogic 9y agoSo very much this. Particularly if you dont have enough context to be personalized, pre-compiled popular segments are a reasonable approach.
- abritinthebay 9y ago> If all first time users see the same thing That's a big, important, if.
- _greim_ 9y agoIt's good odds, though. Obviously depending on the app, these would be non-logged-in users who don't get personalized content.
- abritinthebay 9y agoThere can be (though you’d be surprised- there’s rarely such a thing as a non-identifiable user nowadays). Just pointing out it’s a very big conditional. For example: I work at Bleacher Report and our non-logged-in users get data customized for them. That can be as simple as GeoIP data or can be us knowing (and inferring) what articles or content they’ve seen. The permutations are quite large. Now some blog, or a very simple app won’t do something like that (hell, they might not have the depth of content to be able to) but it’s reasonbly common to have that requirement on large sites outside of v.limited pages (like login/signup etc)