Web-Layer Tests

Web layer tests are designed to monitor and evaluate the performance, availability, and user experience of web-based services, such as websites, web applications, and APIs. These tests focus on the application layer and emulate user interactions or browser behaviors to provide insights into how web services perform from various global or internal vantage points. Web layer tests assess the end-user experience of web services by measuring availability, response times, and performance. They help organizations monitor critical web applications, troubleshoot issues, and optimize performance.

Web Layer tests include:

HTTP Server Tests: Monitor single HTTP/HTTPS requests to an endpoint.
Page Load Tests: Perform browser loading of a web page and its resources.
Transaction Tests: Perform multi-step user interactions or API sequences.
FTP Server Tests: Monitor file transfer operations on FTP, FTPS, or SFTP servers.

HTTP Server Test

For more information about HTTP server tests, see HTTP Server Tests.

API Test

For more information about API tests, see API Tests.

Page Load Test

Page load tests are designed to monitor the performance and availability of web pages by loading a page and its associated resources (e.g., images, scripts, CSS) in a browser. These tests collect metrics to provide insights into user experience and web performance. Page load tests use te-chromium, a browser based upon the Chromium browser codebase. A complete explanation is available here: Navigating Waterfall Charts for Page Load and Transaction Tests.

Instant page load tests provide a screenshot upon test completion, while scheduled page load tests only provide screenshots when errors are recorded. A list of permitted content types is available in Permitted Content Types.

Use Cases for Page Load Tests

Page load tests are critical for organizations aiming to optimize web page performance, ensure user satisfaction, and troubleshoot issues affecting page loading. The primary use cases include:

Monitoring web page performance to ensure web pages load quickly and reliably to provide a seamless user experience
Troubleshooting slow page loads to diagnose why users experience delays when loading web pages
Evaluating CDN performance in delivering web page resources globally.
Monitoring the impact of third-party resources (e.g., ads, analytics scripts) on page load performance.
Identifying misconfigurations or security issues affecting page loads, such as SSL certificate problems.
Pre-Deployment validation to test web pages in staging environments before public release

Page Load Test Metrics

Page load tests collect metrics that capture the entire process of loading a web page, from initiating the request to rendering all resources.

Page Load Time (ms): The total time to fully load the web page, from initiating the request to completing the rendering of all resources.
Completion (%): The percentage of Page Load Test executions that successfully complete without critical errors.
Timeouts (count): The number of test executions that fail due to timeouts, where the page or a resource fails to load within the configured test timeout period.
Errors (count): The number of test executions encountering errors, such as HTTP status codes (e.g., 404 Not Found, 500 Internal Server Error), DNS failures, or script errors, excluding timeouts.
Chromium Version: The version of the Chromium browser engine used by the ThousandEyes agent to execute the Page Load Test, specified as a version number.
Page Size (bytes):The total size of all resources (e.g., HTML, images, scripts, CSS) loaded during the Page Load Test, measured in bytes, including headers and compressed content.
Components (count): The number of individual resources (e.g., HTML files, images, JavaScript files, CSS files) requested and loaded during the Page Load Test.
DOM Load Time (ms): The time from initiating the request to when the Document Object Model (DOM) is fully parsed and the DOMContentLoaded event fires, excluding the loading of sub-resources like images or scripts.

Page Load Test Views

Timeline (Page Load Layer)
Map
Table
Waterfall: A detailed breakdown of the load sequence, showing the timing and status of each resource.

Below is a page load test targeting Google:

For more information, see Using the Page Load View.

Other Included Tests

HTTP server test
Agent-to-server test
BGP test

Transaction Test

Transaction tests are web layer tests designed to emulate multi-step user interactions in a browser or API sequences on web services, mimicking real user journeys such as logging into a website, completing a purchase, or executing a series of API calls. Unlike HTTP server tests, which focus on single requests, or page load tests, which measure a single page rendering, transaction tests interact dynamically with web pages or APIs, providing deeper insights into user experience and application functionality. Transaction tests use the Selenium WebDriver engine. Test scripts are created using JavaScript, from the ThousandEyes Recorder IDE or within the test settings. You can set screenshots and markers at different points within the script to identify important points within the transaction workflow.

For more information, see Transaction Tests.

Use Cases for Transaction Tests

Transaction tests are ideal for scenarios requiring validation of multi-step interactive web workflows. Key use cases include:

Emulating user actions like logging in, searching, or checking out to ensure critical workflows are functional and fast
Testing sequences of API calls (e.g., authentication, data retrieval) to ensure reliability and performance
Diagnosing why users encounter errors or delays in web applications

