Budgets on "Estimated transfer size"

[cexbrayat]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

ng build allows to see the "Estimated Transfer Size" as of version v13.1.

It would be very neat to be able to define budgets based not only the "Raw size", but also on this "Estimated Transfer Size"

Describe the solution you'd like

Something along the lines of:

"budgets": [
  {
    "type": "initial-estimated",
    "maximumWarning": "80kb",
    "maximumError": "160kb"
},

or

"budgets": [
  {
    "type": "initial",
    "estimated": true,
    "maximumWarning": "80kb",
    "maximumError": "160kb"
},

[alan-agius4]

I am not sure about this one to be honest, "Estimated transfer" size is an estimate as the name implies. The actual compressed transfer size might vary between one hosting provider/server and another based on which compression algorithm and level is used.

I think that the estimated should only be used for information purposes only.

It is also important to point out, that while compression helps to reduces the size of the data transferred over the wire, the true size of the JavaScript file still matters a lot because it needs to be parsed and evaluated.

Maybe @mgeche and @dgp1130 have some other thoughts on this.

[dgp1130]

^ @mgechev (fixing typo-d reference)

My immediate reaction to this is that transfer size is probably (?) more important than raw size, but I'm not a web performance expert. Raw size definitely does matter like @alan-agius4 said, since it needs to be parsed and evaluated by the browser (of course tricks like JSON.parse('{"x": "some object literal"}') can have significant improvements on their own, so raw size isn't a perfect measurement of those attributes either). I believe Chrome DevTools' network panel uses transfer size, which is probably what many devs use as a mental comparison, though that has a different use case and context, so it doesn't necessarily mean we should budget on transfer size over raw size.

Since this is an estimate I think it is less useful for strict budgeting. We don't know what compression system or settings the app will actually deploy to prod with. IIRC, we don't actually compress the files with an arbitrary encoding and setting, but instead estimate the size of compressed content through other means. We could also change the algorithm for this estimate in future which would likely break some budgets.

@mgechev, are there are recommendations from Chrome / Aurora in this area? I'm sure they'll generally say that both raw and transfer sizes matter, but I'm curious if they have any higher level thoughts around how devs should think about their page weight. I think internally we use raw size for most benchmarks, but I'm not sure if that was an intentional decision because raw size was considered more useful, or because it's difficult to know what compression mechanism will be used?

[cexbrayat]

I'm not a web perf expert either, but I think estimated (even roughly) bundle size gives a better insight than the uncompressed raw size. Especially in generated code like we have in Angular where it can compress really well. In the end, as an application developer, what I'm really interested in is how much will be downloaded by users (been if I agree that raw sizes do matter as well).

Do you remember when we were rewriting Ivy, and we ended up with raw sizes that were better than VE, but compressed sizes were actually worse? We did not catch it initially because the benchmark was only tracking raw sizes (and then @kara spent days trying to figure out how to make Ivy more "compressable"). Even if this will not be so extreme in an application, I think setting budgets on estimated sizes could be very useful. @kara may have some insights as well now that she is on the Aurora team.