Choose the right wait for a page that loads data later

Why the first scan can miss things

Many pages render their shell first and add results after JavaScript runs. A scan immediately after navigation may see an empty results area, a loading message, or only part of the final interface. The right wait makes a crawl more useful, but it cannot make every dynamic page deterministic by itself.

Prefer a selector that represents readiness

If the page has a stable element that only appears when the content is ready, add a page rule for that URL and wait for the selector. Choose something tied to the completed interface, such as the results list or a status region changing to its ready state. Avoid selectors that exist in the initial skeleton, since they do not prove the data has arrived.

Use network idle or a delay deliberately

A network-idle rule waits for the tab to have a quiet period; a delay waits for a fixed number of milliseconds. Both are bounded. Network idle can be a poor fit for pages with polling, analytics, or long-lived requests. A fixed delay is simple but can be too short on a slow run and unnecessarily long on a fast one.

Set the rule in the profile builder

Open the test-config builder, enter the site target, enable crawling, and add a page rule matching the page path. Select selector, network idle, or delay and use the smallest value that consistently captures the ready state. Export the JSON and import it into the extension before starting the crawl.

Check the captured result

Run the same crawl more than once and inspect whether the expected content is present in the findings. If a selector never appears, fix the selector or investigate whether the page requires a signed-in session. Treat API response mocks as a separate feature: they replace matching same-origin fetch or XHR responses for repeatable tests; they do not wait for a live API response.