To make a website SEO friendly we have to implement Server side rendering
of the application in Angular
.
I have read many of the articles on Server Side Rendering. While reading, I come to know about two types of rendering.
1. Static Server Side Rendering
2. Dynamic Server Side Rendering
But What does it mean? I am not getting this from the articles I have read. Still confused which one to choose for my application.
So I just want to know for which type of application/website we have to use Static and for which type of application/website we have to use Dynamic Server Side rendering?
2
Answers
As you say, there are two ways to render Angular apps on the server. Here is the difference, along with examples to illustrate their use.
Static Server Side Rendering
Essentially this refers to the process of generating pre-rendered pages for your app that you can then host statically using a service such as Amazon S3. The fact that these files are static also means they’d be easy to serve out of a CDN. You simply build the files on your local machine or CI environment, then push to wherever your host is. Here’s a short guide on Pre-rendering Angular Applications.
Ultimately each route you’ve defined in your Angular app results in an HTML file including any dynamically generated content that is displayed on load. This obviously plays well with search engines & crawlers. When a browser loads up one of your pages it gets an immediate pre-rendered response, then Angular kicks in with all the dynamic behaviour defined in your controllers, services etc.
Example:
You’ve built a marketing website showcasing some product. It has a fixed number of routes (home, about, contact). Upon building the app, you get 3 static HTML files, some Javascript, and whatever other assets are involved.
Dynamic Server Side Rendering
You may have guessed, this is particularly useful for when you have dynamic routes (e.g.
/products/:productId
). Using Angular Universal we can run an Express.js server in Node, which will dynamically render each page when requested by a client. This takes a little more time but is well worth it!Example:
You’ve built a shop and every time you add a new product you want it to be available for Google and the likes to index. You also want it to display well in Open Graph preview renderers such as Facebook.
Dynamic SSR (server-side rendering) & Static Pre-rendering
Dynamic SSR is the concept that there will be a live Node server spun up that whenever a Route is hit, it will dynamically generate and serialize the application — returning that String to the browser.
Static Pre-rendering is when we want to pre-render a list of routes, and create static files, (ie: index.html, about-us.html, etc) and then use a server of our choosing (nginx, S3 hosting, etc) to serve up those files later on.
So how do we know which one to choose and when?
Pre-rendering will typically give you better performance since we’re not waiting for a server to hit all the necessary APIs within your application, and nothing has to be “serialized”, it already has all the serialized HTML of your application outputted for each one of the Routes files.
Here’s a good list of questions that we consider with clients before considering which route we need to take.
When to use Static Pre-Rendering:
Your application itself is rather Static.
(or at least the Routes you’re trying to pre-render)
For example: homepage | about us | contact us
Very dynamic portions of your site (and ones that are behind a Login/Auth barrier) can be pointed to the normal Client-side rendered (CSR) version of your application, and Angular can bootstrap itself normally.
Your application doesn’t update very often.
Whenever some changes are needed on the static routes, you can simply run the build script again and republish the /dist folder containing all of your pre-rendered files.
When to use Dynamic SSR:
Typically most applications will need static pre-rendering (since any routes behind an authentication-wall don’t gain much/any benefit from utilizing SSR, since one of the main purposes is the SEO gains, and improved perceived performance.
Remember, you can always have certain aspects of your application not render during SSR, and have those dynamic portions populated during CSR! (client side rendering)
Reference
https://medium.com/@MarkPieszak/angular-universal-server-side-rendering-deep-dive-dc442a6be7b7