Transaction Test Metrics

Transaction tests collect metrics to assess the performance and success of scripted user journeys or API sequences.

Transaction Time (ms): The total time to complete the entire scripted transaction, from the start of the first action to the final step’s completion, measured in milliseconds.
Completion (%): The percentage of Transaction Test executions that successfully complete all scripted steps without critical errors.
Timeouts (count): The number of test executions that fail due to timeouts, where a scripted step exceeds the configured timeout period.
Assert Errors (count): The number of test executions failing due to assertion failures, where a scripted validation check (e.g., check(response.status === 200) or text presence on a page) does not meet the expected condition.
Page Errors (count): The number of test executions encountering page-level errors, such as HTTP status codes (e.g., 404 Not Found, 500 Internal Server Error) or browser errors (e.g., JavaScript exceptions) during page loads within the transaction.
Other Errors (count): The number of test executions failing due to miscellaneous errors not classified as timeouts, assert errors, or page errors, such as script execution errors (e.g., syntax errors in the transaction script), network connectivity issues, or browser-specific issues.
Markers (count): The number of custom-defined checkpoints (markers) in the transaction script that are successfully reached during test execution, used to track progress through specific steps or events (e.g., "Login Completed", "Form Submitted").
Average Marker Timing (ms): The average time taken to reach each custom-defined marker in the transaction script across test executions, measured in milliseconds, reflecting the duration of individual steps or events.
Screenshots (count): The number of screenshots captured during test execution, triggered at specific points in the transaction script (e.g., after a page load, form submission, or error) to visually document the application’s state.

Transaction Test Views

Timeline (Transaction Layer)
Map
Table
Waterfall: A detailed breakdown of the load sequence, showing the timing and status of each resource.

The transaction test below performs a login and a search.

Other Included Tests

HTTP server test
Agent-to-server test
BGP test

For additional guidance on creating a Transaction test, see

FTP Server Test

FTP server tests are designed to monitor the availability and performance of FTP, FTPS, or SFTP servers by measuring file transfer operations (e.g., uploads, downloads, directory listings). These tests collect metrics such as availability, response time, throughput, and error details to provide insights into the health and efficiency of file transfer services. To learn more about FTP, see File Transfer Protocol.

Use Cases for FTP Server Tests

Monitoring FTP Server availability and accessibility to ensure FTP, FTPS, or SFTP servers are consistently available for users or automated systems to access files
Assessing file transfer performance to measure the speed and efficiency of file uploads, downloads, or directory listings to ensure optimal user experience
Troubleshooting file transfer issues to diagnose why file transfers fail or perform poorly for users or applications
Validating secure file transfer protocols (FTPS/SFTP) to ensure they are properly configured and perform reliably

FTP Server Test Metrics

FTP server tests collect metrics that capture the performance and success of file transfer operations, covering the entire request lifecycle from DNS resolution to data transfer completion.

Availability (%): Percentage of successful FTP, FTPS, or SFTP operations (e.g., file upload, download, directory listing), defined as receiving a 2xx FTP reply code.
Response Time (ms): Total time from initiating the FTP request to receiving the first byte of the response (time-to-first-byte), encompassing DNS resolution, TCP connection (or SSH for SFTP), protocol negotiation (e.g., SSL for FTPS), and waiting for the server’s initial response.
Throughput (MB/s): The data transfer rate, measured in megabytes per second, calculated as the Wire Size (bytes transferred) divided by the Transfer Time (time from first to last byte of the file transfer). It reflects the efficiency of file transfer.
Connect Time (ms): Time to establish a TCP connection to the FTP server (or SSH for SFTP).
DNS Time (ms): Time to resolve the FTP server’s domain name to an IP address via DNS lookup.
Negotiation Time (ms): Time to complete protocol-specific handshakes after the TCP connection, including SSL/TLS negotiation for FTPS, SSH authentication for SFTP, or FTP authentication (e.g., username/password verification).
Wait Time (ms): Time from issuing the FTP command (e.g., RETR for download, LIST for directory listing) to receiving the first byte of the server’s response, reflecting server processing time.
Transfer Time (ms): Time to transfer the entire file or data (from first to last byte), also known as Receive Time, for operations like uploads, downloads, or directory listings.
Wire Size (bytes): The total size of the data transferred over the network during the FTP operation, including file content and protocol overhead, measured in bytes.
Error Details: Specific errors encountered during the FTP operation, such as FTP reply codes (e.g., 550 File Unavailable, 530 Login Incorrect), connection timeouts, or protocol errors (e.g., SSL handshake failure for FTPS).

