What agents record
Find slow pages and failing requests the way users hit them
Lab speed tests load one page with an empty cache. Users click through a flow, and the slow request is the one after "Create account". Here is how to see what users actually wait for.
How do I find which pages and requests are slow for users?
Measure during real use, not just page loads: go through the flows users take and record every request's answer time. When Mimiq's agents use your app, the browser records each request to your site slower than 3 seconds and every request that failed or answered 4xx or 5xx, on the step it happened, and the report ranks them by how many agents hit them.
Why speed tests miss it
A page-speed score measures the first paint of one URL. The wait that loses users is usually an API call in the middle of a flow: creating the account, loading a dashboard for a new user, saving settings. It only happens after a click, with data, and no lab test makes that click.
- Every request to your site slower than 3 seconds, with method and path.
- Every request that failed or answered 4xx or 5xx.
- Uncaught JavaScript errors and console errors from your site.
- On the step it happened, next to the screenshot and the agent's words.
- Third-party scripts and trackers are left out.
How it works
- 01
Give it a link and a task
Paste a public address, such as a preview deployment or staging, and say in plain words what a user would try, like "Sign up and start using it". No test scripts and no selectors.
- 02
Pick how many agents
1, 3, 5, 10 or 20 agents, 5 by default. Each acts as a different one of your users and gets its own real browser for up to 40 steps. About 5 minutes for up to 3 agents, about 5 to 15 minutes for 5, and about 15 to 30 minutes for 20. Agents take turns on shared browsers, so it can take longer when other runs are going, and you can close the tab and come back.
- 03
Read what they hit
The report shows what broke, what the browser caught on your site (JavaScript errors, requests that failed or answered 4xx or 5xx, and requests slower than 3 seconds), where each agent got stuck or gave up and why in its own words, with the step and a screenshot, and the problems ranked by how many agents hit them, each with a suggested fix.
- 04
Fix it and run the same agents again
Rerun on the fixed build and see whether the problem is gone for everyone who hit it. Or let your coding agent do the loop through the MCP server, or let the GitHub Action do it on every preview deploy.
What is recorded, exactly
Page loads and fetch or XHR requests to the site under test (the same domain, or the exact host on shared hosting like vercel.app). For each: the method, the path without its query string, and either the status code, the failure, or the time until the server started answering. Messages are cut short and anything that looks like a token or an email is masked.
Requests that a navigation cancelled, and requests to other domains, are not recorded: they say nothing about your app.
What it is not
It is not load testing: a run is a few users, so it shows what is slow for one person, not what breaks at a thousand. It is not real-user monitoring either: use your analytics or monitoring for production traffic, and Mimiq for the build before it ships.
Questions
Can I change the 3 second threshold?
Not per run yet. Tell us what you need at victor@mimiqai.com.
Does it record third-party errors?
No. Only requests and errors from the site under test, so ad blockers and analytics failures do not bury real problems.
Do I see the agent's reaction to the wait?
Yes. The step shows what the agent saw and said while it waited, which tells you whether the wait cost a user.
Keep reading
Let the agents find what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-10-22.