optimizations begin right from the “start screen”

Building Progressive Web Games Part 2

Welcome back! In this part we’ll talk about building the login functionality in a way that our app’s Time to interactivity does not take a hit.

In the time of “Single Page Applications”, it has become really common and easy for developers to send pieces of javascript code to their user which user might never use. This is why I decided to keep just the login functionality a separate part

As we discussed in part 1, we will be using Firebase to authenticate our users with Google. In order to start with firebase here‘s the first step

// install firebase
> npm i -D firebase

After firebase is installed, we’ll add it to the home.jsx as shown below 👇

static import of firebase

NOTE: firebase is distributed in two forms

a. The entire firebase bundle in one file(app, auth, messaging, database etc)

b. Every functionality in its own file

Please do NOT use the first version until you are using all the features. Due to an imperfect tree-shaking, your jS bundle might take a huge hit otherwise.

Before we go any further here’s a look on how our timeline looks without any firebase code

timeline without any firebase code (TTI: ~1.5s)

Now we’ll try to run our new code(with firebase) as production build. In order to do this run the following two commands:

// preact cli tries to prerender the routes for you and firebase
// might cause error here, we'll fix this in next few steps
> preact build --no-prerender
> preact serve

You will observe a few things here:

1. Preact-cli has started warning you about the bundle size, even after using the separate firebase files.
2. This has shifted our ‘Time to interactivity’ by 1s 😟. (An entire second looking at a blank screen)

preact cli warning you about sending too much jS in the same bundle.

timeline when firebase is also in the route bundle(TTI: ~2.5s)

☝️this is bad because even though my user wanted to do a guest login he is waiting for scripts which he’ll never use. We’re going to run a perf axe on it. We’re going to use lazy-loading on this and make the rest of the screen interactive without firebase. So people can use features as they become available/interactive instead of clicking on stuff that does nothing.

In order to do this, we use webpack’s require.ensure and use a LinearProgess to indicate that Google Sign-in is loading in the background.

Here’s what it does for us on the timeline 👇. Notice the ~900ms gain on time to interactivity.

timeline with lazy-loaded firebase code (TTI ~1.6s)

What we just did is really important as we’re not blocking our users for anything, stuff is available for users to interact as it gets downloaded.

We have come to a place where no unnecessary scripts are parsing, a small jS & CSS footprint and one image is download. Hint: Here we see some scope of squeezing a <link rel=prefetch tag in order to tell the browser that take X url and start downloading in low priority, we’ll use it in some time.

So far, a user has landed on our game, quickly got it running, interactive and logged in to play the game. After user has reached here, we’ll route him/her to the main playing screen where a giant(compared to other assets) game engine is waiting to get downloaded so that the game can begin. And if we don’t do a good job at optimizing that, we’re not too far from the slow “download and install” kind of experience of app stores.

This is what we’ll try to fix in the next part, and I PROMISE in next part we’ll do actual game coding as well.

Our finished up start screen 👇

login screen

Code: https://github.com/prateekbh/hopon/tree/part2

So stay tuned.

P.S. Special thanks to Surma, for helping me profile and improve this better.

Earlier parts: https://medium.com/@prateekbh/progressive-web-games-part-1-62dcb89c39ff

Next part: https://medium.com/@prateekbh/building-progressive-web-games-part-3-31398018580d