HTML5 learning-performance

The performance interface provided by HTML5 accurately tells us the precise time (timestamp) of each processing phase of the current webpage when accessing a website page, so as to facilitate front-end analysis.

It is a direct implementation of the browser, which is much more accurate than setting Date. time or cookie in js on the webpage to analyze the webpage time.

Support for browsers: IE9 +, Chrome11 +, and Firefox7 +.

The following figure shows the performance. timing APIs provided by w3c.

Member:

. Navigation(An object called performanceNavigation .)

. Timing(This is an object called performanceTiming that contains many members)

 

PS:

1. performance: only the current html document can be detected. All objects are related to the current document. If we want to check the network condition of an image resource, it will not work. For example, if we want to monitor the user's access to our services, we can create only one iframe, And the url serves a specific address (unless the current page accessed by the user is the object we want to monitor ). Then you can monitor the network status of this request. Therefore, if you can consider using performance for monitoring, you need monitoring mechanisms such as sampling and time points. Otherwise, it will bring additional pressure to the server, not worth the candle. To monitor other resources, use ResourceTiming.

 

PerformanceNavigation (performance. navigation)Object Member

PerformanceNavigation. type

The return value should be one of 0, 1, and 2. Three enumerated values are required respectively:

0:TYPE_NAVIGATE(You can access a page through regular navigation, such as clicking a link or using the get method .)

1:TYPE_RELOAD(The user accesses the page through refresh, including calling the refresh interface in JS)

2:TYPE_BACK_FORWARD(You can use the back button to access this page)

Ps: in the draft, there are actually 3: TYPE_RESERVED (reserved, which is not accessed by the first three methods .)

 

PerformanceNavigation. redirectCount

A read-only attribute that returns the number of redirection requests on the current page. However, this interface has same-source policy restrictions, that is, it can only detect same-source redirection.

Bugs:

1. In IE9, when a page with the same source is connected to address B (whether it is in the same source as a and c) and then redirected to the same Source Page c, the navigation. redirectCount is actually 1. Instead of 0, this bug has been fixed by IE10 PP2.

 

PerformanceTiming (performance. timing)Object Member:

. NavigationStart

The time when the browser completes the unmounting of the previous document (that is, the start time of the page to be loaded ). If there is no previous document, the value of timing. fetchStart is returned.

It seems that only Chrome strictly abides by this draft. That is, if you do not refresh the page or enter an address on a tab to the specified page, the document is uninstalled.

Bugs:

1. IE9, when redirection occurs,. NavigationStart It will be 0. IE10 PP2 has fixed this problem.

2. IE9-IE10 PP2, one problem is refreshing the current page, or when the input address of a tab is not the same page, it is considered that the previous document exists, that is, its navigationStart is earlier than fetchStart. (Unless you enter the address again on the current page and press Enter. When you enter this page again, it is deemed that no previous document has been uninstalled ). In fact, navigationStart is the time of unloadEventEnd.

3. Firefox7-Firefox10, a new tab is also considered a valid document. So at this time, there will be a value, and it is not the value of fetchStart.

. UnloadEventStart

If the previous document is the same as the current document, return the time before the unload event of the previous document. If there is no previous document, or is not the same, return 0.

Bugs:

1. IE9-IE10 pp2, Chrome17-, unloadEventStart will return 0 when the previous document is redirected to the center of the current document and the first two documents are the same

. UnloadEventEnd

If the previous document is the same as the current document, return the time when the unload event occurred in the previous document. If there is no previous document or is not the same, return 0.

If HTTP redirection occurs, or something similar. In addition, if every redirection in the middle of the navigation is not in the same domain as the current document, 0 is returned.

Bugs:

1. IE9-IE10 pp2, Chrome17-, when a redirection occurs between the previous document and the current document, and when the first two documents are the same, unloadEventEnd will return 0.

. RedirectStart

If HTTP redirection occurs, or something similar. In addition, starting from the navigation, every redirection in the middle is in the same domain as the current document, the value of timing. fetchStart that starts redirection is returned. Otherwise, 0 is returned.

Bugs:

1. IE9-IE10 pp2, in page a, link to address B, and redirect to Page c with B source. RedirectStart, which will be 0. That is, the same-origin policy will actually consider the navigation page.

. RedirectEnd

If HTTP redirection occurs, or something similar. in addition, starting from the navigation, if every redirection in the middle is in the same domain as the current document, the last redirection will be returned at the time after the last byte data is received. otherwise, 0 is returned.

Bugs:

1. IE9-IE10 pp2, in page a, link to address B, and redirect to Page c with B source. redirectSEnd, will be 0. That is, the same origin policy, will consider the navigation page.

. FetchStart

If a new resource (this refers to the current document) is obtained or something similar occurs, fetchStart must return the time at which the user agent starts to check its related cache, in other cases, return the time when the resource is obtained.

. DomainLookupStart

Returns the time at which the user agent starts DNS query for the domain to which the current document belongs. if the request does not have a DNS query process, such as persistent connection, resource cache, or even local resources. then the value of fetchStart is returned.

