Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core(driver): add waitForFCP timeout #7356

Merged
merged 8 commits into from
Mar 5, 2019
Merged

core(driver): add waitForFCP timeout #7356

merged 8 commits into from
Mar 5, 2019

Conversation

patrickhulce
Copy link
Collaborator

Summary
Adds a maxWaitForFcp option that can optionally timeout the wait for FCP trigger earlier than overall load.

Related Issues/PRs
closes #7174

@@ -42,6 +42,7 @@ const throttling = {
/** @type {LH.Config.Settings} */
const defaultSettings = {
output: 'json',
maxWaitForFcp: 30 * 1000,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

open to other defaults, 20s maybe? not sure what's reasonable

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10s is fine IMO.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'll probably be too low when using real throttling though, no? :/

how about 15?

Copy link
Member

@paulirish paulirish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % timeout value

@paulirish
Copy link
Member

paulirish commented Mar 1, 2019 via email

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM2, whatever you decide about the exact timeout length

types/externs.d.ts Outdated Show resolved Hide resolved
/* eslint-enable max-len */

if (!waitForFCP) maxFCPMs = undefined;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a little confusing that there are two similar-but-different parameters for this, but this way does seem to make the most sense from both gather-runner and driver's perspectives, so I guess this is where we live now :)

@@ -881,6 +888,11 @@ class Driver {
return function() {
log.verbose('Driver', 'loadEventFired and network considered idle');
};
}).catch(err => {
// Throw the error in the cleanupFn so we still cleanup all our handlers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isn't getting easier to follow... :P

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, it's not, but it's very well tested now and ready for refactoring :)

@brendankenny
Copy link
Member

NO_FCP in the smoke tests, though, and that's for the 30s timeout? 😟

brendankenny and others added 2 commits March 2, 2019 10:36
Co-Authored-By: patrickhulce <patrick.hulce@gmail.com>
@patrickhulce
Copy link
Collaborator Author

NO_FCP in the smoke tests, though, and that's for the 30s timeout? 😟

yeah this makes me pretty nervous :/

@patrickhulce
Copy link
Collaborator Author

oh @brendankenny the FCP timeout was a legit issue with one of the smoketests having no content, now this fails early instead of letting the audits fail

@benschwarz
Copy link
Contributor

I think this is likely to cause issues when "real" throttling is used… (but of course I have no idea).
There'd be no drawback in setting this timeout to be the same as the max load timeout for devtools throttling, right? Should that be a default for that scenario?

@patrickhulce
Copy link
Collaborator Author

I think this is likely to cause issues when "real" throttling is used…

Yeah this was my concern with 10s. I'm not sure I've seen beyond more than 15s, but maybe this is more of a breaking change from that perspective...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Increased failures due to 60s timeout on PSI/LR
4 participants