Technik BlogMake websites faster
Page Speed Monitoring
Finding the root causes of website performance problems is a complex and time-consuming task. The analysis is very complex, as a number of factors influence the load time of a website on the route from the server to the user. In most cases, this is a hopeless task, if important metrics on different layers are not available. netsensor PageSpeed Monitoring helps you to find the needle in the haystack. The significant metrics in our Page Speed test show whether the cause is in the content delivery network or with embedded third-party objects or at the application level.
The Page Speed Test is performed automatically with the headless version of Google/Chrome, the currently most popular browser. The virtual window size is 1366×768 pixels, the most common screen resolution of browser systems. The load of the test systems is constantly monitored to prevent incorrect test results. This ensures that the results are comparable with the loading times of a real user.
All monitored and checked metrics are grouped according to the test and displayed in the summary area. The checks are performed by using configured threshold values and provide information about the state of a metric. According to the status of a metric, events are triggered and listed in the event overview. When an event occurs, all measured values of a test are stored in a metric log. These logs are kept for one year and are displayed when selecting an event. Events can trigger escalation processes such as notifications or automatic recovery procedures.
It is also possible to save the metric logs without triggering events (recording). This function is also controlled by configured threshold values and is primarily used for a subsequent analysis of anomalies.
- Load Status
Indicates the return code of the test. Possible values:
OK All files could be loaded (no timeouts of failed requests (status <= 400)
COMPLETE At least one File with status >= 400 (e.g. file not found)
TIMEOUT No answer from server within timeout
ERROR DNS or other failure
- Time To First Byte
Time spent waiting for the initial response. This time captures the latency of a round trip to the server in addition to the time spent waiting for the server to deliver the response.
A slow time to first byte (TTFB) is recognized by a high waiting time. It is recommended that you have this under 200ms. A high TTFB reveals one of two primary issues. Either:
- Bad network conditions between client and server, or
- A slowly responding server application
Ideally, the metrics for different network paths should be almost identical. If there is and the TTFB is high, then the application needs to be optimized for response speed. This could mean optimizing database queries, implementing a cache for certain portions of content, or modifying your web server configuration. If the TTFB is low in the local test (CDN bypass) then the networks between the monitoring device and the CDN or between CDN and the server are the problem.
- Page Loaded
Interactive Metric Charts
Numerical metrics can be displayed in interactive charts. The charts are divided into two parts. The Plot Area allows you to zoom the metrics. The navigation area supports panning in the recorded history.
Page Load Summary
The overview provides the most important information about the test. This includes the URL, the number of requests for web objects (Items) to render the initial view and the total download size (the combined size of the response headers plus the response body, as delivered by the server). If available and recorded by the test, this data will also be listed separately for external domains.
- DOM Loaded
DOM Loaded corresponds to DOMContentLoaded. The browser typically fire this event, once the HTML is parsed, the document tree is built, and all non-async scripts have been executed (including scripts with defer). This can happen before any resources (images, iframes, stylesheets, fonts, frames) are loaded. Most developers know this event through jQuery’s ready(), which lets you attach callbacks to be executed once the document is ready to read and manipulate.
- Page Loaded
Page Loaded is measured once all resources are downloaded (including async scripts) and the onLoad event is fired. This time indicates that all of the processing is complete and all of the resources on the page (images, etc.) have finished downloading - in other words, the loading spinner has stopped spinning. Note that all of the resources doesn’t include AJAX requests, and dynamically added resources.
For external domains, Page Loaded corresponds to the total transfer time of all associated objects for this domain.
Page Item Report
The Page Item Report shows a list of all the network requests made in the course of loading the page. Each request is displayed in its own row and shows all the metrics in detail for each individual Web object. The request list also displays a timeline for the different parts of each request. Each timeline is given a horizontal position in its row relative to the other network requests, so you can see the total time taken to load the page. More information about the Web object and the corresponding HTTP request and response header is shown in the detail view.
Start Time of each network request relative to the final load event of the HTML document. Almost same time values indicates that requests was sent in parallel. Google/Chrome can send up to 6 concurrent request to a domain.
Time spent performing the DNS lookup. Every new domain on a page requires a full roundtrip to do the DNS lookup.
Time it took to establish a connection, including TCP handshakes/retries and negotiating a SSL. This metric is shown only if a TCP/IP connection is established. If the connection is reused for another request, this metric does not appear in that request's timeline.
Time spent receiving the response data.
- HTTP Details
The Headers window displays the resource's request URL, HTTP method, and response status code. Additionally, it lists the HTTP response and request headers and their values, and any query string parameters. Especially in test mode, the Response Header contains the field Selected-Node. The value refers to the IP address of the processing server node. This allows the correlation of the results with server log files for further analysis.