New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 883285 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocking:
issue 760498



Sign in to add a comment

startup.mobile benchmark: introduce metric like number_of_requests_before_navigation

Project Member Reported by pasko@chromium.org, Sep 12

Issue description

On intent-based startup scenarios the browser should not issue requests like https://www.gstatic.com/chrome/intelligence/assist/ranker/models/... even with IDLE priority before the main loading starts coming along.

One way to guard against accidental requests like that is to introduce a metric that would count the number of requests started before the first navigation requests starts.

Arguably, we also should not saturate the link after loading starts, so the same logic holds true for first contentful paint. On the other hand, an extra request with IDLE priority probably causes little problems when the page is loading.
 
At least part of this sounds like a correctness test that should be implemented elsewhere (not as part of perf testing)?
I think it's at least partly a perf test since the result will still be correct even if we issue extra requests before the main one -- it'll just take longer to load. We can't reliably detect this with WebPageReplay since the extra requests fail immediately and don't actually delay page load. 
Status: Untriaged (was: Available)
Available, but no owner or component? Please find a component, as no one will ever find this without one.

Sign in to add a comment