Anchoring Performance Budgets and Governance in the Team

1. Why performance can't be a single person's job

In many Magento teams there's exactly one person responsible for performance: the senior developer who understands Varnish, or the one colleague who regularly reads Lighthouse reports. Every other decision in the team, new features, third-party integrations, marketing scripts, gets made without regard for load time, because "the performance person will catch it anyway". The result is a bottleneck: that one person becomes the choke point for every deploy decision, and as soon as they go on vacation or leave the company, performance quietly degrades without anyone noticing, until customers complain or revenue drops.

The structural problem is a single point of failure for both knowledge and responsibility. Delegating performance to one person implicitly signals to the rest of the team that load time isn't their job. Governance means deliberately breaking that pattern: anyone who merges code into a Magento or Hyva project shares responsibility for its impact on LCP, INP, and bundle size, the same way everyone shares responsibility for security gaps or test coverage.

2. Defining performance budgets: from metric to team contract

A performance budget is a fixed, team-agreed ceiling for a measurable quantity, for example the maximum JavaScript bundle size, the maximum time to first byte, or an LCP threshold for the category page. The crucial difference from a plain target metric: a budget gets technically enforced, not just measured. Without enforcement, a budget stays a statement of intent, and that's the first thing to fall when a sprint gets tight.

Budgets should be defined per page type, because a category page with 48 products has different requirements than a checkout page. For Hyva stores, a reasonable starting point is an initial JS bundle budget of 170 to 200 KB (gzip), an LCP budget under 2.0 seconds at the 75th percentile, and a CSS budget under 60 KB after Tailwind purging. These numbers don't belong on a wiki page nobody reads, they belong in a machine-readable configuration file evaluated by the CI pipeline.

{
  "path": "/catalogsearch/result/",
  "resourceSizes": [
    { "resourceType": "script", "budget": 190 },
    { "resourceType": "stylesheet", "budget": 60 },
    { "resourceType": "image", "budget": 350 },
    { "resourceType": "total", "budget": 700 }
  ],
  "timings": [
    { "metric": "interactive", "budget": 3500 },
    { "metric": "largest-contentful-paint", "budget": 2000 }
  ]
}

3. Anchoring performance checks in code review

A performance budget only becomes effective once it's part of everyday code review, not a separate process that runs at some later point. Every pull request template should include a short performance checklist: were new images shipped with width/height and the right format? Was a new npm package checked for tree-shakability? Does the change trigger additional network requests in the critical rendering path?

Reviewers should be explicitly encouraged to reject a PR for performance regressions, the same way they would for missing tests. In practice this works best with a fixed comment template reviewers insert when they spot an issue, combined with a local script developers can run themselves before pushing. That way the check becomes a habit instead of an after-the-fact inspection, and nobody feels called out, because the tool delivers the number, not a colleague.

#!/usr/bin/env bash
# Pre-push hook: block the push if the JS bundle budget is violated
set -euo pipefail

BUDGET_KB=200
BUILD_DIR="pub/static/frontend/Mironsoft/default/en_US"

bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

