⚔️ End Game - A split second later
Tags: ssr, webdev, react
Published: 2019-10-04 01:26:18

---
title: ⚔️ End Game - A split second later
published: true
description: the final article about code splitting, and faster SSR
tags: ssr, webdev, react
series: A split second later 
cover_image: https://thepracticaldev.s3.amazonaws.com/i/ri67w24g3u6sbkbcij55.jpg
---
In the Famous `End Game`, Avengers assembled to fight the threat and they won. This is the `End Article` for a `Split Second Later` series, and it's time to assemble all our heroes.

> Before we start - let's recap the previous series

☠️ __Who is the BAD GUY__ ? - the `Time` between you hit "enter", and your site or application is "ready". And it does not matter what does mean "ready" for you - for your user it's always just "ready". So simple, it's really so simple.

🔥 __Who are the GOOD GUYS__? There are many!
- a faster Server-Side or CDN response
- a faster Client-Side boot
- a smaller Network payload
- fewer roundtrips for resources and fewer blocks
- right content and actions delivered in the right time and the right order

Let's found how they would make your site, or application, be ready just __a split second later__.

> 👉 In an alternative universe (multiverse?!) `Das Surma` has written the same story - [techniques to make a web app load fast, even on a feature phone](https://web.dev/load-faster-like-proxx/). Check it out

***

# Faster Response
There are a few ways you can display a `final picture` to your customer. To be more concrete - two ways. As __HTML-first__, and as __JS-first__. But this is not just two ways - they are creating some spectrum, and let me cite the famous [Rendering on the Web](https://developers.google.com/web/updates/2019/02/rendering-on-the-web) to explain it:

![Rendering performance target](https://thepracticaldev.s3.amazonaws.com/i/7kam97nxzx3pdfk3xhk3.png)

However, SSR at this comparison table has a con - __slow TTFB__, which means - you will start getting a response from a server not as soon as in other cases.
This limitation is driven by two technologies: 
- MVC, which is a common way to SSR react applications - first get everything, then read everything, then send everything
- lambda functions of any sort. Which by design accumulates everything you want to send, and then "return" it as one big string.

While lambdas are not yet stream rendering compatible, and there is nothing you can do with it, "MVC problem" is a lie - nothing stops you from sending `<head><script src='main.bundle.js'>` first, letting user start downloading js-bundle, then _read all data_, and then `renderToStream` the result, significantly reducing TTFB. Just get rid of __declarative helmets__, which are not _single rendering pass_ compatible.

> Yes, to be honest - to achieve the best results, you have to get rid of  `react-router` and `react-helmet`. Patterns they implement are not SSR friendly.

This technique is known as __progressive rendering__ and here is my friend @flexdinesh explaining it in details:

{% youtube Q4bCo6KdWyk %}

> Btw, do you still remember the second article of this series - React Cache?

# Faster Client-Side boot
So you open the page, server sent some bytes - the rest is browser job.
"The Rest":
- download all needed scripts
- download all needed styles
- download all needed data
- display something to the client, and ideally from the `first try`

*** 

__Preloading__ the right content is key here. Preload font's before they got used by HTML (which is not loaded yet), and CSS (which is not loaded yet), as well scripts.

The majority thinks that this is achievable only thought `HTML LINK` meta tag, thus not usefull for _lamdas, not yet compatible with stream rendering_, but the truth is - you might [send `preload` as a HTTP](https://www.w3.org/TR/preload/#developer-server-and-proxy-initiated-fetching), not HTML header, you can send from a service "before" labmda.

```
Link: <https://example.com/app/script.js>; rel=preload; as=script
//
<link rel="preload" href="//example.com/widget.html" as="document">
```

***

- display something to the client, and ideally from the `first try`

![first try](https://thepracticaldev.s3.amazonaws.com/i/ve57f46eiko2gsdq4pz1.gif)

And that's the key point - displaying something "once" is a key. I am not talking about the _Death By A Thousand Loading Spinners_, so popular among modern SPA - even __Progressive JPEG__(considered as "good" for slow connections) is leading to multiple renders(while a picture is _progressivle_ loading) wasting CPU(and battery) of your phone. So doing something "once" - is a key for a more _idle_ CPU, and more power to do other stuff.

Finding the good balance between network and CPU utilization, as well as between render/redraw/layout - is a key to better user experience.

Finding the good balance between data sent from a server (the less you send - the faster you read it), and data requested by a client (why not to fetch something a bit later? Why not... not?) - is the point of equilibrium.

...and don't forget about critical CSS.

> It's always about balance

# Smaller Network payload

Is about making your scripts smaller, and about using as fever lines of code as possible. It's about code splitting and code optimization.

- properly isolate your use cases and your code from each other
- use code splitting
- measure intermediate and the final results. [size-limit](https://github.com/ai/size-limit) and [import-cost](https://github.com/wix/import-cost) are your best friends.
- try deferential bundling to ship more efficient code
- CSS usually is not a problem

> `Optimizing JS delivery` is an article you have to recap.

# Fewer roundtrips for resources and fewer blocks
HTTP nowadays is a very complex thing. It's not only about fetching the data from the remote server, but also about TSL __handshaking__ secure connection, connection latency, and effective CDNs.

The key to a faster (up to 2x) response is to use as fewer "connections" as possible, and trying to fit your content into `TCP window size` blocks, to optimize the transport layer (14kb according to Yandex research).

![Loading spectrum](https://thepracticaldev.s3.amazonaws.com/i/kdnf4rjgt0zcdvdoqn5c.png)

Fun fact - according to the statistics acquired by Yandex(link in Russian)[https://habr.com/ru/company/yandex/blog/358944/] - the actual "downloading" part is __NOT__ a problem for mobile phones - but DNS lookups, and _network ceremonies_ are.

# Right content in the right time
Is about loading something when you need it. It's also about coherence, and loading that something when you actually need it. It's also not about loading, but executing.

It has many names, like:
- critical CSS, styles for a `footer` defined before the `footer`, not the `header` - are styles delivered at the right time
- some data stored during SSR in HTML​ `data-` attributes, not in a single and global Redux store - is data defined in the right time
- js code executed, and HTML rehydrated when it really needed, not in the real beginning (also known as a __partial hydration__) - is ​the right action, done in the right time. 

***

# My tech stack
- [react-imported-component](https://github.com/theKashey/react-imported-component) for code splitting
- [webpack-imported](https://github.com/theKashey/webpack-imported) for a better bundler integration
- [devolution](https://github.com/theKashey/devolution) for diferential bundling
- [used-styles](https://github.com/theKashey/used-styles) for critical style extraction.
- [react-prerendered-componet](https://github.com/theKashey/react-prerendered-component) for partial hydration and SSR fragment caching

And so, it's time to explain why you should start with `imported-component`...

{% link thekashey/react-imported-component-v6-4304 %}