Analysis of the performance of the front end of the web

Through the implementation of the first-hand web front-end performance of the data, and then every time the new version of the run, which will get a lot of data, for performance analysis to provide a basic input, but also should be integrated with a variety of tools to collect data from different directions, such as Showslow also support YSlow, Pagespeed,webpagetest and other test tools to pass on the data, so in the specific analysis from the longitudinal, horizontal to collect data, so that the results of statistical analysis can have a practical reference value. Of course, if you also find that other tools can also provide some performance data, can also be collected, such as: Httpanalyzer,httpwatcher all support the program call interface, it is convenient to collect data in the process of HTTP access. There are also features like the Firebug,ie Developer tool that can provide performance calls.


"工欲善其事, its prerequisite", tools have, the means of production also have-data, then the work behind us depends on our own labor to generate value. Performance tuning premise is the analysis of problems, analysis of the problem is the need for certain criteria, can not elephant people say that performance is not good, they say has been tuned to the optimal state of the best, only these standards or need to combine the actual situation to consider the application can not blindly. For example: All best practices will suggest less pictures of the display, search sites can be like this, but if it is an e-commerce site may not be so, otherwise the site is not necessary to do, and performance tuning is in these existing conditions, to ensure that the existing business functions of the premise to find specific can be optimized details, Help improve overall performance, not at the expense of business functions. For example: E-commerce Web site, although can not be reduced, but to convert the picture into an optimized format of the file, PNG is certainly better than BMP, Png8 better than GIF and so on.


So next is the best practice of the N Multi performance evaluation tool, learning and understanding these best practices is the first step to getting started, at least you can have an easy portal to start your work. Specific links are met under:
Yslow
Page speed
Dynatrace
In fact, probably understand, because the use of tool testing will prompt you what is not satisfied, the specific areas are not satisfied, very clear aspects.


Tools are often dead, and often many times these tools give high scores but the front-end performance is still slow, so rules are just one of the basic elements to ensure that the web has good performance, but not the only or most important. So after the evaluation tool we also have to see the specific loading completion time, of course, different page loading time is not the same, the main search is hundreds of K, and e-commerce home are more than 10 m or more, so their page load the full time certainly is not the same. However, it is not necessary, because we do not have to wait for all content to download and then present content to the customer, so still can speculate to "deceive" the user, such as: priority to display the content of the first screen, so that users will recognize the high performance of the page from the feeling. And the full load time of the page is also valuable, you can set a performance standard, according to different page properties to determine the full load time of a specific page should be in what range, but also as the next version of the benchmark data when testing.

Here are 2 important criteria come out, one is the user has the first feeling when the time, one is fully loaded the time spent, tuning is to reduce these 2 time, want to specific tuning before we have to understand the time of the difference between the time to determine the composition, This will provide the best page presentation solution for optimal performance.

first user feel time:
That is, the time when the browser starts rendering, and the browser starts rendering before parsing the HTML, parsing the CSS file, then generating the DOM tree, converting it into a render tree, and then laying out the "specific coordinates" for the nodes in the render tree, and then starting a layer of tree to start rendering, So each step can affect the first user feeling time. Like what:
When a single HTML file is too large, the parsing time will be longer
The CSS format is more efficient than inline, because it is loaded and applied all at once, and it should be in the head of the page when referencing CSS, since browsers generally do not wait until all the DOM is parsed to parse CSS or other things. So loading the CSS file ahead of time can speed up reaching the point where it can be rendered in advance.
Dom Tree generation is from the HTML, the normal HTML should be parsed once can be completed, but if the HTML has a JS call, then the parsing will be repeatedly re-adjust the structure of the DOM tree, which will affect the DOM generation time.
Render tree = DOM + CSS rendering instructions; So the conversion speed of this block depends on the content, the more layers you render, the more natural it will be.
The layout calculation time of the rendering tree depends on the number of nodes in the render tree, that is, the number of nodes in the DOM tree
And finally start rendering and showing what we see on the page.


The first user feels the time---to the---to finalize loading:
The user has the first feeling and does not end, and may be the first feeling is only the content on the page, but not the first screen of the contents of the full display, so to ensure a good first user feel, but also to protect the first screen of the other content is also the initial and time to be downloaded and displayed. So the first screen to use the external resources to first download, and the use of better performance of the resource server, the resources to be distributed in different servers "so you can download in parallel", and the larger picture can be cut into a number of small pictures, and then downloaded separately, so that even a larger picture can be displayed quickly.
Page All resources download finished before loading the onload event, that is, the page display after the completion of some things to do automatically, such as some of the site's pop-up, jumping pages, and so on, these operations are JS to do, and if the time to do JS run too long, so even if the page resource loading completed, the user is not very friendly, So JS running time is also a part of the front-end performance, not only in the loading of JS, the entire page other places of the JS performance is also to be considered, such as the process of a single Ajax request, a front-end operation of the use of JS, and JS In addition to time performance will have CPU, memory consumption performance considerations, These dynatrace tools are available.
In addition, during the whole process of downloading the external resources, we should try to avoid all kinds of request errors.

Of course, in addition to these other factors will affect the Web front-end performance, such as: Network speed, DNS server configuration, etc. how to seize the performance of the bottleneck is the most important, generally the simplest is to see the longest segment, and then according to the actual situation and the environment to determine whether the normal value, In order to determine whether there is the possibility of tuning and corresponding means.

Transferred from: http://blog.csdn.net/five3/article/details/7691365

Analysis of the performance of the front end of the web