In many ways, it is always recommended that our JavaScript script be loaded at the end of the Web page, and in the form of external files, but the fact is not so, the plug-in file is best not too much, the script structure code itself is worth thinking about the problem. We need to rethink the execution of scripts we write and incorporate better JavaScript development ideas into our development.
After reading a few articles about the performance optimizations of JavaScript and jquery, it dawned on me that many of the code structure optimizations I've done in the past have just made Wushi look bloated, and redesigned the structure of the scripting code, no matter what, and the Web page opens up more smoothly.
1. Loading and execution
Loading is the browser fetch code, and execution is the browser parsing script and manipulating the DOM. I previously overlooked the difference between loading and executing a problem, loading less does not necessarily improve speed and performance , only the execution ability to determine the speed of the Web page, of course, loading really accounted for a part of the factor. In the past, we used to put almost all the script code in the form of a file plug-in, and the JavaScript file at the end of the page to load. I would like to say that one, not all scripts to use the file plug -In, two, not all of them should be placed at the bottom of the page . Wushi because it is compatible with HTML5, HTML5 related code must be loaded in the header. Now that the entire page is going to use the jquery library, I've merged the jquery library with the Modernizr and loaded it with a file on the head.
There is a point in JavaScript and jquery-Optimized articles: We can declare function variables in advance, which can be used at any time during page loading, provided that the object must already be loaded. For example, we want a button button#show click on the prompt page is not loaded, we first define a function in the head, after this <button> is a script code, of course, the hint of code too little, we do not have to define the head first.
The script that follows the loading of the document is very obvious to the immediate effect on the Web page , and for a very simple example, we want a certain set of <a> tags to be clicked without entering a new URL, but rather triggering other actions, then we are directly in this group <a > After the end, give them the effect of click,function (e) {E.preventdefault (), you imagine, if you write this code in the external JS document at the bottom of the document, it is more unfortunate to write in the $ (document). Ready (), Then this code first needs to load the page into the document, the document loaded into the code, while the page code has been loaded complete, can be executed preventdefault (), if your page code is very long, in the page loaded out of <a> without loading to this JS file, click <a> a new jump will appear.
Another problem is that the plug-in JS document to load, need a server request, although the current browser support of the number of requests multiplied, but if thousands of people to visit the site, the request to the server caused by the pressure is also conceivable, the request of the time, if counted, It may save some time to include the script directly at the bottom of the page.
2. The function defined by the head will not be executed until it is invoked.
We set up some JS libraries on the head, but they are not executed immediately ( in layman's words it is executed only when it is used ), knowing that execution takes time, and that storing these functions into memory is less time . The sum of the time we load these functions and the amount of time stored in memory may not exceed the time of execution. You can put all of these functions in a plug-in document at the bottom of the page, but you'll encounter loading problems like the one above.
3. Memory variables are much faster than getting DOM nodes
I used to get the length of an array and use it in a for loop, such as for ($i = 0; $i < $a. length; $i + +), and now notice that $a. Length is calculated once, not once in a loop, and the optimized for ($i = 0,$ Len = $a. Length, $i < $len, $i + +) will be much better, store the value obtained by $a.length in the $len variable, only one length operation, not saving a lot of time and space. It is because of this idea that we need to re-examine our own code, whether we can put more of this to find or manipulate the DOM in a variable.
4. Hide and move
If you want your page to load faster, relocation is another set of ideas, do not put code loaded from other servers in the middle of the page, that will make the Web card in that place, the external loading of the code is placed in the bottom of the page, hidden, and so on, so that the page can be displayed normally later, and move them to where they should be. Very simple example is Google ads, if the page at the beginning of the article load Google ads, if affected by the speed of the Web page will be stuck in this place, until the ad code to create a DOM node after the end of the article to show the content. Moving the idea is to leave a piece in the beginning of the article and the same size of the ad area (not even stay, increase the effect), with a small picture or article tips to load ads, the ads loaded in the back, and so loaded, with appendto or other mobile code, the ads moved past.
Through the method of relocation, the Ukrainian help to solve the comment box loading slow caused by the shortcomings of the page display is not complete.
5, the use of different language optimization ideas to other places
We can put some ideas into PHP, the direct access to the data is faster than through the various function calls, not necessarily to use the function, although that is more beautiful. Once the data is taken out of the database, stored in a variable, and then sorted or filtered by the values in the PHP program's processing variables. Save the data in a variable first, and you can reuse it.
Performance optimization is a Web page open speed and execution efficiency of a work, in WordPress, many articles on the network to give advice, but a lot of suggestions in a sense is only for access, and does not involve loading and execution. This is perhaps what we should consider later.
This article is reproduced from: Wushi > Technology Center > Website Performance > Rethinking on the structure of Web script code
Text link: Rethinking on the structure of Web script code
Rethinking about the structure of Web script code