How do you architect an automated performance and accessibility testing pipeline?

WHAT THIS TESTS: This question evaluates whether you can translate performance and accessibility standards into an operational software delivery practice. Interviewers want to see that you understand the difference between collecting metrics and enforcing them, and that you have a concrete strategy for closing the loop with the engineers who actually own the code. They are looking for experience with lab versus field data, and for evidence that you have thought about organizational adoption rather than just technical setup.

A GOOD ANSWER COVERS: A good answer hits five things in order: first, the tooling stack, which means Lighthouse CI running in CI/CD against preview URLs or staging environments on every pull request; second, the assertion layer, where you configure budget assertions for Core Web Vitals such as LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds, plus WCAG rules via axe-core or Lighthouse accessibility audits; third, the data layer, storing historical results in a server like the Lighthouse CI server or exporting to BigQuery so you can visualize trends and distinguish noise from regressions; fourth, the human workflow, integrating results into existing developer channels such as GitHub status checks that block merge on failure, bot comments that surface the exact metric delta and offending resource, and Slack alerts routed to the on-call frontend engineer or a dedicated performance rotation; fifth, the remediation contract, defining SLAs for P0 regressions that block release versus P1 trends that go into the next sprint, and assigning component owners using CODEOWNERS or repo topology so every alert has a named owner and a resolution deadline.

COMMON WRONG ANSWERS: Common wrong answers include suggesting PageSpeed Insights as a CI gate instead of Lighthouse CI; producing reports without assertions so the build never fails; storing scores in a dashboard that no one reviews; treating field data from Chrome UX Report as sufficient for CI, when lab data in CI is what catches regressions before they ship; and ignoring accessibility by focusing only on performance because it is easier to quantify.

LIKELY FOLLOW-UPS: Likely follow-ups include how do you handle flakiness in lab metrics caused by variable CI hardware; when should you trust field data over lab data; how would you performance-test a single page application with client-side routing; what do you do when a third-party script blows your CLS budget; and how do you prevent alert fatigue when every PR triggers a warning.

ONE CONCRETE EXAMPLE: At a previous company we added Lighthouse CI to GitHub Actions using the official Lighthouse CI CLI. We configured lighthouserc.json to assert LCP under 2500 milliseconds, CLS under 0.1, and accessibility score above 90. The CI job uploaded results to our self-hosted Lighthouse CI server, which gave us diff views across commits. We wired GitHub status checks to block merge on assertion failure and sent Slack notifications to the frontend platform on-call. When a developer introduced a heavy hero image that regressed LCP by 800 milliseconds, the PR was blocked within minutes and the bot comment pointed directly to the image URL and suggested preloading and compression. The developer fixed it that day rather than shipping and discovering the issue in production field data weeks later.

Source: web.dev