Parcel 2: Performance Budgets

[devongovett]

Performance budgets are an important part of modern web development. They enable teams to set limits for things like bundle sizes and request counts and prevent regressions over time by failing builds when the team goes over budget. Parcel's default reporter already displays a warning icon next to large bundles in production builds, but we should go farther and enable teams to define their own budgets and make this an error.

Budget Reporter

Support for performance budgets can be implemented in a Parcel 2 Reporter plugin. @parcel/reporter-budget should read budget configuration (discussed below) and report warnings, errors, and hints/suggestions about how to improve performance based on the bundles produced by Parcel. Because Parcel builds your whole app, including HTML, CSS, JS, images, etc., we are in a good position to provide helpful errors and suggestions to improve performance.

Configuration

Lighthouse has already defined a budget.json file that you can put in your repo to specify perf budgets. It allows you to specify limits for both bundle sizes and request counts. We could possibly reuse this very same configuration for Parcel. Alternatively, we could create our own budget file or key in package.json. Looking for feedback here.

Default config

We should have some default limits out of the box when this plugin is enabled:

• Maximum script size: 250kb?
• Maximum number of entry assets (network requests): ??

Looking for feedback here.

Performance Suggestions

Because Parcel is building your whole app, it has a good overall view of all of your code and assets. When we detect a bundle that is too big, or other types of performance pitfalls, we could provide suggestions in the CLI on how to fix it. Here are some initial ideas:

• Suggest code splitting when a large JS bundle is seen
• Suggest using module/nomodule to reduce transpilation cost
• Suggest optimizing large images (see also: Parcel 2: Compression and Image Optimization #3739)
• Suggest using a bundle analyzer to view more detailed information about what's in a bundle
• Suggest avoiding large non-treeshakable libraries (e.g. lodash -> lodash-es, though probably not specific libs?)
• etc.

Feedback

Please leave feedback in the comments below. I'm specifically interested in hearing more ideas on how to make performance budgets and suggestions as useful as possible.

[Banou26]

I'm not sure if I'm the only one having this point of view, but I'd also like having the limits as compressed sizes instead of only the uncompressed size.

I find it easier to visualize bundles/resources weight using an over the network compressed size(gzip, brotli, ect...).

I guess it's probably from the fact that all libs advertise themselves as "XXXkb gzip'd".

[devongovett]

I think one of the reasons that budgets typically measure uncompressed sizes is because regardless of the compression you use, browsers still need to parse all that uncompressed JS which can be slow. But perhaps both are useful.

[jamiekyle-eb]

It would be nice to reuse budget.json. Although we may end up wanting to add more things to it.

[jamiekyle-eb]

We should have some default limits out of the box when this plugin is enabled: [...] Looking for feedback here.

Should we ask some people who work on lighthouse?

[LeoDog896]

This would be extremely useful - at pest-parser/site, there is a need to check for size limits on the website.