Skip to content
MaxoPerf MaxoPerf docs

Daily browser performance scenarios

Most browser performance testing effort falls into four recurring scenarios: verifying web vitals before a release, checking a checkout journey under peak load, catching login-flow regressions, and running a real-browser smoke during a marketing launch. This page gives you the concrete steps and MaxoPerf configuration for each.

Before you start

Section titled “Before you start”
  • Read Selenium performance testing for the Taurus YAML and Python script patterns.
  • Read Hybrid load architecture if your scenario combines browser VUs with protocol load.
  • Have a MaxoPerf test created with the Taurus YAML uploaded. Steps below reference the MaxoPerf console.

Scenario 1 — Pre-release web vitals gate

Section titled “Scenario 1 — Pre-release web vitals gate”

Goal: Verify that a new deploy does not push Core Web Vitals (LCP, TTFB) past acceptable thresholds before you promote to production.

When to run: In CI, after the staging deploy succeeds and before the promote step.

Load profile:

  • VUs: 2–3 browser VUs (no protocol load needed — this is a correctness check, not a load test)
  • Duration: 5 min (enough for multiple browser iterations, no ramp-up needed)
  • Executor: selenium
  • Location: 1 managed location close to your staging environment

How to run in MaxoPerf:

  1. Create a Taurus YAML targeting your staging URL with concurrency: 3 and hold-for: 5m.
  2. Upload a Python script that navigates your key pages (home, product page, dashboard) and asserts on loadEventEnd - startTime < 3000.
  3. Upload both to a MaxoPerf test named “pre-release-web-vitals-gate”.
  4. Trigger the run from CI using the MaxoPerf API: POST /v1/runs with testId.
  5. Poll GET /v1/runs/{id} until status === 'finished'. If errorRate > 0, the assertion failed — block the promotion.

What to look for:

  • Error rate should be 0%. Any assertion failure means a page exceeded the load-time SLO.
  • Iteration count should be ≥ 10 over 5 min (2–3 iterations per VU). Fewer iterations means the browser is spending more time per page — a signal of slowness.
  • Compare p95 browser timing against your baseline from the previous release.

Scenario 2 — Checkout journey under peak load

Section titled “Scenario 2 — Checkout journey under peak load”

Goal: Confirm that users can complete a purchase within acceptable time limits when the backend is serving peak traffic.

When to run: Pre-release, before major promotions (Black Friday, product launches).

Load profile:

  • Protocol VUs: 300–500 (JMeter or k6, targeting API endpoints)
  • Browser VUs: 5 (Selenium, targeting the full checkout UI flow)
  • Duration: 20 min (5 min ramp-up + 15 min hold)
  • Executors: Protocol test + browser test coordinated via VarioTest or started simultaneously

How to run in MaxoPerf:

  1. Create a protocol load test targeting your API endpoints at 300–500 VUs. Use your existing JMeter JMX or k6 script.
  2. Create a browser test with executor: selenium, concurrency: 5, and a Python script that walks through: home → product page → add to cart → checkout → order confirmation.
  3. In the browser script, assert on each page’s loadComplete timing and on the final order confirmation element’s appearance within 10 s.
  4. Start the protocol load test in MaxoPerf. Wait for the ramp-up to complete (watch the Overview tab throughput plateau).
  5. Start the browser test in MaxoPerf immediately after ramp-up.
  6. After both runs finish, compare timestamps on the latency charts. Look for browser assertion failures during the protocol load peak.

What to look for:

  • Browser iteration success rate: should be ≥ 95% (tolerate up to 5% failure for flaky network).
  • Checkout journey total time: the sum of navigation timings across all pages should stay under 15 s.
  • Any browser iteration that failed (assertion error) corresponds to a user who could not complete checkout — correlate with the protocol p95 latency at the same timestamp.

Scenario 3 — Login flow regression

Section titled “Scenario 3 — Login flow regression”

Goal: Catch regressions in authentication performance after backend or frontend changes — login is the critical first step for every authenticated user.

