Reducing layer overhead in LBSE | Nikolas ZimmermannReducing layer overhead in LBSE<br>Conditional layer creation in the layer based SVG engine<br>July 14, 2026 · 14 min · Nikolas Zimmermann<br>The last time I wrote here about the layer based SVG engine (LBSE) was back in autumn 2021, when I published<br>the technical design document. A lot has happened since then, but maybe<br>not what you would expect after almost four years. The engine landed in WebKit and it works well, but it is still<br>not the default. You have to switch it on by toggling a runtime setting (in MiniBrowser). Between autumn 2021 and<br>late 2022 LBSE was bootstrapped upstream, patch after patch. We added support for all the individual building blocks<br>that make up SVG: paths, shapes, text, polygons, etc. within the new LBSE design. After that first big push the work<br>stalled for a few months and resumed in mid-2023, and lasted until April 2024, due to generous support<br>by Wix. During that period most advanced painting features, such as clipping, masking,<br>filters, non-solid paint servers (patterns, gradients), markers, etc. were all implemented, sharing the logic with HTML<br>and CSS rather than running through the separate code paths, as the legacy SVG engine did. Then the work paused again.<br>A project of this size needs sustained funding to move forward, and for a while that funding was not there.<br>LBSE is promising, but it still has to earn its place, and it is worth being precise about what that means, because<br>the goal was never simply &ldquo;make SVG faster&rdquo;. The legacy SVG engine is an island: historically grown, it has its own<br>painting code, its own handling of transforms, clipping, masking, etc. and it shares only a little of the code that<br>renders HTML and CSS for historical reasons.<br>Many improvements that went into WebKit, went into &ldquo;the other engine&rdquo;, the main part, the HTML/CSS rendering engine.<br>GPU-accelerated transforms and animations, accelerated compositing, all the work that made HTML/CSS fast. SVG sat right<br>next to it and got none of it. That is what LBSE is really about. Put SVG on the same machinery, and it inherits all of<br>that at once, and it keeps inheriting whatever comes next, instead of someone having to build it a second time for SVG<br>alone.<br>The catch is that shared machinery is general machinery, and generality is not free. The legacy engine has been hand tuned<br>for exactly one job, with two decades of tuning behind it. LBSE, on the other hand, has to integrate surgically into the<br>shared HTML/CSS rendering code, without regressing that code even a little. This is the hottest code in the engine and it<br>renders every web page out there, so sprinkling SVG special cases through layout and painting until LBSE looks good is<br>simply not an option. Whatever LBSE needs either fits the existing design, or it has to make the existing design better<br>for HTML and CSS too.<br>There is a second kind of work hiding in there as well. Some things that are rare in HTML are everywhere in SVG.<br>Transformations are the obvious example. A typical web page has a handful of transformed elements, while in SVG almost<br>every single element can carry a transform, and deeply nested transforms are the norm rather than the exception. The<br>shared code was written with HTML in mind, and it does its job perfectly well there. So parts of the shared machinery<br>have to be reworked, and fast paths that nobody ever needed for HTML have to be invented from scratch, without making<br>anything slower for HTML in the process.<br>So the bar is a double one. LBSE first has to be competitive<br>with the legacy engine on the plain, everyday rendering that legacy is already good at, because nobody switches engines<br>if a static icon that never moves suddenly takes longer to paint. The rest, the hardware acceleration and every future<br>improvement to the HTML/CSS engine that SVG now gets for free, only counts as a win once that first bar is met.<br>Fast forward to early 2026: This year the status quo finally changed. Igalia made a one-off<br>investment into a fresh round of LBSE development, to give the engine the chance to prove itself. We are hopeful<br>to finally show the world that LBSE is performant, and to attract new partners who share our vision that a performant,<br>hardware-accelerated SVG engine is the future for UIs on embedded devices. This is the first of two posts covering<br>the first half of 2026, where we stand now and how the LBSE project evolved since the long break in 2024. The last<br>six months were intense, and ended with the single most invasive change to LBSE since it was first written. This post<br>covers that change, and the next one picks up the hard problem it left behind.<br>A quick reminder of where we were#<br>When we designed LBSE, the central idea was simple. Instead of keeping the old, separate SVG painting code, SVG<br>should reuse the very same machinery that HTML and CSS already use, the RenderLayer tree.<br>That is what unlocked hardware-accelerated transform animations, perspective...