7 days to build the front-end performance monitoring system

Reprint Address: http://www.uis.cc/content-9-137-1.html

Introduction

Before the W3ctech into the name of the enterprise-Baidu front-end FEX special session had "bombast" said after listening to the lecture after seven days can build their front-end performance monitoring system, since said out also can not promise. Previous article The beauty of the front-end data I believe that we have a certain understanding of the front-end data, the following on the performance of the data and its monitoring to elaborate. start the action .

The performance in this article mainly refers to the Web page load performance, not to the performance. Do not worry, the next "every day" with me into the front-end performance of the world. Day 1 Why you should monitor performance.

"If You cannot measure it, you cannot improve it" ———— William Thomson

This is one of the most fundamental issues, why pay attention to and monitor front-end performance. For the company, performance is directly related to the interests of a certain extent. Abroad, there are many research data in this field:

Performance	Benefits
Google Delay 400MS	Search Volume down 0.59%
Bing delayed 2s	Revenue is down 4.3%.
Yahoo Delay 400MS	Flow down 5-9%
Mozilla page open to reduce 2.2s	Download increased by 15.4%
Netflix opens gzip	Performance boost 13.25% bandwidth reduction 50%

Data Source: Http://www.slideshare.net/bitcurrent/impact-of-web-latency-on-conversion-rates http://stevesouders.com/ Docs/jsdayit-20110511.pptx

Why performance can affect the company's earnings. The root cause is still the performance impact on the user experience. The delay of loading, the operation of the cotton, etc. will affect the user experience. In particular, the user has low tolerance for page response delays and connection interruptions, especially on the mobile side. Imagine you holding a cell phone to open a Web page want to see a message but loaded half a day of mood, you are likely to choose to go directly to change a Web page. Google will also load the speed of the page as a weight of SEO, page loading speed on the user experience and SEO impact of a lot of research.

Although performance is important, the iterative process of development will inevitably be overlooked, performance will be accompanied by the product iteration and attenuation. Especially on the mobile side, the network has been a big bottleneck, and the page is more and more large, more complex functions. There are not a few simple gold rules can be done to optimize performance, we need a performance monitoring system for continuous monitoring, evaluation, early warning page performance status, the discovery of bottlenecks, guidance optimization work. what tools are available for day 2.

工欲善其事 its prerequisite

Page performance evaluation and monitoring has a lot of mature and excellent tools, reasonable use of existing tools can achieve a multiplier effect. Here's a quick introduction to a few common tools: Page Speed

Page speed is a Google-developed tool for analyzing and optimizing Web pages that can be used as a browser plugin. The tool detects the site based on a series of optimization rules, and gives detailed advice on the rules that are not passed. Similar tools such as YSlow are recommended to use the Gtmetrix Web site to view the results of multiple analysis tools, as shown in the following illustration:

webpagetest

Webpagetest is a very good Web front-end performance testing tool, has been open source. You can use the online version or build your own. There are also domestic use of webpagetest built performance test platform, the recommendation of the use of Ali Test (the following example to use the testing of Ali).

With Webpagetest, you can master the data of waterfall flow, performance score, element distribution and view analysis in the process of loading the website. One of the more intuitive view analysis features can directly see the page loading stages of the screenshot:

Note: The entire test results please click here

The above diagram visually shows two important points of view of the Browsing class Web site: Screen time and first screen time, that is, how long the user can see the content on the page, and how often the first screen rendering is complete (including the elements such as picture loading complete). These two points directly determine how long the user waits to see the information they want to see. Google optimization proposal also mentions the reduction of non-first-screen use of CSS and JS, as soon as possible to the first screen rendering. Phantomjs

Phantomjs easily brings monitoring into the ranks of automation. Phantom JS is the WebKit of a server-side JavaScript API that makes it easy to implement web automation testing. PHANTOMJS requires some programming work, but also more flexibility. The official document already has a complete sample of getting the page load har file, specifying that you can view this document, as well as a lot of domestic information about this tool. In addition, the tapir of Sina to eat the development of similar tools BERSERKJS is also very good, but also intimate to provide the first screen statistics function, the specific article can be viewed here. Day 3 Start online real user performance monitoring

Take the director and avoid the short

There must be some students to ask, since there are so many excellent tools, why to monitor the online user real access performance.

We find that the tool simulation test will deviate to some extent from the real situation, sometimes can not reflect the performance fluctuations. In addition to screen first screen, such as the basic indicators, product lines are also concerned about product-related indicators, such as advertising visible, search available, check-in available, and so on, these functions directly with the page JS loading related, through tools more difficult to simulate.

In order to continuously monitor the user access situation and the function of the page in different network environment, we choose to embed JS in the page to monitor the real user access performance on the line, at the same time using the existing analysis tools as a support, the formation of a complete and diverse data monitoring system for product line evaluation and optimization to provide reliable data.

