Skip to content

docs: Publish the performance targets and measurements document #382

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.

Sign up for GitHub

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

Draft
turbobobbytraykov wants to merge 1 commit into
base: master
Choose a base branch
from
+75 −0
Draft

docs: Publish the performance targets and measurements document #382

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

## Unreleased

### Added

- Published a [performance targets and measurements](docs/performance.md) document recording the enforced bundle size budgets, the runtime targets, and how to reseed a budget. Every release publishes its measured sizes against those budgets in the workflow run summary.

## 0.1.0 - 2026-07-14

This release updates the Ignite UI for Blazor to the latest [igniteui-webcomponents@7.2.4 release](https://github.com/IgniteUI/igniteui-webcomponents/releases/tag/7.2.4) and matching related changes from `IgniteUI.Blazor` [25.2.77 (March 2026)](https://www.infragistics.com/products/ignite-ui-blazor/blazor/components/general-changelog-dv-blazor#25277-march-2026), [25.2.102 (May 2026)](https://www.infragistics.com/products/ignite-ui-blazor/blazor/components/general-changelog-dv-blazor#252102-may-2026) and [26.1.51 (June 2026)](https://www.infragistics.com/products/ignite-ui-blazor/blazor/components/general-changelog-dv-blazor#26151-june-2026) with highlights noted below:
Expand Down
4 changes: 4 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,6 +192,10 @@ After the above steps, open the solution in Visual Studio or run the stories pro
dotnet run --project stories/IgniteUI.Blazor.Stories.csproj
```

## Performance

- [Performance targets and measurements](docs/performance.md) — the enforced bundle size budgets and the runtime targets.

[Dock Manager]: https://www.infragistics.com/products/ignite-ui-blazor/blazor/components/layouts/dock-manager
[Commercial]: https://www.infragistics.com/legal/license
[MIT]: https://github.com/IgniteUI/igniteui-blazor/blob/master/LICENSE
Expand Down
67 changes: 67 additions & 0 deletions docs/performance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
# Performance targets and measurements

This document is the published performance budget for `IgniteUI.Blazor.Lite`. It exists so that a size or latency regression is a decision somebody makes on the record, rather than something a consumer discovers after upgrading.

Budgets are enforced, not aspirational: [`eng/bundle-budgets.json`](../eng/bundle-budgets.json) holds the numbers and [`eng/Check-BundleBudget.ps1`](../eng/Check-BundleBudget.ps1) fails the release when an asset exceeds one. The `evidence` job of the release workflow runs that check against the assets that were actually built and attaches `performance-report.md` and `performance-report.json` to the GitHub release.

Every release also publishes its budget in the workflow run summary: the same measured-versus-budget tables, plus any breaches, are written to the job summary of the run that produced the package. The numbers for a given release are therefore readable directly from its run, without downloading an artefact or trusting the table below to still be current.
Comment on lines +5 to +7

## Scope

These budgets cover the static web assets the package ships under `_content/IgniteUI.Blazor`. They do not cover the consuming application's own bundle, the Blazor framework payload, or the .NET runtime download in a WebAssembly host — those are outside anything this package controls.

## Asset size budgets

Measured on 2026-08-27 from a production webpack build (`npm run build` followed by `npm run copythemes`) on Node 22, against `igniteui-webcomponents` 7.2.4.

| Group | Measured raw KiB | Raw budget | Measured gzip KiB | Gzip budget |
| --- | ---: | ---: | ---: | ---: |
| `loader` | 2.5 | 8 | 1.0 | 4 |
| `app` | 408.8 | 460 | 103.8 | 118 |
| `web-components-core` | 272.2 | 310 | 34.5 | 40 |
| `web-components` | 1912.4 | 2100 | 255.6 | 285 |
| `lazy-chunks` | 88.2 | 120 | 27.8 | 40 |
| `license-notices` | 0.7 | 8 | n/a | n/a |
| `source-maps` | 6119.1 | 6900 | n/a | n/a |
| `themes` | 312.8 | 345 | 30.9 | 36 |

| Total | Measured raw KiB | Raw budget | Measured gzip KiB | Gzip budget |
| --- | ---: | ---: | ---: | ---: |
| `served-javascript` | 2684.2 | 2950 | 422.6 | 470 |
| `served-assets` | 2997.0 | 3300 | 453.5 | 510 |
| `package-static-web-assets` | 9116.8 | 10240 | n/a | n/a |

Bundle filenames are content-hashed, so budgets are expressed as patterns rather than filenames, and a file's group is whichever pattern matches it first. `eng/bundle-budgets.json` lists specific patterns before catch-alls for exactly this reason — for example `app.*.bundle.js` is listed ahead of the generic `*.bundle.js`, so an app bundle is budgeted as `app`, not folded into `lazy-chunks`. An asset that matches no pattern at all fails the check, so a new bundle cannot enter the package without someone budgeting for it.

Two things worth knowing about these numbers:

- Source maps are two thirds of the package on disk but are never requested unless a developer opens devtools, so they carry a raw budget and no gzip budget. `served-assets` is the number that describes what a user actually downloads.
- Themes ship as eight prebuilt stylesheets and a consumer references one of them, so the `themes` figure is the whole set, not the per-page cost.

## Runtime targets

The following targets apply to the reference scenario — the Interactive Server test bed in [`tests/IgniteUI.Blazor.Lite.TestBed`](../tests/IgniteUI.Blazor.Lite.TestBed) rendering a single component on a warm server over a local connection, measured on the CI runner class.

| Metric | Target |
| --- | --- |
| Time from `blazor.web.js` start to the package's JS initializer resolving | < 250 ms |
| First component upgrade (custom element defined and rendered) after initializer | < 150 ms |
| Property write from .NET to reflected DOM state | < 50 ms |
| User interaction to `EventCallback` invocation on the server | < 100 ms plus circuit round-trip |

**These runtime targets are published but not yet measured per release.** The bundle-size half of this budget is enforced today; the timing harness that produces the runtime half is tracked separately and lands with the accessibility automation. Until it does, treat the table above as the committed target and the absence of a recorded measurement as a known gap rather than a passing result.

## Changing a budget

Raising a budget is allowed and sometimes correct — a new component or an upstream `igniteui-webcomponents` release legitimately adds bytes. What is not allowed is raising it silently. Update the number in `eng/bundle-budgets.json`, update the measured column in this table, and say why in the changelog entry for the release that carries the increase.

## Reproducing locally

```pwsh
npm ci
npm run build
npm run copythemes
./eng/Check-BundleBudget.ps1
```

The report is written to `artifacts/perf/`. Pass `-ReportOnly` to measure without failing, which is what you want when reseeding budgets after an intentional increase.
Loading