Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how to tune the performance of jQuery". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Create a performance test

The first step in performance testing is to create an appropriate performance test. The most important role that jQuery and other JavaScript libraries play in the code is to use selection to find specific page elements. I focused on this in my initial performance testing. A good performance test should really take advantage of the full power of the JavaScript library, testing it with pages containing thousands of page elements. I should run all the selection methods so that I can see which selection method is the fastest and which is the slowest. The test should know the correct answer in advance to determine whether the JavaScript library performs the selection method correctly. Finally, all the results should be displayed, along with the elapsed time, so that I can compare all the libraries.

I almost overlooked the most important aspect of performance testing: it should be free. After all, the unwritten rule of this series of articles is to take advantage of each other's work, so I continue to carry forward this spirit and use a ready-made JavaScript library for performance testing here. This test is called SlickSpeed Selectors Test (see Resources), and it suits my needs very well. It compares jQuery 1.2.6 (the latest version at the time of this writing) with four other popular JavaScript libraries (MooTools, Prototype, YUI, and Dojo). It then runs 40 selection tests using a page 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.

Compare the performance of JavaScript libraries

For the first performance test, I used a running environment of 2.2 GHz processors, 2 GB RAM, and Firefox 3.0.3 (very important). I ran five tests in this configuration, and figure 1 shows the average results of five runs.

Figure 1. Results of performance Test 1

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

◆ concluded that 1:YUI is extremely slow!

Yes, YUI is really slow compared to other libraries. Take a closer look at each test to find out why the library is very slow in selecting groups of elements (such as "p, a"). This library is the worst choice for pages that require good performance.

◆ concluded that the running times of 2:Mootools, jQuery and Dojo are almost the same.

Compared with the other two libraries, these three libraries are very fast, and Dojo is the fastest of them, while jQuery is the slowest. But from the overall point of view, the speed between them is very close.

◆ conclusion 3: the relative difference between these libraries is quite obvious.

Measure the fastest time / slowest time to determine the relative difference in speed, and you can see that the relative difference is 332%. This difference is quite large, which indicates that choosing different JavaScript libraries when using Firefox will have an impact on performance.

Keep in mind, however, that these conclusions are based on the results of only one browser. This is based on the conclusion reached by Firefox 3.0.3. Now let's move on to the next section, where I'll run the test on different browsers.

JavaScript performance on different browsers

Many junior Web programmers find it inconceivable that different browsers run JavaScript with different results (performance and time are different). Although this is a setback for junior Web programmers (they worry about writing extra code to deal with different browsers), experienced Web programmers knew how to deal with the problem early on in Netscape and Internet Explorer. This is also a highlight of using JavaScript libraries, as they carefully handle many or most of the browser differences.

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

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

Figure 2. Results of performance Test 2

After reading these test results, the first thing you notice is that there is a big time difference between running in these browsers. It takes 168ms to run jQuery on Chrome 1.0 and 1728 seconds to run on IE6. 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 rarely introduce their own JavaScript engine. These differences are quite large.

You should notice that jQuery ranks third in speed when running on Firefox or some other browsers, and No. 1 in other browsers. In fact, these results show that these libraries can be divided into two groups according to performance, regardless of the browser used. Mootools, Dojo and jQuery usually belong to one group, while Prototype and YUI belong to another group, and the former group is much faster than the latter group.

Performance test conclusion

I think all of these conclusions need to be addressed in a special section because they are very important to JavaScript developers. I'm still trying to summarize the performance results above, and I haven't forgotten that this article is about jQuery.

◆ concluded that 1:Mootools, jQuery and Dojo are neck and neck in performance.

Looking at their tests on all five browsers, after averaging, you can see that the performance of the three libraries is almost the same. Ideally, we should investigate the market share of each browser. But adjusting these numbers is difficult because sites that use the JavaScript library are not necessarily accessed by "average users").

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

◆ concluded that the performance of 2:Prototype and YUI is very slow.

Take a look at the comparison of the test results of the two libraries in five browsers with jQuery. After averaging them, you can see how different the performance of the two libraries is. They are on average 300% slower than jQuery in any browser.

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