FTP Server Test Views

Timeline (FTP Server Layer)
Map
Table

The FTP server test below monitors speedtest.tele2.net:21.

Other Included Tests

Agent-to-server test
BGP test

Manually Configuring FTP Tests

FTP Server Basic Settings

URL: Specify
- Protocol (FTP, SFTP or FTPS)
- Domain name and port number of the server, separated by a colon. If the port number is omitted, the defaults are:
  - FTP: 21
  - FTPS: 990
  - SFTP: 22
- Path to the file ("Download" and "Upload" Request Types) or directory on the server ("List" Request Type). Depending on the protocol, you will need either an absolute path (starting point is the root directory, "/") or a relative path (starting point is relative to the user's home directory or other directory per the server configuration). FTP and FTPS use relative paths. SFTP uses an absolute path or a relative path.
Username/Password: Enter the username and password for the FTP account. The username and password are both required. To perform anonymous FTP, enter “anonymous” as the username and your email as the password.
Request Type: Select “Download” to retrieve a file from the FTP server. Select “Upload” to send a file to the FTP server. Select “List” to retrieve a listing of the files in the directory specified by your URL setting. Downloads and uploads use "Image" (binary) transfer; listings use "ASCII" transfer.
Note: The Upload setting will use a random sequence of bytes as the contents of the file upload. The remote filename will be taken from the URL field. It is not possible to specify the file contents, but the size of the file can be specified by the Upload File Size selector. The maximum recommended file size is 2,147,483 Kb.
Limit Download Size/Upload File Size: The number of kilobytes (kB) at which to stop the transfer. Useful for transfers of large files, particularly with slow transfer rates which could result in reaching the test’s Timeout setting prior to completion.
NOTE: Do not use the Limit Download Size or Upload File Size settings in combination with the Desired Reply Code setting.
Verify Content: (List Request Type only) Check the Enable box and enter a regular expression in the field below to verify that a filename or other string(s) is present in your directory listing.

FTP Server Test Advanced Settings

Request Mode: Select “Passive” or “Active” mode FTP. The request mode governs the whether the client or server initiates the data channel’s TCP connection. Passive mode is the more common mode, and is the mode used by web browsers when retrieving files via FTP. Active mode requires an inbound TCP connection to port 20 on the Agent performing the test. If your Agent is an Enterprise Agent, then ensure that the firewall or packet filter rules allow this connection if you have selected Active FTP request mode.
Desired Reply Code: Enter the reply code that will represent successful test completion. An FTP command can generate multiple reply codes; the Desired Reply Code setting checks the last reply code in the response. For a list of FTP reply codes, consult RFC 959.
NOTE: Do not use the Desired Reply Code setting in combination with the Limit Download Size or Upload File Size settings.

Manually Configuring Web Layer Tests

Web Layer Tests Basic Configuration

Test type: HTTP server, Page Load, or Transaction
Test Name: This optional parameter gives the test a label. Where no label is provided, the value in the URL field will be used as the test name, along with a protocol ("http://" by default) prepended.
URL: A URL, domain name or IP address, including TCP port. If a domain name or IP address is used (i.e. protocol specification is not provided) then "http://" is assumed.
Interval: How frequently this test will be run.
Agents: This drop-down lists the ThousandEyes Cloud Agents and (optionally) Enterprise Agents that are available to your account. Select one or more agents to assign them to this test.
Alerts: When the Enable box is checked, the alert rules selected in drop-down list will be active for the test. You can select alert rules with the drop-down list, and create, modify and delete alert rules with the Edit Alert Rules link.
Transaction Script: Transaction tests execute custom Selenium WebDriver-based scripts written in JavaScript language to simulate user interaction with web page elements. Pictured below are several buttons used to insert regularly used code into transaction tests.
Each is detailed below, ordered from left to right:
- Sleep Adds a sleep function set to wait 5 seconds.
- Marker Adds a marker function to track script progress. Note that this can be changed from markers.set to markers.start and makers.stop to track a particular section.
- Screenshot Captures a screenshot.
- Credential Opens credential management options.

Web Layer Tests Advanced Settings

Advanced Settings: Provides configuration of an associated Network test for the target server(s), per the Network Test Advanced Settings tab, and provides the following settings for either the selected test type or an associated HTTP Server view, as indicated below:
- HTTP Server Timing
  - Timeout: Seconds until the test type terminates due to an unresponsive target server. For HTTP server test, the default timeout is 5 seconds. The maximum timeout value is 60 seconds.
  - Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for an HTTP server test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.
- Page Load Timing/Transaction Timing
  - Timeout: Seconds until the test type terminates due to inability to load the page in a page load test or to complete the script in a transaction test within the timeout time. Defaults and maximum values vary by type of Web test:
    For page load tests, the default timeout is 10 seconds. The maximum timeout value is either 0.25 * interval (in seconds) or 60 seconds, whichever is lower.
    For transaction tests, the default timeout is 30 seconds. The maximum timeout value is either 0.5 * interval (in seconds) or 180 seconds, whichever is lower.
  - Note that the HTTP server timeout cannot exceed the page load timeout. For example, if the test interval for the page load test is set to 2 minutes and the rule is to limit the HTTP server timeout to 0.25 * the interval, the HTTP server timeout will be 30 seconds. Since the maximum timeout for this particular page load test is 30 seconds, the HTTP timeout is set to a maximum of 29 seconds in this case.
  - Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for a page load test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.
- Proxy Settings
  - Direct: Do not use proxy.
  - Enterprise Agent's proxy configuration: Use the agent's proxy configuration.
  - Specific proxy configuration: Choose from one of the in-app proxy configurations to use.
- HTTP Authentication
  - Username: The username for the account being accessed by the HTTP request(s).
  - Password: The password for the account being accessed by the HTTP request(s).
  - Scheme: The following are available
    HTTP Basic Authentication
    NTLMv2 (a.k.a. Windows Integrated) Authentication. NTLMv2 authentication is supported for HTTP server tests only.
    Kerberos: Selecting the Kerberos button from the Advanced Settings tab > HTTP Authentication options will have the test use the Kerberos configuration on each agent. The agents selected in the test will also need to be setup for Kerberos authentication in the Network & App Synthetics > Agent Settings > Enterprise Agents > Kerberos Settings subtab. See Kerberos Settings for more information.
    OAuth (HTTP server only), two Initial Authentication Schemes supported with OAuth as under:
    Basic Authentication
    NTLM
- HTTP Request
  - HTTP Version: Select the HTTP version for requests:
    Prefer HTTP/2: Attempt HTTP/2 and fallback to HTTP/1.1 if HTTP/2 is not available.
    HTTP/1.1 Only: Send request(s) using HTTP/1.1 only, no attempt is made to utilize HTTP/2.
  - Window Size (page load and transaction tests only): Select size and orientation (phone or tablet) from the various Desktop, Phone and Tablet options available, or configure a custom size. Defaults to Desktop Small (1024x768).
  - Request Method: (HTTP server only) Select the HTTP request method--either GET or POST. If POST is selected, you may specify data in the POST Body field. The default is GET.
  - SSL Version: Select the version of the SSL/TLS protocol to offer in the SSL Client Hello. This will set the maximum version of SSL/TLS that the connection can use, but a lower version may be negotiated by the server. The options are the following:
    SSLv3: Use SSL version 3.0. No lower version can be negotiated.
    TLSv1.0: The Agent will start the TLS negotiation at version 1.0.
    TLSv1.1: The Agent will start the TLS negotiation at version 1.1.
    TLSv1.2: The Agent will start the TLS negotiation at version 1.2.
    Auto: The Agent will start the TLS negotiation at the highest version of TLS supported by its operating system. Currently the highest version is TLS 1.2 Contact [email protected] if you require confirmation of the current version.
  - Verify SSL certificate: (HTTP server only) By default, certificate-related errors will result in a test error. Uncheck this box to ignore certificate errors during SSL/TLS negotiation.
  - Agent ID Strategy: (page load and transaction only) HTTP requests originating from a transaction or page load test must be identifiable as being a ThousandEyes Agent request. The default identification strategy is to include a custom header (X-ThousandEyes-Agent: yes) on each request. However, in certain situations, the inclusion of this this header can cause a CORS policy violation for some cross-origin requests. To circumvent this issue, HTTP requests can alternatively be made identifiable by instead extending the User Agent request header with the (ThousandEyes Agent) identifier string. Selecting the Extend User Agent Header option will automatically include this identifier string and it will be appended into User Agent text input. If the (ThousandEyes Agent) identifier string is removed from the User Agent text input while the Extend User Agent Header option is selected, the test configuration will not be valid and cannot be saved.
  - Custom Headers: Enter one or more HTTP header strings in the form <stringname>: <value>. Note the whitespace between the literal colon character and the placeholder <value>. The custom header(s) will be transmitted with the target page request (page load test) or each page request (transaction test) but not for objects within a page. When adding multiple headers, delineate between individual headers using a line break.
  - Override DNS: (HTTP server only) Instead of using standard DNS resolution, allows you to specify the IP address to which the target's domain name will resolve. Note that the specified IP address is not that of a DNS server, but the IP address that will be used as the target for the test. This setting is useful for targeting a specific server within a cluster, or when testing HTTPS URLs that require a Server Name Indication (SNI) in the TLS negotiation that is different from the domain name-to-IP address mapping required to access the URL.
  - Client Certificate: (HTTP server only) Configure a client-side certificate, which will be sent in the SSL handshake to the web server to authenticate the client. Check the Enable box, then copy your client certificate (both the private key and the public certificate) in PEM format and paste into the Client Certificate field.
    If your certificate is in PKCS#12 format (.pfx file extension), you may use the openssl utility to create a PEM version. For example, the openssl command for a client certificate mycert.pfx with a password would be:
    openssl pkcs12 -in mycert.pfx -out clientcert.pem -nodes -passin pass:<password>
    Then edit the output file clientcert.pem using a text editor to remove any text before, after, or in between the certificate and private key. The file should look like the following:
    -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEAtjjpbonL7xK2AiVPo7/n0uQiwjk3hN0B3bAR0wVPt6UYLc2h L+T5UOOU5xlNu1ydz2iyxbcV8sn6rtT4NGyRgeh91A+GvCRzR2GMH5vocNMNSuYh <lines omitted for brevity> Nx6ZWZekTlYrelnIM6FsUVUplwlYxU9UqBWeYcLx6BkrKKzoohFSTstI4PhuzE4P lSD/opYrkwCYiNmNX4Z8SU136fbz43FhFUNzmEePNEVLJ2mF0f2Y+ek= -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEGzCCAwOgAwIBAgIJAOUXm6K8B9tnMA0GCSqGSIb3DQEBCwUAMIGjMQswCQYD VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5j <lines omitted for brevity> T4QRFKjtQiTzkGl4NT+wiLi+JLS3sQVpsmfqJ5cBLf91GOpFWQs65Kc7JdUfezs= -----END CERTIFICATE-----
    NOTE: The private key must be placed first, then the certificate.
  - Unsafe Legacy Renegotiation: (HTTP server only) Allows TLS renegotiation with servers that do not support Secure Renegotiation described in RFC 5746. This option is enabled by default for all tests with HTTP options, but can be disabled by unchecking the box.
- HTTP Headers
  - Show HTTP headers in waterfalls: (page load and transaction) Make available HTTP request and response header information for each object in the waterfall displays.
- HTTP Response
  - Desired Status Code: (HTTP server and page load) Sets the HTTP status code returned by the server that is defined as a successful test (i.e. no errors will be displayed in the test table results, no response code-based alerts generated, etc...). By default, either a 200-level or 300-level status code is considered a successful return code. Uncheck the box and enter a response code in the field below to use a different response code.
  - Verify Content: (HTTP server only) Search the HTTP response headers and body (similarly to a curl -i command) for text matching a given POSIX regular expression. Headers and body are searched separately. If no match occurs, the test shows an error condition. Note: the HTTP server test does not execute any JavaScript code, therefore the content generated by JavaScript cannot be verified by this feature. JavaScript-generated content can be matched using a transaction test.
  - Limit Download Size: (HTTP server only) Load only the first number of kiloBytes (kB) specified in the field below the Enable box. The result is not guaranteed to be exactly the number specified, but can be slightly more--but always within a few percent, or less as the size of the download is increased. Note that this function does not use an HTTP Range header, so the HTTP response code should not be affected (i.e. success is a 200 OK response, not a 206 Partial Content response).

Web Layer Test Outputs

HTTP server tests provide a world map containing availability, and on location-by-location basis, the response code served by the target web page, and number of redirects from URL requested until the final page was served.
Page load tests provide all the content from an HTTP server test, along with a page load table, showing the breakdown of the data received by domain and provider, as well as a waterfall chart, which shows the load time, source and provider for each component of the page. The page load test also provides access to DOM load and page load times, which provide elapsed times from the request start.
Transaction tests provide page load detail for each page visited in a transaction, timing information for custom defined markers, screenshots (if configured) as well as overall transaction time and completion percentage, on an agent-by-agent basis.
FTP server tests provide availability, response time and throughput metrics, as well as FTP reply codes for an FTP session.

PreviousTwo-Step HTTP Testing (OAuth)NextNetwork Tests

Last updated 13 days ago