What is Universal Server Side Rendering?

Rendering Technique Capturing Both SEO Optimization and Performance

Sep 25, 2018

What is Universal Server Side Rendering?

In this post I want to explain Universal SSR, widely used in recent modern web applications. I’ll briefly learn about SSR (Server Side Rendering) and SPA (Single Page Application) methods, then explain the Universal SSR method combining these two rendering methods.

Multi Page Application Performing Server Side Rendering

The SSR method is originally the method used in traditional web applications. Recently it’s also called MPA (Multi Page Application) in contrast to SPA (Single Page Application). SSR applications, after routing is performed, when new pages are requested from the server, render HTML each time and download entire pages again on clients.

The rough execution order is as follows:

Client sends a request to the server with URL example.com/products/12.
Server executes the method connected with that URL and finds appropriate HTML Template files.
Get data for product number 12 from Database.
Render final HTML using fetched data and HTML Template.
Send HTML down to client.
Finally users see the view.

Even after users see the rendered page, they could additionally receive more data using Ajax, but since the point when users see the completed page is after step 6 finishes, exceptions like Ajax were omitted.

Also, in step 2, you can see why this method’s applications are called MPA - because HTML Templates matched to each page exist separately. Pros and cons of methods like this are as follows:

Advantages

Since completed HTML is sent down from the server, it’s optimized for SEO (Search Engine Optimization).
Since only resources needed on each page are loaded, initial loading speed can be optimized.

Disadvantages

New resources must be requested every page loading, so overall traffic increases.
Refreshes occur every page move and entire pages are re-rendered, so loading time lengthens.

Single Page Application Performing Client Side Rendering

Recently many Frontend developers develop A.K.A SPAs (Single Page Applications) performing Client Side Rendering. In other words, it means applications where pages actually downloaded from servers are just 1, and afterward perform dynamic rendering through JavaScript.

The rough execution order is as follows:

Client sends a request to the server with URL example.com/products/12.
Server, whatever it is, if request URL starts with exmplate.com, finds and sends down index.html.
And additionally sends down JavaScript Bundle together. For example, it would be files like bundle.js that come out when building with modulers like Webpack.
Client executing bundle.js requests product number 12’s data from server using API api.example.com/products/12.
Server gets product number 12’s data from Database then sends data down to client.
Client renders views using received data.
Finally users see the view.

It got kind of complicated compared to earlier. The reason this method is SPA is in step 2. Usually that url is declared in settings of server engines like Nginx or Apache, and if requests come to urls matching conditions, they find and send index.html files. Whatever url it is, if it matches conditions, only one index.html is sent, so it’s called Single Page.

And since clients currently don’t have product number 12’s data, they must additionally make API calls to receive product number 12’s data.

Then let’s also look at SPA’s pros and cons.

Advantages

After downloading all static resources from the server during initial loading, only necessary data is downloaded during page moves, so loading speed is fast and overall traffic can be reduced.
Since refreshes don’t occur during page moves, user experience (UX) improves.

Disadvantages

During initial loading, all static resources not used on current page are received, so initial loading speed is slow.
Vulnerable to SEO.

SSR vs SPA

We’ve looked at rough execution flows and pros and cons of each method. Both SSR and SPA methods have pros and cons of loading speed. What’s different?

SSR’s advantage is initial loading speed. SPA downloads all static resources used in the entire application during first loading, so initial loading speed is slow, but afterward there’s no need to additionally download resources, so operating speed afterward is fast.

On the other hand, SSR only needs to load resources needed on current pages, so initial loading speed can be faster compared to SPA. However, since received static resources aren’t stored somewhere, even resources received on previous pages must be received from scratch again whenever pages move.

So loading time during page moves after application initialization can be slower in SSR.

But SPA method’s tremendous disadvantage is exactly SEO. SEO is abbreviation for Search Engine Optimization, meaning search engine optimization as directly translated.

Search engines are basically based on crawling and collecting pages. The problem is that bots doing crawling don’t have ability to execute JavaScript.

Recently cases like Google crawler are said to have JavaScript execution ability, but personally I see it as not yet trustworthy to that degree. Moreover, when sharing pages on SNS like Facebook, crawlers must read Open Graph tags for shared site information to display correctly. When crawlers read pages where JavaScript didn’t execute, there’s just blank pages, so there were problems of not properly displaying information.

I also tried methods like #! (hashbang), _esacped_fragment_, or Pre rendering to solve this problem, but even writing applications as recommended by search engine companies, compared to SSR methods, they couldn’t help not properly scraping data.

Emergence of New Concept Server Side Rendering

Choose SSR and SPA’s advantages are wasteful. Choose SPA and SSR’s advantages are wasteful. Then what should we do? So the method that came out is the method appropriately mixing both methods widely used recently. Perform SSR only during users’ first requests, and afterward perform dynamic rendering like SPAs. This method has advantages like below:

Advantages

Solve SEO and initial rendering speed problems by sending down completed HTML with SSR for first requests
Also bring SPA’s advantage of fast render speed during page moves by performing rendering on client afterward
Since all 3 major Frontend frameworks Angular, React, Vue officially support such SSR methods, Client and Server can be bound with same Context. In other words, components I made execute identically whether rendering on client or server.

But all technologies have Trade-offs… what are the disadvantages?

Disadvantages

Code is complex. If you don’t clearly understand application operation order, it’s really confusing.
Since rendering is performed on server, more CPU is used compared to simple resource serving, and load can be placed.
For Frontend developers unfamiliar with servers, if development proceeds like clients, unintended bugs can occur.

Especially cases like #2 and #3 were parts I overlooked. Parts that had no problems on clients became fatal mistakes on servers and came back as bugs.

In the next post, I want to write about and reflect on my experience introducing Vue-ssr at work and what mistakes I made.

That’s all for this post on What is Universal Server Side Rendering?