Umi app’s first screen loading speed increased by 3 times + (Common first screen optimization method)

According to the previous blog, I am the company’s front-end framework umi, Ali products based on routing, support configuration routing and contracted routing at the same time, to ensure that the function of routing is complete, and function expansion of the front-end application framework.

The problem

The loading speed of the homepage of our website is very slow all the time. Although we use UMI, we still use SPA instead of SSR. The loading speed of the first screen is about 6s. When we look at the network analysis why the loading speed is so slow, we see that some static resources umi[hash].js occupy 3.5m of memory, and the response speed is higher than 6s. This is only a simple JS file, let alone a SPA file loaded on the first screen.

Preliminary thinking

During this period, I thought of many ways to load the home page faster, such as:

  • Smoke components
  • Compress the picture, for this I also wrote a Node application front end project group picture management
  • There are also some web compression speeds, such as splitting files using smaller plug-in libraries

Further study of

I’ve been doing a lot of work on loading speed, After reviewing the request body of network, it is found that several static files occupy the most bandwidth. Through Response Header, it can be seen that our server is started by Nginx I believe that those of you who have used UMi-CLI or any CLI will see that the static resources packaged on the server are very large

Take a closer look at the request header information

Request Headers
  Accept - Encoding: gzip, deflate
Copy the code

I have always known about the concept of Gzip compression, but I only saw gzip in our network request REQ, not in the RES content. Because the server deployment is not in the front end, it is not easy to directly refer to the back-end or operation and maintenance students.

I opened Baidu pair and compared baidu’s response

Response Headers
  Accept - Encoding: gzip, deflate
  server: JSP3/2.014.
Request Headers
  accept-encoding: gzip, deflate, br
Copy the code

Nginx is not used for load balancing and compression of static resources. Then I went to the Internet to search for knowledge about Nginx and Gzip. There are many such articles, students can Google.

To solve the problem

Fortunately, I have enough authority to get the test server to open GZIP as prompted by the website

The final configuration of our nginx.conf is as follows

server {
    gzip on;
    gzip_buffers 32 4 K;
    gzip_comp_level 6;
    gzip_min_length 100;
    gzip_types application/javascript 
    text/javascript text/css text/xml;
    gzip_disable "MSIE [1-6]\."; # Configure to disable gzip condition, support regex. This indicates that Gzip is not enabled in Internet Explorer 6 and below (because earlier versions of Internet Explorer do not support gzip_vary on). }Copy the code

Many configurations of gzip_types have less application/javascript, but realistically you’ll find most of the js file requests in web requests are as follows:

Content-Type: application/javascript
Copy the code

This is important, because it’s 2021.

After the configuration is complete, remember to restart nginx. When we look back at the entire network request, the size of umi[hash].js, which occupied the largest memory, has been reduced by nearly 4 times in size, and the overall response speed has been 3 times faster, which can really be said to be basically fast response speed.

conclusion

For the front-end, client performance optimization is always the goal of the front-end, the joy of the second.

As for performance optimization, I feel that targeted performance optimization should be implemented, such as first-screen speed/file compression/resource integration, and learning to observe request response, analyze and solve problems.