Server-First Rendering of Web Pages

54 views Asked by At

There are generally three approaches to rendering in web pages:

  • Server-side rendering
  • Client-side rendering
  • Some combination of the above two

I am interested in implementing the third approach as it, at least in theory, combines the best of both worlds: Fast first load and SEO benefits plus eliminating the need for server requests at every button click.

Leaving specific frameworks aside and focusing on concepts, I want to know which of the following would be generally best practice (with the understanding that each use case is different):

  • On first visit, together with the server-side generated HTML, asynchronously load the all the JavaScript code and all the blank templates necessary to render subsequent views on the client side. On each new view, load only JSON from the server and populate the templates.
  • On first visit, together with the server-side generated HTML, asynchronously load only the JavaScript routing code. Load the template and JSON only when the new view is requested.
  • On first visit, together with the server-side generated HTML, asynchronously load only the JavaScript routing code. Load server-side generated partial HTML chunks when the new view is requested.

I may be wrong, but it appears that most implementations use the first method (load everything) rather than the other two where templates/JSON are loaded when views are requested. If that is indeed the best practice, why is that better than the other two methods?

Thanks.

1

There are 1 answers

0
Mark Adelsberger On BEST ANSWER

There are two trade-offs in play here:

1) If you load everything, the initial load may be slower; but if you load on demand, specific operations may be slower.

2) If you load everything, you may load things the client won't end up using which could waste time; but if you load each element only when needed, you may make extra round trips to the server which can be even more costly in terms of perceived performance.

How to weigh those trade-offs does depend on a lot of factors, like expected network latency vs. bandwidth, whether parts of the app are indeed unlikely to be accessed by some users, etc.

In general if my app is already going to take 2 seconds to load, I'd rather make it take 2.1 seconds instead of having some subsequent operation also show a delay. But if we're talking about a case where the initial load time would double, maybe I have to think differently about that. Again, lots of variables.

As a rule of thumb, I like the idea of bundling templates, images, scripts, etc. down to a single bundle - or, if there are on or more sub-modules that really won't be used all the time, maybe one bundle for the core and one for each such sub-module.