There is no faster way to slow down a website (pun intended) than to use a bunch of JavaScript code on it. When using JavaScript, you have to pay for it with the performance of projects no less than four times. Here is how the site's JavaScript code loads users' systems:
- Downloading a file over the network.
- Parsing and compiling unpacked source code after download.
- Execution of JavaScript code.
- Memory consumption.
This combination turns out .
And we include more and more JS code in our projects. As organizations move towards sites powered by frameworks and libraries like React, Vue and others, we are making the core functionality of sites very heavily dependent on JavaScript.
I have seen a lot of very heavy sites using JavaScript frameworks. But my vision of the issue is very biased. The fact is that the companies I work with turn to me precisely because they are faced with complex problems in the field of site performance. As a result, I became curious about how common this problem is, and about what kind of "penalties" we pay when we choose one or another framework as the basis for a certain site.
The project helped me figure this out. .
Data
The HTTP Archive project tracks a total of 4308655 links to regular desktop sites and 5484239 links to mobile sites. Among the many metrics associated with these links is a list of technologies found on the respective sites. This means that we can sample thousands of sites that use various frameworks and libraries and learn about how much code they send to clients and how much load this code creates on users' systems.
I collected March 2020 data, which was the most recent data I had access to.
I decided to compare aggregated HTTP Archive data across all sites with data from sites found using React, Vue, and Angular, although I considered using other source material as well.
To make it more interesting, I also added sites that use jQuery to the source data set. This library is still very popular. It also introduces a different approach to web development than the Single Page Application (SPA) model offered by React, Vue and Angular.
Links in the HTTP Archive representing sites that have been found to be using technologies of interest
Framework or library
Links to mobile sites
Links to regular sites
jQuery
4615474
3714643
React
489827
241023
View
85649
43691
Angular
19423
18088
Hopes and dreams
Before we move on to data analysis, I want to talk about what I would like to hope for.
I believe that in an ideal world, frameworks should go beyond meeting the needs of developers and provide some specific benefit to the average user who works with our sites. Performance is just one of those benefits. This is where accessibility and security come into play. But this is only the most important.
So, in an ideal world, some kind of framework should make it easy to create a high-performance site. This should be done either due to the fact that the framework gives the developer a decent base on which to build a project, or due to the fact that it imposes restrictions on development, puts forward requirements for it that complicate the development of something that turns out to be slow.
The best frameworks should do both: give a good base, and impose restrictions on the work, allowing you to achieve a decent result.
Analyzing the median values ββof the data will not give us the information we need. And, in fact, this approach leaves out of our attention . Instead, I derived percentages from the data I had. These are 10, 25, 50 (median), 75, 90 percentiles.
I'm especially interested in the 10th and 90th percentiles. The 10th percentile represents the very best performance (or at least more or less close to the best) for a particular framework. In other words, this means that only 10% of sites using a particular framework make it to this level, or higher. The 90th percentile, on the other hand, is the other side of the coin - it shows us how bad things can get. The 90th percentile is the sites trailing behindβthose bottom 10% of sites that have the most JS code or the longest time to process their code on the main thread.
Volumes of JavaScript code
To begin with, it makes sense to analyze the size of the JavaScript code transmitted by different sites over the network.
The amount of JavaScript code (Kb) transferred to mobile devices
Percentiles
10
25
50
75
90
All sites
93.4
196.6
413.5
746.8
1201.6
jQuery sites
110.3
219.8
430.4
748.6
1162.3
Vue sites
244.7
409.3
692.1
1065.5
1570.7
Angular sites
445.1
675.6
1066.4
1761.5
2893.2
React Sites
345.8
441.6
690.3
1238.5
1893.6
Amount of JavaScript code sent to mobile devices
Amount of JavaScript code (Kb) transferred to desktop devices
Percentiles
10
25
50
75
90
All sites
105.5
226.6
450.4
808.8
1267.3
jQuery sites
121.7
242.2
458.3
803.4
1235.3
Vue sites
248.0
420.1
718.0
1122.5
1643.1
Angular sites
468.8
716.9
1144.2
1930.0
3283.1
React Sites
308.6
469.0
841.9
1472.2
2197.8
Amount of JavaScript code sent to desktop devices
If we talk only about the size of the JS code that sites send to devices, then everything looks about as you might expect. Namely, if one of the frameworks is used, this means that even in an ideal situation, the volume of the site's JavaScript code will increase. This is not surprising - you cannot make a JavaScript framework the basis of a site and expect that the volume of the project's JS code will be very low.
What is remarkable about this data is that some frameworks and libraries can be considered a better starting point for a project than others. Sites with jQuery look the best. On desktop versions of sites, they contain 15% more JavaScript than all sites, and on mobile they contain 18% more. (Admittedly, there is some data corruption here. The fact is that jQuery is present on many sites, so it is only natural that such sites are more closely associated than others with the total number of sites. However, this does not affect how raw data is output for each framework.)
While the 15-18% increase in code volume is a notable figure, comparing this with other frameworks and libraries, one can conclude that the "tax" levied by jQuery is very low. Angular sites in the 10th percentile send 344% more data to desktop than all sites, and 377% more to mobile. React sites are the next heaviest, sending 193% more code to desktop than all sites, and 270% more to mobile.
Earlier, I mentioned that although using a framework means that a certain amount of code will be included in the project, at the very beginning of work on it, I hope that the framework is able to somehow limit the developer. In particular, we are talking about limiting the maximum amount of code.
Interestingly, jQuery sites follow this idea. While they are slightly heavier than all sites at the 10th percentile (by 15-18%), they are slightly lighter at the 90th percentile at around 3% on both desktop and mobile. This is not to say that this is a very significant benefit, but it can be said that jQuery sites, at least, do not have huge JavaScript code sizes, even in their largest versions.
But the same cannot be said about other frameworks.
Just like in the case of the 10th percentile, at the 90th percentile sites on Angular and React differ from other sites, but they differ, unfortunately, for the worse.
At the 90th percentile, Angular sites send 141% more data to mobile than all sites, and 159% more to desktop. React sites send 73% more to desktop than all sites, and 58% more to mobile. The code size of React sites at the 90th percentile is 2197.8 KB. This means that such sites send 322.9 KB more data to mobile devices than their closest competitors based on Vue. The gap between desktop sites based on Angular and React and other sites is even bigger. For example, desktop React sites send 554.7 KB more JS code to devices than similar Vue sites.
Time taken to process JavaScript code in the main thread
The above data clearly indicates that sites using the frameworks and libraries under study contain large amounts of JavaScript code. But of course, that's just one part of our equation.
After the JavaScript code has arrived in the browser, it needs to be brought into a workable state. Especially many problems are caused by those actions that have to be carried out with the code in the main browser thread. The main thread is responsible for processing user actions, for calculating styles, for building and displaying the page layout. If you overwhelm the main thread with JavaScript tasks, it will not have the opportunity to complete the rest of the tasks in time. This leads to delays and "brakes" in the work of the pages.
The HTTP Archive database has information about how long it takes to process JavaScript code in the main thread of the V8 engine. This means that we can collect this data and find out how much time the main thread takes to process the JavaScript of various sites.
Processor time (in milliseconds) related to script processing on mobile devices
Percentiles
10
25
50
75
90
All sites
356.4
959.7
2372.1
5367.3
10485.8
jQuery sites
575.3
1147.4
2555.9
5511.0
10349.4
Vue sites
1130.0
2087.9
4100.4
7676.1
12849.4
Angular sites
1471.3
2380.1
4118.6
7450.8
13296.4
React Sites
2700.1
5090.3
9287.6
14509.6
20813.3
Processor time related to script processing on mobile devices
CPU time (in milliseconds) related to script processing on desktop devices
Percentiles
10
25
50
75
90
All sites
146.0
351.8
831.0
1739.8
3236.8
jQuery sites
199.6
399.2
877.5
1779.9
3215.5
Vue sites
350.4
650.8
1280.7
2388.5
4010.8
Angular sites
482.2
777.9
1365.5
2400.6
4171.8
React Sites
508.0
1045.6
2121.1
4235.1
7444.3
Processor time related to script processing on desktop devices
Here you can see something very familiar.
For starters, sites with jQuery spend significantly less on JavaScript processing on the main thread than other sites. At the 10th percentile, compared to all sites, jQuery sites on mobile spend 61% more time processing JS code on the main thread. In the case of desktop jQuery sites, processing time increases by 37%. At the 90th percentile, jQuery sites score very close to the aggregate scores. Specifically, jQuery sites on mobile devices spend 1.3% less time on the main thread than all sites, and 0.7% less time on desktop devices.
On the other side of our rating are the frameworks that are characterized by the highest load on the main thread. This, again, is Angular and React. The only difference between the two is that while Angular sites send more code to browsers than React sites, Angular sites take less CPU time to process code. Far less.
At the 10th percentile, desktop Angular sites spend 230% more time on the main thread processing JS code than all sites. For mobile sites, this figure is 313%. React sites are the worst performers. On desktop, they spend 248% more time processing code than all sites, and 658% more on mobile. 658% is not a typo. At the 10th percentile, React sites spend 2.7 seconds of main thread time processing their code.
The 90th percentile, when compared to these huge numbers, looks at least a little better. Compared to all sites, Angular projects spend 29% more time on desktop devices in the main thread, and 27% more time on mobile devices. In the case of React sites, the same figures look like 130% and 98%, respectively.
Percentage deviations for the 90th percentile look better than similar values ββfor the 10th percentile. But here it is worth remembering that the numbers indicating the time seem rather scary. Let's say 20.8 seconds on the main mobile thread for a website built with React. (I think the story of what actually happens during this time is worthy of a separate article).
There is one potential complication here (thanks for drawing my attention to this feature, and for carefully considering the data from this point of view). The fact is that many sites use several front-end tools. In particular, I've seen a lot of sites using jQuery alongside React or Vue, as those sites are migrating from jQuery to other frameworks or libraries. As a result, I hit the database again, this time selecting only those links that correspond to sites that use only React, jQuery, Angular, or Vue, but not any combination of them. Here's what I got.
Processor time (in milliseconds) related to processing scripts on mobile devices in a situation where sites use only one framework or only one library
Percentiles
10
25
50
75
90
Sites that only use jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Sites that only use Vue
944.0
1716.3
3194.7
5959.6
9843.8
Sites that only use Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sites that only use React
2443.2
4620.5
10061.4
17074.3
24956.3
Processor time related to processing scripts on mobile devices in a situation where sites use only one framework, or only one library
First, something that is not surprising: when a site uses only one framework or one library, the performance of such a site improves more often than not. Each instrument performs better at the 10th and 25th percentiles. It makes sense. A site that is made using one framework should perform better than a site that is made using two or more frameworks or libraries.
In fact, the performance of each front-end tool studied looks better in all cases, except for one curious exception. What surprised me was that at the 50th percentile and above, sites using React perform worse when React is the only library they use. This, by the way, was the reason that I present this data here.
This is a little strange, but I will still try to look for an explanation for this strangeness.
If a project uses both React and jQuery, then that project is likely somewhere halfway through the transition from jQuery to React. Perhaps it has a codebase where these libraries are mixed. Since we've already seen that jQuery sites spend less time on the main thread than React sites, this might tell us that implementing some functionality in jQuery helps the site perform a bit better.
But as the project transitions from jQuery to React and relies more on React, things are changing. If the site is really high quality, and the site developers use React carefully, then everything will be fine with such a site. But for the average React site, extensive use of React means that the main thread is under heavy load.
The gap between mobile and desktop devices
Another point of view from which I looked at the researched data was to study how big the gap is between working with sites on mobile and desktop devices. If we talk about comparing the volumes of JavaScript code, then such a comparison does not reveal anything terrible. Of course, it would be nice to see smaller amounts of downloadable code, but there is not much difference in the amount of mobile and desktop code.
But if we analyze the time required to process the code, a very large gap between mobile and desktop devices becomes noticeable.
Increase in time (percentage) related to processing scripts on mobile devices compared to desktop
Percentiles
10
25
50
75
90
All sites
144.1
172.8
185.5
208.5
224.0
jQuery sites
188.2
187.4
191.3
209.6
221.9
Vue sites
222.5
220.8
220.2
221.4
220.4
Angular sites
205.1
206.0
201.6
210.4
218.7
React Sites
431.5
386.8
337.9
242.6
179.6
While some difference in code processing speed between a phone and a laptop is to be expected, such large numbers tell me that modern frameworks are not sufficiently targeted at low-powered devices, and that they are striving to close the gap they have discovered. Even at the 10th percentile, React sites spend 431.5% more time on the mobile main thread than on the desktop main thread. jQuery has the smallest gap, but even here the corresponding figure is 188.2%. When website developers make their projects in such a way that their processing requires more processor time (and it happens, and it only gets worse over time), the owners of low-powered devices have to pay for it.
Results
Good frameworks should give developers a good foundation for building web projects (in terms of security, accessibility, performance), or they should have built-in restrictions that make it hard to build something that violates those restrictions.
This does not seem to apply to the performance of web projects (and presumably not to their ).
It's worth noting that just because React or Angular sites spend more CPU time preparing code than others doesn't necessarily mean that React sites are more CPU intensive than Vue sites while running. In fact, the data we reviewed says very little about the operational performance of frameworks and libraries. They talk more about the development approaches that, consciously or not, these frameworks can push programmers. We are talking about documentation for frameworks, about their ecosystem, about common development techniques.
It is also worth mentioning something that we did not analyze here, namely, how much time the device spends executing JavaScript code when navigating between pages of the site. The argument in favor of SPA is that once the single page application is loaded into the browser, the user will theoretically be able to open the pages of the site faster. My own experience tells me that this is far from a fact. But we do not have data to clarify this issue.
What is clear is that if you are using a framework or library to create a website, you are making a compromise in terms of initially loading the project and getting it ready to go. This applies even to the most positive scenarios.
It is perfectly possible to make some compromises in appropriate situations, but it is important that developers make such compromises consciously.
But we also have reason for optimism. I'm excited to see how closely the Chrome developers are working with the developers of some of the front-end tools we've reviewed in an effort to help improve the performance of those tools.
However, I am a pragmatic person. New architectures create performance problems as often as they solve them. And it takes time to fix bugs. Just as we should not expect will solve all performance problems, you should not expect this from new versions of our favorite frameworks.
If you want to use one of the front-end tools discussed in this article, it means that you have to put extra effort into not harming the performance of your project in the meantime. Here are some considerations to consider before starting a new framework:
- Test yourself with common sense. Do you really need to use the chosen framework? Pure JavaScript today is capable of a lot.
- Is there a lighter alternative to the chosen framework (like Preact, Svelte or something else) that can give you 90% of the capabilities of this framework?
- If you're already using a framework, consider if there's something that offers better, more conservative, standard options (eg Nuxt.js instead of Vue, Next.js instead of React, and so on).
- What will your JavaScript performance?
- How can you a development process to make it harder to inject more JavaScript code into a project than is absolutely necessary?
- If you are using a framework for ease of development, consider send framework code to clients. Maybe you can solve all the issues on the server?
Usually these ideas are worth looking at, regardless of what exactly you have chosen for front-end development. But they are especially important when you are working on a project that lacks performance from the very beginning.
Dear Readers, How do you see the ideal JavaScript framework?
Source: habr.com