DEV Community: Mladen Stojanovic

Get 100 lighthouse performance score with a React app

Mladen Stojanovic — Tue, 07 May 2024 19:35:50 +0000

⁠In this article, I will lead you through a high-level setup on what is needed to achieve those always-eluding high scores in your lighthouse metrics, even if you use a proper React app, and fetch everything from a CMS!

In subsequent posts, I might dive deeper into the details of each individual component of this setup

What are we looking at?

You probably looked at your network tab numerous times debugging some API calls and looking at your requests and responses, but I bet you haven't paid too much attention to the Waterfall column of this table, and that one can paint almost a full picture of a website from a performance perspective, and we'll refer back to it from our sections below.

What can we observe from this waterfall example?

First of all, you can notice that the home page loaded extremely fast, it took just 708ms for it to completely load (but not fully finish - more on that later) and the total downloaded content is just 162kBs, which is insane compared to a whopping 490MBs of just node modules this small project has!

We can group this waterfall into roughly 3 parts:

HTML Document
Assets & JS
Other files that are not needed for the initial render (but important for performance otherwise!)

HTML document pretty much lays down the "plan" and tells our browser that the assets and JS files are needed next and that they should be downloaded in parallel. You can observe this behavior in the waterfall by noticing this group of files that started to download at the same time, and the third group of documents, downloaded after everything has been completed which serve the purpose of "preloading" the pages from the navigation bar and speed up subsequent linking to them.

Let's talk about the 2 things that make this happen: building and serving

Building the app

Even though there is now a variety of frameworks that can do somewhat of a similar thing, I always keep coming back to Next.js as I believe it is the most mature React server-side-rendering option out there. The time this framework has been out really can be seen by the amount of optimization these guys did to bring this framework to the best light possible.

Cool, but the only time I previously managed to get 100 performance score is when I deployed a static html + css website, how the hell did you manage it with Next.js?

Someone on the internet

Well, we're pretty much doing the same thing :)

If you set in your next.config.js file

const nextConfig = {
  output: 'export'
}

module.exports = nextConfig

and run

npm run build

it will generate an out folder with static html, css, and js!
Not only that but Next.js magic will split all your code per page, and optimize as much as it can, therefore shrinking your js files to a minimum!

Using the Next router will also enable prefetching of your next pages so when you click on another page, it will appear almost instantly!

First of all, you can notice that the home page loaded extremely fast, it took just 708ms for it to completely load (but not fully finish - more on that later)

If you get back to this paragraph and the waterfall graph, you can notice a couple of files downloaded after the red line which marks the loaded event, and those are metadata for about and blog pages, which are in my navbar!
⁠
⁠Next.js loaded everything needed for this page, rendered it fully thus making it blazing fast, and then after that, loaded some metadata for other pages without blocking anything else. Having to set up something like this ~5 years ago required having a team of webpack and JS gurus and ninjas so I'm in awe that we get configurations like this out of the box today.

But wait a minute, I told you about fetching the data from a CMS, how is that being handled?

Using Next.js generateStaticParams function in combination with dynamic route segments will fetch all your CMS content in build time, and generate each blog post page to a static html file, as well as the blog post list, therefore losing another set of API calls from the client!
⁠
⁠Here is all the magic in the code snippet from my page @ src/app/posts/[slug]/page.jsx

const AllPosts = 

  query AllPosts {

    posts(orderBy: publishedAt_DESC) {

      id

      slug

    }

  }

;

async function getPosts() {

  const allPosts = await fetch(process.env.HYGRAPH_ENDPOINT, {

    method: 'POST',

    headers: {

      'Content-Type': 'application/json'

    },

    body: JSON.stringify({

      query: AllPosts

    })

  }).then((res) => res.json())

return allPosts.data.posts

}

export async function generateStaticParams() {

  const posts = await getPosts()

  return posts.map((post) => ({

    slug: post.slug

  }))

}

Serving the app

We have our static and optimized files, now we have to serve our app somewhere.

We will store our files on the s3 bucket and place Cloudfront CDN in front of it.

What do we get from that setup?

Looking at one of the files in the network tab you will notice that the file is encoded with br which stands for brotli compression algorithm which has better compression around 15-20% than gzip which was previously the standard.

On top of that Cloudfront is caching our data which you can see by Hit from cloudfront message which means that your static content (which is your whole app at this point) is available physically in a location near you, which will bring latency to a minimum!

