Website Technical Analysis Report--Happy Net

Reader contribution: has been studying the Internet technology, often visit such websites, whim, why we do not go to see the technical framework of these sites what kind of? Research the source code? So there is this series, first to find who? Or to find a cottage version of the net surgery, this happy net, not that happy net, hehe.

Frankly speaking, I do not want to register, also do not want to study too much, in general, a site most important is the home page, Ok, then we start from the home page.

This series of articles is only a personal research release, for informational purposes only.

Analysis tools: Various browsers, Firebug (a Firefox plugin)

Happy NET home is a simple landing page, incredibly do 385.2KB, such as a net of such a large flow, every more than 1kb means every day n more money. I did not find the official PV or independent IP data, according to the Alexa data for reference, estimated daily average of independent IP is 528,000, we estimate that every independent IP access to a landing bar, in fact, may be less, Because many users may be directly on the home page landing (Alexa data is not so reliable, for reference).

How much bandwidth do we need per 1k of Web page? To calculate, we need to 528,000/1024=515mb/the bandwidth of the day, and then we average, 24 hours a day, the average user access is calculated (in fact, the average peak access will be more than one times above), the required bandwidth per second is 528000/(24 hours * 60 Minutes * 60 seconds) =6kb, considering the peak, estimated to be above 12k.

Reader, like happy net so simple landing, can completely control within 100k size, why so much, a moment to see the analysis of the Web page can know. What is this concept? 385-100=285k, then calculate the bandwidth: 285k * 12k/1024 = 3.3M. Darling, happy net needs to add 3.3M of exclusive bandwidth every day. How much is the bandwidth of 3.3M? We take the mid-range of the room to give examples, Beijing mid-range 3M independent bandwidth, how to get 350,000 pieces of it, plus the CDN bandwidth, it is estimated that happy net every year to increase the cost of 580,000.

Analyze the existing problems of happy net:

1. JavaScript files are written directly in the Web page

Happy Web Landing page has a large number of JavaScript code, such code is not conducive to maintenance, on the other hand, also do not use users to load the page. Roughly calculated, a happy landing page has more than 180 lines of JavaScript code, and the total code is only 336 lines, which means that the code in the JavaScript code accounted for 1/2.

2. Web page does not open gzip

According to the information returned by the file header can be seen, happy net should be built on Linux nginx, add gzip should not be difficult thing? And like HTML and static js/css these files, gzip can reduce at least 50% of the transmission volume, when this one, you can save millions of dollars per year.

Of course, some people would argue that gzip will aggravate the pressure on the server, and the client decompression time and reduce the file size of the transmission speed does not have much benefit. But I think, for static files, can be placed on a separate server, the server can compress files into the cache, so do not read IO, the response speed will improve. At the same time, although the user's bandwidth is already 512k ADSL above, but why I can not let users see our web page faster? 10,000 step back said that users really care about this fast for a few seconds, then why we can not reduce the pressure of bandwidth to save costs? If the savings of the money to reward employees, maybe they can bring me more surprises.

3. JavaScript doesn't do any processing

Happy net of JavaScript is really interesting, their developers code quality is good, at least the annotation is good, but the question is, you need to send these notes to the client, do you want to teach us how to write JavaScript code? Such code is sent to the client, both for bandwidth and will leak the site's code.

Happy Net's core JavaScript file Xn.core.js 105k, such a large annotation accounted for a lot of code, I tried to use Yahoo and Google's compression tools to compress, but because there are errors in the code can not be completed, so have to give up. But I estimate this JS, the most basic compression to remove empty lines and comments, you can reduce the size of about 1/5, if some confusion, should be in the 40k or so, if again gzip, should be only 15k within.

4. The picture file is too big

The login page has a 157k sys-bj2.jpeg file, oh, my God, it's so big. I downloaded this picture and found that this picture is actually a combination of several pictures. Their designers are actually trying to reduce the number of requests to the server, so merge a few pictures into one. However, they are wrong in this way.

We want to reduce the number of requests, is generally a small picture, generally a few K px* 36px below the small picture merge, rather than the large picture is also merged. Because of the number of small pictures, and large picture of the merging, will also increase the size of the picture. I will optimize this picture with PS, optimize to 66k, also did not find obvious distortion. So I think that is a larger picture, can also be optimized to 80k, not so 157k size of the image.

One more sentence, the total number of this picture is only 5 merged is completely unnecessary, and the picture biggest has 600px*255px, and the smallest only 10px*10px below, this kind of merger does not have any benefit, hundred harms and does not have a benefit!

Summarize

As a very large web site, the Web page structure is also very simple, it should be done smaller, such as within 100k. As you can see from my analysis, the main problems focus on javascript,gzip and pictures, and the overall code quality is OK. Of course, we are not only nit-picking, we should also see some good places, as follows:

1. Home processing is relatively in place, although JavaScript is not compressed, but the total size of only 108k

2. Fewer file requests, this and happy net itself, happy Network is not a Web page structure complex site, so the number of documents will naturally be less

3. static files and Web pages deployed separately

4. JavaScript annotations are good, but should not be sent to the client

Important recommendations:

1. Turn on gzip compression

2. Compress JavaScript and CSS, and cache these files

Finally, this analysis is written here, for the sake of the matter, and any site and related personnel have no relationship, hehe.

Source: Reader Conis submission, original address. Copyright NOTICE: This text grants the Moonlight blog to publish, other unauthorized website media reprint, needs to add the author website address http://iove.net, otherwise regards as the infringement.