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

Problems with mesuring slow sites #1464

Closed
denar90 opened this issue Jan 13, 2017 · 8 comments
Closed

Problems with mesuring slow sites #1464

denar90 opened this issue Jan 13, 2017 · 8 comments
Assignees

Comments

@denar90
Copy link
Contributor

denar90 commented Jan 13, 2017

Hi. We got some issue in pwmetrics project, where users and me personally faced some problems using ligthouse API for getting site metrics. So I used @paulirish suggestion and run trace stuff (cloned repo and run node lighthouse-cli --save-assets --save-artifacts https://www.cnet.com/special-reports/jony-ive-talks-about-putting-the-apple-touch-on-the-macbook-pro/ --output=json > results.json). I'm attaching archive with results for kinda slow site.
Hope it will help you guys.

P.S. Don't hesitate to ask me for additional info or smth.

results.zip

Thanks.

@denar90
Copy link
Contributor Author

denar90 commented Jan 13, 2017

One more thing. After debugging I found out that Lighthouse throws error: No usable firstMeaningfulPaint event found in trace twice.

@wardpeet
Copy link
Collaborator

wardpeet commented Jan 18, 2017

I always get a memory exception when saving the trace. I'll have a look at your results :)

@tmf
Copy link

tmf commented Jan 20, 2017

Hi @denar90 @wardpeet,
First: a big thank you for this awesome project!

I also looked into this issue and found that there could be several reasons for this (not finding a firstMeaningfulPaint event in the trace):

There could be several ways to solve the problem:

  • pass in a driver flag pauseAfterLoad to wait more after both the load event and network idle event have been detected... This will (unreliably) give the driver the chance to record the fMP.
  • extend recording the trace by waiting for the fMP event in either a gatherer's pass method or by adding a promise to wait for the trace event in the driver's _waitForFullyLoaded method . This should only happen when the the pass is configured to record the trace from the beginning.
  • MAX_WAIT_FOR_FULLY_LOADED should maybe be overridable by a flag: with a 5x CPU throttling it is more probable for slow sites to run into this hardcoded timeout of 25 seconds.

Hope that helps :)

@wardpeet
Copy link
Collaborator

Thanks for the breakdown, maybe a better solution is when no fMP at all can be found we can just classify your site as slow XD

@denar90
Copy link
Contributor Author

denar90 commented Jan 21, 2017

Do you have any idea how can it be interpreted? Maybe return firstMeaningfulPaint value equals to some constant which means that site is to slow... We really need some indicator for this.


But I also like an idea about making MAX_WAIT_FOR_FULLY_LOADED changeable (change it value by flag value)...

@wardpeet
Copy link
Collaborator

wardpeet commented Jan 21, 2017

@denar90 would you find it useful that you can change it?
I would find it more useful to show that pageload took longer than 30s. Than you know that you have a slow site no? (might be wrong 😄 )

@denar90
Copy link
Contributor Author

denar90 commented Jan 21, 2017

I think so. Taking as example site we are having issue with, and using webpagetest I got these results
https://www.webpagetest.org/result/170121_0G_WY7/
It's very slooooow. Load Time - 71.087s !!!

@denar90
Copy link
Contributor Author

denar90 commented Feb 27, 2017

Looks like fixed 🎉
Thanks guys 💃

@denar90 denar90 closed this as completed Feb 27, 2017
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

No branches or pull requests

3 participants