You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 apath
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 supportedbudgets.json
as an assertion format since launch. It would be easy enough to installlighthouse-ci
alongsidelighthouse
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 likeperformance-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 maintainThe 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 oflighthouse-ci
-style assertions, or abudgets.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.The text was updated successfully, but these errors were encountered: