Where Do HTML Pages Come From?

By Guy Y.

Aug 15, 2018

Web apps come in all shapes and sizes, but they all have one thing in common –
They render content on a web browser with HTML (Hyper Text Markup Language).

Where this HTML code is generated is defined by the chosen architecture:

Server-Side Rendering (SSR):

  • This means that HTML is generated at the server, and passed down to the client.

Client-Side Rendering (CSR):

  • This means that only a basic HTML response is passed down.
  • Using Javascript (JS), additional HTML code is generated and added to the Document Object Model (DOM).

Some say the first is heavenly, and the latter is the devil’s creation, while others feel completely the opposite. But like everything in life, each has its pros and

Page Load time

With SSR, the browser just needs to parse the HTML and apply its style. This is
what browsers are optimized for.

CSR requires additional work from the browser after the initial HTML is parsed
and rendered. It loads JS and executes it, which in turn manipulates the DOM (maybe
even block rendering till more data is fetched from the server). A
lot can be done… and this can be quite a bottleneck.

Also, since we developers ask the user device to perform fewer tasks, we also are more
compatible with low-end devices.

Search Engine Optimization (SEO)

Web crawlers can easily read HTML content. This is how search engines and social
media networks scan and categorize pages. If we want our page to be
found or shared easily, it should be set to SEO.

SSR makes the job of crawlers easy, as everything is visible right away.
CSR requires the crawlers to execute JS in order to let the page fully
load. Sadly, not all crawlers support such functionality.

User interactions

When the user interacts with the app, the user interface (UI) changes. For example, a user may click a button that expands a list of content.

Such a change with CSR is easy to do. When the user clicks the button we request
data from the server, and manipulate only the list by executing the JS

SSR doesn’t handle small UI changes. It makes a request to the server, which in turn
responds with a whole HTML page, where the only small difference is the expanded list.
In short, we ask the browser to redo a lot of work for a minor change.

So… how to choose?

When we start a new project, we select our tools and stack. It is very tempting
for developers to debate over and then choose between SSR and CSR, but while doing so it is
important to take all the factors into consideration.

While load time and SEO are mostly considered an engineering realm, we do need to
listen to our User experience (UX) designers and understand what they have in mind.

We should define our product requirements, and then choose which stack is
better for our case. A strong team can overcome any challenge presented to it,
however, choosing the wrong tools usually means we will be solving issues that
we could have avoided.

As rule of thumb, I feel that the more complex the UX is the stronger our preference should be for the CSR.

At one end of the scale there are static pages:

  • Everything on the page is predefined.
  • All styles can be implemented with CSS.

Clearly, SSR is the better option to stack.

On the other end, the complex UX apps (i.e. interactive games) are easier to
build with CSR.

  • Despite lots of JS logic, the app is still not usable until JS executes.
  • This may require multiple interactions between the client and server.

In the real world, not everything is black and white. Chances are that an app doesn’t strictly match any of the above cases.

In Michael Bleigh’s post, he provides a strong indicator about which way to should go when it’s hard to decide.

Bridging The Gap

Once the decision is made, it doesn’t mean we should accept our doom. We can
have both – a great and complex UX that is also fast to load, no matter what stack we
choose. This result is just easier to achieve when we have a good starting point.

Some single-page application (SPA) frameworks provide ways to generate the initial HTML at the server side, letting the client side app take over once the page loads (hence
improving the page load time and allowing for SEO). Those are known as
“Universal Apps.”

For example:

Static pages also can achieve better UX by executing JS to the pre-rendered

Living with the decision

Choosing the stack is just a starting point on a long road.

As was said in a famous “Indiana Jones” film: choose wisely. The right choice may lead to a happier and more productive team.

Now go and build something great 🙂

Leave a Reply