ميزانيات الأداء باستخدام Lighthouse

A performance budget is a set of agreed limits, such as max JavaScript size or a minimum LCP, that the team commits not to exceed. It turns vague goals into enforceable thresholds.

Without budgets, performance erodes silently as features pile on. A budget makes regressions visible and blocking, shifting performance left into development.

• Resource budgets: byte size and request counts per type (script, image, total).
• Timing budgets: metric thresholds like LCP, TBT, CLS.

Lighthouse reads a budget.json describing resource and timing limits. It then flags any audited page that exceeds them.

Timings are listed alongside sizes. Values are in milliseconds for time metrics.

Pass the budget file to the Lighthouse CLI. Exceeded items appear in the report's Budgets section.

Lighthouse CI (lhci) can assert budgets and fail the build when limits are breached, so regressions never merge.

Assertions support warn and error levels. Start new budgets as warnings to gather data, then promote to errors once the team is confident.

Base budgets on current measurements plus a small margin, or on competitor benchmarks. Budgets that are impossible to meet get ignored; budgets that are too loose never fire.

The LHCI server stores historical results so you can chart metric and size trends and tighten budgets gradually as performance improves.

• Define resource and timing budgets.
• Run them locally via CLI.
• Assert them in CI with LHCI.
• Start as warnings, then enforce as errors.

You want a pull request to fail automatically when the script bundle grows beyond a set size. What achieves this?

You learned to set resource and timing budgets in budget.json, run them with the Lighthouse CLI, and enforce them in CI via Lighthouse CI assertions. Start with warnings, promote to errors, and track trends to keep performance from regressing.