◆ conclusion 3: if the performance requirements are relatively high, choose one of Mootools, jQuery and Dojo to get almost the same performance.

Based on the above average, choosing one of these three libraries can gain more performance advantages than choosing one of the other two libraries. Judging from the average of running on all browsers, their performance is equal. Therefore, when you choose JavaScript libraries, there is nothing wrong with choosing one of these three libraries.

◆ conclusion 4: if the performance requirements are relatively high, do not choose Prototype or YUI.

If you require high performance JavaScript libraries, or if you plan to create a large JavaScript project, you should not choose either of these two libraries. The performance of these two libraries is much lower than that of the others.

◆ conclusion 5: the impact of browsers on performance is 9 times greater than that of JavaScript libraries.

I think this is the most important conclusion of all the conclusions in this paper. You can discuss which JavaScript library is the fastest in certain situations, but its ultimate impact is minimal! In terms of performance, the impact of the browser is much greater than the library itself. Looking back at the average of figures 3 and 4, you can see that of the three fastest libraries, the slowest one (Dojo) is only 15% slower than the fastest one (jQuery). Only 15%! However, if you look at the difference between the speed of jQuery running on the fastest browser (Chrome 1.0) and the slowest browser (IE6), the difference is 1000%! Judging from these two figures, 15% is negligible to 1000%. At this point, the debate about which of the three faster libraries is the fastest can stop, because they have little impact on the final result.

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

In some cases, you can control which browser to use to access the site. You are lucky if you can control which browser to use. I came across such a lucky project. In this case, if you have a complex JavaScript application, or if you think performance is important, you should control the browser that users use to access the Web application. These tests have clearly shown the impact of browsers. If your JavaScript application is heavily visited, you can tell users that they must use Chrome.

◆ conclusion 7: if you can't control the browser the user uses, consider the performance on IE6 first.

However, in most cases, we have no control over what browser users use to access our site. However, a large number of users use IE 6 to browse the web. This browser has the slowest JavaScript engine in the tests so far. But because it is still used by a large number of users, and good Web design needs to "adapt to the worst," this means that you can consider designing your JavaScript application based on IE6.

JQuery performance tuning

The second part of this article will discuss how to improve the performance of jQuery code. The previous section shows that choosing jQuery as the JavaScript library points in the right performance direction. If you are reading this article, you may already be using jQuery. But the speed of the underlying library does not mean that all the code you write is of high quality. If you don't look back and think about what to do, using jQuery will still produce very slow code.

This section introduces some knowledge of performance tuning and best practices for improving the speed of jQuery code.

Tip # 1-search through ID instead of CLASS as much as possible

Two common search techniques in jQuery code are searching through the element's ID and searching through the element's CLASS. Before using the regular JavaScript JavaScript library, it was fairly simple to find page elements through ID. You can use the getElementById () method to find elements quickly. But without the JavaScript library, it will be more difficult to find CLASS, and if necessary, we will help by coding in its ID. When using jQuery, searching for CLASS is as simple as searching for ID on a page, so the two searches seem to be interchangeable. However, this is not the case. Searching through ID is much faster than searching through CLASS. When searching through ID, jQuery actually uses only the built-in getElementById () method, but when searching through CLASS, you must traverse all the elements on the page to find a match. Obviously, searching through CLASS results in a very slow response when the page is larger and more complex, while searching through ID does not slow down as the page gets larger.

The jQuery performance test results you ran earlier support this data. Let's look at each test to see what we need to pay attention to in the jQuery code. In this example, look at the test results when searching through ID and CLASS, respectively (figure 5).

Figure 5. Comparison between ID search and CLASS search

These tests are different, but the data they produce show that searching through ID is much faster than searching through CLASS. How does this affect jQuery code? Keep these tips in mind when writing a search: if you can choose both CLASS and ID, you usually choose ID. If you need to search for certain elements in your code, be sure to assign them an ID.

Listing 1 shows an actual jQuery test that you can run on your machine to verify:

Listing 1. CLASS and ID

$(document) .ready (function () {console.info ("Start Test"); var d = new Date (); console.info (d.getSeconds () + "+ d.getMilliseconds ()); var testBody ="; for (var item0; I)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.