For a simple comparison of different monitoring methods, you can view the following table:

type	Advantages	Disadvantage	Sample
Non-intrusive	Complete indicators, client-side active monitoring, competition products monitoring	Unable to know the performance impact user number, sampling less easily distorted, unable to monitor complex application and subdivision function	Pagespeed, PHANTOMJS, Uaq
Invasive type	Real mass user data, able to monitor complex applications and business functions, user clicks and area rendering	Need to insert script statistics, network indicators are not complete, can not monitor competing products	DP, Google statistics

Day 4 How to collect performance data.

Monitor users ' pain points

What are the indicators on line monitoring? How to better reflect user perceptions.

For the user, he felt why the page is not open, why the button is not clicked, why the picture shows so slow. For engineers, it is possible to focus on browser load process metrics such as DNS queries, TCP connections, service responses, and so on. According to the user's pain point, the browser loading process to extract four key indicators, that is, screen time, the first screen time, the user can operate, the total download time (definition visible on the article). How are these indicators counted? determining the starting point of statistics

We need to start counting when the user enters the URL or clicks on the link, because it can measure the user's waiting time. If your user's high-end browser is high, you can use the navigation timing interface directly to get the statistical starting point and the various stages of the load process. In addition, the cookie can record the time stamp of the way to statistics, it is necessary to note that the cookie method can only be counted in the jump data. Statistics screen time

Screen time is the first time users see content, also known as the first rendering time, the chrome version has a firstpainttime interface to obtain this time-consuming, but most browsers do not support, must think of other ways to monitor. Careful observation of Webpagetest view analysis found that the screen time appears in the head outside the chain of resources loaded near the end, because the browser only load and parse the head resources will really render the page. Based on this, we can approximate statistic screen time by acquiring the moment when the head resource is loaded. Although not precise, it considers the main factors that affect screen: the first byte time and the header resource load time.

How to Count head resource loading? We found that the head embedded in the JS usually need to wait for the front of the js\css loaded before it will be executed, is not in the browser head in the bottom plus a "JS statistics header resource loading end point." You can test with a simple example:

<! DOCTYPE html>
 
After the test found that the statistics of the head load time is just the same as the Ministry of the resources download time is similar, and replaced by a very long execution time JS will wait until the completion of JS statistics. This method is feasible (for specific reasons to view browser rendering principle and JS single-threaded related introduction). Statistics first screen time

The statistics of the first screen time is more complicated, because it involves many kinds of elements such as pictures and asynchronous rendering. Observation of the load view can be found to affect the first screen of the main factors of the loading of the picture. You can get the time to finish the first screen rendering by counting the load time of the picture in the first screen. The statistical process is as follows:

First-screen location call API start Statistics-> binding the first screen of all pictures in the Load event-> page after loading to determine whether the picture is in the first screen, find the most slowly loaded a-> first screen time
 
This is a simple statistical logic in the case of synchronous loading, and also need to pay attention to several points: the page exists in the case of an IFRAME also need to judge load time GIF pictures in IE may repeatedly trigger the load event should be excluded asynchronous rendering in case of asynchronous fetch data inserted after the first screen CSS important background image can be requested by JS request picture URL to statistics (browser will not repeat loading) no picture to the statistics JS execution time, that is, the text appears time statistics users can operate and total download

The user can operate by default to count Domready times, because the event action is usually bound at this time. For the use of modular asynchronous loading JS can be in the code to actively mark the loading time of important JS, which is also the statistical method of product indicators.

The total download time can be used to count the onload time, which can be used to count the time-consuming loading of the resources that are loaded synchronously. If there is a lot of asynchronous rendering on the page, you can use the full time of the asynchronous rendering as the total download time. Network Metrics

Network type judgment

For the mobile end, the network is the most influential factor of the page loading speed, it is necessary to adopt the corresponding optimization measures according to different network, for example, for 2G users to adopt a simple version. However, there is no interface on the web to get the user's network type. In order to obtain the user network type, we can judge the corresponding network of different IP segments by means of velocity measurement. For example, there is a classic Facebook program. After the analysis of the velocity, the user's loading rate has obvious distribution between the areas, as shown in the following figure:


Each distribution interval just corresponds to the different network type, after with the client's auxiliary test, the success rate can be above 95%. With the corresponding rate data of this IP library, we can judge the user network type according to IP when analyzing the user data.

Network Time consuming statistics

Network time-consuming data can be obtained by reference to the previous navigation Timing interface, similar to the resource Timing, to get the load time of all static resources on the page. With this interface, you can easily get DNS, TCP, first byte, HTML transmission, and other time-consuming, navigation timing interface diagram is as follows:


The above focuses on the Data acquisition section, which is also the most critical part of the system, only to ensure that the data can reflect the real user perception, can be the right remedy to enhance the user experience. After the data is collected we can unify the reports after the page has been loaded, such as the example: