Make a summary every day, persistence is victory!
/** @date 2021-07-06 @description Front-end performance optimization */Copy the code
One (sequence)
As a front-end developer, performance tuning is an important part of the game, because we are the developers closest to the user, so we have to know something about performance tuning.
Yesterday summarized the process from entering the URL to rendering the page, from which you can actually see many points that can be optimized.
Based on what I know so far, I summarize performance optimization from two aspects: the network request level and the browser rendering level.
Ii (Network Request)
- Reduce HTTP requests: Optimization is essential at the network level because the network is based on HTTP. What can be done to reduce HTTP requests?
Reduce HTTP requests by combining smaller files into a single file for requests, merging small ICONS into Sprite images, converting small images to BASE64 format, and so on
-
Compress resources, reduce transmission pressure: Compress resources, reduce the size of resources, can effectively reduce the pressure of HTTP request data, small resources, high efficiency, you can carry out code compression, image compression, open gzip, Treeshaking, etc
-
Using HTTP/2.0: HTTP/2.0 does a lot of good things for HTTP optimization, such as binary protocols, header compression, multiplexing, push functionality, etc
-
Use CDN: CDN is a content distribution network. It obtains data from the nearest CDN server through the principle of proximity and reduces the pressure of network requests from the physical distance
-
Caching: Through the browser cache, resources can be stored in the browser and directly retrieved from the cache when needed, reducing the need to send requests. This is a very efficient PERFORMANCE optimization at the HTTP level.
Caches are divided into strong caches and negotiated caches:
Strong Cache: Forces the browser to use the Cache to retrieve data. The request header configures Expires or cache-control max-age. Max-age has a high priority
Negotiated cache: Optional, a request is sent to the server to determine whether the cache is used. ETag and if-none-modified are used to determine whether the resource has changed. If the resource has changed, the status code 200 and the new resource are returned
Iii (Browser Rendering)
-
Use the link tag to import CSS instead of using the style tag, because the CSS in the style tag is parsed by the HTML parser and does not block DOM parsing, which can cause “splash screens”.
-
Place the link tag at the bottom of the head tag. Because CSS parsers do not block DOM parsing when parsing CSS, avoid placing the link tag at the bottom and parsing CSS after DOM parsing
-
Put the style tag at the bottom of the body tag. Since JS execution blocks DOM parsing, CSS parsing, and page rendering, it should be executed last to avoid blocking
-
Reduce redraw rearrangement: Redraw refers to changes in non-layout styles such as background color that will be redrawn by the browser. Rearrangement refers to changes in layout style attributes such as width that will be rearranged and redrawn
We can optimize redrawing and rearrangement in the following ways:
Use CSS Layers: Since the smallest unit of redraw rearrangement is a layer, place elements that are often redrawn and rearranged on a single layer so that the redraw and rearrangement of this layer does not affect the entire page. Use the following method to separate a SINGLE LAYER of CSS:
a. transform: translateZ(0); B. video element C. Canvas element D. element using CSS animation e. will-change: transform;Copy the code
Reduce the width, height, and other layout attributes of the element;
RequestAnimationFrame instead of setInterval;
Use transform to change the layout, not left, top;
-
Use the WebWorker to open a new thread to handle some manipulation
-
Make proper use of anti-shake and throttling functions