BUNDLE_SIZE_KB=$(du -k "$BUILD_DIR"/js/*.js 2>/dev/null | awk '{sum+=$1} END {print sum}')

if [ "$BUNDLE_SIZE_KB" -gt "$BUDGET_KB" ]; then
  echo "Performance budget exceeded: ${BUNDLE_SIZE_KB}KB > ${BUDGET_KB}KB"
  echo "Review the code review checklist before pushing: docs/performance-checklist.md"
  exit 1
fi

echo "Bundle size OK: ${BUNDLE_SIZE_KB}KB / ${BUDGET_KB}KB"

4. CI/CD as a gatekeeper: enforcing budgets automatically

Human reviewers miss regressions, especially when a bundle grows slowly across many small commits. That's why actual enforcement of a performance budget belongs in the CI pipeline, not in the goodwill of individual reviewers. A Lighthouse CI run against a staging instance on every pull request, combined with a bundle size check, surfaces regressions before they land on the main branch.

What matters is that a budget violation actually turns the build red, not just leaves a warning in a PR comment nobody reads. A red build is unambiguous and technically blocks the merge, similar to a failing unit test. At the same time, there should be a documented, deliberate exception process, such as a label like "budget-override-approved" that a tech lead must explicitly set, so exceptions stay traceable instead of quietly becoming the norm.

name: performance-budget

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse-ci:
    runs-on: ubuntu-latest
    steps:
      # Check out the pull request branch
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: bin/npm ci

      - name: Build Hyva theme assets
        run: bin/npm run build

      # Fail the build if any page exceeds its Lighthouse budget
      - name: Run Lighthouse CI against staging
        uses: treosh/lighthouse-ci-action@v11
        with:
          configPath: ./lighthouserc.json
          uploadArtifacts: true
          temporaryPublicStorage: true

      - name: Post budget results as a PR comment
        if: failure()
        run: echo "Performance budget violated, see the Lighthouse CI report above"

5. Making dashboards visible to the whole team

Performance data that only one person sees in a private Lighthouse report doesn't change team behavior. A dashboard visible in the daily standup, on a screen in the team room, or as a Slack digest turns performance into a shared state instead of hidden knowledge. Grafana with a Prometheus or InfluxDB data source, fed from real user monitoring via the web-vitals library, works well because it shows trends over weeks instead of just snapshots.

Granularity is the deciding factor: a single aggregated number obscures which team or which page is responsible. A dashboard showing p75 LCP per page type and per most recent deploy makes the causal chain between a change and a regression immediately visible. For Magento teams it also helps to overlay deploy markers from the CI pipeline on the performance time series, so a sudden spike can be traced directly back to a release.

{
  "title": "LCP p75 by Page Type (7d)",
  "targets": [
    {
      "expr": "histogram_quantile(0.75, sum(rate(web_vitals_lcp_seconds_bucket[7d])) by (page_type, le))",
      "legendFormat": "{{page_type}}"
    }
  ],
  "thresholds": {
    "steps": [
      { "color": "green", "value": 0 },
      { "color": "yellow", "value": 2.0 },
      { "color": "red", "value": 2.5 }
    ]
  }
}

6. Performance as a sprint goal, not an afterthought

As long as performance work only happens "when there's time left over", it practically never happens, because there's never time left over in the daily grind of a sprint. Performance tasks belong in the backlog as their own tickets, estimated and prioritized like any other feature, not as invisible side work nobody on the sprint board is credited for. A simple, effective approach: every sprint reserves a fixed share of capacity, say 10 to 15 percent, explicitly for performance and technical debt work.

To keep this from becoming lip service, performance should also show up in the definition of done: a story only counts as finished once the budget for the affected page is met. Product owners need to understand that a regression in checkout performance is a bug just like a broken discount code, and needs to be prioritized in the backlog accordingly, instead of being pushed aside as a "technical detail".

7. Handling pushback when deadlines compete with performance work

In practice, performance work regularly collides with feature deadlines, especially ahead of major campaigns like a Black Friday launch. The most common mistake is quietly ignoring performance budgets in those moments because "we don't have time for this right now". This is exactly where it becomes clear whether governance is real or just exists on paper: an exception process with visible approval is better than a silent rule bypass, because it makes the cost of the decision visible.

It helps to translate performance costs into business language instead of arguing in milliseconds: one extra second of load time on the product page tends to correlate with a noticeable drop in conversion rate, especially on mobile devices. Once stakeholders understand that a missed performance budget means real revenue loss, prioritization gets easier. An escalation path where the tech lead and product owner decide together, instead of one side deciding alone, also prevents performance from always being the losing party.

8. Roles, responsibilities, and a sustainable performance culture

A performance champion model works better than a single permanently responsible person: a champion who rotates every sprint or quarter moderates performance reviews, maintains the budget configuration, and is the first point of contact for regressions, without being the sole executor. This spreads knowledge across the whole team, and the role becomes a learning opportunity instead of a permanent load on one person.

In Magento and Hyva projects, this responsibility can be mapped cleanly through codeowner rules and layout XML conventions: critical templates and blocks that frequently affect LCP or INP, such as category pages or checkout, get a comment block referencing the associated budget, so every developer sees the context immediately when opening the file. Retrospectives should discuss performance regressions the same way they discuss production incidents, including a short root cause analysis, so the same cause doesn't come back in the next release.

<!-- Layout XML: mark a performance-critical block with its budget owner -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <!-- Performance budget: LCP under 2.0s, owner: category page squad -->
        <!-- See performance-budgets.json for the enforced threshold -->
        <referenceBlock name="category.products.list">
            <arguments>
                <argument name="cache_lifetime" xsi:type="number">3600</argument>
            </arguments>
        </referenceBlock>

        <!-- Reviewer checklist item: does this block add render-blocking JS? -->
        <remove src="ThirdParty_Module::js/heavy-banner-rotator.js"/>
    </body>
</page>

9. Performance governance compared: individual ownership vs. team ownership

The difference between a team that leaves performance to a single person and a team with established governance shows up along the same recurring dimensions. The table below summarizes where the biggest differences lie.

In practice, these dimensions reinforce each other: without a visible dashboard there's no basis for a sprint goal, and without a sprint goal a code review comment has no follow-through. Teams that introduce all four levers together typically see a noticeably more stable performance baseline within a few sprints, instead of the usual sawtooth curve of improvement right after an audit followed by slow decay afterward.

10. Summary

Performance governance solves a structural problem: as long as load time remains one person's job, it inevitably degrades once that person is unavailable or under time pressure. A performance budget only becomes effective once it's technically enforced, visible in code review, turns the build red in the CI pipeline, and stays viewable for the whole team through a dashboard. Only that combination turns a good intention into a durable practice.

The decisive cultural shift lies in treating performance as a fixed part of sprint planning, with reserved capacity and a place in the definition of done, instead of an afterthought that's the first thing cut under deadline pressure. A rotating champion model spreads knowledge across the team, and a visible, documented exception process ensures that pushback against competing feature deadlines plays out productively instead of destructively.

11. FAQ: Performance Governance in the Team