JavaScript time Consumption--excerpt

Time consumption of JavaScript2017-12-24 Dwqs The front-end thing .

As our website relies more and more on JavaScript, we sometimes (unintentionally) transfer some (time-consuming) things in a way that is not easy to trace. In this article, I'll show you some ways to get your website to load quickly and interactively on your mobile device.

Summary: Less code = less parsing/compiling (time) + less transmission (time) + less decompression (time)

Internet

When most developers consider the time consumption of JavaScript, they will first consider the JavaScript download and execution consumption. The more bytes The script transmits, the longer it takes for the user to connect more slowly.

Even in the developed countries, this is a problem to face, because the user's effective network connection type is not necessarily 3G, 4G or Wifi. You can connect to the coffee shop's WiFi, or you may be connected to a cellular hotspot on the previous 2G network.

As a result, developers need to find ways to reduce JavaScript transmission time on the network. I offer some reference ways to do this:

• With code splitting, only the code required by the user is transferred.

• Reduce code volume (use uglify for ES5, babel-minify or uglify-es for ES2015)

• Compress the code (you can use Brotli ~ q11, Zopfli, or gzip). Brotli is better than gzip on compression ratio. This approach helps the Certsimple website reduce script volume by 17% and helps LinkedIn save 4% of the script load time.

• Remove the useless code. You can view the code coverage situation through DevTools. For code separation, you can learn about advanced optimizations such as tree-shaking, Closure compiler, and more. For public libraries, you can use some code optimization plug-ins, such as the Code optimization plug-in for Lodash Lodash-babel-plugin, which can be used for optimized plug-ins contextreplacementplugin like Moment.js class libraries. In addition, use babel-preset-env & browserlist to avoid compiling features that are already supported by modern browsers. Some of the more advanced developers may be careful to analyze Webpack bundles to help identify unnecessary dependencies.

• Optimizes network transport through caching. max-agecache scripts by and by Etag , reducing the transmission of bytes. Service Worker Caching technology enables your application to have network resiliency and the ability to use features like the V8 code cache. At the same time, it is also possible to understand the file hash name for long-term caching.

Parse/Compile

After the script is downloaded, JavaScript is the most time-consuming place for the JS engine to parse/compile the code. In the performance panel of Chrome DevTools, the parsing and compiling of JS is the Scripting time yellow part.

More accurate parse/compile times can be seen from the Bottom-up/call Tree.

But why is that so?

Taking a long time to parse/compile the code can severely delay user interaction on the site. The more scripts that are transferred, the more time it takes to parse/compile the code before the site can interact.

Browsers also spend a lot of time dealing with images of the same size (images still need to be decoded) compared to scripts. But on most mobile devices, JS is more likely to have a negative impact on the interactivity of the page.

Context is important when we talk about script parsing and compiling slowly-we're talking about ordinary mobile devices. The average user's phone is configured with a low-provisioned CPU and GPU, possibly due to the memory limitations of the phone, and there is no L2/L3 cache setting.

In the JavaScript performance article, I noticed that it took a different time to parse approximately 1M of the extracted script files on low-provisioned phones and high-provisioned phones. There is a 2~5x time difference between the fastest-resolving mobile phone and the average mobile phone in the market.

What about the different configurations of mobile phone access CNN.com?

Compared to JS, which takes about 13s to parse/compile a CNN website with a regular mobile phone (Moto G4), the IPhone 8 is only required to offer 4s of time. This can significantly affect the speed at which users fully interact with the site.

This highlights the importance of testing ordinary mobile devices (such as Moto G4) rather than just the mobile device in your pocket. However, contextual relationships are also important: optimize the hardware devices and network environment for site users.

Drill down into the types of mobile devices that real users use to access your site, so they can understand their real CPU/GPU and other hardware constraints.

On the other hand, we also need to reflect on whether we really transmit too many scripts?

Through the HTTP Archive analysis about the previous 500K website on the mobile device transfer script size, you can find that 50% of the site needs to occupy 14s, users can interact with the site, but these sites only use 4s time to parse and compile JS.

It's not surprising that in the time it takes to get and handle JS and other resources, users need to wait for a while before the page can interact, but we can do better here.

Removing non-critical scripts on the page not only reduces transmission time, but also reduces CPU parsing/compilation time and potential memory overhead, which can increase the speed at which pages can interact.

Execution time

Not only does the parsing and compiling of the script take time, but the execution of the script also takes time. Long execution times also delay the user's interaction with the site.

If the script executes more than 50ms, the latency of the interactive time will be the sum of the time it takes the script to download, compile, and execute the script. --Alex Russell

To reduce the execution time of a script, you can split the script into small chunks to avoid locking the main thread. Consider whether you can reduce the amount of work that the script needs to do during execution, and if the workload is large, divide the script into small chunks to decompose the workload to increase the speed at which the page can interact.

A model to reduce the cost of JavaScript delivery

When you try to reduce JavaScript parsing/compiling and network transfer time, you can also try to reduce the cost of JavaScript delivery by routing-based code splitting or PRPL mode.

PRPL is a pattern that optimizes page interaction through code splitting and caching:

With V8 's Runtime call Stats, we can analyze the load times of some popular mobile stations and PWA apps. As you can see, the time required for script parsing (the orange part) is the most time-consuming part of page loading:

Other consumption

In addition to the above, JavaScript can affect page performance in the following ways:

• Memory. Due to GC (garbage collection), the page may appear frequently flashing or stuck. When the browser reclaims memory, JS execution will be paused, so the frequency of JS suspended execution and the frequency of the browser to reclaim memory is positive correlation, so you need to avoid memory leaks and frequent memory recycling caused by JS execution pause, maintain the smoothness of the page.

• During run time, long script execution blocks the main thread and causes the page to not respond. Splitting the workload of a script into smaller chunks to perform (using requestAnimationFrame() or requestIdleCallback() scheduling tasks) minimizes responsiveness.

Progressive Bootstrapping (Progressive boot)

Because the cost of optimizing interactivity is high, many sites consider optimizing the visibility of content. When JavaScript Bundles is large, some developers take the service-side rendering to reduce the white-screen time (first paint times), and then "Upgrade" to event processing when the JS process is complete.

But this way is also time consuming: 1) usually sends a large HTML file as a response, 2) the page may only be partially interactive until the JavaScript finishes processing.

Thus gradual guidance may be a better way. Browse please request a minimized feature page (consisting only of the html/js/css required by the current route), and when there are more resource requests, the app can lazily load the resources and then gradually unlock more features.

Loading code proportionate to what's in view is the Holy Grail. PRPL and Progressive Bootstrapping is patterns that can help accomplish this.

Reference

• The cost of JavaScript

• JavaScript Start-up Performance

• Solving the Web performance crisis

• Can you afford it? Real-world Performance Budgets

• Performance Futures

JavaScript time Consumption--excerpt