In the last section, I introduced the points that can be optimized during the loading process of the web page. In this section, I will talk about the optimization of the network part.
The network section includes the following processes:
- The DNS query
- Establishing a TCP Connection
- Sending an HTTP request
DNS and TCP are nowhere to be found, so we’ll have to go with HTTP. HTTP is a round-trip process where the browser sends a request and receives a response.
request
At the request level, we also talked about the optimization of the request link in the previous section, which is to reduce HTTP requests, because network requests are the most uncertain factor in the whole process, and they are most intuitively affected by the environment. Then what specific aspects should be reduced, such as:
- Every image, style… Loading will send HTTP requests, so you can turn the picture into Base64, now the front-end development is generally using packaging tools to carry out engineering development, packaging tools will generally provide pictures to Base64 plug-in; Merge small ICONS into CSS sprites, etc. Place small ICONS into a file, just load it once, and then crop it from the position of the image, but don’t blindly merge the file too big, that can also affect the experience
- Too many style files and script files can also increase HTTP stress, so merge scripts and styles appropriately, but do not blindly merge files too large will affect the loading speed
- Use location.reload() less to refresh the page and re-request resources every time you reload
The response
The optimization you can make in response is as simple as reducing the size of the response resource — using gzip compression, enabling gzip compression is as simple as adding Accept-Encoding :gzip to the request header. HTTP compression is the process of re-encoding HTTP content for the purpose of reducing volume.
Gzip can help us compress about 70% of the volume, but it is not a cure-all, it also has a price, enabling Gzip requires a waste of server computing resources, server CPU performance is not unlimited, if there is a large number of compression requirements, the server can not bear, this time will not be worth the loss
HTTP cache
HTTP caching is one of the most efficient ways to reduce load time. HTTP caching comes in two forms: strong caching and negotiated caching.
A strong Cache is controlled by two fields, Expires and cache-Control. When a request is made again, the browser determines whether the target resource “matches” the strong Cache based on the Expires and cache-control fields. If so, the browser will retrieve the resource directly from the Cache. There is no more communication with the server.
If you look at a response that uses a strong cache, you can see that it uses cache-control and has a maximum valid time of 31536,000, which translates to nearly a year, meaning that you don’t need to request the resource for another year
Negotiated cache, as its name implies, is the result of negotiation between the browser and the server. When requesting a resource, the browser will ask the server whether the resource is expired. If the resource is expired, the browser will reload the resource. Common negotiation cache fields include ETag/ if-none-match, last-modified/if-modified-since, and so on
The HTTP status code changes to 304 with the negotiation cache
See my previous article on strong caching and negotiated caching
Content delivery Network CDN
At present, CDN has become a very cheap resource. Major cloud service providers have provided their own CDN services with a very low price. CDN selects the server closest to the request by judging the geographical location of users to reduce the distance of resource transmission and thus reduce the response time
The core of CDN lies in cache and back source. The CDN server caches the resource files of the root server. Back source is the process in which the CDN server requests resources from the root server, usually after the resource cache expires.
Static resource loading speed is always a key indicator of front-end performance, because static resource requests are generally large and bulky. Placing static resource on CDN can reduce the pressure of application server, so that application server can concentrate on processing services without being distracted to respond to static resource. Generally, static files are placed on the CDN, such as images, style files, etc
Lazy loading
Lazy loading can be not important picture files in need of loading, priority will be the overall framework of the web page to load out, when the user needs to browse pictures to request. In addition, skeleton screens can be used to optimize the user experience while the user is waiting for the page to load, for example, the Nuggets article details page uses skeleton screens
