Common optimization tips for web performance

Common Skills

What the browser does after entering the URL:

1. DNS domain name resolution;
2. Establish a TCP connection;
3. Send HTTP request;
4. The server processes the request;
5. Return the response result;
6. Close the TCP connection;
7. The browser parses the HTML;
8. Browser layout rendering;

Ideas: try to optimize each step.

optimization:

1. DNS service
2. By configuring the host yourself, you can save the step of DNS query.
3. Spend money on bandwidth
4. The back-end optimizes the query speed of the sql statement to make it return to the front-end data faster.
5. Connection multiplexing, backend set keep-alive
6. The backend enables gzip code compression, and the browser will automatically decompress it
7. First load css and then load JS, let the user see the page first, and then realize the interaction.
8. Lazy loading, the first page the user sees is loaded first, and then the rest of the pages are recorded.
9. Preload, such as reading a novel and load the next page in advance
10. http caches css/js/images, sets the cache time on the backend, and uses the hash value to determine the files that need to be updated. cache-control
11. Use more than 2 but no more than 4 domain names, because domain names limit the maximum number of concurrent requests (CDN domain names)
12. Cookie-free, separate multiple domain name requests that require cookie requests and those that do not require cookies, and speed up requests that do not require cookies.

The following is the reproduced content:

When talking about front-end performance optimization, what are we going to talk about?

background

Throughout our front-end learning life, we have always heard the words "performance" and "experience" again and again. Front-end performance optimization is not only a practical issue that front-end engineers need to pay attention to at all times, but also a point that is frequently asked in front-end interviews. The reason why interviewers love to ask is because they are lazy. Just by asking this question, you can test the interviewee's knowledge breadth, depth of knowledge, ability to summarize, and express ability to a certain extent, and you can continue to ask other questions along this line.

When asked the question of performance suddenly, most people will suddenly be stunned. I always feel like I have a lot to say, but I feel cluttered and don't know where to start. After some thought, I slowly came up with the "Yahoo Performance Optimization N Military Rules" I saw in the early years of interview questions, scratching my head and scratching my head to say seven or eight. The interviewer asked "Is there any more?" with a blank face. At this moment, he had to squeeze the brain like a sponge, and then drip out two or three more specious oily water. My heart is full of distress, complaining that my memory is not good enough.

In fact, even if they recite dozens of sentences in one breath, the interviewer is not necessarily very satisfied. One of the reasons is that too many entries can be annoying and the interviewer can't remember what you said. Second, the answer in this way obviously gives people a feeling of rote memorizing. (The interviewer really owes it to me)

what are we going to talk about

There are two approaches to answering the performance question. Following these two ideas, you can answer a dozen or even dozens of optimization schemes naturally and "intellectually" without much memory. Of course, the premise is that you have really used these optimization schemes.

Idea 1. Starting from the front-end performance scenarios that are exposed to daily

Performance bottlenecks mainly occur in three scenarios

1. It takes a few minutes for each code package to be modified during development, which is too slow ( Development Build Phase )
2. Open the website, wait for dozens of seconds to see the page, too slow ( resource loading and page rendering stage)
3. After the page is displayed, the animation on the page is not smooth. Scrolling the page or dragging the element feels serious, and even the page will crash ( operation experience stage)

1. Development and construction phase (FAQ: How to make Webpack packaging faster)

• Concurrency: use multi-process packaging
• Cache: Use the cache when packaging
• Smaller package size: narrow file search scope and reduce unnecessary compilation work

2. Resource loading stage

The core idea is: the transmission volume should be small, the distance should be close, parallel transmission, resource multiplexing, and preloading.

transfer volume is small

• HTML compression at build time
• Build-time CSS compression merge
• Build-time JavaScript minification merge
• Compression of images at build time
• Use SVG sprites or font icons instead of image icons
• Gzip is enabled on the server, and the data is compressed again before transmission
• TreeShaking is used during construction to reduce unnecessary code introduction
• Single-page application routing lazy loading, reducing the volume of resources loaded for the first time
• Lazy loading of components reduces the size of resources loaded for the first time
• Lazy loading of images reduces the size of resources loaded for the first time

be close

• Deploy static resources to CDN

Parallel transmission

• Upgrade to HTTP2.0 (FAQ: What upgrades have HTTP2.0 made compared to HTTP1.x? Multiplexing; binary framing; server-side push; data stream priority; header compression)

Resource reuse

• Configure static resource caching on the server (FAQ: HTTP caching strategy? Cache-Control? keep-alive? 304? ETag?)
• Packet multiplexing when packing

preload

• Browsers preload secretly at idle time, <link rel="prefetch" href="url">

Third, the page rendering stage

• CSS on top, JS on bottom
• Loading CSS is recommended to use link instead of @import
• Unimportant externally introduced JS uses defer or async attribute to load asynchronously

Fourth, the operation experience stage

• smooth animation
• • Try to use transition and animation to achieve CSS animation , instead of JS to achieve animation (running on the main thread has an impact on the smoothness of animation)
  • Use transfrom and opacity as much as possible for animation (no need to redraw and reflow, best performance)
  • translateZ/translate3d enable hardware acceleration
  • JS animation uses requestAnimationFrame to use less setInterval
• Scroll/move/operate smoothly
• • Fewer DOM additions and deletions (virtual long list, DOM Diff)
  • High frequency operation using stabilization and throttling
• intensive computing
• • Computationally intensive operations can be handed over to WebWorker for concurrent processing

from Ruoyu@hungry valley

Idea 2. Talk about front-end performance from the perspective of life

Suppose you are the CTO of the company, and now there is a product that needs to be launched in the shortest possible time. How to do it under the premise that the existing team does not work overtime or 996? The plan is nothing more than:

1. Compression requirements, iterative development - compression
2. Use more old wheels (code, solutions, architecture) and build fewer new wheels - caching
3. Increase manpower - concurrency

Corresponding to front-end performance optimization

• Compression requirements, iterative development: compression and merging of static resources, Gzip, various lazy loading, and narrowing the search range of files during development and packaging
• More use of old wheels (code, scheme, architecture) and fewer new wheels: HTTP caching when resource requests, configuration and use of caching when developing and packaging, and sub-package reuse when packaging
• Increase manpower: use HTTP2 to implement concurrent requests when requesting resources, configure and use concurrent capabilities when developing and packaging, WebWorker

Starting from the above two ideas, it is natural for you to have a lot of experience, and you can easily excite yourself and the interviewer, and even control the follow-up questions to a certain extent.

When it comes to performance, a 6-word proverb comes to mind: compresses , caches , concurrency . The rest is left to the cerebellum to play freely.

One-time understanding of performance optimization

www.yuque.com/hvvsva/xcxoqg/gugadx