You are here: / / How Server Side Rendering improves initial loading times
Optimizing image delivery

How Server Side Rendering improves initial loading times

Performance is key for all sites. Not only does it improve SEO, but it increases sales and customer happiness. But companies must recognize the challenges that are involved. In this series, we’ll go through the main areas of site performance, how you can improve the performance of your site, and the trade-offs you’ll have to make when it comes to performance versus customer experience.

In the first article of this series, we’ll look at Server Side Rendering.

What’s Server Side Rendering?

Server Sider Rendering, or SSR for short, is when the HTML of a website is generated on the server before it’s delivered to the user.

If you’re using Frontastic, you’ll have a Progressive Web Application (PWA) or a Single Page Application (SPA). The code is written in JavaScript, and the browser creates the HTML based on data that describes what’s shown on the current page. The main benefit of this approach is faster page transitions between pages because the browser only loads the data and not the rendered HTML for the next page. It only updates the parts of the HTML that needs updating. So it results in the site feeling like an app as the user never gets a blank page when clicking on something as only the necessary parts of the page are updated.

What are the challenges of this approach?

The challenge with this approach is that some clients and even browsers don’t support JavaScript. This is especially true for some search engine bots. The Google bot supports JavaScript, but many others don’t.

To overcome this challenge, we always deliver HTML on the initial request of any client or browser. This is so that the client can understand the contents of the website even without executing all the JavaScript. That means all of the search engines can index the content of the website. It’s the generating of this HTML that’s known as Server Side Rendering.

While it does sound pretty easy, there are some challenges involved. The JavaScript execution environment inside a browser is always different from the JavaScript execution environment on the server. For example, the size of a user’s browser isn’t transmitted during the initial request. So we can’t know it during SSR, but many frontend components rely on knowing the browser size.

At Frontastic, we already use common tools like domino, as well as some additional magic to guess the browser window size to enable the best possible rendering. For example, you can configure certain Frontastic components to only show on certain device types — and this is always based on the dimensions of the browser window. We guess the device type during the initial rendering and then provide this information to the rendering code. This is so we can decide which Frontastic components to render (as well as estimating the best possible image dimensions). By leaving out the unused Frontastic components like this and delivering images as small as possible, it reduces the size of the transferred data that improves the rendering performance even further.

More to know about Server Side Rendering

While developers using our platform can write their own frontend components, Frontastic makes sure they’re rendered properly on the server. This is to make sure all data on your site can be indexed by search engines, as well as providing the optimal initial rendering time for every user.

There are still some ways to break this behavior for some components, though. For example, almost all slider implementations need JavaScript for positioning and sizing calculations. These will never reliably work on the server. And while we try not to use JavaScript for tasks like this, sometimes things can still break. We’ll always announce these errors as soon as possible during development and on the staging system.

This is so you don’t accidentally deploy something to production that then can’t be indexed by search engines. A great thing about our setup is that even if you break the Server Side Rendering, your users most likely won’t notice. This is because everything will still be visible in common browsers — and we send a correct status code, so search bots won’t accidentally index your missing component.

How can I benefit from Server Side Rendering?

As a Frontastic customer, you’ll have all the tools you need to deliver the best Server Side Rendering experience to your users (and the search bots). But for this to work best, your developers need to make sure all their styling and layout calculations use CSS and not JavaScript.

You want to know more?

Request guided demo
Portrait Catherine Jones

Catherine Jones

Catherine’s the Lead Editor at Frontastic. She’s worked in many different positions at different levels but always with a customer focus and is always looking to create the best experience for users.

Stay in the loop

Subscribe to our newsletter to keep up-to-date on all the latest Frontastic news.

Related

operational efficiency as metric for headless commerce

Operational efficiency: The future metric for headless eCommerce platforms

,
This blog post explores how operational efficiency will be the future metric for headless eCommerce platforms. If you've moved to headless or are planning towards headless transition then this article will serve as the best guide for you.
Read more

Frontastic architecture: Frontastic studio

,
In our architecture blog series, we'll look at each part of the Frontastic architecture, how it works, and what you can do with it. In this post, we'll focus on the Frontastic studio.
Read more

Progressive web apps vs native apps: Pros and cons

,
Just because websites are online storefronts doesn't mean you should ignore improving your user's experience. If anything, that fact alone should encourage you to offer up-to-date website experiences. This blog post explains why brands need to experiment when developing digital experiences.
Read more
MACH Alliance Logo