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

User Story: WebAssembly developers want smaller published output to speed up their apps load time #44317

Closed
8 of 9 tasks
Tracked by #43767
marek-safar opened this issue Nov 5, 2020 · 6 comments
Closed
8 of 9 tasks
Tracked by #43767
Assignees
Labels
area-Meta Cost:L Work that requires one engineer up to 4 weeks needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration Priority:1 Work that is critical for the release, but we could probably ship without size-reduction Issues impacting final app size primary for size sensitive workloads User Story A single user-facing feature. Can be grouped under an epic.
Milestone

Comments

@marek-safar
Copy link
Contributor

marek-safar commented Nov 5, 2020

In the .NET 5 release, we established a baseline of 2.2 MB for the fully compressed output of the default Blazor template running with .NET Core setup. For .NET 6 version, we are aiming to reduce that size by at least 20% for the same template to address size regression compare to .NET Core 3.x where the default template size was 1.7 MB. This is an ambitious goal, and will likely require numerous aggressive approaches to achieve it, including the removal of numerous non-essential features.

The only concern here is the wire size with full compression (at the moment, Brotli). The size or the required computation on either end is unimportant.

There is a dashboard available for historical size tracking at https://aka.ms/dotnetperfstatus. The case we care about is file type .br, .NET 6. Of particular note is the currently largest files: dotnet.wasm at 0.9 MB, System.Private.CoreLib.dll at 0.4 MB, and icudt.dat at 0.3 MB. No other file is above 0.1 MB, but combined they are around 0.6 MB.

Work Items

@marek-safar marek-safar added User Story A single user-facing feature. Can be grouped under an epic. Priority:1 Work that is critical for the release, but we could probably ship without Cost:L Work that requires one engineer up to 4 weeks labels Nov 5, 2020
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 5, 2020
@marek-safar marek-safar removed the untriaged New issue has not been triaged by the area owner label Nov 5, 2020
@marek-safar marek-safar changed the title User Story: Browser workloads will reduce published output to speed up web pages load User Story: Browser workloads have to reduce published output to speed up web pages load Nov 5, 2020
@ghost
Copy link

ghost commented Nov 6, 2020

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

@marek-safar marek-safar changed the title User Story: Browser workloads have to reduce published output to speed up web pages load User Story: Browser developers want smaller published output to speed up theirs apps load time Nov 27, 2020
@marek-safar marek-safar changed the title User Story: Browser developers want smaller published output to speed up theirs apps load time User Story: Browser developers want smaller published output to speed up their apps load time Nov 27, 2020
@marek-safar marek-safar changed the title User Story: Browser developers want smaller published output to speed up their apps load time User Story: WebAssembly developers want smaller published output to speed up their apps load time Nov 27, 2020
@SambhavSacheti
Copy link

SambhavSacheti commented Nov 28, 2020

Hi @marek-safar - The link https://aka.ms/dotnetperfstatus is not working :-(

@marek-safar
Copy link
Contributor Author

It does for me but it probably requires different permissions (we'll need to check)

@marek-safar marek-safar added the size-reduction Issues impacting final app size primary for size sensitive workloads label Dec 9, 2020
@SamMonoRT
Copy link
Member

@SambhavSacheti does this link work for you - https://aka.ms/blazorwasmsize ?

@joperezr joperezr added this to the 6.0.0 milestone Feb 9, 2021
@lewing
Copy link
Member

lewing commented Aug 11, 2021

Nothing left is targeting 6.0

@lewing lewing modified the milestones: 6.0.0, 7.0.0 Aug 11, 2021
@ghost ghost added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Aug 31, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Sep 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta Cost:L Work that requires one engineer up to 4 weeks needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration Priority:1 Work that is critical for the release, but we could probably ship without size-reduction Issues impacting final app size primary for size sensitive workloads User Story A single user-facing feature. Can be grouped under an epic.
Projects
No open projects
Development

No branches or pull requests

8 participants