About the author

Hello, my name is Kyrieliu, a front-end engineer working in Shenzhen. Welcome to follow my blog. If you have any discussion about the front end, please add my wechat (K-i2Ving) to discuss. Welcome to visit and grow together.

Questions arising from an interview

I interviewed a candidate a while back, and when I asked her what she thought was a common tool for front-end performance optimization, she was adamant that Sprite graphics reduce the number of page requests and that she often used images in her projects but the truth is that Sprite graphics are no longer used in the front end.

This article will take a look at the “Reduce HTTP requests” section of the Yahoo! Catch-all for front-end performance optimization, and ask a question from the HTTP protocol level: Why does modern front-end engineering not need to focus on HTTP requests?

80% of the end user’s waiting time is spent on the front end. Most of this time is spent loading resources such as images, videos, styles, scripts, etc. The ultimate solution to this problem is to “control the number of HTTP requests by reducing the number of page resources”, and the fewer HTTP requests, the faster the page will be rendered to the user.

After all, remember how messy this process sounds 👇

However, it is not always possible to render the page quickly and present the simplest text content to users. Even if our front end is willing, product managers and designers are also unwilling to do ten million of them.

With the explosive development of network content in recent years, presenting more and more rich content in the terminal is an irreversible trend of development, so the front-end engineers of this era should take into account the rich content of the page, and constantly accelerate the response speed of the web page.

Here are some ancient front-end performance optimization rules for reducing the number of requests (” Yahoo Catch-all “was introduced in late 2006) and how these rules have fallen into place or disuse in modern front-end engineering.

File merging

File merging, as the name suggests, is the merging of multiple files into one file (JavaScript or CSS), which naturally aims to reduce the number of files and thus HTTP requests. For example, if we have a page that references multiple JS and CSS files from different domains, the number of HTTP requests that need to be made when initializing the page is the sum of these files. Then came tools such as Grunt and gulp, which allowed developers to build multiple files of the same type into a single large file so that they could get the same content (or “collection of files”) with fewer requests.

Sprite figure

The original name of Sprite is “CSS Sprites”, which means “Sprites”, but it happens to be the same as the English name of “Sprite”, so everyone in China calls it “Sprite”.

Sprite is also simple: combine small images on a page (or entire website) into one large image, and use the corresponding image using BACKground-image and background-Position CSS.

However, since the concept was introduced earlier than automated build tools such as Gulp and WebPack, front-end engineers often had to make Sprite graphics themselves to improve page loading performance, which was painful.

Similar to Sprite, there is another scheme called “mapping”. The essence is to put a lot of images together to reduce the number of HTTP requests. Unlike Sprite, maps advocate putting together all the original quality images on a page. However, it was soon abandoned due to the limited use of scenarios (generally only used in scenes with coherent images).

Base64 pictures

In Yahoo’s catch-22, Base64 images are called inline images. The essence of Base64 image is to encode an image with base 64. The generated string can be used to replace the image address in HTML and CSS files.

But unlike other optimizations, Base64 doesn’t necessarily mean “optimizations” : When encoding base64, the resulting strings tend to be very long, which adds to the size of HTML or CSS, so there are trade-offs to be made. In the Webpack project, we specify that images below 8KB should be converted to base64 images.

But that’s no longer necessary

In modern front-end engineering, few people care about “merging files to reduce HTTP requests” anymore, or even “performance optimization” as the HTTP protocol has evolved.

Remember the three-way handshake and four-way wave for TCP connections? It doesn’t matter, I will paste the picture again if I forget.

Each HTTP request will undergo a TCP three-way handshake before it is sent out. When the data transmission is completed, another four-way handshake is carried out.

The picture above, no mistake, but (but again), that was nearly 20 years ago. A review of the HTTP protocol history shows that the full HTTP protocol (HTTP 1.0) was created in 1996, upgraded to HTTP 1.1 three years later, and upgraded to HTTP 2.0 again in 2015. In fact, as of 2021, HTTP has entered the 3.0 era.

Strictly speaking, merging files as a performance optimization should have been questioned after HTTP 1.1. Why is that? Take a look at the chart below:

HTTP 1.1 supports Connection (keep-alive) and Pipelining (Pipelining) by default, which means that multiple HTTP requests can share the same TCP Connection in sequence, greatly reducing the cost and latency of establishing a TCP Connection.

In 2015, HTTP 2.0 emerged with a halo of multiplexing, not only solving the problem of blocking HTTP 1.1 pipelined requests, but more importantly, multiplexing faster!

Below is a visual comparison of HTTP 1.1 and HTTP 2.0 under the same network conditions.

To sum up, in modern front-end engineering, there is no need to do this kind of “optimization” of merging files to reduce HTTP requests. Instead, front-end applications are so large that they require “subcontracting loading” and “lazy loading” to reduce the actual size of each static file. This results in faster download times and faster parsing on the browser side.

The last

If my content is helpful to you, a like is the biggest encouragement for me ~

If you have any questions or controversies, feel free to comment in the comments section

Please join me on wechat (K-i2Ving) if you are reading this, you are not alone on your way (remember to note “From nuggets”, I will pass in a second).