A Fast Website Has to Stay Fast at Every Release

743e4881aa7966bb06de5bb4c9b8d133d41069ec9189c5d90347a6d9fa8eaa37

Give design decisions a performance budget

A performance budget is an agreed limit before a team adds more work to a page. It can cover display time, blocking work, or JavaScript transfer size. An image or widget becomes easier to assess when its cost has a visible allowance.

These are illustrative, stricter starting points than the actual policy above. Measure a baseline under a defined test profile before adopting them. They are not measurements of Enersys production.

The illustrative 3,500 ms lab limit does not change the 2.5-second Core Web Vitals good threshold. Passing a load-time CLS check also cannot establish that nothing shifts after a visitor scrolls or opens another part of the page.

The 250 KiB budget needs a definition of what it includes. A report of uncompressed file size and a report of network transfer size cannot be compared directly as a regression.

Start with a limit the team can maintain and set a date to tighten it. A threshold that needs an exception on every release will quickly lose its purpose.

Make the decision rule readable

This illustrative lighthouserc.cjs assumes the static export has already been built. Its stricter values are proposals. A production implementation should pin Lighthouse CI, Chrome, and dependencies.

module.exports = {
  ci: {
    collect: {
      staticDistDir: './out',
      url: [
        'http://localhost/th',
        'http://localhost/en',
      ],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'categories:performance': ['error', {
          minScore: 0.85,
          aggregationMethod: 'median',
        }],
        'largest-contentful-paint': ['error', {
          maxNumericValue: 3500,
          aggregationMethod: 'median',
        }],
        'total-blocking-time': ['error', {
          maxNumericValue: 300,
          aggregationMethod: 'median',
        }],
        'cumulative-layout-shift': ['error', {
          maxNumericValue: 0.1,
          aggregationMethod: 'median',
        }],
        'categories:accessibility': ['error', {
          minScore: 0.80,
          aggregationMethod: 'median',
        }],
      },
    },
    upload: {
      target: 'filesystem',
      outputDir: './lighthouse-results',
    },
  },
};

Here, error makes a threshold failure return a non-zero exit code. Explicit median aggregation uses the middle value for each metric across three runs. The last run in a manifest should not be presented as the aggregate decision. Lighthouse CI configuration

The JavaScript budget in the table is not enforced by this snippet. It needs a separate check using the agreed size definition. The Accessibility floor of 0.80 is carried over from the existing workflow; it is not certification of accessibility or proof that every task works with a keyboard and screen reader.

Pinning versions helps distinguish a page change from a tool change. When upgrading the tools, compare the old and new baseline before changing thresholds. Avoid upgrading the measurement system and weakening its criteria together, because the cause of any difference becomes harder to identify.

Work through a candidate that fails

Suppose a service page replaces its main image and adds an external widget. Every figure in this example is invented to explain the decision. None is an Enersys result.

The candidate fails the illustrative Performance and LCP criteria even though its best score is 0.87. Showing only that run would leave the approver with incomplete evidence. TBT remains within budget, so this table alone does not justify declaring JavaScript the main cause.

The next step is to inspect the LCP report and network waterfall. Did the LCP element change? How large is the image? When did the browser request it? When did the widget compete for resources? Form a hypothesis, change one factor, such as sizing the image for its displayed dimensions, then measure again under the same conditions.

For the developer, match the LCP element to its resource URL. Separate waiting for HTML, waiting to request the resource, loading it, and waiting to render it. A late request calls for checking whether the initial page exposes the image to the browser. A large file calls for sizing and compression work. A loaded but hidden element calls for inspecting JavaScript work or reveal conditions. Change the part the trace identifies, rerun, and attach the diff and new candidate reports. Breaking down LCP

If the fix brings the candidate within budget, attach the new reports to the new candidate. A result from the previous files cannot certify later changes, even if the change is one line.

Separate a failed threshold from an invalid test

A test machine competing for CPU with another build can produce unstable results. Chrome failing to start, or the page returning 404, can make the audit unusable. This design holds the release in both cases, but assigns different work.

For a reproducible threshold failure, the change owner investigates the regression. For an infrastructure failure, the test-system owner restores the environment and reruns the same candidate.

Agree on retry policy before a failure occurs. An example is one full retry when there is evidence of an infrastructure problem, preserving the first reports and the reason. If measurements remain unstable, pause the decision and repair the measurement system. Repeatedly running until one result is green removes the point of a threshold.

Report collection should still execute after an assertion failure, while the final status retains the failure. Successfully uploading an artifact does not mean the audit passed. A skipped check or absent report should not count as a pass either.

Connect the evidence to the release permission

Our proposal is to carry evidence with the build from candidate creation through production.

1. Identify the source commit, lockfile, and tool versions, then build the release candidate.
2. Audit that candidate’s output. For a container release, test files extracted from the same image or run that image in the test environment.
3. Save every URL’s reports with the commit and artifact or image digest.
4. Allow production approval only after all required results are present and passing, then release the same artifact by its tested digest.
5. Check the live pages and connect field observations back to the release.

If audit and deployment jobs share a GitHub Actions workflow, needs can express a dependency. The design also needs artifact handoff and candidate identity checks. A job called Lighthouse does not create that relationship on its own. GitHub Actions job dependencies

When another system performs deployment, including the current manual path, that system must verify a passing result for the same digest before approval. Otherwise, the pull request result remains information that the deployment can bypass.

An emergency exception should record its approver, reason, accepted risk, expiry, and follow-up work. The release record must retain the exception as an exception, so it cannot later be described as an ordinary gate pass.

Keep watching after production receives visitors

Testing local output covers what the team ships. It does not cover DNS, CDN behavior, caches, third-party services, and visitors’ devices. The proposed process adds a production URL check after deployment to catch environmental differences.

Scheduled checks between releases also matter: a third party can change behavior without a commit in our repository. Keep the URLs, test profile, schedule, and alert owner consistent enough to compare. Distinguish an unavailable page from a possible performance regression before routing the alert.

For field data, track p75 by page type and device when sample size permits. Put the observation window and release dates on the same chart. A dataset containing several releases cannot immediately establish the effect of the latest one.

With CrUX, check whether the result represents a URL or an origin and whether enough data is available. CrUX has user and popularity eligibility requirements. Missing data is not evidence that a website is fast or slow. CrUX methodology

If collecting measurements directly, keep the metrics and context that help diagnose performance, such as page group and release identifier, with data handling appropriate to the service. Attaching the text someone entered into a form does not improve a speed measurement.

Put evidence in front of the promise

A release approver should be able to open the record and identify the tested pages, candidate, criteria version, failures, exceptions, and rollback artifact. Content owners should see which budget a new image or embed consumes. Operations owners should know where each alert goes.

Speed helps visitors reach information and continue their task. A faster measurement does not establish a particular revenue increase; that outcome needs its own measurement. Google also states that good Core Web Vitals results do not guarantee top search rankings. Google Search guidance on page experience

For a team starting today, choose one important page and collect a repeatable baseline. Then deliberately create a failing candidate in a test environment. If the normal production path can still release it, the first task is to connect that evidence to the permission to deploy.

For the next 30 days, we propose a named engineering owner for the baseline and weekly regression review, an operations owner for scheduled-check failures and production incidents, and a release approver who records exceptions. The content owner reviews new images and embeds against the budget. At day 30, these owners should review failed checks, retry reasons, response times, exception expiry, and field-data coverage, then decide whether to tighten the budget or fix measurement gaps. This is a proposed ownership plan, not a claim that these duties have already been assigned at Enersys.