Using a CDN with your fully static app makes so much sense, and when you get a good compression algorithm on top of that, plus the build-time optimizations, can't get any better than that!

Bonus - CMS

Bonus points for getting that 100 SEO score go to Hygraph CMS, as it has good SEO support, graphQL API as you saw in the code snippet above so you can generate queries easily, as well as good templates and starters (which I used for my blog).

Feel free to check out the performance mentioned at https://mrocketsolutions.com/blog and comment below if you have any other options or questions!

How to deploy a React app without a server, easy, no compromises

Mladen Stojanovic — Tue, 27 Oct 2020 01:02:32 +0000

The story

You have an idea of an awesome app you want to create and you have a good knowledge of React, so what do you do?

npx create-react-app myApp
cd myApp
npm start

and you are good to go! Everything is going really smoothly in your local environment and nothing stands in your way to creating that beautiful UI, leveraging the power of React all along the way.

Time passes by, you finish your app, and surely, you want to show your app to the world.
Maybe you are not ready for a full-fledged production-ready app with a domain, and all the bells and whistles, but only want to show it to someone else. You want to have it online without too much hassle.

So, what are your options?

When running npm run build to create an optimized production build of your app that create-react-app provides, info in the terminal window tells you this

The build folder is ready to be deployed.
You may serve it with a static server:

  npm install -g serve
  serve -s build

This means you need to have a server in place to get your application up and running.
The problem with servers is that computing power costs money, and there is a small chance you will find it unlimited for free anywhere, and also, you really aren't ready to pay money for your app at the moment. Other than that, setting up an HTTP server, getting a domain, etc. is a challenge on its own...
But, you are a seasoned React veteran. You know that building a React app gives you a folder with all the files you need to have an app working.

Cloud services

That is where the first major part of this puzzle gets solved... cloud computing!
But it's really not that exotic because I'm mostly talking about storage solutions those provide, Azure Blob Storage, and Amazon s3 buckets.
Both of them have an option to host a static website, and setting it up is fairly easy since both Azure and AWS provide free tier services for storage solutions that you cannot go out of if they are being used in a non-high load/traffic use-case. Definitely read the pricing tables for both of them if you plan to host something serious on them!

create-react-app on AWS s3

I will now show you a really basic create-react-app deployed to an s3 bucket, and later on, I will show you how to do it by yourself on Azure! You can easily find similar tutorials for deploying static websites on the AWS s3 bucket. Comment below if you want an AWS s3 deployment tutorial as well.

my really complex React app

You will immediately recognize the default create-react-app screen with a twist. I added a router and an "About" page with links that can guide you back and forth.
Our demo app works great until you try to refresh, or land directly on a page which is not our home page [e.g. /about]. This is where any relatively serious app fails using this approach.
The problem is that a React app is a single-page app with just one index.html which executes js files who then do their magic and fill up our app with all the beautiful content.

If you take a look at the bucket for this app, you will quickly realize that there is no "about" folder with an index.html file inside of it, so we rightfully get a 404 error. We would need to have a server that redirects all of our traffic to this index.html and the javascript inside which will boot up our React app and figure out what we are trying to see.

Next.js

This is where Next.js comes in and saves the day!

If you don't know what Next.js is, seriously go look it up and do a bit of research, it's awesome!

I cannot give Next.js enough justice by doing this, but I will try to sum it up for anyone who hasn't heard about it before.
Next.js is a framework for React which mainly provides server-side rendering out of the box, and it can be seen only as an "extension" to React because you still only write regular js and jsx (ts/tsx also supported!), but it is much, much more! Next.js gives us a router out of the box and it only "forces" us to use the file system as routes, so every file inside the pages folder is a regular React component, but it is also a route.
For example, creating a component inside the pages folder like pages/about.js instantly registers the /about route to go to this file.
Next.js also provides us with some additional functions that help server-side data fetching which will come in handy pretty soon.
You can start a new Next.js project as easy as create-react-app.

npx create-next-app
# or
yarn create next-app

The project

I created a small Next.js app which I connected to a free cocktails API, fetched a couple of cocktails, listed them, created a detail page of every one of them. Here is the link to the project so you can check it out

https://staticappdemo.z6.web.core.windows.net/

I also provided the source code on github if you want to follow along.

I will try to explain how this is done pointing out a couple of "gotchas" inside Next.js and then do the step by step deployment to Azure!

