Improve page performance in modern web apps

Improve page performance in modern web apps

Foreword, this article is translated from https://docs.google.com/presentation/d/1hBIb0CshY9DlM1fkxSLXVSW3Srg3CxaxAbdocI67NCQ/edit#slide=id.g32e52b1ea6_1_0 After seeing it, I feel that the system explained is clear and clear, which is really a good article. I added my own understanding and translated it, and chatted to deepen my impression.

Hardware, network, two physical factors that cannot always be avoided in terms of performance

1. How hardware affects performance

Hardware (i.e. processing power) determines the performance of computationally intensive tasks The
browser has to parse, compile and execute all the js as follows:

For each stage, the difference in the amount of code obviously affects its monetization i.e. performance , this difference is especially noticeable on machines with low processing power.
Of course, other types of resource requests will also affect performance. In contrast, the impact of js is more prominent.
Therefore, considering the CPU conditions of different users, it is necessary to reduce js monsters (that is, reduce the size of js). You can start from the following aspects:

1. remove unnecessary js
2. lazy load non-critical js

3. with related tools

   1.1 Remove unnecessary js

   Convert only when necessary

   Conversion is only done for clients that require ES5, 80% of browsers already support ES2015. (Combining with our own actual development, it is true that 80%+ of mobile phones already support ES2015 on the mobile side, but only oppop and vivio mobile phones do not support it.) Because there are still some costs after the conversion, as shown below:

//ES2015
books.map(b => b.title);
//ES5
books.map(function(b) { return b.title; }, this);
//体积大了一倍

Use Compression Tool/Optimization Tool

Tools like UglifyJS & Closure Compiler have some optimizations in addition to compression.
For most js, whitespace removal and symbol modification in compressed code account for 95% of the workload, not careful code conversion.
Compression should not be blind and should balance the following points.

• better compression ratio
• High computer resource consumption
• Preliminary preparation
• Possible side effects
  Compression may not be a blind pursuit of smaller size. Relatively speaking, compression should also weigh other aspects. It is more common that the code compression takes a long time compared to other processes. Problems with keywords may be encountered after compression.
  How to solve it should actually start from its own project.
• Optimize cacheable static resources as much as possible
• Find a balance between compression volume and time

Use tree-shaking to remove useless code

Consistent with the purpose of compressing the code, reducing the resource size is just a solution from another level. Like webpack, rollup provides this feature.
tree-shaking will remove unused exports

//tool 
//used
export function a(){
    console.log('1')
}
export function b(){
    console.log('2')
}
//app.js
import {a} from './tool'
a()

function b is not used, and b will be deleted in the final packaged file.

ES2015 modules are static and can use tree-shaking

import/export is determined before execution, and both can only be used at the top level, without conditional logic (not executed after all)

Limitations of tree-shaking

• Just delete unused exports
  
• Not all codebases supported (ES2015 only)
• May not be the best
  it is difficult to determine whether deletion will have side effects, this packer can only keep

self-examination

Tools are not perfect, and it is difficult to identify a problem before executing it.
At present, it should be self-improved from code specifications and code comments.

for the frame

If not necessary, please do not use. Large frameworks are at least 300kb in volume.
Of course it is necessary, please choose based on the following points:

• server-side rendering
  
• lazy loading
• Code optimization
  
• performance

1.2 Lazy loading of non-essential js

Let's take a look at the difference between different import methods of js

	Default way	Async	Defer
render blocking	Yes	no	no
execution time	download finished	download finished	document parsing completed

Using code splitting and lazy loading

• Reduce the js that needs to be loaded at startup
  
• Load unrelated js as little as possible. The
  traditional way is to load Bundle js, and code splitting is to divide the code into different chunks
  . There are also two extremes here:
  
• Each module corresponds to a js , which is
  not easy to compress , is
  conducive to caching
  , and has smaller granularity

• The whole application only corresponds to one js , which is
  easy to compress . It
  is not good for caching . If
  the granularity is too large, it can be maintained.
  Suddenly there is a sense of moderation.

  1.3 Using other tools

  using html and css

  In some cases, vanilla JS (that is, native JS) may be required. The framework brings convenience and inevitably has some other performance consumption. Referring to an article here you can see how I switched my React app to VanillaJS (isn't that a bad idea)
  For example:
  Netflix lowered their login page TTI (Transmission Time Interval) by 50% The following way:
• Use native js instead of React

• Load the rest when the user logs in

use server

Put expensive libraries on the server side and use ssr instead of client-side-render.
ssr can reduce our initial page load events to 1/5 and reduce the difference between different browsers.
ssr is indeed optimized for the first screen, and the advantages are not much to say. But here's a word, don't blindly ssr, especially the interface with a long response time for the initial request

The impact of the network

First understand two concepts:

• Bandwidth: Data throughput (bits/sec)
• Latency: Delay data transfer time (ms)

For most markets, the bandwidth can meet the demand (the statistics here are foreign, with an average of 26 megabytes, slightly lower in China), and the average page size is 3.5Mb. Transmission time (3.5/26) 0.13s. Domestically it will be a little bit worse.
Latency has a significant impact on performance.
Latency of mobile network

The internet	delay ms
5G	<=4
4G	<=100
3G	100-500
3G	300-1000

Adapt to the limitations of mobile networks

The following aspects should be considered separately.

• reduce the number of requests
• Optimize the critical path
  
• reduce request size

2.1 Reduce the number of requests

The cost of creating a new connection is expensive, and the following process must be repeated

Establishing a connection requires 1 to 3+ responses before data is corresponding.

1. DNS query (possible)
2. TLS handshake (possibly)
3. request resource

Initial state connection cannot be fully utilized

TCP slow-start limits the amount of data sent in the initial response

Sending more data is usually cheaper than creating a new connection.

The requested volume and corresponding time are not linear.
The consumption of two 50k requests is much larger than one 100k request.

Reduce the use of redirects

• Redirects add expensive loops to the server
  
• Server-side redirection is better than client-side (fast and cacheable)
• Take a look at the 301 and 302 response codes

use cache

Ideally, whether the resource is up-to-date should not be requested over
the network by:

• Use Content-addressed URLs:
  that is, the content corresponds to the address, log13234d.jpg instead of log.jpg
  
• use max-age

This browser tweak saved Facebook 60% of requests

Use service workers to enhance caching

Service workers can help us:

• Intercept network requests
• Access browser cache
  
• Instead of sending network requests to handle expired resources

use http2

With HTTP2, only one connection is required per origin, reducing connection creation overhead.

2.2 Optimizing the critical path

Optimize the events required for page rendering or loading to complete as quickly as possible.

Browser optimization of resource requests

For all requests, the browser has weight processing, that is, they are loaded with different priorities. Specifically, it is important that the priority of blocking rendering is higher.
As shown below:

Use Resource Tips

Early-load or request content that will be used by:

• Dns-prefresh
  
• preconnect
• Preload (current page)
• Prefetch (next page)

2.3 Reduce request size

• Use Brotli compression Better compression ratio
  compared to gzip
  , the bigger the file is, the bigger the file size is
  Faster decompression The
  compression speed is greatly improved
• reduce js size
  
• Optimizing pictures
  23 will not be mentioned any more, there are many ways.

concluding remarks

For good resources, the benefits of reading more are still obvious. This time I feel that I have more experience in the translation, but because of my lack of talent and knowledge, I hope to correct me if I am wrong. In a word, learn together. More please move