Crystallize

Frontend performance: React SSR and the Uncanny Valley

Let's say that you just implemented React SSR. After measuring your frontend performance, you're pleased to see that you got a very good pageindex score, but then you notice something else.

Shortly after the page is presented, it doesen't seem to work? You have a hard time scrolling and buttons don’t seem to do anything? But if you wait just a bit, a handful seconds or more, suddenly everything works.

Congratulations, you've entered the Uncanny Valley.

The Uncanny Valley

What you are experiencing is a side effect of server side rendering (SSR), and is a typical scenario when you do React SSR. If SSR gives us this problem, why do we even do it then? Two big reasons: ecommerce SEO and frontend performance.

It can be measured, roughly, as the time from the page looking ready (Pagespeed Index), and the page becoming interactive (Time To Interactive).

If you want the Uncanny Valley visualized, it looks like this:

The LIE

The term “Uncanny valley” is a bit too elegant in my ears, and I’m working with a different term myself:

LooksInteractive,Eh?

Or just LIE for short.

In essence, a lie is what it really is. The users are presented with a page that for the most part is ready, except for the interactive elements. If they try to use those elements, nothing happens and the users are left with a sense that your web page is not working. And it does not help that we don’t give them any indication of when it IS ready either.

How big of a lie?

Since we have established that we are in fact lying to our users, let’s see for how long time it is. I mean, if it is not for a very long time it’s really not a big problem. Let’s take the website of newnormalgroup.com, which is using Crystallize to fuel their content.

On a medium range cell phone with a regular 3G connection, the lie is: 6.6 seconds. This means that for 6.6 seconds, the user is seeing a layout that is not ready. For instance, you cannot click the menu button in that time.

Why is this happening? There are a few factors that come into play, but the biggest player on the pitch is: Javascript. If we remove all scripts and don’t bother to rehydrate React ‘n friends, the total lie is just 2.5 seconds. Much better, now we’re down to an acceptable level, and we can look to other ways of optimizing the frontend performance even further.

Conclusion

I would like to encourage you all to always measure frontend performance and get insights on how your webpages perform. When you are presented with the numbers, define your KPI’s and start working on getting better performance and experience for your end users!

This topic also covered this topic in this recorded 5 minutes lightning talk on React Amsterdam back in april.

Looks interesting?

Create a free tier account or contact us if you have any questions.

Team up with Crystallize