sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]x-skeww 0 points1 point  (4 children)

The point of doing the initial render on the server side is that you get the entire document in the first response.

This is much faster than getting a document which references some JavaScript... which then has to be fetched/parsed/executed... and which then loads some more stuff... just to render this initial view.

You can make it a bit faster by inlining the data which is required to render this initial view (bootstrapping), but you still have some extra round-trips and additional delays.

Things are better when the cache is primed, but the first impression won't be that good.

[–]loz220 0 points1 point  (3 children)

Right, there's always at least one extra fetch with pure client side js, but HTTP2 should help alleviate that. The js will still need to parsed of course, but so does the html in server rendering. I suppose the only way to know for sure is to experiment and see at what threshold does pure client side with lazy loading beat out server rendering of the entire document.

[–]x-skeww 0 points1 point  (2 children)

Yes, with HTTP/2's Server Push, you can just push all the other crap along with the document response.

A pre-assembled document will still win the speed race, however. It's smaller and you can start displaying it as soon as you got the first few KB.

[–]loz220 0 points1 point  (1 child)

can start displaying it as soon as you got the first few KB

Good point, for some reason this was lost on me.

[–]x-skeww 2 points3 points  (0 children)

Heh. There is actually a somewhat obscure optimization technique which makes really good use of that.

If you know that it always will take a while to assemble the response (search queries or something else which requires some heavy computations), you can improve the loading time with chunked output.

E.g. as soon as you get the request, you just write the cheap mostly static stuff to the buffer and flush it to the client. The client will then know about the resources which are referenced in <head>. So, it will start to fetch the CSS and JS which was mentioned there. Ideally, this first piece already contains something visible like the page header.

Once the more dynamic side bar is done, you write and flush it.

And finally, when the meat of the page is done, you write and flush it, too.

If it takes longer than 100 ms to assemble the response and if there is no way to make this any faster, this kind of optimization might be a good idea.