Bugs:

1. the implementation of Firefox7-Firefox10 has errors. because of its value, it does not comply with the corresponding time node described by the standard. by default, navigationStart is used as the time start point and the redirection time is accumulated in the middle. and get the domainLookupStart time. even if the redirection is a non-same-source redirection. the time consumed will be calculated. then, this explains why domainLookupStart-fetchStart often gets a negative value when no redirection occurs, because navigationStart is earlier than fetchStart.

. DomainLookupEnd

Returns the time when the user agent ends the DNS query on the domain to which the current document belongs. if the request does not have a DNS query process, such as persistent connection, resource cache, or even local resources. then the value of fetchStart is returned.

Bugs:

1. Refer to the domainLookupStart bug. End.

. ConnectStart

Returns the user agent's request documents to the server, the time at which the connection was established. If the connection is a persistent connection, or directly obtain resources from the cache (that is, there is no connection with the server ). returns the domainLookupEnd value.

Bugs:

1. Firefox7 when the resource goes through the cache, that is, when no connection is created, the value of connentStart is 0.

2. firefox8-Firefox10, when no connection is created, the value of connetStart is the value of fetchStart, not the value of domainLookEnd. however, this involves an inertial problem because the cumulative time of domainLookupEnd has deviated from the standard, even if connectStart complies with the standard. it is also a problematic value.

. ConnectEnd

Return the User Agent Request Document to the server. After the connection is established successfully (note that it is not the time of disconnection .) that time. if the connection is a persistent connection or resources are directly obtained from the cache (that is, no connection is established with the server), the value of domainLookupEnd is returned.

Bugs:

Refer to the connectStart issue. connectEnd has the same issue.

If the connection fails and the user agent re-connects, connectStart and connectEnd should be related to the re-connection. connectEnd must include the connection establishment time and the SSH handshake protocol and SOCKS authentication time.

. SecureConnectionStart

Optional. if the user agent does not have the corresponding stuff, set this to undefined. if you have the HTTPS protocol, you need to return the time when the SSL handshake starts. if it is not HTTPS, 0 is returned.

Supplement: Firefox7-10, IE9-IE10 PP2, all wood has implemented this api. So it is always undefined.

. RequestStart

The time when the request document starts from the server, cache, and local resources is returned.

If the connection is disconnected in the middle of the request, and the user agent re-connects and re-Requests the resource, then requestStart must be the time corresponding to the new request.

Performance. timing does not contain a "requestEnd" interface for the end of a single table request. There are two reasons:

1. The end of the request that the user agent can determine does not represent the end time in the correct network plug-in. Therefore, designing this attribute is useless.

2. Some user proxies, If You Want To encapsulate an interface that represents the HTTP layer and the request End Time, the cost will be very high.

Bugs: 1. When Firefox7 is directly cached locally, the value of. requestStart will be 0. (Firefox8 has fixed this problem)

. ResponseStart

Returns the time when the user agent receives the first byte of data from the server, cache, and local resources.

. ResponseEnd

Returns the time when the user agent receives the last character, which is earlier than the time when the current connection is closed. The document may come from the server, cache, or local resource.

Supplement: this value should be read after we can ensure that it is actually after the end of Response. for example, window. onload. because of the chunked output. when the script is executed and the value is obtained, the response is not over. this results in inaccurate acquisition time.

Bugs: 1. IE10 PP2 and Chrome17. this value is read when the script in the middle of the document is executed. It will be 0. IE9 had no problem, but IE10 PP2 had a problem. 2. chrome16-, (Chrome17, this problem has been fixed .) enter the same address in the address bar and go to the local cache. the time of responseEnd is earlier than the time of responseStart. (I have to admit that this is a wonderful thing !) 3. chrome17-, from page a to address B, and then redirect to address c. If address c is cached. then. responseEnd time, which may be the time of ResponseStart. (well, we can place our hopes on Chrome18 .) Implementation differences: (this is not mentioned in the draft. when the document is output in segments, how to handle responseEnd in the process of receiving intermediate document data leads to browser implementation differences .)IE9-IE10 PP2, Firefox8-Firefox10, does not exist in the Response phase (non-cache .). the end time of receiving the first chunked package. responseEnd time. (This will lead to a series of problems in the future .) chrome17-, Firefox7, will not be updated during the receiving process of the segmented data. responseEnd time, whose value is always 0.

. DomLoading

When the user agent sets the "current document readiness" of the document to "loading.

(Current document readiness is actually the status corresponding to document. readyState API .)

Reference: http://dev.w3.org/html5/spec/dom.html#current-document-readiness

Bugs: 1. IE9. this value is always later than the final responseEnd value in the case of multipart output document. the bug of responseEnd-based IE implementation. this is also reasonable. implementation differences: iE9-IE10 PP2, when the document is output in chunked mode. domLoading always has a valid value after the last chunked is received by the browser. that is to say, the current situation in IE is. domLoading. in any case, it must be later than responseEnd. other browsers do not have this problem. however, this problem causes inaccurate DOM Parse calculation in IE. that is, domInteractive-domLoading may even get 0.

