Improve page performance in modern web apps

Improve page performance in modern web apps

Preface, this paper is translated from https://docs.google.com/presentation/d/1hBIb0CshY9DlM1fkxSLXVSW3Srg3CxaxAbdocI67NCQ/edit#slide= Id.g32e52b1ea6_1_0 see after the feeling of the system is clear, is a good article. Add your own understanding translated a bit, talk to deepen the impression.

Hardware, network, two physical factors that are not always able to be avoided in terms of performance one, how hardware affects performance

Hardware (that is, processing power) determines the performance of computationally intensive tasks
The browser must parse, compile, and execute all JS as shown below:

For each phase, the difference in code volume obviously affects performance, which is particularly noticeable on low-processing machines.
Of course, other types of resource requests can also affect performance, in contrast to the impact of JS is more prominent.
So consider the situation of different user CPU, reduce JS monster (that is, reduce JS volume) is very necessary. You can start with the following:

1. Delete Unnecessary JS
2. Lazy load non-critical JS

3. With related tools

   1.1 Delete unnecessary JS only when necessary to convert

   Only the clients that need ES5 are converted, and 80% of browsers already support ES2015. (in combination with their actual development, mobile is really 80%+ mobile phone has been supporting ES2015, only encountered Oppop,vivio these two phones do not support.) Because the price after conversion is still there, as follows:

//ES2015books.map=>b.title);//ES5books.map(function{returnb.title;},this);//体积大了一倍

Using the Compression tool/Optimization tool

Tools like Uglifyjs & Closure Compiler have some optimizations outside of compression.
For the majority of JS, compressed code hollow-cell removal and symbol modification accounted for 95% of the work, not a careful code conversion.
Compression should not be blind and should balance the following points.

• Better compression ratio
• High consumption of computer resources
• Pre-preparation
• Possible Side effects
  Compression may not blindly pursue the volume of smaller, relatively speaking, compression should also weigh the other aspects. The more common is the code compression when compared to other processes, the extra long time consumption. You may encounter a keyword problem after compression.
  How to solve the problem should be starting from its own project.
• Optimize cacheable static resources as much as you can
• Find a point of balance between compressed volume and time

Use tree-shaking to remove useless code

Consistent with the purpose of compressing the code, reducing the size of the resource is only a solution from another level. This feature is available as Webpack,rollup.
Tree-shaking will remove exports that are not used

//tool //usedexportfunctiona(){    console.log(‘1‘)}exportfunctionb(){    console.log(‘2‘)}//app.jsimport{a}from‘./tool‘a()

Function B is not used, and B will be deleted in the final packaged file.

The ES2015 module is static and can be used tree-shaking

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

The limitations of tree-shaking

• Simply delete unused exports
  
• All code libraries are not supported (ES2015 only)
• May not be the ultimate
  It is difficult to determine whether the removal has side effects, and the packager can only retain

Self-troubleshooting

Tools are not perfect, and it is difficult to identify a problem before it is executed.
You should now be self-perfecting from code specifications and code annotations.

For frame

Do not use if you do not have to. Large frame at least 300kb in volume.
Of course, please choose based on the following points:

• Service-Side rendering
  
• Lazy Loading
• Code optimization
  
• Performance

1.2 Lazy loading non-required JS

First look at the difference between JS different introduction mode

	default mode	Async	Defer
Blocking rendering	Is	Whether	Whether
Timing of execution	Load complete	Load complete	Document parsing complete

Using code splitting and lazy loading

• Reduces the JS that needs to be loaded at startup
  
• Load irrelevant JS as little as possible
  The traditional approach is to load the bundle JS, code splitting is to divide the code into different chunk
  There are also two extremes here:
  
• Each module corresponds to a JS
  Bad compression
  Facilitates caching
  Smaller particle size

• The entire application corresponds to only one JS
  Easy compression
  Not conducive to caching
  Size is too large to maintain
  Suddenly there is a sense of moderation, everything has degrees, all the single operation can not be too demanding the ultimate, the balance is reasonable

  1.3 Using other tools to use HTML and CSS Some situations may require vanilla JS (i.e., native JS), the framework brings convenience while inevitably there are some other performance costs. Mentioned here is an article you can see how I changed my React application to Vanillajs (this is not a bad idea)
  As an example:
  Netflix lowered their login page 50% for TTI (transfer interval) by the following way:
• Use native JS instead of react

• Load the remaining parts when the user logs in

Using the server

Place costly libraries on the server side, using SSR instead of Client-side-render.
SSR can reduce our initial page load events to 1/5 and reduce the differences between different browsers.
SSR does the first screen optimization is indeed very large, the advantages are not much to say. But here, don't blindly SSR, especially if the initial request has a longer response time interface

Second, the impact of the network

Start by understanding the two concepts:

• Bandwidth: Data throughput (bits per second)
• Delay: Delayed data transfer time (MS)

For most markets, bandwidth is available (statistics are foreign, average 26 trillion, domestic slightly lower), average page size 3.5Mb. Transmission Time (3.5/26) 0.13s. Domestic will be almost.
Latency has a significant impact on performance.
Latency for mobile networks

Network	Delay Ms
5G	<=4
4G	<=100
3G	100-500
3G	300-1000

Adapting to the limitations of mobile networks

The following aspects should be considered separately.

• Reduce the number of requests
• Optimizing Critical paths
  
• Reduce request size

2.1 Reducing the number of requests the cost of creating a new connection is expensive, repeat the following procedure

Establishing a connection requires 1 to an answer before the data corresponds.

1. DNS queries (Possible)
2. TLS Handshake (Possible)
3. Requesting resources

Initial state connection cannot be fully exploited

TCP Slow-start limits the number of Ririe data that is sent in the initial response

Sending more data is typically a cost-effective scenario than creating a new connection.

The requested volume is not linearly related to the corresponding time.
Two times the 50k request consumes a lot more than a 100k.

Reduce the use of redirects

• Redirection increases the server's expensive cycle
  
• Server-side is a little bit better than client-side (Fast and cacheable)
• Take a look at the response of 301 and 302 code

Using the cache

Ideally, it is true that resources are not up to date and should not be requested over the network
This can be done in the following ways:

• Using content-addressed URLs:
  That is, the content corresponds to the address, log13234d.jpg rather than log.jpg
  
• Using Max-age

This browser adjustment saves Facebook 60% of requests

Using service workers to enhance caching

Service worker can help us:

• Intercept Network requests
• Accessing the browser cache
  
• To handle outdated resources instead of sending network requests

Using HTTP2

When using HTTP2, only one connection is needed per source, reducing the overhead of connection creation.

2.2 Optimizing critical paths

Optimize the events needed to render or load the page so that you can do it as quickly as possible.

Browser-Optimized resource requests

For all requests, the browser has the right to re-process it, which is loaded with different priorities. Specifically, it is important to block rendering with higher priority.
As shown in the following:

Using Resource hints

Load or request the content you want to use in the following ways:

• Dns-prefresh
  
• Preconnect
• Preload (current page)
• Prefetch (Next page)

2.3 Reduce request Size

• Using Brotli compression
  Relative to Gzip
  Better compression ratio, the larger the file the more obvious
  Faster decompression
  Greatly improved compression speed
• Reduce JS Volume
  
• Optimize your pictures
  23 will not mention more, there are many ways.

Conclusion

For good resources, the multi-read income is still very obvious. This translation feels more and more, but because I caishuxueqian, if there are mistakes also hope to correct. In a word, learn together. More please

Improve page performance in modern web apps