JavaScript performance optimization tips: javascript Performance Optimization

JavaScript performance optimization tips: javascript Performance Optimization

(Click the public account at the top of the page to follow it quickly)

Ivan Č uri-control

Http://www.cnblogs.com/powertoolsteam/p/javascript-performance-optimization.html

As the most common literal scripting language, JavaScript has been widely used in Web application development. To improve the performance of Web applications, it is a good choice to start from the performance optimization of JavaScript.

This article explains the JavaScript performance optimization skills from the loading, context, parsing, compilation, execution, and bundling aspects, so that more front-end developers can master this knowledge.

What is high-performance JavaScript code?

Although there is no absolute definition of high-performance code, there is a user-centered performance model that can be used as a reference: RAIL model.

Response

If your application can respond to user operations within 100 milliseconds, the user will regard the response as immediate. This applies to clickable elements and does not apply to scroll or drag operations.

Animation

On a 60Hz display, we want to have 60 frames per second for animation and scrolling. In this case, each frame is about 16 ms. In this 16 Ms period, only 8-10 ms is actually used to complete all the work, and the rest of the time is occupied by the internal and other differences of the browser.

Idle Work

If you have a task that takes a long time and requires continuous running, make sure that it is divided into small blocks to allow the main thread to respond to user input operations. User input with a task delay of more than 50 ms should not appear.

Load

Page loading should be completed in 1000 milliseconds. On mobile devices, this is a hard target, because it involves page interaction, not just rendering and scrolling on the screen.

