JQuery performance indicators and tuning (1)

This article was inspired by the reader's e-mail feedback on a previous article, which wrote: "jQuery is impeccable on simple pages, but its performance is extremely low on complex pages. You must use regular JavaScript For complex pages before resolving performance issues ." This immediately reminds me of "what is the performance comparison between jQuery and JavaScript ?" In fact, I rarely see articles comparing jQuery libraries with JavaScript or other JavaScript libraries. Like most people, I may only see the ease of writing client code with jQuery, ignoring possible performance problems. In my opinion, it is worthwhile to compromise between ease of use and performance. But is there such a compromise? Is jQuery slower than "normal" JavaScript? Is jQuery slower than other libraries? This article will try to answer these questions.

BKJIA recommended topics: jQuery from entry to entry

The most important consideration for measuring JavaScript performance is the execution of JavaScript environments. Because the code runs on the client, its execution depends on the client computer, which makes the client machine the most important factor affecting performance. Obviously, new servers running 4-core CPUs must execute code faster than older 400 MHz processors. There is no doubt. However, since you cannot control the machines that Web application users use to access your site, you must consider many hardware factors when measuring performance.

Another important aspect of JavaScript performance is that it is used to run JavaScript browsers. It may not be easy for new JavaScript users to find this influence factor. Each Browser contains a JavaScript engine, that is, the local code used to parse and execute JavaScript code and process Web application pages. Therefore, the performance of JavaScript depends heavily on the browser used by the client, and in some cases, you can control the browser used by the user. This article provides some guiding principles on JavaScript performance and explains the impact of different browsers on performance.

Finally, after summing up JavaScript, especially jQuery's performance, I will determine some best practices that can improve jQuery's code performance and take full advantage of the fastest-Running code, avoid the slowest part of the code. After reading this article, the question "is jQuery good?" will be answered, and the person who sends me the email will know whether his assertions are correct.

Create a performance test

The first step about performance testing is to create a suitable performance test. The most important role that jQuery and other JavaScript libraries play in code is to select to find specific page elements. I focused on this in my initial performance tests. A good performance test should truly exert all the power of the JavaScript library and test it with a page containing thousands of page elements. All selection methods should be run, so that I can see which method is the fastest and which is the slowest. The test should know the correct answer in advance to determine whether the JavaScript Library Correctly executes the selection method. Finally, all results should be displayed with the running time used, so that I can compare all databases.

I almost ignored the most important aspect of performance testing: it should be free. After all, the unwritten rules of this series of articles are to use each other's results, so I continue to develop this spirit and use a ready-made JavaScript library for performance testing. This Test is called SlickSpeed Selectors Test (see references), which is very suitable for my needs. It compares jQuery 1.2.6 (the latest version when writing this article) with four other popular JavaScript libraries (MooTools, Prototype, YUI, and Dojo. Then, it runs 40 selection tests on pages with thousands of page elements. In other words, this is the best performance test I want. I will use this test in the first performance test analysis.

Comparison of JavaScript library Performance

For the first performance test, I used a 2.2 GHz processor, 2 GB RAM, and Firefox 3.0.3 (very important ). I run five tests under this configuration. Figure 1 shows the average results of five tests.

Figure 1. Performance Test Result 1

What conclusions can be drawn from the first test? Now we only focus on the overall results, rather than each test. After obtaining some general conclusions, I will focus on each test later in this article.

◆ Conclusion 1: YUI slowed down to the extreme!

