How do you architect an automated performance and accessibility testing pipeline?
This tests operationalizing quality gates via automation, not manual checks. A strong answer covers Lighthouse CI in CI/CD, fail thresholds for CWV and WCAG, and a triage workflow assigning regressions to owners.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
What is the most critical factor that distinguishes an effective automated performance and accessibility pipeline from one that merely generates reports?
- a.It audits production URLs with PageSpeed Insights instead of preview environments.
- b.It relies on Chrome UX Report field data to validate every pull request.
- c.It stores historical Lighthouse scores in BigQuery to visualize long-term trends.
- d.It enforces assertion budgets that block merges and routes regressions to named owners.Correct
Why? this is the answer
The card emphasizes that operationalizing quality gates requires enforcing thresholds that block merges and assigning regressions to specific owners, not just collecting metrics. Option C describes a useful but insufficient data layer, since trends without enforcement are commonly ignored.
Just read this? Test yourself on what you have been reading.
Read the original → web.dev
- #performance
- #accessibility
- #ci-cd
- #lighthouse
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on performance — each one lists the topics its interview covers.
See open roles