Photo by Minku Kang on Unsplash
Client-Side Rendering (CSR)
With the rise of SPAs in the 2010s, CSR or Client-Side Rendering, became a popular rendering model for shops wanting to build modern web applications. Instead of the browser making a request to the server for each page of the website, a single HTML page (which is really just a shell) is sent to the browser when the site loads.
Also sent to the browser at this time, is all of the JavaScript needed for the entire application, which then renders all of the subsequent HTML, on the client (we’re setting aside lazy-loaded modules and code-splitting here, for simplicity sake).
Since everything is loaded up front, there are no additional trips to the server needed except to load data from APIs. So user interaction/navigation is instantaneous, making a website behave almost like a desktop application.
But this is not ideal for website crawlers because they have to wait on that initial load and execute JavaScript to see page content. Therefore, CSR apps might receive a lower ranking from search engines. For websites that need the best possible SEO and are not behind a login wall (in which case there are no pages that can be indexed anyway), this might not be acceptable.
I find that SEO is usually discussed in the abstract and it’s hard to find solid data — I think because there are so many variables. As a developer, you can test your local site for SEO using Litehouse in dev tools and with the Web Vitals chrome extension. Again, there are many variables to consider, so you can’t assume that just because you get a 100 SEO score in Litehouse that you’re good to go. I also don’t think that you can assume your CSR application cannot achieve good SEO, especially as crawlers evolve.
Additionally, while loading everything up front as CSR does is great for interaction/navigation once the first (and only) page is loaded, it may increase the load time of that first page. One important measure of this is First Contentful Paint (FCP), which is the time it takes for the first text or image to be rendered in the browser. A time of 1.8 seconds or less is considered fast (by Google). You probably don’t have to worry too much about this if your users have good internet connections. But this could become an issue for users with poor internet connections, such as you might experience on mobile devices.
Server-Side Rendering (SSR)
To improve SEO and initial page load time, SSR or Server-Side Rendering, was introduced. SSR requires a server which runs the necessary JavaScript and makes the necessary API calls to construct and deliver a full HTML page on the first request, which may improve the initial load time and SEO since it allows the crawler to see page content without executing JavaScript.
One trade-off is that this increases the server load for very high traffic websites. Additionally, while the data for the page is being retrieved, the user will not see anything, which is one of reasons why CSR became popular. If it takes a fairly long time to retrieve the data for a page, then CSR will deliver the content of a page to the user faster that SSR, even if it’s not the complete page.
With SSR, we’re back to where we were in the pre-SPA days for the initial page load. For websites that need the best SEO and aren’t behind a login-wall, the trade-off is considered worth it.
Static Site Generation (SSG)
Wanting to improve the initial page load time even more, SSG or Static Site Generation, was introduced. With SSG the entire website, including all of the data needed, is constructed at build time and deployed out to a CDN. This drastically increases the build time, but the result is that everything is prebuilt and ready to go, resulting in the fastest possible initial page load.
Additionally, websites that have a global reach can deploy to CDN’s around the world, dropping the load time a little more for users in different parts of the world. This is good for static sites whose content does not change very often (like documentation or blog sites) because you have to rebuild the entire site when the content changes. Crucially, the page data cannot be in any way dependent upon the request (or the user making the request), since the page is populated with data long before the user or the request comes along.
Incremental Static Regeneration (ISR)
About a year ago, Next.js introduced something called ISR or Incremental Static Regeneration. With ISR, a page can be static like with SSG, but you can specify a revalidation interval so that a user will always receive a static page, but if the revalidation interval has passed, the page will be regenerated in the background and the next user will receive with the updated (static) page.
So it is still the case that the first user will receive a stale page — but only that first user. This eliminates the need to rebuild the entire site when the content changes. It is still the case that the page data cannot be dependent upon the request or the user.
Next.js was created specifically to address these rendering optimization techniques which most impact websites that have very large traffic, a global reach, and need good SEO, such as Netflix, Hulu, Target, etc. As such, Next.js has focused more on SSR/SSG/ISR than have frameworks like Angular, but I think that is starting to change.
SSR, SSG and ISR in Angular
Angular Universal is the official SSR library for Angular and has been around since 2017. It has been announced recently that it will be moved into the core framework in the future. The team has been working on improving SSR, and non-destructive hydration (which doesn’t destroy and rebuild the DOM) was released in developer preview in v16.
SSG has been possible for Angular since around 2019, with the standalone tool Scully. Since early 2021, SSG and hybrid SSR/SSG has been possible with Angular Universal alone using prerender. Recently, a new meta-framework has been developed that I think seeks to be to Angular what Next.js is to React — Analog. It will be very interesting to see how it develops alongside the core framework.
For ISR, a library has surfaced called ngx-isr. It makes it very easy to implement ISR on top of Angular Universal. However, to be accurate, I think it differs slightly from ISR in Next.js in that the first serve will always be SSR, as opposed to Next.js where the first serve is always SSG. It is possible to implement the Next.js flavor of ISR by combining Angular Universal’s prerender capability with serverless or edge functions, there just is no built-in way or tool to do this for you — yet.
Serverless functions are code that executes without the developer worrying about where it runs. It still runs on a server, of course, it’s just that it’s a cloud server that the developer doesn’t have to mess with.
Edge functions are basically the same thing, except that they execute at the edge of the network, closer to the user, thereby reducing latency a bit.
Conclusion
While CSR works just as well or is preferred for many websites (and I would say most websites where Angular tends to find itself), there are situations where SSR/SSG/ISR are needed. Although frameworks like Next.js have led the way with these techniques, you can still achieve SSR, SSG or hybrid SSR/SSG easily with Angular. It may not be quite as easy to achieve ISR (the Next.js version) in Angular as it is in some other frameworks yet, but I would expect that to change soon.
It’s exciting to see that the Angular community is focusing more on SSR/SSG/ISR and I look forward to seeing the changes that are coming soon — from the core team’s focus on SSR/SSG, to the new meta-framework, Analog.
Bibliography
- https://blog.angular.io/whats-next-for-server-side-rendering-in-angular-2a6f27662b67
- https://www.youtube.com/watch?v=TXhZ1Hs5MoE (rangle.io webinar on Analog)
- https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- https://web.dev/learn-core-web-vitals/?utm_source=lighthouse&utm_medium=devtools
- https://web.dev/vitals-measurement-getting-started/
- https://github.com/mgechev/hybrid-rendering
- https://angular.io/guide/universal
- https://developer.chrome.com/docs/lighthouse/performance/first-contentful-paint/
Top comments (0)