Yes, YUI is really slow compared with other libraries. Carefully check each test to find out why the library is very slow when selecting element groups (such as "p,. This library is the worst choice for pages that require good performance.

◆ Conclusion 2: Mootools, jQuery, and Dojo run almost the same time.

Compared with the other two libraries, these three libraries are very fast, and Dojo is the fastest among them, while jQuery is the slowest. But globally, the speed between them is very close.

◆ Conclusion 3: The relative differences between these databases are obvious.

The relative difference between the fastest time and the slowest time to determine the speed. You can see that the relative difference is 332%. This difference is relatively large, which indicates that selecting different JavaScript libraries will affect the performance when using Firefox.

But remember, these conclusions are only based on the results of one browser. This is based on Firefox 3.0.3. Now let's go to the next section and I will run the test on different browsers.

JavaScript performance on different browsers

Many junior Web programmers think it is incredible to run JavaScript in different browsers with different results (different performance and time. Although this is a setback for junior Web programmers (they are worried about writing additional code to handle different browsers ), however, experienced Web programmers know how to deal with this problem early in Netscape and Internet Explorer. This is also a highlight of using JavaScript libraries, as they all handle many or most browser differences with caution.

The main reason for the difference in JavaScript speed is that each browser uses its own JavaScript Engine. The JavaScript engine is a local code used to parse JavaScript and execute it based on Web applications. Therefore, the execution speed of JavaScript is directly related to the underlying engine. In recent months, many browser companies have been paying more and more attention to the performance of their browsers. As JavaScript on some pages becomes increasingly complex, the speed of the JavaScript engine can affect the response speed of Web applications. So when companies like Google and Firefox talk about their JavaScript Engines, they talk about the next generation of engines 10 times faster. This is very important for Web applications, because the speed of the underlying JavaScript Engine directly leads to the emergence of more complex Web applications.

Now, you know that the JavaScript engine is a factor in the speed of JavaScript Execution, so let's run the test we just ran on Firefox on different browsers, and try to find out the impact of different engines on JavaScript performance. Remember, this test is the same as the one I ran earlier on Firefox, so everything except the JavaScript engine is the same. Figure 2 shows the test results.

Figure 2. Performance Test Result 2

After reading these test results, you first notice that the time difference between running these browsers is very large. Running jQuery on Chrome 1.0 takes 168 milliseconds, while running on IE6 takes 1728 seconds. This is an incredible time difference! The jQuery selection method runs 10 times slower on IE6 than on Chrome! Now, you know why Google likes to boast about its JavaScript Engine and why some browsers seldom talk about its JavaScript Engine. These differences are large.

You should note that jQuery runs at 3rd bits on Firefox or some other browsers, and 1st bits on other browsers. In fact, these results indicate that, based on performance classification, these libraries can be divided into two groups, regardless of the browser used. Mootools, Dojo, and jQuery usually belong to one group, while Prototype and YUI belong to another group. The former group is much faster than the latter group.

Performance test conclusion

I think all these conclusions need to be elaborated in a specific section, because they are very important to JavaScript developers. I still try to summarize the above performance results, and have not forgotten that this article is based on jQuery.

◆ Conclusion 1: Mootools, jQuery, and Dojo have no difference in performance.

Check their tests on all five browsers. After calculating the average value, you can see that the performance of these three libraries is almost the same. (Ideally, we should look into the market share of each browser. However, it is difficult to adjust these numbers because the site using the JavaScript library is not necessarily accessed by the "average user ).

Figure 3. Average value of test results (Mootools, jQuery, and Dojo)

◆ Conclusion 2: Prototype And YUI are slow in performance.

Let's take a look at the comparison between the test results of these two libraries in five browsers and jQuery. After calculating their average values, you can find the performance differences between the two databases. They are 300% slower than jQuery on average in any browser.

Figure 4. Average value of test results (jQuery, Prototype, and YUI)

◆ Conclusion 3: If you have high performance requirements, choose Mootools, jQuery, and Dojo to obtain almost the same performance.

Based on the average value, selecting one of the three databases gives you more performance advantages than selecting one of the other two databases. From the average value obtained by running on all browsers, their performance is equivalent. Therefore, when you select the JavaScript library, selecting one of the three libraries will not be wrong.

◆ Conclusion 4: If you have high performance requirements, do not select Prototype or YUI.

If the JavaScript library is required to have high performance, or you plan to create a large JavaScript project, you should not choose one of the two libraries. The performance of these two databases is much inferior to that of other databases.

◆ Conclusion 5: the browser's performance impact is 9 times that of the JavaScript library.

I think this is the most important conclusion in all conclusions of this article. You can discuss which JavaScript library is the fastest in a specific situation, but the final impact is very small! For performance, the browser has a much greater impact than the library itself. Looking back at the average values of 1, 3, and 4, you can see that among the three fastest libraries, the slowest one (Dojo) is only 15% slower than the fastest one (jQuery. Only 15%! However, you can see the speed difference between jQuery's fastest browser (Chrome 1.0) and the slowest browser (IE6). The difference is 1000%! From the two figures, 15% is insignificant for 1000%. So far, the fastest debate on which of the three fastest databases can be stopped, because they have little impact on the final results.

◆ Conclusion 6: if JavaScript performance is important to Web applications and you can control which browser to choose, select the fastest browser!

In some cases, you can control which browser to use to access the site. If you can control which browser to use, you are lucky. I met such a lucky project. In this case, if you have a complex JavaScript Application or you think performance is important, you should control the browser that users use to access Web applications. These tests clearly show the impact of the browser. If your JavaScript Application has a high access volume, you can tell users that they must use Chrome.

◆ Conclusion 7: if you cannot control your browser, you should first consider the performance of IE6.

However, in most cases, we cannot control the browser users use to access our site. However, most users use IE 6 to browse the Web page. In tests so far, the browser's JavaScript engine is the slowest. However, since there are still a large number of users using it, and a good Web design needs to "adapt to the worst case", this means you can consider designing your JavaScript Application Based on IE6.