Skip to main content
🍞
Best Practices
Faster React TTI by Replacing Apollo with Urql

Faster React TTI by Replacing Apollo with Urql

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 page speed 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 page speed 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 into one more way of optimizing.

The performance metric Time To Interactive (TTI), is the time it takes from the browser to 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 been 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) are 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 fewer 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 is still a bunch of other Javascript running on the app. And getting 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.