Run RealBrowser tests

You've recorded your user path. Now it's time to run tests and collect meaningful data about your application's performance.

RealBrowser gives you two types of insights: request metrics that show server response times, and Core Web Vitals that reveal what users actually experience in the browser.

Before you start

Make sure you have:

Capture request metrics

Want to know how long your server takes to respond? The CaptureRequests action tracks request and response times for every call the browser makes.

Start collecting metrics

Add a CaptureRequests action to your user path:

  1. Insert a CaptureRequests action at the beginning of your user path, immediately following the OpenBrowser action.

  2. Configure bucket parameters if needed:

    • url to group request metrics based on exact URL matches.

    • resourceType to group request metrics based on resource type matches.

    • regexp to group request metrics based on regular expression matches.

Once this action runs, RealBrowser collects metrics from every browser request. By default, all requests go into a single bucket. Use the grouping parameters to separate them.

Group requests automatically

Don't want to configure buckets manually? Tricentis NeoLoad can set them up for you.

For a new RealBrowser recording:

After recording with RealBrowser, the Post-recording Wizard lets you specify the number of CaptureRequests actions in your new user path. Tricentis NeoLoad automatically forms buckets based on the requests during recording:

  • XHR and Fetch type requests provide high granularity and result in individual url buckets with exact URL match.

  • Other detected request types go into corresponding resourceType buckets.

For an existing user path:

  1. Run Check Virtual User for the user path you want to update.

  2. Right-click the user path element in the Check VU tree and select Update recorded contents from the context menu.

  3. Right-click the user path element in the design tree, hover over Advanced > RealBrowser, then choose an option to manage capture requests actions.

Handle HTTP errors

During recording, RealBrowser logs every request and response, including error codes. Some errors are expected, like a 404 for a missing favicon. You can tell Tricentis NeoLoad to ignore specific errors.

An HTTP error is ignored when all of these are true:

  • In Project settings > Runtime parameters > Responses, the Do not mark the specified HTTP error code when the same error occurs during the recording box is selected.

  • The error must happen during recording.

  • The error code must be on your list of codes to ignore.

  • The error's response code must match the recorded code and URL with its parameters.

Core Web Vitals testing scenarios

Core Web Vitals tell you what users actually experience: how fast pages load, how responsive they feel, and how stable the layout is. Here are some ways to use them.

This scenario shows how to monitor user experience across multiple pages to identify performance variations.

Configure monitoring:

  1. Enable Core Web Vitals for your user path using the post-recording wizard.

  2. For more granular monitoring, add captureWebVitals actions after each page navigation you want to monitor.

Analyze performance:

  1. Go to Results > Values to view detailed Core Web Vitals data.

  2. Sort results by LCP to identify pages with slow loading times.

  3. Check CLS values to find pages with layout stability issues.

  4. Review INP scores to identify pages that feel unresponsive to user interactions.

This scenario demonstrates how to track user experience performance across an entire workflow from start to finish.

Set up journey monitoring:

  1. Create a user path that represents a complete user journey (homepage → search → product → checkout).

  2. Add captureWebVitals actions at key journey points:

    • After homepage load

    • After search results display

    • After product page load

    • After checkout page load

  3. Run the test with appropriate load to simulate realistic user conditions.

Evaluate journey performance:

  • Use the Graphs view to create scatter plots visualizing the relationship between different Core Web Vitals metrics.

  • Look for pages where multiple metrics perform poorly, indicating significant user experience issues.

  • Use percentile graphs to understand performance distribution across different journey stages.

This scenario shows how to establish baselines and detect performance regressions before they reach production.

Establish baseline metrics:

  1. Run your Core Web Vitals-enabled test against the current production version.

  2. Export results to CSV to create a baseline dataset.

  3. Document the 75th percentile values for each monitored page as your performance baseline.

Compare against new deployments:

  1. Run the same test configuration against the updated application.

  2. Compare Core Web Vitals results against your baseline metrics.

  3. Look for pages where metrics have degraded beyond acceptable thresholds.

Infrastructure sizing

Infrastructure sizing depends on scenario design, target application resource consumption, and available hardware. Load Generators need one browser instance per virtual user, which uses significantly more resources than protocol-based testing.

The sizing process requires balancing RAM and CPU. CPU is the primary resource that causes throttling during iterations. To mitigate throttling, increase think times to simulate realistic user behavior (a few seconds of page reading between actions).

General estimates for a low to medium resource-consuming target application:

  • 1 GB RAM per virtual user

  • 2 actions per second per CPU core

Example

A Load Generator with 32 GB RAM, 8 CPU cores, and a typical virtual user executing 3 actions per second:

  • RAM capacity: 32 GB / 1 GB = 32 virtual users

  • CPU capacity: 8 cores x 2 actions per second = 16 actions per second total. At 3 actions per virtual user = approximately 5 virtual users per core, or 40 virtual users total.

  • Limiting factor: RAM (32 virtual users). However, CPU throttling may reduce this number further.

These are theoretical estimates. Run sizing tests in your environment to find the ideal ratio of virtual users per CPU for your specific application. These estimates assume no other processes are running on the Load Generator.

Best practices

Get the most out of your RealBrowser tests with these tips:

  • Realistic conditions: Use load conditions and network settings that reflect your actual user base.

  • Consistent environments: Ensure test environments closely match production.

  • Representative content: Test with realistic data that matches production content size and complexity.

  • Focus on 75th percentile: Align with industry standards by evaluating the 75th percentile results.

  • Consider page context: Different page types have different performance expectations.

  • Track trends over time: Monitor changes across multiple test runs to identify performance trends.

  • Combine with traditional metrics: Use Core Web Vitals alongside response times and throughput for comprehensive analysis.

  • Include in CI/CD pipelines: Integrate testing into your deployment process to catch regressions early.

  • Share results with stakeholders: Use data to communicate user experience impact to business stakeholders.

What's next

Want to dig deeper? Check out these resources: