Time to First Impression<\/strong><\/p>\n This is the time from when the URL is entered into the browser until the user has the first visual indication of the page that gets loaded. It depends on the initial HTML document when the browser can start drawing content. There are different Best Practices available that talk about different strategies. Google for example downloads a minimalist page to provide a fast first visual rendering. It then delays loads more content after \u2018onLoad\u2019 or even later when the user starts interacting with the page.<\/p>\n The recommended value for this KPI is like this \u2013 great if < 1s, acceptable if < 2.5s and slow if > 2.5s<\/p>\n DOM Ready Time<\/strong><\/p>\n The \u2018DomReady\u2019 event is fired when the DOM content has loaded and the program can access all HTML Elements without waiting for all those images to load also, which just means finding out when the document’s DOM tree has fully initialized, versus the entire document and every object in it. A classic example is the insertion\/ deletion of nodes via the DOM, which can in fact be done sooner rather than later, when the DOM has loaded versus the document itself (i.e. firing of \u2018window.onload\u2019 event).<\/p>\n Other resources, such as images, may not have been downloaded when this event occurs. This corresponds to the DOM Content Loaded in Mozilla Firefox and IE 9.<\/p>\n Page Load<\/strong><\/p>\n This is the time until the browser triggers the onLoad event which happens when the initial document and all referenced objects are fully downloaded. Fully Loaded<\/strong><\/p>\n This is the time until all onLoad JavaScript handlers have finished their execution and all dynamically or delay loaded content triggered by those handlers has been retrieved. It is sometimes a bit hard to identify the exact time when the page is fully loaded especially when JavaScript handlers use reoccurring timeouts that constantly modify the page, e.g.: to implement a ticker<\/p>\n The recommended value for this KPI is like this – great if < 2s, acceptable if < 5s and slow if > 5s<\/p>\n HTTP Load<\/p>\n It marks the completion of all HTTP or HTTPS requests made by the page<\/p>\n Network Time KPIs<\/strong><\/p>\n KPIs listed in this section measure the time taken by various activities during processing an HTTP request by Browser.<\/p>\n Following is a sample timeline for a fictitious http request. It contains all activities that can be associated with HTTP requests. All activities listed in the picture below are explained in detail later. It needs to be noted that not all activities are present in every HTTP request. For example, DNS Lookup Connect might not be required if it is already resolved \/ connected. Similarly, \u201cCache Read\u201d for 304 response code would not be present if content is modified and served from web \/ application server. The timeline width associated with each activity is for sample purpose only.<\/p>\n Blocked Time<\/strong><\/p>\n Cache Read Time<\/strong><\/p>\n DNS Lookup<\/strong><\/p>\n Connect Time<\/strong><\/p>\n Depending on the browser and the number of resources that are served by a domain the browser establishes one or multiple connections to each domain that hosts resources for the page. Connect Time is the time it takes to establish the TCP\/IP connection to the web server. Connections usually stay open unless the Web Server directs the browser to close the connection (Connection HTTP Header). When using secure communication via SSL, the Connect Time also includes the time of the SSL handshake. High Connect Time can therefore have the following reasons: slow network connection to the web server, usage of SSL and not allowing the browser to keep the connection open.<\/p>\n An excessively high number of TCP connects may indicate that HTTP persistent connections, also known as keep-alive connections, have not been correctly configured on the server. These long-lived HTTP sessions allow multiple requests to be sent over the same TCP connection, and in some cases have been shown to result in an almost 50% speed up in latency times for HTML documents with lots of images.<\/p>\n Send Time<\/strong><\/p>\n Send Time is the time required to send the HTTP request message to the server and will depend on the amount of data that is sent to the server. For example, long Send times will result from uploading files using an HTTP POST<\/p>\n Wait Time \/ Server Time<\/strong><\/p>\n Wait is the idle time spent waiting for a response message from the server. This value includes delays introduced due to network latency and the time required to process the request on the web server.<\/p>\n High Server Time means that the Web\/Application Server required a long time to process the request. This is particularly relevant with requests that trigger application logic to be executed on the application server where higher Server Times can be expected \u2013 especially under heavy load periods. Monitoring Server Time is important to identify bottle necks, performance and scalability problems with the application server. It is usually easier to scale static content delivery by adding more web servers with load-balancers or by using a Content Delivery Network. It is not that easy to scale a dynamic application in the same way. Keeping an eye on this metric is important.<\/p>\n Receive Time<\/strong><\/p>\n Receive Time is the time taken to read the response message from the server. This value will be depending on the size of the content returned, network bandwidth and whether HTTP compression was used.<\/p>\n Time to First Byte (TTFB)<\/strong><\/p>\n It is the duration from the initial network request being initiated by the browser to the first byte being received from the server. It includes TCP connection time, the time to send the request and the time taken to get the first byte of the response message.<\/p>\n Network Time<\/strong><\/p>\n Network is the total duration of all network related operations for an HTTP request.<\/p>\n Requests Elapsed Time<\/strong><\/p>\n It is time when http request has been invoked at the final request. It can be calculated as \u201cBlocked Time\u201d + \u201cNetwork\u201d. It might be the case that sending of first request takes time and that\u2019s why \u2018Blocked Time\u2019 becomes important.<\/p>\n # Network Roundtrips<\/strong><\/p>\n This is the total number of network requests that get downloaded with the website. The ultimate goal is to keep this number as low as possible in order to reduce roundtrips. Monitoring this KPI gives an early indication on newly introduced content that can negatively impact page performance.<\/p>\n Great sites require fewer than 40 requests, acceptable are up to 100 requests. Sites with more than 100 HTTP Roundtrips are considered bad.<\/p>\n Some entries do not cause a network round trip because either an error occurred (e.g. ERROR_INTERNET_NAME_NOT_RESOLVED) or because no network request was required (e.g. entries resulting in a (Cache) response<\/p>\n # XHR (AJAX) Requests<\/strong><\/p>\n The total number of XmlHttpRequests (XHR) sent via JavaScript to retrieve data asynchronously from the server. Monitor this KPI to identify sudden changes in dynamic content retrieval via XHR. Some JavaScript frameworks provide update mechanisms with the server-side and use XHR for these purposes. Depending on the configuration it can end up with too many XHR requests that not only impact client side performance but also cause additional load on the application server.<\/p>\n Total Number of HTTP 300s\/400s\/500s<\/strong><\/p>\n This is the total number of requests to the server that responded with an HTTP Status Code of 300 (Redirect), 400 (Authorization Problem) or 500 (Server Error). These are requests that should be avoided as they have a negative impact on the page load time. The root cause of these problems is often server-side related implementation, configuration or deployment issues.<\/p>\n Number of Domains<\/strong><\/p>\n The number of domains that host the web sites resources is important as it affects DNS, Connect and Wait Time. Additional domains that are utilized to download resources will have a direct reduction in the wait time because the browser ultimately uses more physical connections. This can have an opposite effect when more DNS lookups are needed and more time is spent to establish the physical connections.<\/p>\n Number of Single Resource Domains<\/strong><\/p>\n Single Resource Domains should be avoided as you pay a high price for performing the DNS and Connect to download a single resource. It is sometimes not avoidable when downloading content from external content providers (such as ad-services). When having the deployment under your own control you want to make sure not to have single resource domains.<\/p>\n # Resources with No or Past Date Caching<\/strong><\/p>\n Number of network roundtrips increases because of it.<\/p>\n # Resources Having Short Expires Headers<\/strong><\/p>\n Number of network roundtrips might increase because of it.<\/p>\n Hit Count<\/strong><\/p>\n The number of times that the browser has read content from the cache entry.<\/p>\n Downloaded Data<\/strong><\/p>\n This is the total amount of data that has been received from web server(s) (i.e. response headers and content). In the case of HTTPS connections this includes the overhead of the SSL encryption process. Uploaded Data<\/strong><\/p>\n The total amount of data that has been sent to web server(s) (i.e. request headers and POST data). In the case of HTTPS connections this includes the overhead of the SSL encryption process.<\/p>\n Total size of Image \/ CSS \/ JS<\/strong><\/p>\n Besides keeping track of the total page size it is important to look into the sizes of the individual content types such as Images, Style Sheets and JavaScript files. With this it is easier to spot the main contributors of page size.<\/p>\n The AJAX Edition makes the assumption that most Images, CSS and JS files served from the same domain can be merged so that we do not end up having more than 1 CSS, 6 Images and 2 JS files from the same domain.<\/p>\n Average HTTPS Overhead<\/strong><\/p>\n This is the average overhead in bytes of each HTTPS request. If this value is high (more than a few hundred bytes), it may indicate that the server is incorrectly configured and is causing an excessive number of HTTPS renegotiations.<\/p>\n Compression Saving<\/strong><\/p>\n This is the reduced total number of bytes and percentage which received content was compressed by HTTP compression.(i.e. “gzip” or “deflate”).<\/p>\n","protected":false},"excerpt":{"rendered":" For \u2018Single User Load\u2019 testing, web analyzers like HTTP Watch, DynaTrace etc. are used while browsing through the scenarios and the page load time and various other KPIs are collected. The KPIs are analyzed further for tuning the web page response time. Following are the key KPIs that can be used for making an analysis […]<\/p>\n","protected":false},"author":2,"featured_media":13143,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[20,214,8,29,81],"ppma_author":[3736],"class_list":["post-11","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-performance-testing","tag-load-testing","tag-performance-testing","tag-performance-testing-tools","tag-regression-testing","tag-software-performance-testing"],"authors":[{"term_id":3736,"user_id":2,"is_guest":0,"slug":"admin","display_name":"Cigniti Technologies","avatar_url":{"url":"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/120X120-1.png","url2x":"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/120X120-1.png"},"user_url":"http:\/\/www.cigniti.com\/","last_name":"Technologies","first_name":"Cigniti","job_title":"","description":"Cigniti is the world\u2019s leading AI & IP-led Digital Assurance and Digital Engineering services company with offices in India, the USA, Canada, the UK, the UAE, Australia, South Africa, the Czech Republic, and Singapore. We help companies accelerate their digital transformation journey across various stages of digital adoption and help them achieve market leadership."}],"_links":{"self":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts\/11"}],"collection":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/comments?post=11"}],"version-history":[{"count":0,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts\/11\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/media\/13143"}],"wp:attachment":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/media?parent=11"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/categories?post=11"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/tags?post=11"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=11"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nJavaScript onLoad handlers use this event to manipulate the current initial state of the page. This event is one of the options explained earlier to download additional or delay load content.
\nThe recommended value for this KPI is like this \u2013 great if < 2s, acceptable if < 4s and slow if > 4s
\nThe significance of an \u2018onload\u2019 event is that all resources associated with web pages are downloaded and it is in ready \/ working state for starting the application.<\/p>\n![\"\"](\"https:\/\/cigniti.com\/blog\/wp-content\/uploads\/2014\/02\/network-time-kpis-image4.jpg\")
<\/p>\n\n
\n
\n
HTTP Requests KPIs<\/h3>\n
Size Related KPIs<\/h3>\n
\nThis is the total size of all resources that make up your page. It is important to keep track of the total payload size. The larger web sites become the longer it takes to download. Changes to the page \u2013 such as adding images or new java script libraries \u2013 can have a significant impact on download time.<\/p>\n