- Scrub across the time range chart to zoom in on a particular time period. Click a blue pip in user experience or milestone breakdown to go to the drill-down page where you can see complete results for the script execution. An alert banner will appear on this page if the web path is targeting a webserver that does not respond to ICMP, and you’ll be prompted at that time to select a supplementary target.
- Move along the timeline to see results from a different execution. See how the server-network-browser breakdown works in Workflow execution performance.
- Time spent in a browser queue waiting for a network connection.
- DNS lookup
- Time spent resolving the domain name in the url.
- Time spent establishing a TCP connection with the web server.
- Time spent waiting for the first HTTP response from the web server.
- The time it took for the server to send the entire response starting from the first byte received.
Workflow execution performance
- Network time
- Comprised of two parts: the time it takes to establish a connection and send the resource request to the server, and the time between receiving first and last byte of the response. Modern browsers download many resources in parallel; so, while network time is calculated for each resource in the milestone and then totaled, concurrent times are counted only once.
- Server time
- The time between the server receiving the request and the browser receiving the first byte of the response, adjusted for network latency. As with network times, server activity may be happening in parallel for many resources, so we count concurrent times only once.
- Browser time
- The time it takes for the APM internal browser to render the page after all the content is received; what’s important to understand is that browser rendering begins after the first byte is received, and occurs in parallel to all of the other activities you see in the milestone performance waterfall chart.
So how do you take advantage of the network, server, browser breakdown? What you want to do is look at each time as a percentage of the total page load time. Find the biggest color block on the bar graph and speed up that element because chances are it’s the one slowing things down; when you do, you’ll see that color block get smaller and the others get bigger. If performance is still slow, repeat. This is how the workflow execution breakdown is useful: it keeps you focused on the elements that are most impacting performance so that you can resolve issues faster. Keep in mind that, out of context, the individual times won’t give you much information about an element’s impact on page load; arbitrarily shaving off server time might not result in noticeably faster page load; this is especially true for browser time, since it’s concurrent with other activities.