Hi, for this first article, I'm going to present you the different rendering paradigms I met during my experience and give you some advices to choose the most adapted to your needs.
I specify that I'm not an expert and that my advices won't necessarily be applicable to your job, but if it can give you some indications then it's all good 🚀🚀🚀
Finally this is not a crash course on rendering, I will explain briefly the paradigms involved but I advise you to look at other articles if you don't know what it is
Server Side Rendering 🎨
As the name suggests, the page is generated on the server side in this paradigm.
SEO Oriented
Page generated on server side
First of all, a complete and standardized HTML5 document is generated and downloaded from the web server to the client.
Thus, search engine can easily parse it and better understand their content because no javascript is needed to access content
HTML semantic structure, textual content, keywords, meta data are a lot of informations related with each others, which are parsed and analysed by search engine and crawler to classify websites.
Multiple Page
Since the pages are generated on the server side, it's possible to establish several SEO strategies based on keywords. For example, imagine you have a cooking site. You can orient the content of your homepage according to the keywords related to your company and what differentiates you from your competitors. In the same way, it is interesting to implement a content machine that would target more generic keywords allowing to target a larger audience, an article or a recipe.
Very fast load
Few or none Javascript required 🖥️🖥️🖥️
The first cool thing is that we don't need to write a ton of javascript to make our site work properly. This makes perfect sense, since all the work is done on the server side with a different language, whether it's templating, routing, application state management and GUI components. As a result, Javascript becomes less cumbersome and sometimes totally useless which results in a very fast loading and execution of Javascript.
Server-side generation performance
Server-side generation also has many performance benefits.
First of all, you don't need to run Javascript to see the GUI, except for events and dynamic components among others.
This makes your page very accessible, even if Javascript tends to be used by the vast majority of browsers, there are still cases where it can be done without.
Given this fact, the majority of the components of the graphic interface are perfectly feasible in HTML/CSS no matter how dynamic your page is.
For example, if you want to display the list of the last articles of your blog according to a page number, you don't need to make any call to the DOM of the browser but simply use the server side template engine
Drawbacks ❌❌❌
Page is regenerate every refresh
The advantage of server side rendering is also a problem when the application is used often.
The page is regenerated and downloaded at each refresh, the same goes for images, fonts, styles, and scripts.
Of course solutions like the browser cache exist but it is not infinite and the html page is not cacheable since its content is dynamic. Also, an html page can be very heavy because of the inline styles, the inline javascript and the dynamically generated content.
If you are on a mobile network with a weak connection and little mobile data this can be a problem.
Should I use it
From my point of view and personal experience, server-side rendering should be chosen when the content of the site does not change frequently, e.g. once a week seems a reasonable limit.
Secondly, I would recommend this paradigm if your business strategy is based on exclusive content rather than an exclusive service. This probably means that SEO is important to you and therefore server-side rendering is ideal, if not essential.
Finally if SEO is essential to your business then server side rendering is a must.
Single Page App 🎨
The single page app is a new way of designing a website.
As its name indicates, a SPA is above all an application, which means that it is much more service and use oriented than content oriented.
The browser here just retrieves an html file containing the minimal code to host the javascript bundle for the application and the page content.
Then during all the use the graphical interface is entirely generated on the client side. The dynamic content is simply retrieved as JSON from a Stateless REST API and added to the GUI via the DOM
Performance in use
The use of a SPA is very fast and ergonomic.
Since many aspects of the server have been moved to the client side, we don't end up with a set of unrelated pages, but with a real client-side application that manages
- Routing
- State management
- Template Engine
This makes SPA a very fast application to use, since the GUI is generated on the client side with the template engine, there is no need to refresh the page each time.
Not generating the html page each time provides a more application-like user experience. For example when you change the current route, only the content to be changed changes and the page does not refresh, this gives a much smoother and more enjoyable browsing experience.
The use of json for dynamic content is also a very beneficial point. Not only is it much faster to download but also much less expensive in terms of network resources.
Moreover you have more control over it, allowing you to use the client side cache for example.
Separation of concern
A SPA allows for greater flexibility and better separation of concerns.
As we have seen, the client truly becomes an application in its own right.
This means that the server here no longer has a state and is totally independent of the client.
In most cases, we use a REST API for the server. This API only performs the business logic and returns information independently of the context.
In other words, all the server does is return information from its internal or external services.
The advantage here is the total independence of the client and the server, you can use any client you want as long as it is capable of making requests.
You want to design a mobile application? You can, just connect your mobile application to your API and you're done.
Want to build a desktop application? Perfectly feasible with solutions like Electron
The possibilities are endless, it all depends on your imagination.
Drawbacks ❌❌❌
More javascript code
Yes, managing part of the business logic of an application on the client side can have many advantages.
But you should not forget that it takes code to perform all these actions, and all this has a cost in terms of performance and loading.
More technical functionality means more code, which means a longer first page load.
Of course solutions like caching exist, but they become very quickly outdated if you frequently make changes to your production code.
Not adapted for SEO
Client-side generation is not at all suitable for SEO. You don't get a complete html file but only a boilerplate.
Of course you can always modify the metadata of your page and try to position yourself with that but it's a waste.
Then it is not possible to manage multiple pages, which means you can't target multiple keywords for a more generic audience.
Should I use it 🔥
As my point of view, I recommand that you choose SPA as your last option. Don't forget, unlike popular belief, most of websites are not web application. Your blog isn't a web application, a portfolio isn't a web application, a newspaper isn't a web application.
What makes the difference between an application and a website is the type of service offered.
Is your business differentiated by its content or by a unique service and functionality? If it's the latter, then the single page APP may be an option worth the cost.
The frequency of the dynamic content is also a key point.
- Does it change very frequently, every hour for example?
- If so, does this content need to be retrieved in near real time
- Is this content created most of the time by your users and therefore not suitable for SEO
Is it worth it from a mobile data consumption point of view for a customer to download a whole bundle rather than several pages?
For that users must spend time on your application. This means that your service must be attractive and exclusive. If the user only spends 5 minutes a day, then downloading a whole bundle of Javascript is totally useless. But if the user uses your application 1 hour per day, it's ok.
Static Site ?Generated 🎨
The last paradigm you may encounter is the dynamically generated static site. By dynamically generated I mean generated during build.
It is not always necessary to use a framework for this, sometimes a backend route system with a set of static html/css pages do the trick very well.
Perfect for SEO
As for the server-side rendering, the pages are fully generated on the server side and multi-pages are fully supported.
Also, but this is just me, I think that forcing the team to write the content during the site build pushes them to write more detailed, targeted and relevant content.
Attack surface
For web security a static site is unattackable, you have no internal services running behind your site the user inputs are not used.
Drawback ❌❌❌
Content generated at build time
This is the main problem with this kind of sites. You have no real time control over your site which makes most of the functionality impossible.
Moreover, if a customer wants to make a modification on a site, he must master at least a templating language and have followed a small training on the use of the Framework
If you need to make modifications regularly, this can cause many problems. The interface is not as ergonomic as a CMS and you need to have access to the source code.
Should I use it 🔥
A static site generated during the build is a perfect option if you simply want to create a site whose content changes very rarely but that you want to make known.
Conclusion ✨
This article is here only to give indications about what I consider relevant from a personal point of view.
I always invite you to adapt your solution as much as possible to your initial problem and never to foolishly follow fashionable recommendations.
In real life, things are not set in stone, there are grey areas and it is up to you to detect them.
Personally I always choose server side rendering as my first option, it allows me to be more flexible. It is quite possible to distribute a small SPA on an SSR via a different route, the reverse is not possible.
Finally, don't overthink about this paradigm. Choose the simplest and least restrictive solution for you. If your site just needs a route system and a set of static pages, just go for it.
Top comments (1)
Hi, I would like to cite your post for my dissertation paper. Could you give me a name, so I could include it to bibliography?