Why We Rebuilt Our Rendering Engine
Rebuilding core infrastructure is a high-stakes bet. You're investing significant time in something that users will hopefully never notice — because if you've done it right, everything looks the same but works better. If you've done it wrong, things that worked before break.
We rebuilt our component rendering engine. Here's why we did it and what came out the other side.
What Was Wrong with the Original
The original rendering engine was designed when the platform was younger and smaller. It worked well in that context. But as the platform grew — more component types, more configuration options, more complex layouts — the original design started showing its age.
Performance was the most visible symptom. Pages with complex layouts — multiple panels, relation tables, computed fields, embedded components — were slower than they should be. The rendering engine was doing redundant work: resolving the same definitions multiple times, computing layouts that hadn't changed, making database calls that could have been cached.
The second symptom was harder to see from the outside: development velocity slowed as the rendering code became harder to reason about. Adding a new component type required understanding too much of the existing code. Edge cases were hard to test. Changes in one area had unexpected effects in another.
What We Built Instead
The new engine separates concerns cleanly. Definition resolution happens once, upfront. Layout computation is separated from data loading. Components declare their dependencies explicitly, which makes caching straightforward and makes the order of operations predictable.
The cleaner architecture made it possible to implement better caching — not just for the final rendered output, but for intermediate stages that are expensive to recompute. Definitions that haven't changed since the last request are served from cache. Layouts that are identical between requests are computed once.
The Numbers
Page load time for complex screens: down 40% on average. Screens with heavy relation loading: down 60% in some cases. The 5th-percentile users — the ones with the most complex workspaces — benefited most.
The Risk We Accepted
Rebuilding core rendering meant accepting the risk of regression. We addressed it with an extensive test suite covering rendering output before and after, and a staged rollout that let us catch differences early.
No significant regressions made it to production. The bet paid off.
The new engine is the foundation for the next phase of rendering improvements. Rebuilding now was the right call.