docs: Publish the performance targets and measurements document

[turbobobbytraykov]

Description

Publishes docs/performance.md — the performance budget for IgniteUI.Blazor.Lite — and links it from the README and the changelog.

The document exists so that a size or latency regression is a decision somebody makes on the record, rather than something a consumer discovers after upgrading. It covers:

• Scope — the static web assets shipped under _content/IgniteUI.Blazor. Explicitly not the consuming app's own bundle, the Blazor framework payload, or the WebAssembly runtime download, none of which this package controls.
• Asset size budgets — measured raw and gzip figures per group and per total, taken from a production webpack build on Node 22 against igniteui-webcomponents 7.2.4, each alongside the budget it is checked against.
• Two things the numbers need context for — source maps are two thirds of the package on disk but are never fetched unless devtools is open, so they carry a raw budget and no gzip budget; and the themes figure is all eight prebuilt stylesheets, not the per-page cost of the one a consumer references.
• Runtime targets — four latency targets against the Interactive Server test bed, published as a commitment and marked plainly as not yet measured per release, since the timing harness lands with the accessibility automation.
• Changing a budget — raising one is allowed and sometimes correct; raising it silently is not. The rule is: update eng/bundle-budgets.json, update the measured column, and say why in the changelog.

The one substantive change from the version in #371

The document now records that every release publishes its budget in the workflow run summary, not only as an attached artefact. eng/Check-BundleBudget.ps1 already appends the measured-versus-budget tables and any breaches to $GITHUB_STEP_SUMMARY; the doc previously mentioned only performance-report.md/.json on the release. The practical difference for a reviewer is that the numbers for a given release are readable straight from its run — no artefact download, and no need to trust that the table in this document is still current.

Motivation / Context

This is the PERF-09/10 gap from the package readiness assessment: the package had no published size or latency budget, so there was no threshold a regression could be measured against and no record of what "acceptable" meant.

Split out of #371 so the budget can be reviewed on its own terms rather than as a footnote to a release-workflow refactor.

Important

This document describes enforcement that lives in #371. eng/bundle-budgets.json, eng/Check-BundleBudget.ps1 and the evidence job are not on master yet, so until #371 merges the two relative links in the opening paragraph will 404 and the "enforced, not aspirational" claim describes machinery that is one PR away. If that is not acceptable, this PR should merge after #371 rather than before it — or the enforcement files should be pulled in here. Flagging rather than deciding.

Type of Change (check all that apply):

• Bug fix
• New functionality
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (no functional changes)
• Documentation
• Demos
• CI/CD
• Tests
• Changelog

Component(s) / Area(s) Affected:

Documentation only. No product code, build, or workflow changes.

How Has This Been Tested?

• Unit tests
• Manual testing
• Automated e2e tests

The run-summary claim was verified against the script rather than assumed: eng/Check-BundleBudget.ps1 builds the totals and groups tables plus a "Budget breaches" section, writes them to performance-report.md, and appends the same lines to $GITHUB_STEP_SUMMARY when it is set. Relative link targets were checked against master — see the note above for the two that do not resolve yet.

Test Configuration:

• .NET version: n/a
• Hosting model: n/a
• Browser(s): n/a
• OS: n/a

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code
• This PR includes API docs for newly added methods/properties
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes behavioral changes and the feature specification has been updated with them
• Accessibility (ARIA, keyboard navigation, focus management) has been verified

[Copilot]

🟡 Changes recommended

The new document claims and links to enforcement machinery under eng/ that is not present in this PR (broken links + “enforced today” wording becomes incorrect when published standalone).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Publishes a performance budget/targets document for IgniteUI.Blazor.Lite and surfaces it from the repo’s primary documentation (README + changelog), so bundle-size/regression expectations are discoverable and reviewable.

Changes:

• Add docs/performance.md documenting scope, bundle-size budgets, runtime targets, and local reproduction steps.
• Link the new performance document from README.md.
• Add a changelog entry announcing the published performance budget/targets document.

File summaries

File	Description
README.md	Adds a new “Performance” section linking to the published performance budget/targets doc.
docs/performance.md	Introduces the performance targets and size budgets document (tables + guidance).
CHANGELOG.md	Records publication of the performance document in the Unreleased “Added” section.

Review details

Suppressed comments (1)

docs/performance.md:52

• This sentence states that the bundle-size budget is “enforced today”, but in this PR there is no eng/ enforcement script/budgets present. To avoid the doc becoming incorrect when published without the enforcement PR, make this statement conditional/neutral (or explicitly refer back to the earlier caveat).

**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.

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.