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

Consider dropping budgets from lighthouse core #15203

Closed
brendankenny opened this issue Jun 26, 2023 · 0 comments · Fixed by #15950
Closed

Consider dropping budgets from lighthouse core #15203

brendankenny opened this issue Jun 26, 2023 · 0 comments · Fixed by #15950
Assignees
Milestone

Comments

@brendankenny
Copy link
Member

Performance budgets in lighthouse core has always been a bit architecturally awkward, basically a secondary level of scoring and report on top of the core scoring and report. Another option at the time they were being developed was to make them external to Lighthouse itself -- run Lighthouse, then assert Lighthouse's output against a budget -- but that ended up not being chosen for various reasons. Budgets haven't functionally evolved since just after landing, and while relatively stable, have a pretty big code footprint. When the legacy runner is removed in 11.0, it might be a good time to remove budgets as well.

Some parts of budget functionality are so simple that it's borderline easier to do it manually than to set up a json file and add the command line flag (e.g. extract LCP with jq and assert that it's ≤ 2500ms), but some of it is harder and would require extra tools (e.g. picking which budget to apply to a particular page based on a path property with wildcards in it). We'd want a clear migration path (ideally requiring little to no work) for budget users if we remove budgets from lighthouse core.

lighthouse-ci has supported budgets.json as an assertion format since launch. It would be easy enough to install lighthouse-ci alongside lighthouse and use it to assert budget constraints. Bonuses:

  • lighthouse-ci actually sets the exit status code based on the outcome of the assertion (instead of burying the result in audits like performance-budget in the LHR that then still have to be extracted to be usable)
  • lighthouse-ci's assertion format has many more budgeting features than budgets.json supports, so developers can set more sophisticated conditions for the performance they want to maintain

The main thing blocking this is that the usual lighthouse-ci path requires setting up a testing end point, a database for LHRs, etc. If you just want to assert an LHR against a budget, that's too much work, but that should be easy to fix.

The assert command loads a bunch of LHRs and runs the requested assertions against them, either from an assertion preset (e.g. lighthouse:recommended), a set of lighthouse-ci-style assertions, or a budgets.json file. All of that is configurable except the directory the LHRs are loaded from, which only uses .lighthouseci/.

If that path were configurable, you could run lhci assert --lhr=path/to/lhr.json --budgetsFile=budget.json after lighthouse finishes. Your existing budgets work and you get the aforementioned bonus benefits, so now this line can also be dropped directly into github actions, etc.

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

Successfully merging a pull request may close this issue.

3 participants