Optimizing Initial Webpage Load and SEO with Server-Side Rendering

Very few developers concentrate their web building efforts on the client experience or the overall organizational marketing strategies. In order to bring up your website on a search result, you need to make some changes to the website through some best practices during the development for optimal page load time.

When it comes to client-side rendering solutions like Google, websites are ranked in the search results based on metrics in algorithms where the website crawlers identify the best content to showcase for a particular search. The SEO aspect of webpages will boost the overall website’s ranking in the search engine. According to them, one such metric is page load time. Lesser page load time or site load time indicate that the users are more prone to spend time on the website rather than on a slower loading site.

Generally, when the user opens the website, the browser makes a request to the server which responds by sending a single HTML file without any content or loading screen until the browser fetches all the elements. This basically means that the user is presented with a blank page until the content is fetched and compiled before it is rendered for display.

The client-side framework or CSR works in such a way that the slow initial load helps in the subsequent pages loading fast. But, the communication with the server happens only for getting run time data. It can be quite detrimental to garnering website traffic. The process is slow for most user network connections, forcing them to discontinue engaging with your webpage and moving on to another.

It ultimately puts your webpage lower in the search page results. The application hardly stands a chance of being recommended on social media owing to the poor website performance.

Problems and lost features with CSR

1. Search engines don’t honor rendering JavaScript

An Angular single-page application will almost have the empty html page as source code like below. The only special element is app-root element which is the root element of the angular application. And the actual content comes via the java script into this root element.

Search engines like Google and its Googlebot does not honor rendering JavaScript, and content displayed in JavaScript goes unnoticed by the web crawler, due to which the website will not be visible in the search results.

2. First meaningful page

Starting from the first page to the meaningful visible page, any single page application with CSR might take some time (at least 2s or 3s) to load the first meaningful page. But most of the users leave the page if the page does not load in 2 or 3 secs.

3. Site preview

Site and page previews entice the users to open your blog or post. Whether we post our blogs on social media or share them through a web communication platform, they fetch the content to generate the preview so that the user can see it in the news feed. But when there is no content in our page no feed can be generated. This is because in such applications, the source code’s root element is empty without content.

Substituting CSR with SSR and making websites effective for SEO

Clearly, CSR is not ideal in many situations and we may need to find another solution to circumvent those problems. They can be overcome, however, with Server-Side Rendering (SSR).

As the first step towards tackling the above problems, we should start by not leaving the root element empty. This is so that we can render the root element content dynamically on the server. Thus, search engines and site preview can see the meaningful content. After this, angular kicks in and takes over the page. Then app will be up and running and will work as usual.

All of this can be achieved through server-side rendering (SSR). With SSR, when the user opens the application, the browser makes a request to the server and the response will be ready to provide HTML.

Server-side rendering (SSR) provides for an application the ability to contribute to webpage rendering in the browser by displaying it on the server instead of the browser. Server-side sends a fully rendered page to the client. The client’s JavaScript bundle takes over and allows the SPA framework to operate.

SSR can be achieved by Angular Universal for Angular applications, and React’s Next.js for React applications.

Enabling server-side rendering with Angular Universal

The Angular Universal technology renders Angular applications on the server. We can get it with the @angular/platform-server package.

A normal Angular application executes in the browser, rendering pages in the DOM in response to user actions. Angular Universal executes on the server, generating static application pages that later get bootstrapped on the client-side. This means that the application generally renders more quickly, giving the users a chance to view the application layout before it becomes fully interactive. (Reference: https://angular.io/guide/universal)

On a side note, it may be noted that server-side rendering does not increase the app’s performance, but makes it accessible to search engines and third-party social media services.

Server-side rendering skeleton

AppModule imports BrowserModule which is used to run the app in the browser. The AppModule is configured in the main.ts file which boots up the app. This is also called the entry point for the webpack build. It is the standard angular application configuration.

For server-side rendering, we rep the whole application in another module called AppServerModule. This module imports native ServerModule from angular.main.server.ts which will be created as the entry point for the second webpack build (i.e., server build).

In short, we will be having two builds, one for the browser and the other for the server.

Setting up Angular Universal

We start by using this command to add Angular Universal to your app: ng add @nguniversal/express-engine/clientProject ssr-playround

The above command adds/modifies the below files:

• AppServerModule.ts
• main.server.ts
• AppModule.ts
• angular.json (build options)
• package.json
• tsconfig.server.json

Building the App

For the next step, we build the client and server for the app. The build process is different for both client and server, as both these platforms are different.

Once the build is over, we can see two sub-folders for client and server under the ‘dist’ folder.

Next thing we need is a Node.js server to perform the below functions:

• Pre-render the application and deliver the generated HTML whenever the request comes in
• Provide application bundles via the web server

Steps for setting up the server code

• Set up the Express server
• Serve the files statically from the browser folder.

Now we come to the most interesting part of the setup, which is setting up the Express engine to render the HTML.

• Register ngExpressEngine, the engine that is a script which tells Express how to render the specific HTML. (Register the ‘view’ engine called ‘html’).
  
• Tell Express to use the engine whenever the request comes in and when something needs to be rendered. This will be the route. (Not every route can be handled by serving it statically).
  

Express takes the index.html file which is empty and brings angular into that page to bootstrap the application as it is in the browser. Once the index.html is ready, then it is being return to the client automatically.

The basic behavior described above is handled automatically when using the NgUniversal Express schematic. (The compilation of typescript to JavaScript and the bundling will be done by the webpack which has been configured already).

Command to compile and bundle the server process: npm run compile:server

Start the server using this command: node dist/server

Now our app is up and running with server-side rendering and can be open through localhost:4000 to see the generated HTML through view source.

The Generated HTML code using SSR:

After completing these steps, finally, our webpage details can be found on search engines. In conclusion, for any public facing and dynamic content rendering applications, we can choose server-side rendering as a solution for better content reach. However, while choosing the solution for your application, it is always a great idea to pit the pros against the cons.

Pros:

• Initial content is loaded with SSR for the purpose of SEO and social media sharing
• Increases the perceived performance
• It works great for static sites
• Simple tooling through CLI

Cons:

• Node.js or its wrappers are always required for SSR
• Frequent server requests are made
• An overall slow page rendering to begin interactions within the page
• Full page reloads

The pros and cons of using SSR as opposed to CSR can be described by metaphorically comparing it to the supermarket and the restaurant.

With client-side rendering you go to the super market once and spend time walking around and picking food items to stock for the month. After the initial spend, food is readily available on demand for each meal from home.

But with server-side rendering, getting a page element rendered is analogous to you driving over to the restaurant every time you want to eat. You will be going to and fro for each meal, but it is instantly satiating and doesn’t involve plenty of initial prep time to buy the ingredients.

Practically, SSR simply boosts your website/application’s performance in the search results. This eventually pays off in the bigger business scenario.

For intel on the best application interface practices and extensive services for your website and application building needs, head over to Innominds’ Software Products and Digital Engineering.

Reach out to us by mailing us at marketing@innominds.com.