Javascript price
As our sites are increasingly dependent on JavaScript, you have to pay for what we send to users. Sometimes the price is not visible at first sight. In this article, I will explain why it is useful to exercise a little discipline if you want to speed up loading and performance on mobile devices.
tl; dr: less code = less parsing / compilation + less transfer + less unpacking
When most developers think about the cost of javascript, they reflect on the download and execution times. Sending more bytes of javascript takes longer, the thinner the channel with the user.
')
This can be a problem even in the countries of the first world, since the effective type of network connection for a user is not necessarily 3G, 4G or WiFi. You can sit in a cafe with WiFi, but be connected to a hotspot via a cellular connection at a speed of 2G.
The cost of networking JavaScript can be reduced in the following ways:
Top tips on how to reduce the amount of javascript code sent to users
After downloading the JavaScript code, one of the main expenses becomes the time of parsing / compiling this code in the JS engine. In Chrome DevTools, parsing and compiling is part of the yellow Scripting time in the Performance panel.
On the Bottom-Up and Call Tree tabs you can see the exact time of parsing and compilation:
Panel Chrome DevTools Performance> Bottom-Up. When activated, the V8 Runtime Call Stats feature shows the time spent in the parsing and compiling steps.
But why is this important?
The high consumption of time for parsing and compiling code can greatly increase the delay in user interaction with the site. The more javascript code you submit, the longer the parsing and compilation phase will continue before the site begins to respond to user input.
If we compare it with JavaScript, then images of the same size also have numerous processing costs (they also need to be decoded!), But on the equipment of an average mobile phone, it’s rather JS that will negatively affect the interactivity of the page.
The javascript and image bytes consume resources differently. Images usually do not block the main stream and do not freeze the interface during decoding and rasterization. But JS can affect interactivity due to parsing, compiling and code execution.
When we talk about slow parsing and compilation, context is important - here we are talking about mid-range mobile phones. Ordinary users may have phones with slower CPUs and GPUs, without an L2 / L3 cache, and even with limited memory.
In the article “ JavaScript Startup Performance ”, I noted the parsing time of approximately 1 megabyte of unpacked (simple) JavaScript code on weak and powerful hardware. Between the fastest smartphones and the average difference is 2–5 times the parsing / compilation time.
The parsing time of a 1MB JavaScript bundle (~ 250 KB in gzip) on PCs and mobile devices of different classes. When taking into account the cost of parsing, you need to add the cost of unpacking a file of approximately 250 KB in size to a JS code of approximately 1 MB
What about real sites like CNN.com?
A modern iPhone 8 spends about 4 seconds on parsing / compiling CNN scripts, compared to ~ 13 seconds on an average phone (Moto G4) . This can significantly affect how much time passes before the user gets the opportunity to interact with the site.
The time of parsing on the Apple A11 Bionic chip compared to Snapdragon 617 in a regular Android smartphone
This shows the importance of testing on average hardware (like Moto G4), and not just on the phone that is in your pocket. But context is important: optimize for the devices and network conditions that your users have .
Analytics tools can show which mobile devices of a class to real users of your site. This makes it possible to understand the real limitations of the CPU / GPU.
Do we really ship too much javascript? Well maybe :)
HTTP Archive (top about 500 thousand sites) shows the use of JavaScript on mobile sites . And we see that 50% of sites need more than 14 seconds before they become interactive. These sites spend up to four seconds only to parse and compile JS.
If we also take into account the time needed to load and process JS and other resources, then it is not surprising that users leave the page without waiting for it to be “defrosted”. There is definitely room for improvement.
If you remove non-critical JavaScript from the pages, then you reduce download time, CPU-intensive parsing / compilation, and potential memory overflow. It will also help your pages get online more quickly.
Not only parsing and compilation have their price. Execution of JavaScript (execution of the code after parsing / compiling) is one of the operations that is performed in the main thread. Long execution times also affect how soon the user will be able to interact with your site.
To cope with this, it makes sense to transfer JavaScript to small fragments that will not capture the main stream for a long time. Learn how you can optimize script execution time.
If the goal is to reduce the time of parsing / compiling JavaScript and passing over the network, there are some useful techniques, such as route-based chunking and PRPL .
PRPL is a technique for optimizing interactivity by aggressively splitting code into fragments and caching:
Let's see what effect you can get.
We analyzed the load times of popular mobile sites and progressive web applications using the V8 Runtime Call Stats. As you can see, the parsing time (shown in orange) is a significant part of the time costs:
The Wego site uses PRPL, tries to keep a low parsing time on the routes and goes on interactivity very quickly. Many of the other sites listed use split code and performance budgets, trying to reduce JS costs.
JavaScript can affect performance in many ways:
Many sites optimize the visibility of content through interactivity. To quickly start rendering with large JavaScript bundles, developers sometimes use server-side rendering; then "update" the image when JavaScript is finally processed.
Be careful - everything has its price. You 1) essentially send a larger HTML response that may affect interactivity; 2) you can leave the user in a plausible "sinister valley", where in fact half of the interactivity is not available until the processing of JavaScript is completed.
Progressive bootstrapping may be a better option than this approach. Submit a minimally functional page (composed of only the most necessary HTML / JS / CSS for this pass). When other resources arrive, the application will lazily load them and unlock additional functionality.
Progressive Bootstrapping , illustration by Paul Lewis
Downloading the code according to what is displayed on the screen is a real grail. PRPL and progressive bootstrapping are techniques that help get closer to it.
Transmit size is critical for thin channels. The parsing time is important for devices with a weak CPU. We need to strive for minimum performance.
Different companies have achieved some success by introducing tight performance budgets at the time of transferring, parsing, and compiling JavaScript. See Alex Russell’s budget guide for mobile sites and apps, “ Can we afford it ?: Performance budgets in the real world .”
It is useful to consider what space JS leaves in our architectural decisions for application logic.
If you are creating a site for mobile devices, try using specific hardware, minimize JavaScript parsing / compilation time, and implement a performance budget so that your developers keep track of their JavaScript costs.
My performance on Chrome Dev Summit 2017 is about the price of javascript. Later, performance is analyzed using real sites like Pinterest and Tinder.
tl; dr: less code = less parsing / compilation + less transfer + less unpacking
Network
When most developers think about the cost of javascript, they reflect on the download and execution times. Sending more bytes of javascript takes longer, the thinner the channel with the user.
')
This can be a problem even in the countries of the first world, since the effective type of network connection for a user is not necessarily 3G, 4G or WiFi. You can sit in a cafe with WiFi, but be connected to a hotspot via a cellular connection at a speed of 2G.
The cost of networking JavaScript can be reduced in the following ways:
- Send only the code that the user needs . This will help the separation of the code into parts.
- Minification (Uglify for ES5, babel-minify or uglify-es for ES2015).
- Maximum compression (using Brotli ~ q11 , Zopfli or gzip). Brotli is superior to gzip in compression. At CertSimple, he reduced the JS code by 17% , and LinkedIn reduced the load time by 4% .
- Delete unused code . It can be revealed by the code coverage tool in DevTools . For removing unnecessary code, see tree-shaking , advanced Closure Compiler optimizations, and corresponding library plugins, such as lodash-babel-plugin or Webpack ContextReplacementPlugin for libraries like Moment.js. Use babel-preset-env and browserlist to avoid transpiling in modern browsers. Advanced developers can do a careful analysis of the Webpack bundles to remove unnecessary dependencies.
- Caching to reduce network traffic . Determine the optimal lifetime of the scripts (max-age) and provide validation tokens (ETag) in order not to transfer unchanged bytes. Caching service workers can make your application resilient in front of network failures and provide the desired access to features like caching code in V8 . Learn about long-term caching by hashing file names .
Top tips on how to reduce the amount of javascript code sent to users
Parsing / compiling
After downloading the JavaScript code, one of the main expenses becomes the time of parsing / compiling this code in the JS engine. In Chrome DevTools, parsing and compiling is part of the yellow Scripting time in the Performance panel.
On the Bottom-Up and Call Tree tabs you can see the exact time of parsing and compilation:
Panel Chrome DevTools Performance> Bottom-Up. When activated, the V8 Runtime Call Stats feature shows the time spent in the parsing and compiling steps.
But why is this important?
The high consumption of time for parsing and compiling code can greatly increase the delay in user interaction with the site. The more javascript code you submit, the longer the parsing and compilation phase will continue before the site begins to respond to user input.
If you compare by bytes, JavaScript processing is more expensive for a browser than an image or a font of equivalent size - Tom Dale
If we compare it with JavaScript, then images of the same size also have numerous processing costs (they also need to be decoded!), But on the equipment of an average mobile phone, it’s rather JS that will negatively affect the interactivity of the page.
The javascript and image bytes consume resources differently. Images usually do not block the main stream and do not freeze the interface during decoding and rasterization. But JS can affect interactivity due to parsing, compiling and code execution.
When we talk about slow parsing and compilation, context is important - here we are talking about mid-range mobile phones. Ordinary users may have phones with slower CPUs and GPUs, without an L2 / L3 cache, and even with limited memory.
Network capabilities and device capabilities do not always match. A user on an excellent fiber-optic channel is not necessarily an excellent CPU to parse and evaluate the JavaScript that comes to his device. The reverse is also true ... terrible network connection, but exceptionally fast processor. - Christopher Baxter, LinkedIn
In the article “ JavaScript Startup Performance ”, I noted the parsing time of approximately 1 megabyte of unpacked (simple) JavaScript code on weak and powerful hardware. Between the fastest smartphones and the average difference is 2–5 times the parsing / compilation time.
The parsing time of a 1MB JavaScript bundle (~ 250 KB in gzip) on PCs and mobile devices of different classes. When taking into account the cost of parsing, you need to add the cost of unpacking a file of approximately 250 KB in size to a JS code of approximately 1 MB
What about real sites like CNN.com?
A modern iPhone 8 spends about 4 seconds on parsing / compiling CNN scripts, compared to ~ 13 seconds on an average phone (Moto G4) . This can significantly affect how much time passes before the user gets the opportunity to interact with the site.
The time of parsing on the Apple A11 Bionic chip compared to Snapdragon 617 in a regular Android smartphone
This shows the importance of testing on average hardware (like Moto G4), and not just on the phone that is in your pocket. But context is important: optimize for the devices and network conditions that your users have .
Analytics tools can show which mobile devices of a class to real users of your site. This makes it possible to understand the real limitations of the CPU / GPU.
Do we really ship too much javascript? Well maybe :)
HTTP Archive (top about 500 thousand sites) shows the use of JavaScript on mobile sites . And we see that 50% of sites need more than 14 seconds before they become interactive. These sites spend up to four seconds only to parse and compile JS.
If we also take into account the time needed to load and process JS and other resources, then it is not surprising that users leave the page without waiting for it to be “defrosted”. There is definitely room for improvement.
If you remove non-critical JavaScript from the pages, then you reduce download time, CPU-intensive parsing / compilation, and potential memory overflow. It will also help your pages get online more quickly.
lead time
Not only parsing and compilation have their price. Execution of JavaScript (execution of the code after parsing / compiling) is one of the operations that is performed in the main thread. Long execution times also affect how soon the user will be able to interact with your site.
If the script runs longer than 50 ms, the time before the start of interaction with the site is increased by the entire time it takes to download, compile and execute JS - Alex Russell
To cope with this, it makes sense to transfer JavaScript to small fragments that will not capture the main stream for a long time. Learn how you can optimize script execution time.
Ways to speed up JavaScript delivery
If the goal is to reduce the time of parsing / compiling JavaScript and passing over the network, there are some useful techniques, such as route-based chunking and PRPL .
PRPL is a technique for optimizing interactivity by aggressively splitting code into fragments and caching:
Let's see what effect you can get.
We analyzed the load times of popular mobile sites and progressive web applications using the V8 Runtime Call Stats. As you can see, the parsing time (shown in orange) is a significant part of the time costs:
The Wego site uses PRPL, tries to keep a low parsing time on the routes and goes on interactivity very quickly. Many of the other sites listed use split code and performance budgets, trying to reduce JS costs.
Other costs
JavaScript can affect performance in many ways:
- Memory. Pages may jerk or slow down frequently due to garbage collection. When a browser requires memory, JS execution is suspended, so that frequent browser garbage collection can stop execution more often than desired. Avoid memory leaks and frequent pauses of garbage collection so that pages move smoothly.
- Long-term execution of JavaScript blocks the main thread, which is why the page is frozen. This problem can be dealt with by breaking the code into parts using
requestAnimationFrame()requestIdleCallback().
Progressive bootstrapping
Many sites optimize the visibility of content through interactivity. To quickly start rendering with large JavaScript bundles, developers sometimes use server-side rendering; then "update" the image when JavaScript is finally processed.
Be careful - everything has its price. You 1) essentially send a larger HTML response that may affect interactivity; 2) you can leave the user in a plausible "sinister valley", where in fact half of the interactivity is not available until the processing of JavaScript is completed.
Progressive bootstrapping may be a better option than this approach. Submit a minimally functional page (composed of only the most necessary HTML / JS / CSS for this pass). When other resources arrive, the application will lazily load them and unlock additional functionality.
Progressive Bootstrapping , illustration by Paul Lewis
Downloading the code according to what is displayed on the screen is a real grail. PRPL and progressive bootstrapping are techniques that help get closer to it.
findings
Transmit size is critical for thin channels. The parsing time is important for devices with a weak CPU. We need to strive for minimum performance.
Different companies have achieved some success by introducing tight performance budgets at the time of transferring, parsing, and compiling JavaScript. See Alex Russell’s budget guide for mobile sites and apps, “ Can we afford it ?: Performance budgets in the real world .”
It is useful to consider what space JS leaves in our architectural decisions for application logic.
If you are creating a site for mobile devices, try using specific hardware, minimize JavaScript parsing / compilation time, and implement a performance budget so that your developers keep track of their JavaScript costs.
Additionally
My performance on Chrome Dev Summit 2017 is about the price of javascript. Later, performance is analyzed using real sites like Pinterest and Tinder.
Source: https://habr.com/ru/post/343562/
All Articles