You will notice that inside my pages folder I have a structure like this

+----_app.js
+----index.js
+----cocktails
|   +-- [id].js
|   +-- index.js

pages/cocktails/index.js is my /cocktails route, and pages/cocktails/[id].js is Next.js way to handle dynamic routes, so /cocktails/123abc will go to that file and we will have 123abc available to us inside this file as id.
Since Next.js provides us with static HTML export, we will use that feature to fetch our cocktails in build time and deploy everything as static pages to our cloud storage solution.

The first thing we need to do is use the getStaticPaths function that Next.js provides for us so that we can tell it what routes do we need to be generated at build time.
Inside our [id].js file you can see this piece of code.

// This function gets called at build time
export async function getStaticPaths() {
  // Call an external API endpoint to get cocktails
  const res = await fetch(
    "https://www.thecocktaildb.com/api/json/v1/1/filter.php?a=Alcoholic"
  );
  const parsedRes = await res.json();
  const cocktails = parsedRes.drinks.slice(0, 9);

  // Get the paths we want to pre-render based on cocktails
  const paths = cocktails.map((cocktail) => ({
    params: { id: cocktail.idDrink },
  }));

  // We'll pre-render only these paths at build time.
  // { fallback: false } means other routes should 404.
  return { paths, fallback: false };
}

As you can see here, we only fetch the cocktails for their ids and map them as per documentation so that Next.js knows those are the ids we want to have for our cocktail routes.

After that, you can see getStaticProps being used like this

// This also gets called at build time
export async function getStaticProps({ params }) {
  // params contains the cocktail `id`.
  // If the route is like /cocktails/1, then params.id is 1
  const res = await fetch(
    `https://www.thecocktaildb.com/api/json/v1/1/lookup.php?i=${params.id}`
  );
  const cocktail = await res.json();

  // Pass cocktail data to the page via props
  return { props: { cocktail: cocktail.drinks[0] } };
}

We use the id to fetch details of an individual cocktail and then pass it down for us to use it inside props.

Next.js doesn't know that we want to use it as a static HTML export so it won't create the file structure as we want it for that use case. We can quickly fix that by adding this piece of code inside next.config.js

module.exports = {
  trailingSlash: process.env.NEXT_PUBLIC_ENV === "prod",
};

This tells us to use the trailingSlash when doing a production build. You now need .env.development and .env.production files which Next.js will automatically recognize when building the app for production, or for you to use in your local environment.

To build the app as static HTML, I added a new script to package.json

"build:static": "next build && next export"

Running npm run build:static creates an out folder with all our pages built inside their own id folders. If everything went well, your out folder should look something like this:

Deploy to Azure

Creating a free Azure account should be pretty easy, and in the Azure dashboard, use the search bar on top to find the Storage accounts service. After entering Storage accounts you should see something like this

Click on Create storage account button or Add button on top left.

