Repository navigation
Budgets on "Estimated transfer size" #22293
Description
Activity
- changed the title
[-]Budgets on "Estimated trasnfer size"[/-][+]Budgets on "Estimated transfer size"[/+]on Dec 3, 2021 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.
^ @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?
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.
Just what I'm looking forward to, estimated transfer size is what actually matters. I have an initial raw size of 3.5mb (with all styles & basic components from my ui framework), but while transmitting its only about 490kb. I had been using Webpack Bundle Analyzer to be sure the transmitting size is not over 500kb in prior versions.
It just got a bit easy with 13.x, this feature will make it much more easier.
Hi everyone, thanks for the discussion and input on this over time!
After revisiting this feature request, we have decided not to move forward with adding budgets based on estimated transfer sizes, and we will be closing this issue.
Here is the rationale behind this decision:
-
Deterministic CI Gating:
CLI budgets serve as hard gates in CI/CD pipelines (failing the build when exceeded). Uncompressed raw size is completely deterministic and reproducible across all environments. In contrast, "estimated transfer size" is an approximation. The actual over-the-wire size depends entirely on how and where the application is deployed (e.g. Brotli vs. Gzip, compression levels, dynamic CDN compression like Cloudflare vs. pre-compressed static assets). Gating a build on an estimate means changes in compression libraries or heuristics between tool versions could cause CI builds to fail without any code changes in the project. -
The True Cost of JavaScript (CPU & Memory):
While transfer size dictates download time over the network, raw uncompressed size directly drives decompression, parsing, bytecode compilation, and memory consumption in the browser. Compression does not reduce the CPU execution cost or heap memory overhead on the client, which are critical drivers of Core Web Vitals like Interaction to Next Paint (INP) and Total Blocking Time (TBT). Budgeting against uncompressed size remains the most effective guardrail against main-thread performance degradation on real-world (especially mobile) devices. -
Appropriate Tooling:
CLI budgets are intended as static guardrails against accidental code bloat (e.g. inadvertently importing an entire heavy library instead of a single utility). For teams that want strict budget gates specifically on compressed or over-the-wire transfer sizes, dedicated performance tools like Lighthouse CI,size-limit, or CDN-level deployment checks are much better suited to evaluate your assets in the context of your specific hosting environment.
Thank you again for opening this request and contributing to the discussion!
-
🚀 Feature request
Command (mark with an
x)Description
ng buildallows 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:
or