When to run: On every deploy to staging (automated CI check), and before any release that touches the auth service, identity provider, or login page.

Load profile:

  • VUs: 3–5 browser VUs
  • Duration: 5–10 min
  • Executor: selenium
  • Script: Navigate to login page → enter credentials → assert redirect to dashboard → assert dashboard content loads

How to run in MaxoPerf:

  1. Write a Python script that:

    • Navigates to https://staging.example.com/login.
    • Enters test credentials (from environment variables — never hard-coded).
    • Asserts driver.current_url contains /dashboard within 10 s.
    • Captures and prints loadEventEnd - startTime for the post-login dashboard load.
    • Asserts load time < 2000 ms.

  2. Store test credentials as MaxoPerf secrets (see Manage test secrets). Inject them via environment variables in the Taurus YAML:

    execution:
      - executor: selenium
        concurrency: 3
        hold-for: 5m
        scenario: login-regression
    

    scenarios:
      login-regression:
        script: scripts/login_check.py
        browser: chrome
        headless: true
    

    env:
      TEST_EMAIL: ${TEST_EMAIL}
      TEST_PASSWORD: ${TEST_PASSWORD}

  3. In CI, trigger the test via POST /v1/runs and check the result. Any non-zero error rate on the login assertion means a regression.

What to look for:

  • Error rate = 0%. A single failed login attempt is a regression signal.
  • Dashboard load time p95 < 2000 ms (or your established baseline + 20% tolerance).
  • Iteration time (full login → dashboard) trend: flag if it increases > 10% vs the previous run on the same commit range.

Scenario 4 — Marketing-launch real-browser smoke at load

Section titled “Scenario 4 — Marketing-launch real-browser smoke at load”

Goal: Verify the marketing site and main conversion pages stay fast and functional during a product launch that drives spike traffic.

When to run: 30–60 min before a scheduled marketing launch or announcement. Repeat every 10–15 min during the launch window.

Load profile:

  • Protocol VUs: 500–1000 (targeting the CDN-backed marketing site and the conversion API)
  • Browser VUs: 5 (Selenium, visiting the landing page, feature pages, and sign-up flow)
  • Duration: 15 min (to cover the launch announcement window)
  • Executor: Protocol test + browser test (VarioTest or simultaneous)

How to run in MaxoPerf:

  1. Set up a “launch readiness” protocol load test at 500–1000 VUs targeting the marketing site static assets, the conversion API, and the sign-up form submission endpoint. Use Taurus HTTP or k6.
  2. Set up a browser test with 5 Selenium VUs visiting: landing page → features page → pricing → sign-up form fill and submit.
  3. In the browser script, assert on:
    • Landing page loadComplete < 3000 ms (LCP threshold proxy).
    • Sign-up form appearing within 5 s.
    • Post-submit redirect succeeding (no 5xx in the browser console).
  4. Run both tests simultaneously during the 15 min before launch. Check that error rate on the browser test is 0% and that iteration count matches expected.
  5. Monitor in the MaxoPerf console during the launch window. If the browser error rate spikes, investigate immediately.

What to look for:

  • Browser error rate must be 0%. Any failure means users cannot complete the conversion flow.
  • Landing page load time under protocol load: compare TTFB and loadComplete against the idle baseline captured in the pre-launch check.
  • Sign-up form submission latency: check whether slow sign-up (> 5 s) correlates with high API error rate in the protocol test.

Quick reference

Section titled “Quick reference”
ScenarioProtocol VUsBrowser VUsDurationKey assertion
Pre-release web vitals gate02–35 minloadComplete < 3 s per page
Checkout under peak load300–500520 minCheckout journey completes < 15 s; error rate < 5%
Login flow regression03–55–10 minLogin → dashboard < 2 s; error rate = 0%
Marketing-launch real-browser smoke500–1000515 minLanding page < 3 s; sign-up completes; error rate = 0%

Where to go next

Section titled “Where to go next”