Front-End performance optimization (JavaScript supplemental) __java

JavaScript File loading

Managing JavaScript code in your browser is a tricky problem because code execution blocks browsers, such as drawing the interface. Each time you encounter a <script> tag, the browser stops to wait for the code to download and execute, and then I continue to work on the other parts. There are several ways to reduce the performance impact of JavaScript files by placing the JS file at the bottom of the page

Place all <script> labels at the bottom of the page, immediately above the body close tag </body>. This ensures that the page finishes parsing The JS file before the script is run

To package JS files, the less the page <script> label, the faster the loading speed of the page, and the quicker the response. Both external script files and introverted code. Use non-blocking downloads to add defer properties to <script> tags dynamically create <script> element, use it to download and execute code with XHR object to download code, and inject it into the page. data access Four ways to access

In JavaScript, the data storage location can have a significant impact on the overall code performance, with four types of data access: Direct, variable, array, object member, which has different performance

Direct and local variable access is fast, while array items and object members require longer time scope chains and closure access speeds

When you access a variable inside a function, it looks up through the scope chain until it is found, which means that the longer the scope chain is, the longer the average lookup time will be. As with and try-catch increase the length of the scope chain, it also degrades performance. It can be learned that accessing global variables is slow because they access the last loop of the scope chain in the prototype chain

When accessing the properties of an object, we sometimes need to traverse the prototype chain, which means that the longer the prototype chain, the lower the average efficiency of the lookup element, the deeper the prototype in the prototype chain, and the slower the access DOM

When the browser finishes downloading all of the HTML, JavaScript, CSS, and pictures, it parses the file and creates two internal data structures: a DOM tree and a rendering tree

Each DOM tree node that needs to be displayed has at least one node in the Render tree (hidden DOM nodes naturally do not have nodes in the render tree), the dots on the render tree are called boxes or boxes, and the page elements are defined as a box with padding, margins, borders, and positions, according to the CSS model. Once the DOM tree and the render tree are constructed, the browser can draw the elements on the page.

When DOM changes affect the element's geometric properties (width and height), the browser needs to recalculate the element's geometry. If the change of this element affects other elements, the browser invalidates the affected part of the render tree and then reconstructs the rendering tree. This is the reflow (also called the re-typesetting). When the reflow is complete, the browser redraw the affected part of the screen in a redraw process

Of course not all DOM changes affect geometric attributes, such as changing the background color, which triggers the redraw

Reflow and redrawing are heavy operations that can cause the browser to block, so whenever possible, you need to avoid changing the change element size of the visible DOM element position by adding or removing the elements (border, padding, margin, height, width) Content Change original page render browser window change size query and refresh render tree changes

Because the amount of computation is related to each backflow, most browsers are optimized by a rendering queue. However, when you get some Dom properties with JavaScript, you will (involuntarily) force all render events in the queue to not complete before. For example, get the following properties:
* offsettop, Offsetleft, offsetwidth, offsetheight
* ScrollTop, ScrollLeft, ScrollWidth, scrollheight
* ClientTop, ClientLeft, ClientWidth, clientheight
* getComputedStyle () (in IE for currentstyle)

In order for these properties to return the correct values, the browser has to run all the render events in the render queue to ensure that the values are correct. So minimize access to these attributes if-else

When multiple if-else are executed, they retrieve each condition sequentially until all conditions have been retrieved or a matching condition has been retrieved. So we can organize the IF statement in the form of a tree, like the following code:

if (con = = 1) {return result1;}
else if (con = = 2) {return result2;}
else if (con = = 3) {return RESULT3;}
else if (con = = 4) {return RESULT4;}
else if (con = = 5) {return RESULT5;}
else if (con = = 6) {return result6;}
else if (con = = 7) {return result7;}
else if (con = = 8) {return result8;}
else if (con = = 9) {return result9;}

This code will then determine whether con equals 1,2,3,4,5,6,7,8,9, if it is 9, it will be judged 9 times, we can change it to:

if (Con <= 3) {
    if (con = = 1) {return result1;}
    else if (con = = 2) {return result2;}
    else {return RESULT3;}
} else if (Con > 3 && con <= 6) {
    if (con = = 4) {return RESULT4;}
    else if (con = = 5) {return RESULT5;}
    else {return result6;}
} else if (Con <= 9) {
    if (con = = 7) {return result7;}
    else if (con = = 8) {return result8;}
    else {return result9;}
}

In this way, we can reduce the number of lookups through the form of a three-pronged tree, such as looking for 9 times, respectively, to judge 0~3,3~6,6~9,7,8,9, only 6 times

If-else Besides the tree-like coding, there is an optimized place. Because of the logic of its sequential judgment, we can according to the probability, the probability of a relatively large judgment on the front, the probability of a small put in the back, which can also reduce the average lookup length switch

It turns out that in most cases the switch is faster than the if-else, but only when the number of conditional questions is large can it be significantly faster. If-else when conditions increase, the performance burden is higher than the switch, so it is recommended that you use switch. But switch is only used to judge several different discrete values, and there is no if-else can judge the value of discrete or range of flexibility to play table method

You can do it in the form of a table, put all the processing functions in an array, and then use the condition as a key, which is faster than both switch and if-else, and will not incur additional performance overhead when new conditions are applied.

Many algorithms are recursive implementations, because recursion triggers function calls more than once, and function calls are expensive (such as creating runtime contexts, running stacks, creating AO, replicating scope chains, destroying AO, 弾 stacks, and so on), try to turn recursion into loops. and the runtime stack in many browsers also have a depth limit, when the maximum depth of the runtime stack, browsers have their own processing methods, but are processed according to the wrong string different stitching method

There are many different ways to string stitching:
1. Use + Direct stitching
2. Use + + splicing
3. Use Array.join () stitching
4. Use String.Concat () stitching with plus sign stitching

When using + + + +, different browsers will do different degrees of optimization, if the IE7 and his previous browsers, the optimization does not do well, such as the following operations:

STR + + "one" + "two"

The following steps are actually performed:
1. Create a temporary variable in memory
2. Assign this temporary variable to "Onetow"
3. Temporary string and str stitching
4. Assigning results to Str

And if you change to the following:

STR + + "one"
str = "Two"

This avoids the creation of temporary strings and can speed up performance to a certain extent

Or use the following methods:

str = str + "One" + "two"

But if you use the following method:

str = "one" + str + "two"

You cannot determine if there is an optimization. Different browsers allocate memory differently, browsers other than IE try to extend the memory of the left-end string of the expression, and then simply handcuff the second string to its tail, creating a temporary string to store one{str original content}, resulting in reduced performance Browser optimization

Many browsers stitch together strings that are added sequentially at compile time to optimize the runtime, such as:

STR + + "one" + "two"

will be optimized into

str = "Onetwo"

string concatenation in ie7-

The use of + and + + in ie7-is slow, and array.join () is much faster, which is the only way to efficiently connect a large number of strings in ie7-browsers String.Concat

This approach is slow and try not to use regular expressions to optimize how regular expressions work

The regular expression processing follows several steps:
1. Compile
2. Set Start position
3. Matches the characters of each regular expression
4. Match success or failure

In the implementation of regular expressions, backtracking is the basic component. It's expensive and easy to get out of control. Backtracking is the only factor in the performance of regular expressions

When a regular expression is matched, the a marker point is established in a place with multiple branches, and then all branches are traversed from left to right, and if the branch fits, the next marker point is advanced, and if all branches do not conform, it goes back to the previous marker point and tries the other branches of the previous marker. When you try another branch of the previous marker, this marker will try to get back out of control all over again if needed

When a regular expression occupies the browser for a second, or longer, it is very good that backtracking is out of control, and the reason is likely to appear. * This non greedy match causes almost every character to be tried as a marker point

The solution to this type of problem is to point out, as specifically as possible, the form of character matching between the delimiters, or to use a forward-expression nested quantifier to cause performance degradation

Nested quantifiers can greatly increase the number of branches, such as a regular expression a+a+b obviously did not aa+b good, such as matching Aaaaaaaaaaaaaab, the former produces more branches than the latter a number of suggestions Focus on how to get the match to fail faster: Regular expressions are slow, often not because they are slow to succeed, but failure is slow, because failure will find all the cases with a simple, necessary character start: This can speed up the failure of the match, if the start character does not match, the following tag points will not be matched to write two times template, To repel the resources that follow them: when a character is able to overlap a contiguous subexpression, the path will have a significant positive value, so it needs to be materialized to reduce the number of points and narrow their scope: directly using the existing classes (such as \w,\d) in regular expressions is faster than using | Use non-capture groupings: Capturing grouping takes time and memory for recording back references, the use of non-capture groupings avoids the overhead of layering regular expressions, capturing the text of interest first, and then using the new regular expression to handle exposing the required characters, as simply as possible to determine which of the necessary characters to use the appropriate quantifiers, Greedy quantifiers and lazy quantifiers are different when it comes to matching the same string, and, given the correct premise, selecting quantifiers with fewer backtracking times can improve performance by assigning regular expressions to variables to reuse them. When regular expressions are created, they need to be compiled, and the compilation has the extra overhead of splitting complex regular expressions into simple fragments, avoiding too much work with one expression, and resolving UI thread-related with two or more regular expressions

The recommended JavaScript execution time is no more than 100ms (preferably 50ms), and the task can be decomposed by settimeout and SetInterval to join the UI thread. In fact this idea and JavaScript engine garbage collector's iterative process is similar to AJAX

When Ajax gets the data, you can use the post or Get method

If the request returns data without changing the server status indication, you should use get. Get requests are cached, and if you extract the same data multiple times, you can improve performance

And when the URL and the requested parameter length of more than 2048 characters to use post extraction data xhr (MXHR)

Multi-part XHR allows multiple resources to be obtained using an HTTP request, we can package the resources into a large string of specific delimiter delimiters, sent from the server to the client, JavaScript handles these large strings, and then resolves each resource according to its own type and information

It should be noted that Ajax is not cached in the browser, natural use of MXHR will not be cached, in some static resources to use this approach is not very good. But if you really need to get it every time, it's slower to send multiple requests. img Beacon

We can set src as a url,img element of a script file by creating an image object that we do not need to insert into the DOM, a form called an IMG Beacon

This approach applies to get requests, and the server does not have to return data to the browser after it obtains data

At the same time, we can listen to the server in the image Load event to successfully accept the data format XML: The support is broad but inefficient, and quite verbose JSON: compact, lightweight, faster parsing JSONP: Using JavaScript interpreter for parsing , the parsing speed is very fast, the amount of data is only a little bit more than JSON (function name and parentheses) HTML: No parsing, data verbose custom format: parsing, slow and error-prone, data length can be very short other do not use eval and its similar use literal amount to avoid duplication of work, When detecting the browser, save the first detection results to consider the bit operation using the original method, because they are written in C + + file preprocessing, compression (gzip), merging, Uglify try Cdn