Crystallize logo

Faster React TTI by Replacing Apollo with Urql

Psst: we are hiring frontend developers and backend developers.

Illustration of backend developer holding a laptop against a designer holding a picture of cat

Having a fast API for your ecommerce is a vital backbone of the infrastructure. It ensures that the performance bottleneck is not the data provider, and leaves you to dedicate focus to other important arenas; such as frontend performance. Important topics to consider on frontend performance are pagespeed index and time to interactive. We replaced the Apollo GraphQL client library with Urql and saw significant performance improvements.

Reducing Time To Interactive (TTI)

We have done a blog post on the relative difference between pagespeed index and time to interactive, the uncanny valley, which is a very critical time for any website and is really important if you are doing an ambitious ecommerce. In the article, we highlighted what this effect is, and how to measure it. Let’s dive in to one more way of optimizing.

The performance metric Time To Interactive (TTI), is the time it takes from the browser start loading a web page until it is ready-to-use for the end user. When TTI has happened, it means that most of the client side javascript has downloaded and executed, and that the application is ready to receive user input. Improving TTI directly improves the uncanny valley score, which makes it the place to start looking for improvements in your application.

When doing a React application, it is quite easy to get into a situation where the client js bundle gets quite big, which tends to be difficult to pick up when you are deep in implementing new features on a tight timeline. This might lead to huge js bundles that get shipped to the users, something that can have a massive effect on mid-and-low end devices.

Less Javascript Execution is Better

To put it simply: the more work you give the browser, the worse TTI you will get. And as TTI gets worse, the end users (and your business) is starting to suffer.

Improving TTI

One simple way of improving TTI is to not ship any javascript at all. Sure, the application is no longer as interactive as you might want it, but for some sites this is still OK.

Another, more realistic way to improve TTI is to simply send less Javascript, and also carefully monitor the performance of the code that you are executing. If you send less bytes to the client, and the client ends up executing less code, you are on a great path towards a better TTI.

Let’s take a real-world example, our React Frontend Boilerplate, which does ship a moderate amount of Javascript to the client. It’s using Apollo for managing the GraphQL api, which is a very popular library for React these days, but it is quite big in size and has a bunch of features that we might not need in an ecommerce.

Our partner Formidable has made a lightweight alternative to Apollo, Urql, which I wanted to try out. It is smaller in bytes, and still promises great performance.I deployed the boilerplate on Now V2, and did 5 tests with the latest version of Apollo and another 5 with Urql.

The average TTI with Apollo: 3.86 seconds

The average TTI with Urql: 3.50 seconds

TTI improvement: 360 ms

URQL is Simply Faster than Apollo

This does not look like a huge improvement, but bear in mind that we only switched out the Graphql client. There are still a bunch of other Javascript running on the app. And getting a 360ms for free by just using a different library to consume an API is an effective and safe way of optimizing, which does not require you to do a bunch of refactoring of your application code.

After testing out Urql on our boilerplate and the effects it has on frontend performance, we made the switch last week and are now using it by default.

Milliseconds matter.