Today I’d like to talk to you about rendering and that means for your website.
CHOOSE A RENDERING STRATEGY FOR YOUR WEBSITE
Whenever you open a website in a browser, the browser will render the page. And when you interact, like, scroll or click on the page, or you resize the browser or turn your phone, it will often have a render it again. But what is this rendering? Well rendering means a lot of different things in different contexts. 3D graphics, for example, are rendered, but that completely different from what we talk about today. Even the browser rendering the website is only somewhat related to what this video is about.
We want to focus today on rendering websites from the website’s owner’s perspective. Put simply, rendering in this context is the process of pulling data into a template. There are different strategies as to where and when this happens, so let’s take a look together.
Back in the old days, people usually edit HTML files directly and upload them to a web space or server where they would we served to users. When you look at websites, however, you often notice similar pages with different content, but the exact same structure, like product detail pages or articles.
So we can improve the process by separating the page structure in template file and store and edit the content the separately. We then use a program to put the content in the relegate templates. As an example of this, you could static site generators, such as Jekyll, Hugo, and Gatsby, all the others. When you create new content or modify existing content, you run a program to create new html files based on that content and templates. Then you upload these file into your sever.
This has a bunch of advantages. For one, it’s really simple way of making a website, and you don’t need to do much to set up a server to it. It’s also very robust and very secure, as there isn’t much interaction happening with the server and you can look it down quite tightly. The downside is to have to run the program somewhere, like on your computer or on your phone, and you need to do that every time something on your website changes. It also can’t respond to interactions from your visitors. So that limits what you can do on your website.
Despite being pretty simple, this is a rendering strategy. This one is called pre-rendering. You render it before serve the website. The next strategy is different is that regard. It render whenever someone visit a pages, as it does the rendering on your server that is called server side-rendering.
With server side-rendering, or SSR for short, the program that puts the content into your templates move from your computer to the server that handle requests from visitors. That server run the program, and the program Decides on things like URL, Visitor, Cookies, and others things, what content to put into which template and return it to the user’s browser.
That has advantages as well. It can respond to things like user’s login status. It can respond to user actions like logging in, or creating an account, or signing up from a newsletter. It can also potentially create new content based on user interaction, like comments on an article or reviews and ratings on a product.
It does come with downsides too, though. The setup is a bit more complex and requires more work to keep it secure, as users’ input can now reach your server and can potentially cause problems. Another thing is that it’s a bit most wasteful with resources, as it re-executes the program and renders the page every time a new visitor comes to your pages. By server side-rendering supports interactions, these interactions are a bit or limited. Posting a comment will flash an empty page for a tiny moment, as it effectively reloads the page in the browser, which doesn’t feel very happy.
Depending on how often content changes, you can use a cache to prevent the extra renderings for each visitor, and you can use proxies and firewalls to protect the server from intruders. There also is way to build websites that are more like apps. They are meant to be highly interactive and might offer Features like navigating geographical data or perform Complex tasks, such as 3D modeling or video editing. This usually is done through a rendering strategy known as client-Side rendering, or CRS for short.
In CRS, the server sends the template and the uses of a program usually JavaScript, that run in the visitor browser, to ask your server for the data to display it later on. It can do this multiple time in the background and in response to user interactions, like clicks and scrolls, or whatever you want. The interactions feel like they’re in an app. They happen smoothly happen in background without the page reloading visibly. But as with everything in life, there’s no face lunch either. It come pros and cons too.
The advantages are the app like customizable behavior and the separation of where the data come from and where the templates are stored. It can also be made available offline thanks to progressive web app technologies. The downside is that the code runs in an environment you do not control, the user’s device and browser. If the code isn’t working correctly, the user might only some content or none of the content of all. It’s also very wasteful as the program runs every visitor sees your content, but you can’t easily cache it in a central space, like your server would do in the SSR scenario.
The main issue with CSR usually is the risk that in case something goes wrong during transmission, the user won’t see any of your content. That can have also SEO implication. If Google search and other search engines can’t see the content, will they can’t index it.
To fix that, you might add something called hydration to your setup, if CSR is involved. With that you combine the aspect of SSR as the primary initial content is loaded into the template on your server, and only follow up interactions involve CSR later. While this sounds like the best of both worlds, this also means more code and more complex setup, and that might result in a less robust experience and more maintenance. So which one should you pick? Well, in the end that depends on a bunch of factors
Such as what does your website do? How often does the content changes? What kind of interactions do you want to support? And what kind of resources do you have to build, run, and maintain your setup?
To help you pick which one is right for you, take a look at this overview of the pros and cons of each approach, and work out what fits your goals best.
That’s it for today.
Leave you a comment below if you would like to learn more about technical topics, and leave like.
