Access to the complete Lighthouse metrics #79
Comments
@dschmidtadv thanks for reporting this. We will have a look if we can enable this. Our main concern is how we can make this a nice experience for the user. And extra insights on your use case would be very valuable. |
This would be a really valuable addition (I've noticed it being unavailable from the API recently), but I guess the issue is how verbose the JSON response might be if including that information. You're able to
|
Ah man I'd love this. Though one option is just surfacing the information for us to use in our pupetteer scripts. A first party solution that integrates with dashboards/screenshots etc would be incredible. E.g. the status pages feature v2 could include rolling averages for first paint etc. Pew pew. |
@StanLindsey @coderkind I hear you and we are looking into this! Our biggest concern regarding offering this service is the problem with "variability" See https://developers.google.com/web/tools/lighthouse/variability This means we have to first find an infrastructure solution that gives dependable, stable metrics without making it ridiculously expensive: this is a problem with many services that run Lighthouse in Lambda or equivalent FaaS infrastructure. |
@tnolet does the infrastructure need to be more dependable and stable than the one that currently allows you to use Puppeteer/Playwright to take screenshots? I appreciate there's variability between running Lighthouse tests (even run off a local machine). Regarding cost; is there a top-level of functionality from Lighthouse you might expose (kinda like how you're just allowing Chromium in Playwright right now)? I see options in the npm docs to limit certain checks, e.g.
|
@coderkind those are great suggestions and we are considering all options. The workloads are pretty different though, because of the strong emphasis on performance vs. the strong emphasis on functionality we have right now. |
@dschmidtadv @coderkind @StanLindsey we are taking more and more steps in the direction of supporting performance metrics. I'm sure you will be already somewhat satisfied with some features we are rolling out soon, but I would love to get your thoughts on "next steps" and how we can do better here. Would it be cool if I contact you for this for a short chat? |
@tnolet do you have any updates on the status of this work? I can see on https://www.checklyhq.com/docs/browser-checks/tracing-web-vitals/ that, for example, TTI (time to interactive) is missing. Potentially, TBT lacks context without a TTI measurement also. Additionally, CLS is listed as one of the 5 metrics offered, however is also listed under a section dictating what cannot be measured. Let me know if I missed something here. |
Hope this helps! |
💡 For general support requests and bug reports, please go to checklyhq.com/support
Is your feature request related to a problem? Please describe.
We are not able to access Lighthouse report details from the API when executing browser checks.
Describe the solution you'd like
We would like to be able to access Lighthouse report details so we can fail tests when performance degrades.
Describe alternatives you've considered
Some data is available thru the performance.getEntriesByName object, we are using this as a workaround.
The text was updated successfully, but these errors were encountered: