Web performance is a big and complex topic. In this post we’ll narrow it down to a discussion of front end JavaScript frameworks and how using one versus another might impact the performance of your app. In particular, we’ll be looking at two things: (1) how long it takes a framework to update the user interface, and (2) the time required to download and parse the package(s) required for the framework to be functional.

My go-to resource for this data over the last couple years has been the js-framework-benchmark by Stefan Krause. It’s good, but also kind of complicated. It’s easier to look at a subset of the results, and that’s what we’ll be doing in this article. I encourage you to check out the tool Stefan has built and dig into more of the data on your own, particularly if your favorite framework is missing from the graphics below. It may be available on Stefan’s site (he tests 40+ frameworks).

Also, a quick warning:

These results are preliminary - use with caution (they may e.g. be from different browser versions

With that caution duly noted….

Let’s See the Numbers

The first batch of results will be looking at how long each framework takes to do various operations on a large table - creating rows, removing them, etc. Another important point, these are keyed results. Here’s the explanation from Stefan’s site:

Keyed implementations create an association between the domain data and a dom element by assigning a 'key'. If data changes the dom element with that key will be updated. In consequence inserting or deleting an element in the data array causes a corresponding change to the dom.

In the image below, the larger the number, the slower the framework performed on the task. Looking at the bottom value “slowdown geometric mean” is an indicator of overall performance and this is how they are ranked, left to right. On the far left is “vanillajs” - meaning no framework - that acts as a reference point.

As you can see, I’ve included most of the popular frameworks as well as couple of less-well-known, but interesting frameworks. Preact (which is pretty popular) and Inferno have APIs very similar to React, which is why I included them. They may be good options if you are on a team that uses React, but are building an app where performance is a high priority. Also note that keyed results will typically be slower - the framework is being asked to do more work.

Of the most popular frameworks, Vue looks pretty darn good. Angular and React are both notably slower, but post very similar numbers to one another. The Inferno library is the stand out of the group, however. As an aside, the author of Inferno, Dominic Gannaway, was recently hired by Facebook to work on the React team.

Now let’s check out the non-keyed results:

There are a few things to note. First of all, we see that there are fewer frameworks listed because non-keyed results are not available for every framework. We also notice that the results have been shaken up a bit.

Vue is the slowest of this group and Angular is now the fastest of the popular frameworks. The fastest of all is Svelte, which is an interesting framework that takes a different approach - you should definitely check it out.

Before we move on, I would be remiss if I didn’t mention the framework that topped all others - Surplus, by Adam Haile 🎉. It wins in both keyed and non-keyed tests. There are a number of others that also performed quite well including petit-dom and dio. I didn’t include them above because I wanted more room for the most popular libraries/frameworks. If you go to the results table, you’ll see it gets overwhelming quickly and some trimming needed to be done to make things manageable for our purposes.

Startup Metrics

The results above looked at how fast the frameworks were once a page was fully loaded and they performed operations on a large table. The next set of numbers looks at things from a different angle - download, parse and compile time.

These measures help tell us how long users have to wait before the page they are loading is functional. Generally speaking, the more JavaScript you download, the longer it takes and the more code there is for the browser to parse and compile.

Again, these results are grouped by keyed and non-keyed. Let’s start with with the keyed results:

These measurements don’t have a single handy value by which they are ranked, but generally, green is good, red is bad. Again, Inferno is looking good, as are Svelte and Preact. Of the most popular frameworks, Vue performs the best and Ember is looking a bit flushed at the back of the pack

Now let’s see the non-keyed results:

In this group, Svelte looks really fast and really lightweight. The total byte weight is less than vanilla JavaScript! I told you it was an interesting framework!

Final Thoughts

I got the idea to write this article about a month ago after reading The Cost of JavaScript by Addy Osmani. There was a chart that he shared that hit home for me. It showed how long a 250KB gzipped (1MB unzipped) JavaScript bundle took to parse on various mobile devices with the average phone being highlighted. Here it is:

As I alluded to earlier, I have been following Stefan’s benchmarking for quite a while now and I immediately connected his work with Addy’s article. When we are prioritizing performance, most of the time we’re talking about mobile devices. These mobile devices are often less capable than many assume. And by many, I mean me - and probably a bunch of other people too.

Front end JavaScript frameworks are impressive feats of engineering. They are complex and difficult to do well. The choice of which framework to use on a given project is sometimes not easy. There are a lot of trade-offs that have to be be weighed.

For example, a framework like React has a huge ecosystem that can accelerate your project by providing many third-party libraries and abundant training resources, among other benefits. But is it the best choice for a project that is targeting users on 2G networks? Maybe not.

Deciding which framework is going to work the best ultimately comes down to project requirements and the team building it. Hopefully the results highlighted here have provided some food for thought.

If you liked this post, sign up for my weekly newsletter. I curate the best JavaScript writing from around the web and deliver it to readers every Thursday. The sign up form is right below this article.

Until next time, happy coding…