# Cut the site's browser‑driven quality gate from 1,636 seconds to 615 by scheduling its checks longest‑first through a worker pool bounded to four lanes, after measuring that alphabetical order cost 320 seconds against 224. 2025 **Situation.** Eleven of the site's checks drive a headless browser: layout at every window shape the design draws, type scale, translated‑text expansion, contrast, accessibility rules, forced colours, mascot sizing, motion, print across six paper combinations, console errors and visual regression. Run one at a time they took 1,636 seconds, a little over twenty‑seven minutes. A gate that takes twenty‑seven minutes is a gate that gets skipped, and a skipped check is indistinguishable from a passing one. **Task.** The wall clock had to come down far enough that running them was the default rather than a decision, without weakening any of them. **Action.** The work was measurement first. Each check was timed individually on a twelve‑core machine: layout at 405 seconds, type at 301, translation at 282, contrast at 189, accessibility at 178, and so on down to seventeen. Two findings shaped the answer. Running all of them at once was slower than running four at a time — 265 seconds against 224 — because each check is itself a browser doing parallel work, and oversubscribing the machine costs more than the concurrency wins. And ordering by longest processing time first beat alphabetical order by nearly a third, 224 seconds against 320, which is the classic scheduling result and shows up here because the checks vary by a factor of twenty in cost. So the runner is a bounded worker pool, sized from the core count with a floor of two and a ceiling of four, fed longest‑first. Alongside it the checks were widened rather than narrowed: they now share one viewport table of twenty‑two window shapes, derived from every media query the stylesheet actually contains, which took the layout check alone from 95 seconds to 405. **Result.** The gate went from 1,636 seconds to 615, while the checks got broader rather than thinner — the serial cost went up and the wall clock came down. The measurement is the part worth keeping: two reasonable‑sounding choices, running everything at once and running things in the order they were written, were each measurably worse than the alternative. --- - Role: Build and Release Engineer - Categories: [Frontend Engineering](https://engineer.company/categories/frontend/), [DevOps](https://engineer.company/categories/devops/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Performance Tuning](https://engineer.company/categories/performance/), [Testing & QA](https://engineer.company/categories/testing/), [Python](https://engineer.company/categories/python/) - Services: [Frontend Development](https://engineer.company/services/frontend-development/), [DevOps & CI/CD Automation](https://engineer.company/services/devops-cicd/), [Technical Leadership & Consulting](https://engineer.company/services/technical-leadership/)