Modern load Best Practices (Chrome Dev Summit 2017) (https://www.youtube.com/watch? V = _ srJ7eHS3IM)

Let's take a look at some statistics:

• If the loading time of a mobile website exceeds three seconds, 53% of users will stop accessing the website.

• 50% of users want to complete page loading in less than 2 seconds

• It takes more than 10 seconds for 77% of mobile websites to load 3G networks.

• 19 seconds is the average loading time of mobile sites on 3G networks

Code content

You may have noticed that the biggest bottleneck is the time required to load the website. Specifically, it refers to the time when JavaScript is downloaded, parsed, compiled, and executed. In addition to loading fewer JavaScript files or loading more flexibly, it seems that there is no other way.

In addition to starting a website, how does JavaScript code actually work?

Before optimizing the code, consider the content you are currently building. Are you creating a framework or a VDOM library? Does your code need to perform thousands of operations per second? Are you working on a library with strict time requirements to process user input and/or animations? If not, you need to shift your time and energy to more influential places.

Writing high-performance code is not that important, because it usually has no impact on macro plans. 50 k ops/s sounds better than 1 k ops/s, but in most cases the overall time will not change.

Parse, compile, and execute

Basically, most JavaScript performance problems do not come from running the Code itself, but are a series of steps that must be taken before the Code starts to be executed.

Here we will discuss the issue of abstraction layers. Most of the code running on the computer is compiled in binary format. This means that, except for all operating system-level abstractions, code can be run locally on the hardware without any preparation.

JavaScript code is not pre-compiled and is readable in the browser.

The JavaScript code will be parsed first, that is, read and converted into a structure that can be used to compile the computer index, then compiled into bytecode, and finally compiled into a machine code for device/browser execution.

Another important aspect is that JavaScript is single-threaded and runs on the main thread of the browser. This means that only one process can be run at a time. If your DevTools performance timeline is filled with yellow peaks and the CPU usage reaches 100%, frame loss will occur. This is a common and annoying situation for rolling operations.

Before JavaScript code is run, you need to complete all the parsing, compilation, and execution work. In the ChromeV8 engine, parsing and compilation accounts for about 50% of the total JavaScript execution time.

Therefore, we should understand two things in this section:

1. Although the time length and package size of JavaScript parsing are not completely linear, the less JavaScript to be processed, the less time it takes.

2. Every JavaScript framework you use (React, Vue, Angular, Preact ...) Is another abstraction level (unless it is a pre-compiled ). This not only increases the size of your package, but also slows down your code because you are not directly communicating with your browser.

Some methods can alleviate this situation, such as using service workers to execute some work in another thread in the background, or using asm. js to compile code that is easier to compile machine commands.

All we can do is avoid using JavaScript animation libraries. These libraries are used only when regular CSS conversions and animations are completely unfeasible.

Even if these JavaScript animation libraries use CSS conversion, merging attributes, and requestAnimationFrame (), they still run on the main JavaScript thread. Basically, these libraries use inline styles to access the DOM every 16 Ms. Make sure that all JavaScript is completed within 8 ms of each frame to keep the animation smooth.

On the other hand, CSS animation and conversion will run in the main thread. If they can be executed efficiently, the re-layout and re-arrangement can be avoided.

Considering that most animations are running during loading or user interaction, this can provide a very important adjustment space for your web applications.

Web Animations API is an upcoming feature set that can execute high-performance JavaScript animation without the main thread. However, currently, CSS conversion and other technologies need to be used.

Bundle size is very important

Now it is no longer in

There are multiple end tags

In this way, you can use a small amount of JavaScript, which means that your project may no longer need the entire Lodash library. If you must use a JavaScript library, you can also consider using something other than React, such as Preact or HyperHTML, which is only 1/20 of the React size.

Webpack 3 has a magical function called code segmentation and dynamic import. Instead of bundling all JavaScript modules into an app. js package, it uses the import () syntax to automatically split the code and load it asynchronously.

You do not need to use frameworks, components, and client routing to achieve these benefits. You only need to write the following content in the main JavaScript file:

If (document. querySelector ('. mega-widget ')){

Import ('./mega-widget ');

}

If your application needs to use this widget on the page, it dynamically loads the required support code.

In addition, Webpack needs to run time and inject it into all. js files generated by it. If you use the commonChunks plug-in, you can use the following content to extract the runtime to the Chunk:

New webpack. optimize. CommonsChunkPlugin ({

Name: 'runtime ',

}),

Make sure that the Webpack has been loaded before the main JavaScript package, the running time of all other chunks will be stripped to their respective files, which is also known as runtime. js. For example:

<Script src = "runtime. js">

<Script src = "main-bundle.js">

Then, compile the code and the polyfills part. If you are writing modern JavaScript code (ES6 +), you can use Babel to convert it to ES5 compatible code. Compared with the native ES6 + code, compilation not only increases the file size, but also increases complexity, and often causes performance degradation.

In addition, you may also use the babel-polyfill software package and whatwg-fetch to fix missing features in earlier browsers. Therefore, if you are writing async/await, you also need to use the regenerator-runtime generator to compile the package.

The problem is that you have added nearly KB of content to the JavaScript software package. This is not only a huge file, but also a huge parsing and execution cost, so that you can support older browsers.

One way is to create two independent bundle and load them according to actual conditions. With the help of Babel-preset-env, the babel conversion compiler makes it easier to handle both the new and old browsers.

A non-standard but effective method is to put the following content in an inline script:

(Function (){

Try {

New Function ('async' () => {}')();

} Catch (error ){

// Create script tag pointing to legacy-bundle.js;

Return;

}

// Create script tag pointing to modern-bundle.js ;;

})();

If the browser cannot recognize the async function, it will be considered an old version of the browser, and the polyfill package will be used. If it can be identified, the user will be processed by modern browsers.

Conclusion

To speed up the Website, you must ensure that the website can quickly load JavaScript files for fast interaction. Your JavaScript code should be divided into smaller, manageable bundle and asynchronously loaded as much as possible. On the server side, make sure that HTTP 2.0 is enabled for faster parallel transmission and gzip/Brotli compression, greatly reducing the JavaScript transfer size.

I think this article is helpful to you? Please share it with more people

Follow the "front-end overview" to improve front-end skills