Gate 4 — Performance & Security: A Slow or Unsafe UI Is a Broken UI The fourth gate covers the two qualities most often treated as someone else's problem, later : performance and security. Both share a pattern — they are invisible until they are serious, they are found in production instead of in review, and when they show up, nobody in particular owns them. This gate pulls both forward in time and pins them to an owner: the platform, at release, enforced by a number. The key idea behind the gate: a slow UI and an unsafe UI are broken UIs — as serious as a functional bug, not a lesser thing to fix if there is time. A component that renders the correct output but stutters for three seconds, or ships a serious security hole, has failed the user just as much as one that renders the wrong thing. Why these two belong together Performance and security look unrelated, but they fail the same way as team problems: Both are easy to put off. "We'll optimize later." "We'll do a security pass before launch." Neither blocks the demo, so both slide. Both are found late and cost a lot. A performance problem shows up as a user complaint weeks after the change that caused it. A security hole shows up in an audit — or an incident. Both have no natural owner without a gate. Performance is everyone's and no one's. The risky dependency was added by someone who has since moved teams. The gate fixes all three the same way: make each one a release blocker with a number attached , checked automatically, owned at the platform boundary. The performance half Performance becomes enforceable when it stops being a feeling and becomes a budget: Bundle-size budgets at the package and component level. (The bundle is the JavaScript users download; its size affects load time.) Going over a limit does not quietly get absorbed into an ever-growing bundle — it triggers a decision or blocks. The trend is tracked, so slow growth is visible. Tree-shaking checks — proof that importing one component does not drag in the whole library. (Tree-shaking is the build step that drops unused code.) Render profiling for data-heavy components — a per-frame budget (around 16ms) under real load, so a grid that is smooth with 10 rows and unusable with 500 is caught before a user finds it. Field and lab metrics — Core Web Vitals (Google's real-user speed measures) and Lighthouse scores as gates on major releases, blocking a release whose score drops too far. The heavy-dependency sidecar pattern supports all of this: large optional dependencies (charts, rich text, ML) live in separate, lazy-loaded packages, so the core stays small no matter what any one team adds. The security half Security becomes enforceable when it is owned at the platform boundary instead of handed off to teams who assume the platform took care of it: Dependency vulnerability scanning — zero High or Critical issues on the shipping branch; builds fail automatically on a violation. The real attack surface of a UI platform is its dependency tree, and this is what guards it. Lockfile integrity — an unexpected change to the lockfile (the file that pins exact dependency versions) blocks the pipeline, closing a supply-chain hole. Injection discipline — dangerous HTML injection is banned in core components; the rare fair case (showing external HTML) is isolated into a reviewed sidecar with a trusted cleaning library. CSP compatibility — no , no inline scripts, so the platform runs cleanly under a strict Content Security Policy (a browser rule set that blocks unsafe scripts). Budgets are what make it fair The thread tying both halves together is the same as the rest of the framework: a number removes the argument. "Is this bundle too big?" and "is this security issue serious enough to block?" are opinion-based questions that, under a deadline, always drift toward "ship it." A budget and a severity limit make them objective. The build decides, the same way every time, and there is no meeting about whether 47KB is fine when the budget says 45. That fairness is also what gives performance and security an owner . A gate that fires names the boundary that owns the fix — the platform team for a framework-level problem, the contributor for a component that blew its budget. Without the gate, both qualities are everyone's job, which is another way of saying nobody's. Where this goes next The depth is in Part V — Chapter 11 (Performance Budgets as Release Blockers) and Chapter 12 (the Security & Supply-Chain Shield), including the license-governance extension that vulnerability scanning alone misses. Gate 4 in one line: A slow or unsafe UI is a broken UI — make performance a budget and security a boundary, both enforced by a number, so neither can be put off into a production incident.