Test Settings for Page Load and Transaction Tests

This page addresses two test types that fall under Browser Synthetics: page load and transaction tests. These two test types are unique in that they emulate a browser's interaction with a website.

The content below supplements Working With Test Settings and describes test configuration specifically for page load and transaction tests. You’ll need user permissions in ThousandEyes to create and edit test settings.

If you just need to run a test using API calls, and don’t need to emulate a user journey in a browser, use the API Test Type.

The test settings are available under Cloud & Enterprise Agents > Test Settings as shown below.

Summary:

Choose Cloud & Enterprise Agents > Test Settings and click Add New Test.
Choose Web as the Layer and then choose either Page Load or Transaction as the Test Type.
Complete the Basic Configuration and Advanced Settings tabs as needed. Most of the required defaults are already filled in.
Click Run Once to ensure that the test configuration is valid.
Click Create New Test to save and activate the test.

Initial Test Settings

When you choose the test type, you can see all the view layers that will be enabled by your new test. If no name is specified, the Test Name uses the value in the URL field, along with a prepended protocol (https:// by default).

The majority of the ThousandEyes test configuration settings are shared between page load and transaction tests, and many are common to all or most ThousandEyes test types. For commonly shared test layers such as Network and BGP, see Working With Test Settings.

Basic Configuration Tab: Page Load and Transaction

The basic test configuration is the same for both page load and transaction tests.

The Basic Configuration settings are as follows:

URL - Specify a domain to monitor using the format http(s)://domain:port/path for example https://google.com. If you type a simple domain like google.com, the prefix https:// is automatically prepended.
Schedule - Used if running this page load or transaction test from more than one ThousandEyes Agent. You can stagger the test launches so that the target server doesn’t identify the test as a security threat.
- Default - Choose Default to launch all tests on all agents at the start of each test round if possible. If the test round specifies a 5-minute interval, choose Default to cause all agents to attempt to launch this test at the beginning of that 5-minute test interval. Note that tests will not necessarily execute at the beginning of the interval. Exactly when the test runs is a function of how many tests are assigned to the agent and the intervals and runtimes of those tests.
- Round Robin - Stagger the tests so that each agent launches the test on the same interval, but they don’t all start simultaneously. See Using Round Robin Test Scheduling for more information.
Interval - The test interval is the frequency with which the test will be run.
- Default: 2 minutes
Agent (s) - Choose one or more ThousandEyes Cloud Agents, or choose from the ThousandEyes Enterprise Agents that are available to your account. Both Cloud Agents and Enterprise Agents can be selected.
Alerts, Enable - When the Enable box is checked, all the alert rules currently selected in the drop-down immediately below will be active for the test.
- Default: Enabled
4 out of 6 Alert Rules Enabled - Drop-down to quickly see which alert rules are associated with this test.
- You can create, modify and delete alert rules using the Edit Alert Rules link.
- Default: A few built-in alert rules are automatically associated with new page load tests. You can de-select them, view the alert rule, or create your own alert rules as described in Creating and Editing Alert Rules.
Alert Suppression Windows - This drop-down appears if you have any alert suppression windows configured under Alerts.

Advanced Settings Tab, Page Load and Transaction

The Advanced Settings apply to both page load and transaction tests, except where noted.

Browser Options

Browser Options allows for additional fine-tuning of page load and transaction tests.

The Browser Options are as follows:

Chromium Version - Drop-down selector to choose which version of Chromium for this test. See Configure Dual Chromium for details.
Screenshot / Enable - Check box. You can disable screenshots for data privacy reasons without having to remove those lines from the transaction script. For example, if you are monitoring a HIPAA-compliant application you might want to disable screenshots that show patient identifying information.
Default: Enabled
Browser Language: Drop-down selector to choose the language/locale of the browser used during testing.
When a visitor with a browser setting for a specific language/locale lands on a web site, that site can redirect them to the appropriate landing page that uses their preferred language. For example, if you are looking to test the Portuguese-language version of your site for visitors located in Brazil, or who have Portuguese selected as their preferred language, you can create a transaction test that runs on the default site for Portuguese.
Default: English (US)
Microphone and Camera / Allow or Block: Button. Used for collaborative web applications such as Google Meet that may prompt the user for permission for the app to use the camera or microphone.
- Allow: The ThousandEyes transaction or page load test will emulate a fake camera and microphone to be used in that application.
- Block: Deny permission. Camera and microphone will not be available for the application.
Default: Block
Geolocation / Allow or Block: Button. For web applications that require the user's location in order to test an area of the application, the target web application might request permission to use the location of the browser.
- Allow: The ThousandEyes test provides the location of the ThousandEyes agent to be used for the test. Using the agent’s location provides data consistent with that vantage point.
- Block: Denies permission to use geolocation.
Default: Block
Page Loading Strategy: This option lets you choose how long to wait to execute the webdriver command. The Page Loading Strategy gives you the option to execute the next action without waiting for all the elements on the page to load. For example, you might have a page or application where the DOM loads quickly, but because of JavaScript that modifies the page, or assets that take a long time to load, you might otherwise have to wait a long time before executing the next action on your transaction script.
There are three major milestones for loading a web page: when the structure of the page (HTML) has been downloaded, when the major structural elements are present (DOMContent Loaded) and when images and other assets of the page have finished rendering (last contentful paint). You can see this in the page load waterfall charts: the "index.html" object shows when the HTML has finished downloading. The blue line denotes when the DOM content has loaded, and the red line in the waterfall shows when the page has fully loaded.
Drop-down options as follows:
- Normal. Wait for the entire page to load, meaning that HTML content and all resources have been downloaded and parsed before moving to the next action in the transaction test script.
- Eager. Wait for the DOMContentLoaded event, meaning that HTML content is downloaded and parsed, and the document readiness state is “interactive”, before moving to the next action in the test script.
- None. Wait only for HTML content to download. Once the HTML is downloaded, the test proceeds to the next action in the transaction test script.
Default: Normal

Page Load or Transaction Timing

Page load or transaction timeout affects unit consumption as described in Calculating Units.

The Page Load Timing settings are as follows:

Timeout - This is the overall page load or transaction test timeout setting. Note that there’s a separate timeout for the HTTP server portion of this test. Timeout is the number of 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.
Slider with a range 5 - 15 seconds. Timeout is equal to or larger than Target Time for View. Also note that the maximum timeout can change based on the interval selected in the basic settings.
- Default:
  - 10 seconds for page load tests. The maximum timeout value is either 0.25 * interval (in seconds) or 60 seconds, whichever is lower.
  - 30 seconds for transaction tests. The maximum timeout value is either 0.5 * interval (in seconds) or 180 seconds, whichever is lower.
Target Time for View - Specifies the expected or “normal” timeout for the transaction or page load test. Influences color-coding legend on the test view Map tab for the page load or transaction view layer. If a test completion takes longer than this threshold, the test still runs but the results show in red instead of green.
Slider with a range 1 - 30 seconds. Cannot exceed the Timeout.
- Default:
  - 6 seconds for page load
  - 10 seconds for transaction

Exclude Elements from Metrics and Waterfall

Use the exclude feature to exclude all objects from a domain, a sub-domain, or even specific objects such as very large images, for example *.domain.com/very_large_logo.jpg.

Exclude Domains / Object URLs:
Text entry. Ignore large page objects that you don’t care about that could be negatively impacting your page load times and raising false timeout alarms. Can also be used to block requests to third-party tracking tools.

Excluding domains or URLs can be helpful for ignoring third-party assets that are not important to your teams’ primary business objectives. Requests to blocked domains or objects appear greyed out in the waterfall and will not affect test metrics collected.

Note that entering a domain such as google.com only blocks the main domain (https://google.com). Blocking subdomains requires a wildcard, for example *.google.com would block docs.google.com, maps.google.com and google.com itself.

Network

Network layer test settings for page load and transaction tests are the same as for other test types, described in Working With Test Settings.

Proxy Settings

Use Proxy Settings to select a pre-configured setting from within ThousandEyes. You can view or configure these settings under Cloud & Enterprise Agents > Agent Settings, under the Proxy Settings tab. See Collecting Proxy Metrics for more information.

TLS

The TLS area has separate options as follows:

Disable SSL verification for page load and transaction tests
Use a client-side certificate

The TLS settings are as follows:

SSL Version - Select the version of the SSL/TLS protocol to offer in the SSL Client Hello from the ThousandEyes Cloud or Enterprise Agent.
This will set the maximum version of SSL/TLS that the connection can use, but a lower version may be negotiated by the server.
Drop-down 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 ThousandEyes Customer Support if you require confirmation of the current version.
Default: Auto
Verify SSL Certificate - Checkbox. Applies to both the HTTP view and to the page load or transaction view, for page load and transaction tests.
By default, certificate-related errors will result in a test error. Uncheck this box to ignore certificate errors during SSL/TLS negotiation.
If your page load and transaction tests have SSL verification disabled at the ThousandEyes Agent level, review your configuration and use the test-level setting going forward.
Default: Selected
Enable Client Certificate - Checkbox. Use this feature if your test target requires a client-side certificate, and copy the certificate body into the text field below. The text box under Enable shows suggested text and hints as described in Converting Certificates into PEM Format.

The certificate body itself is obscured once the test has been saved. To change an existing client certificate, click Remove, re-enable the checkbox, and then copy in the new certificate.

HTTP Authentication

Authentication settings for page load and transaction test types are the same as for the HTTP server test type, with the exception of OAuth and NTLM:Negotiate. See Working With Test Settings for information on the HTTP server test type.

NTLM authentication may fail in some situations for page load or transaction tests, because NTLM negotiation using GSSAPI and NTLMSSP is not natively supported by the Linux libraries available for use with BrowserBot. A website that supports both Kerberos (ticket-exchange negotiation) and NTLM (credentials provided) and which sends a generic WWW-Authenticate: Negotiate header will cause the NTLM authentication to fail on any BrowserBot tests, even when NTLM still works for the HTTP server test.

HTTP Request

HTTP request settings for page load and transaction tests include HTTP versions, redirects, browser versions, device emulation, and the use of custom headers.

The HTTP Request settings are as follows:

HTTP Version - Options
- 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.
Default: Prefer HTTP/2
Follow Redirects / Enable - Checkbox to enable redirects.
Default: Selected
Device Emulation - Drop-down options with these main device type categories. A range of options are available for different device type, including custom dimensions for each:
- Desktop
- Phone
- Tablet
- Laptop
Default: Desktop Large
Device Emulation / pixel dimensions - The browser display updates based on Device Emulation selection immediately above.
Default: 1440 x 900 px
Device Emulation / portrait or landscape - Icon. The browser display updates based on Device Emulation selection immediately above.
Default: Landscape
User Agent - The user agent normally refers to what your browser is sending in the user-agent heading. In this case it refers to what ThousandEyes sends when running this test.
Drop-down options include various browser options for Windows and Mac OS. Chrome, Firefox, Internet Explorer, Edge, Safari. Options are:
- Default
- Additional options for commonly used browsers
- Choose Custom for other browsers not specified
Default: Default
User Agent / Custom - If Custom is selected immediately above, this text box populates with suggested text, which may show different versions based on recent software updates.
For example, the suggested text might read something like this: “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36”
Agent ID Strategy - Drop-down options for the identifier to use for the ThousandEyes Cloud or Enterprise Agent that is running this test. Options:
- Add x-thousandeyes-agent Header: Identify ThousandEyes Agent HTTP requests by including the custom x-thousandeyes-agent: yes header to every request.
- Extend User Agent Header: Identify ThousandEyes Agent HTTP requests by extending the user agent request header with the ThousandEyes Agent identifier string. Use if default ThousandEyes Agent header causes CORS issues.
Default: Add x-thousandeyes-agent Header
Custom Headers - Drop-down options. Use the plus sign to the right to add multiple entries. Options are:
- Root Request
- Specific Domain
- All Domains
Default: Root Request
Custom Headers / text - Enter one or more HTTP header strings in the form <stringname>: <value>. Note the whitespace between the literal colon character and the placeholder <value>. When adding multiple headers, delineate between individual headers using a line break. The custom headers will be transmitted with the target page request (page load test) or each page request (transaction test) but not for objects within a page.

Notes on Agent ID Strategy

ThousandEyes adds one line to the HTTP request headers that identifies the HTTP request as coming from a ThousandEyes Cloud or Enterprise Agent. By default, that identifier is this string:

x-thousandeyes-agent: yes

Sometimes the default agent identifier causes problems with cross-origin resource sharing on the target server. CORS affects third-party HTML objects that might be fetched from another site. A third-party domain owner can choose not to allow sharing for requests containing unknown agent identifiers, which might cause all HTML objects from that domain to fail to load properly.

To get around this limitation, the alternative Agent ID strategy option Extend User Agent Header: appends the ThousandEyes Agent identifier string at the end of the line immediately above that (the line that begins with user-agent).

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.

HTTP Response

HTTP response settings are the same as for other web layer test types, described in Working With Test Settings.

The HTTP Response settings are as follows:

Desired Status Code / Default (2xx or 3xx) - Check box
Default: Selected
Desired HTTP status code of the response - Use to set a custom status code, if Desired Status Code / Default is un-checked immediately above.

One reason to specify a custom HTTP status code is if you can’t run the test that you really want due to authentication challenges on the server side. In this case, even a “403 - forbidden” might constitute a success message, because it tells you that the target is still responding

Verify Content / Enable - Check box. If selected, a text box appears. Enter a POSIX Extended Regular Expression to match against the content of the response.
Non-matching responses will be marked as errors.
Note: the HTTP server portion of the test does not execute any JavaScript code, nor does it expand any CSS. It simply downloads the initial page and stops. It does not load anything that comes from other files. Therefore the content generated by JavaScript cannot be verified using a page load test. If you need to match JavaScript-generated content, use a transaction test instead.
Default: Not selected

HTTP Headers

Use this setting to suppress the capture and display of HTTP headers on the ThousandEyes platform.

The HTTP Headers settings are as follows:

Show HTTP headers in waterfalls - If enabled, shows HTTP request and response header information for each object in the waterfall displays. You can view by clicking the [Header] link in a waterfall row.
De-select in order to suppress sensitive data that might otherwise be available in ThousandEyes.
Default: Selected

Additional Transaction Test Settings

The test settings for transaction tests are almost the same as for page load tests, with a few additional settings as described below.

Basic Configuration Tab, Transaction

All Basic Configuration settings are the same for a transaction test as for a page load test, except as noted below.

Download the ThousandEyes Recorder (shown first time only) - Link to download the ThousandEyes Recorder IDE. Use the Recorder to generate your own transaction scripts without having to write any code. See ThousandEyes Recorder for more information.
Transaction Script - Text window. Transaction tests execute custom Selenium WebDriver-based scripts written in JavaScript, to simulate user interactions with web page elements.
You can write your own transaction test script, use the ThousandEyes Recorder, or copy from another script and modify it. See Getting Started With Transaction Tests for more information, and visit the ThousandEyes scripting repository for some scripting examples.
Default: A skeleton transaction script is generated with the JavaScript functions necessary for ThousandEyes transaction tests.
Transaction Script / Icons - Use the icons to insert special functions at selected points within your transaction test script.
- Hourglass - Add sleep function which waits 5 seconds before proceeding to the next step in the script.
- Timer - 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 - Capture screenshot at a particular point in the script. You can temporarily disable screenshots without having to remove these lines from your script by un-checking the Screenshot | Enable checkbox under Advanced Settings tab, Browser Options section.
- Key - Add login credentials from the ThousandEyes Credentials Repository, available as a separate tab under Cloud & Enterprise Agents > Test Settings. See Working With Secure Credentials for more information.

See Transaction Test Development Guide for more information.

Transaction Script Window

Transaction tests execute custom Selenium WebDriver-based scripts written in the JavaScript language to emulate user interaction with web page elements. There's a download link for the ThousandEyes Recorder as well.

Advanced Settings Tab, Transaction

All of the items on the Advanced Settings tab for transaction test configuration are identical to the same settings as they appear for page load test configuration, with the exception of the default timeouts.