You will need to create a new resource group (if you haven't did that previously) and you can do that inside the wizard easily. It looks like this

Fill in the storage account name and choose a location geographically closest to you (or your audience).

Leave everything else as default and go straight for the Review + create button.

The deployment will take about a minute or less and you should now see your new storage account inside the Storage accounts dashboard

Click on the newly created storage account. It will open up a menu. Scroll down and find the Static website option. Enable it and fill the Index document name with index.html and Error document path with 404/index.html. Next.js provides default 404 page for us. Click the save button and you will have your new website endpoint ready! It should look something like this

Scroll the menu back up to Storage explorer (preview) click on it and open the BLOB CONTAINERS folder and there you will see a $web folder. That is where your built app files will be.

Before we can upload our files here, we need to add ourselves as a blob owner, otherwise, the upload will fail. To do that, on the menu, find Access Control (IAM) option. Click on the Add role assignments. Select the role Storage Blob Data Owner. Assign access to User, group, or service principal and in select field type in your e mail address associated with your Azure account. It should look like this

The next thing you want to do is install the Azure CLI for your OS

After that is done, enter your terminal and start with logging in to Azure

az login

A new browser tab should open up for you to log in to your Azure account.

After that, you need to find out the key for your storage account. To do that run

az storage account keys list --account-name 'mladenteststorage'

just replace mladenteststorage with your storage account name.

You should get an output that looks something like this:

az storage account keys list --account-name 'mladenteststorage'
[
  {
    "keyName": "key1",
    "permissions": "Full",
    "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  },
  {
    "keyName": "key2",
    "permissions": "Full",
    "value": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }
]

Take the "value" from the "key1" and write it down.

And finally to upload everything to our blob storage

az storage blob upload-batch -d '$web' -s 'C:\Users\mlst2502\...path-to-your-project\out' --account-name 'mladenteststorage' --account-key 'key-that-you-wrote-down-previously'

And there you have it! Your app should be visible on the URL you saw in the Static website section of your storage account!

If you read this all the way till the end, thank you for your attention! I hope this helped you in any way, and if you have any questions about the topic, feel free to ask me in the comment section, or find me directly on any of my social networks which are listed on my website

What is React Server Side Rendering and should I use it?

Mladen Stojanovic — Fri, 10 Aug 2018 12:58:58 +0000

As stated in the title, I will try to present some pros and cons regarding this not-so-hot-anymore technology, and also help someone new to React SSR understand it a bit more.

First of all, let's dive into some terminology stuff

SSR? Isomorphic? Universal? WTF?

First of all, for some of you that don't know (as I haven't until recently) server side rendering is nothing special. Any ordinary static website is server side rendered, a server gets your request and spits out HTML to your browser.
We also had templating languages doing some neat tricks for us that are considered as server side rendering.
BUT when we talk about JavaScript, Server Side Rendering usually points out to an ability of a front-end code to render HTML while running on a back-end system.

SPA + SSR = Isomorphic*

* or universal

Isomorphic or Universal apps are interchangeable phrases commonly referring to a way of writing your apps so that you use the same language on both server and client side. More specifically, for JavaScript, best case scenario would be that you also use the same syntax.
For example if you are running your back-end in NodeJS you are probably using CommonJS module syntax.

//...Our awesome app code...
const circle = require('./circle.js');
//...Rest of our awesome app code...

And you write your React in ES6

//...Our awesome app code...
import React, { Component } from 'react';
//...Rest of our awesome app code...

Using Webpack we can start using our ES6 import syntax also on server side of our app, and that is the true goal of an isomporphic app.

Why would I want to use React with server side rendering in the first place?

Well, our traditional React app would have this flow when loading:

Browser requests a page
PAUSE
We get pretty empty html and a script tag pointing to a JS file where all of our code lives
Browser requests that script
PAUSE
Content visible on the screen

We now see that we have 2 round-trips to server, which is kinda acceptable. But let's imagine that our app has a list of blog posts, or a series of images, or whatever that we need to request from some API, now the flow is a bit more realistic and looks something like this:

Browser requests a page
PAUSE
Browser requests our JS
PAUSE
React app boots, requests data from backend
PAUSE
Content visible on the screen

As you can see, the number of requests increased, so there is a lot more happening before our user sees anything on the screen.

Now for the Server Side Rendered React App

Browser requests a page
PAUSE
Content visible on the screen!

Whaaat? How? Let's look at it in a bit more detail

Browser requests a page
Server loads React in memory
Server fetches required data
Server renders React app
Server sends generated HTML down to the browser
USER SEES CONTENT
Require JS file
React App boots, requests data from backend
App rerenders (hydrates) on the screen.

As you can see we did only 1 trip to the server before getting some content for our user. Now, the content that we served before we rerendered everything is static, so if our user is super fast and starts clicking before hydrate happens, the app will not be responsive.

What problems are we solving using this approach?

Two of the biggest ones are SEO and perceived performance boost

If your app is a bit larger, search engine crawlers will see your page as a mostly empty html with a single script tag that requests your massive React app, as it won't wait for the moment it fills up the DOM, your page won't get indexed.
Meanwhile, Google improved their crawlers to search for javascript created content also, but Bing or Baidu are still lacking this feature, so if larger percentage of your audience is coming from other search engines, you will have to work that out.

With React SSR your First Meaningful Paint time will be (in most cases) significantly lower. This is an important metric for some companies. You certainly heard stories of numerous companies increasing their profit by cutting down on load times for their web apps. (https://wpostats.com/).

Above I wrote perceived performance boost, and while it is true that you will get content to your user faster than using a traditional React app, the catch is that it probably isn't a performance boost. In the SSR request example a little bit above you see that server is also doing everything that client does: It boots up React, renders the app for you and spits out HTML. This means that you are doing everything 2 times which isn't ideal. Also renderToString() method that react uses to convert your beautiful jsx code to HTML is really slow and also synchronous. This puts server under more load, and your initial response from server will arrive later.

If you decided to go with server side rendering, you will probably have 2 servers: One for the API and business logic, and another one for rendering purposes. Knowing how big of a task your rendering process is, you can scale up your rendering servers to match the increased load.

Since I am not the first one who had issues with these problems, engineers over at Walmart labs created a tool that optimizes those quirks React SSR has, called Electrode. They also wrote couple of cool articles about it, really worth reading if you made it this far :) (https://medium.com/walmartlabs/using-electrode-to-improve-react-server-side-render-performance-by-up-to-70-e43f9494eb8b)
There are also "frameworks" for React SSR like Next.js for example which is gaining nice traction and support from community.

Using React SSR also adds multiple levels of complexity. Remember freely using window or document to do stuff? Forget about it!

I am just kidding of course, but you will have to be extra cautious, since the app will run first in a Node environment, window and document for example are not defined there, so you will have to restrain yourself from using them outside componentDidMount or without if (typeof window !== 'undefined'). I cannot remember how many times my app broke until I got used to it.

Your Node server will catch your routes and pass it down to React to decide what to render, so how does it have access to your router on server? It doesn't. Solution? Double routes. Your Application renders depending on something from your Redux store? Double store.

There are many complexities introduced with SSR, luckily for us, tools like Next.js solve many of them, but if you are stuck with solving all those problems by yourself, it will be really hard.

Should I use React Server Side Rendering?

Maybe.

If you / your company really values SEO, and significant number of your visits come from search engines other than google, yes.

If you / your company really values user perceived performance, think about it, if your client side application performance can't get anything better, then yes.

In any other case, my advice is to stay out of it, it will just increase complexity of your project without really much benefits.

How we decreased load time by 40% by removing just 1 file

Mladen Stojanovic — Thu, 28 Jun 2018 14:56:27 +0000

So the title of this article is really clickbait-ish, but in reality it is exactly what happened.

I started working on a project around September last year. Since all of the NDA stuff happened with the client, I cannot write much about names, but it is a big company in their respective field.
They are using a React SSR app to serve their websites which are not source of their income, it is for information, some blog posts, articles etc. Of course they have ads on it, and it is visited decently, but they didn't pay that much attention to it.

I know what you're going to say now: How come that they don't pay that much attention to it but they are using a really modern stack for their "not so important" website?

Well they wanted the previous team to build it with cutting edge tech since they were redesigning and recreating everything, and as you guessed, using some cutting edge technologies early in its adoption will leave you with (some) negative outcomes, but more on that in other posts (hopefully).

Back to the present, my team and I got in as a part of a team that will maintain and add features to this (and several other) projects for this client. From the first day it really annoyed me how the app is slow, even though it is created as a server side rendered react app, it should be lightning fast! New Relic stats were coming in every week and showed something like 10 or 11 seconds of average loading time, it was really crazy!

Couple of months in, I was at a tech conference where I attended a talk and workshop by Harry Roberts (https://twitter.com/csswizardry) a performance consultant where I was really inspired by his biggest point in the whole presentation:

Your website's performance will increase as soon as you start paying attention to it

Or something like that, it was a long time ago :)

But from that point I actually started paying attention to this app's performance.
In between standard issues and sprints, I started to analyze what are the biggest problems of our app and really fast I realized that our app's CSS file was 2.9MB unzipped and 1.9MB gzipped.
I was shocked, how does a CSS file reaches this kind of size? It is a big app, but not THAT big. And gzip loves repetition, how this cannot be compressed even more?

Time passed with new tasks and strict deadlines, we've all been there, but that CSS file just couldn't get out of my mind. One day my teammates and I sat down and started looking for a problem. We sorted every css file in the project and found out there was one that was 1.5MB large(!!!)

Someone put 8 decently sized images (around 1500x600px), converted it to base64 and put it in a css file which was loaded every time in a bundle, even when it hasn't been used!
Deleting that file reduced our bundled css file to 1.3MB unzipped, or 700KB gzipped! A huge win!

Later on I tested the website with some performance tools and every single one showed decrease of 40 to 60% in load time! (first paint, full page load etc.)

Moral of the story:

Pay attention to your app's performance, sometimes really small changes can bring you really awarding results!

Cheers!