. DomInteractive

When the user agent sets the "current document readiness" of the document to "interactive.

In terms of standards, when domReady is in the "interactive" status, it means that the document Parsing is complete. as described in the standard, the first thing after the DOM tree is created is to set "current document readiness" to "interactive"

Reference: the first step in the http://dev.w3.org/html5/spec/the-end.html#the-end.

Bugs: 1. IE9, IE10 PP2. in the case of multipart output documents, this value is not the time after all documents are parsed, but the time when the first data block is parsed. It is a bug implemented based on responseEnd IE. this is also reasonable after the assumption. Implementation differences: (as not mentioned in the draft, what is the default value of document parsing when it is not completed, which leads to differences in browser implementation .)As I personally understand it, the resolution is not over. It should be 0. however, IE seems to have a different understanding of this thing. other browsers will be 0. however. IE9-IE10 PP2, it will be more interesting. even for multipart output, I get the value. it is also consistent with the domInteractive value after onload. the reason for this magic is that the official IE system bug is guided. this time is an incorrect reference, and the time when DOM parsing completes the first data block. instead of the entire document. however, it is necessary to find a deeper reason for the tangle. this is because the User Agent sets "current document readiness" to "interactive. this is always the case if IE is used to process html documents output in segments. This value is different from that of other browsers. It is understandable.

. DomContentLoadedEventStart

Returns the time when the DOMContentLoaded event occurs in the document.

See Step 1 in http://dev.w3.org/html5/spec/the-end.html#the-end. the difference between DOMContentLoad and DOMInteractive is two steps. one of them is that all open elements go out of the stack and check whether there are scripts to be run in the script list to be run. If so, execute until the list is empty. then trigger DOMContentLoad. the main task is to list the scripts to be run. some may be added in different browsers in different ways. for example, document. write the script for writing the Document Stream and the script deferr script .. therefore, we should know that the deferr script also requires him to postpone domContentLoaded, which is the most commonly used domReady. (at least this is the case with html5 specifications .)

. DomContentLoadedEventEnd

The end time of the DOMContentLoaded event in the document.

Supplement: the so-called event end time refers to the callback event if the DOMContentLoaded event is registered by the developer. the End time of this time minus the Start time. it will be the approximate event of the callback execution. of course, some browsers may have a 2-3 ms error. however, this time is negligible. in a similar case, there is a later one. loadEventStart, End. window. time consumed by all onload callbacks.

. DomComplete

When the user agent sets the "current document readiness" of the document to "complete.

PS: If a status of current document readiness is triggered multiple times, the corresponding time returned by the corresponding APIs domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete, it should be the first time this status is triggered.

. LoadEventStart

The time when the document triggers the load event. If the load event is not triggered, this interface returns 0.

. LoadEventEnd

The time after the document triggers the load event. If the load event is not triggered, this interface returns 0.

External: in addition, I look forward to Microsoft's private implementation, the msFirstPaint attribute. It is significant to monitor the time spent in browser first rendering.

Chrome also has some private support:

In chrome. loadTimes (), the following code obtains the basic running time information.

Var timing = performance. timing; var readyStart = timing. fetchStart-timing. navigationStart; var redirectTime = timing. redirectEnd-timing. redirectStart; var appcacheTime = timing. domainLookupStart-timing. fetchStart; var unloadEventTime = timing. unloadEventEnd-timing. unloadEventStart; var lookupDomainTime = timing. domainLookupEnd-timing. domainLookupStart; var connectTime = timing. connectEnd-timing. connectStart; var requestTime = timing. responseEnd-timing. requestStart; var initDomTreeTime = timing. domInteractive-timing. responseEnd; var domReadyTime = timing. domComplete-timing. domInteractive; // domComplete is sometimes 0var loadEventTime = timing. loadEventEnd-timing. loadEventStart; var loadTime = timing. loadEventEnd-timing. navigationStart; // when it is obtained too early, loadEventEnd is sometimes 0console. log ('time consumed to prepare the new page: '+ readyStart); console. log ('redirect redirection time consumed: '+ redirectTime); console. log ('appcache time consumed: '+ appcacheTime); console. log ('time consumed before unload: '+ unloadEventTime); console. log ('dns query time consumed: '+ lookupDomainTime); console. log ('tcp connection time consumed: '+ connectTime); console. log ('request time consumed: '+ requestTime); console. log ('Load the request to the DOM: '+ initDomTreeTime); console. log ('time consumed for interpreting the dom tree: '+ domReadyTime); console. log ('Load event time consumed: '+ loadEventTime); console. log ('total time consumed from start to load: '+ loadTime );

 

From:

Http://www.cnblogs.com/_franky/archive/2011/11/07/2238980.html

Http://www.th7.cn/web/html-css/201311/14802.shtml