Front-end page management problem?-why use gif to manage

1 background

The lighthouse is a front-end monitoring system launched by the shell-finding front-end architecture group. When I recently docked with the business side, I was asked this question:

Why use GIF for front-end monitoring?

This question is very interesting. We know that the current mainstream front-end monitoring (Baidu Statistics/Youmeng/Google Statistics) are all using GIF for management. But why do these systems use GIF, is it because there is no other solution?

This has to start with the principle of front-end monitoring.

2 Principles of front-end monitoring

The so-called front-end monitoring is actually the process of reporting user information (UA/mouse click position/page error/stay time/etc) to the server from the web page after certain conditions are met. Generally, the reported data is encoded with url_encode (Baidu Statistics/CNZZ) or JSON encoded (神策/朱葛io) as a string, passed to the server through the url parameter, and then processed uniformly on the server side.

The key to this process is:

1) Ability to collect user information;

2) Be able to report the collected data to the server. In other words, as long as the data can be reported, whether it is requesting a GIF file or requesting a js file or calling a page interface, the server does not actually care about the specific reporting method.

Reporting data to the server can be done through the request interface, requesting ordinary files, or requesting image resources. Why do all systems use the same method of requesting GIF images to report data?

 

 

3Why mainstream solutions use GIF to report data

To answer this question, we must use the method of elimination.

 

First of all, why can't I directly use the GET/POST/HEAD request interface to report?

 

This is easier to think of the reason. Generally speaking, the dotted domain name is not the current domain name, so all interface requests will constitute cross-domain. Cross-domain requests are prone to be intercepted by the browser and reported errors due to improper configuration, which is unacceptable. Therefore, directly exclude.

 

 

Secondly, why can't we report by requesting other file resources (js/css/ttf)?

 

This is related to the characteristics of the browser. Generally, after the resource node is created, the browser will actually send the resource request only after the object is injected into the browser DOM tree. Repeatedly operating the DOM will not only cause performance problems, but loading js/css resources will also block page rendering and affect user experience.

 

But the picture request is an exception. Not only does not need to insert the DOM to construct the image management, as long as the Image object is created in js, the request can be initiated, and there is no blocking problem. In the browser environment without js, the img tag can also be used for normal management. This is other types of resource requests. Can't do it.

 

Therefore, in all the schemes for managing by requesting file resources, using pictures is the best solution.

 

Possible way_exclude file request

 

There is one last question left. The same are all pictures. 1x1 transparent GIF was used for reporting instead of other PNG/JEPG/BMP files.

 

This is the last step of the method of elimination. The reason is actually not easy to think about and needs to be looked at separately.

 

First of all, 1x1 pixels is the smallest legal picture. Moreover, because it is done by pictures, it is best for pictures to be transparent, so that it will not affect the display effect of the page itself. Both indicate that the picture is transparent. Just use a binary bit to mark the picture as a transparent color, without storing color space data. , Can save volume. Because transparent colors are needed, JEPG can be directly excluded (BMP32 format can support transparent colors).

 

Then there are BMP, PNG and GIF, but why did you choose GIF?

 

Because of the volume!

 

Below is a 1x1 pixel transparent image, the smallest BMP/PNG/GIF file structure.

 

BMP：

BMP

PNG：

PNG

GIF：

GIF

As you can see, the smallest BMP file requires 74 bytes, the PNG requires 67 bytes, and the legal GIF only requires 43 bytes.

 

In the same response, GIF can save 41% of traffic compared to BMP and 35% of traffic compared to PNG. Comparing this way, the answer is obvious.

 

When reporting data, GIF is obviously the best choice.

 

Possible options_final result

 

 

4 summary

Front-end monitoring uses GIF to report mainly because:

• No cross-domain issues;

• Will not block page loading and affect user experience;

• The smallest size among all pictures, compared with BMP/PNG, it can save 41%/35% of network resources.

 

Finally, thank you all for your support:

@周晨 raised this question;

@大董 pointed out that loading pictures does not need to manipulate the DOM, and the performance is better;

@CC老师 pointed out that in an environment without JS, only picture management can work normally (GET method needs to be triggered by the user);

@丸九 introduces the characteristics of various image formats and explains why a 1 pixel transparent image is necessary;

@伍子胥 reviewed the information on the Internet and confirmed the key factor: file size.