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

New budget.json API #10617

Open
khempenius opened this issue Apr 21, 2020 · 3 comments
Open

New budget.json API #10617

khempenius opened this issue Apr 21, 2020 · 3 comments
Assignees

Comments

@khempenius
Copy link
Collaborator

khempenius commented Apr 21, 2020

Feature wishlist (not comprehensive):

  • Better home for CLS
  • Reduce over-reliance on the term “budget”
  • Syntax for features like UserTiming or FileSize budget

Discussed here:
#10579

@khempenius khempenius changed the title budget.json API, v2 Apr 21, 2020
@WebCloud
Copy link

Hello @khempenius! One of the things that me and my team have been trying to get done is to closely monitor our custom metrics through lighthouse reports. One possible great addition to the budget.json would be to be able to set a budget for user-timings for that purpose. That way we can assure those metrics don't degrade without any warning 😄.

@khempenius
Copy link
Collaborator Author

Hi @WebCloud, Thanks for the suggestion - this is a great idea. I created a issue for this (though tbh I've been bad at tracking things in Github rather than my head).

More broadly speaking, I think this is a good example of a usage pattern that the new budget.json API needs to address: the syntax for specifying budgets of things like user timings or file size where both a name (performance mark name, file name) and a metric (user-timing, file-size) needs to be supplied.

@thejimbirch
Copy link

Hi,

Developer here looking into budgets for the first time today at the request of a consultant. What I found not available from their request was:

  1. The ability to set a requirement on a total score like Lighthouse Page Speed Score > 90. We can of course work around this by having the test totally fail if it doesn't reach that number.
  2. First Input Delay (FID)
  3. Time to Interactive (TTI)
  4. Number of DOM elements. (This may be "resourceType": "total")
  5. HTML Requests (iframes) (This may be "resourceType": "third-party")

Thanks for a great too and for continuing to improve it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants