Website rendering strategies

MARTIN SPLITT: Hello, and welcome to Search
Central Lightning Talks.
Today I'd like to talk to you about rendering
and what that means for your website.
[MUSIC PLAYING]
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 to 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's completely different from what we talk about today.
Even the browser rendering a 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 webspace or server where
they would be 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 files and store and edit the contents separately.
We then use a program to put the content
in the relevant templates.
As an example of this, you could use static site generators,
such as Jekyll, Hugo, Gatsby, and 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 files onto your server.
This has a bunch of advantages.
For one, it's a really simple way of making a website,
and you don't need to do much to set up a server for it.
It's also very robust and very secure,
as there isn't much interaction happening with the server
and you can lock it down quite tightly.
The downside is that you 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 you serve the website.
The next strategy is different in that regard.
It renders whenever someone visits a page,
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
moves from your computer to the server that handles requests
from visitors.
That server runs the program, and the program
decides on things like URL, visitor, cookies,
and other 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 for 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 more 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 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 a 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 CSR for short.
In CSR, the server sends the template
and then uses a program, usually JavaScript,
that runs in the visitor's browser,
to ask your server for the data to display it later on.
It can do this multiple times 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 in the background
without the page reloading visibly.
But as with everything in life, there's no free lunch either.
It comes with pros and cons too.
The advantages are the app-like customizable behavior
and the separation of where the data comes from
and where the templates are stored.
It can also be made available offline thanks
to progressive web app technologies.
The downsides are 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 see some content or none
of the content at all.
It's also very wasteful as the program runs
every time a 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 also have SEO implications.
If Google Search and other search engines
can't see the content, well, 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 a 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 change?
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 us a comment below if you would
like to learn more about technical topics, and leave like
or subscribe to our channel if you
want more content around Google Search from us.
Thank you so much for watching, and bye bye.
[MUSIC PLAYING]