I get the feeling this is an AI hallucination. It uses the canvas to render the text to be measured, which doesn't bypass the browser layouting. The only potential performance to be gained here is rendering straight to a canvas instead of building a dom node, but it's not clear that it's actually faster. I can't imagine the cost of a single <p> is that large, and I'm not certain that it's slower than whatever steps the canvas API uses to turn text into pixels.
What you're missing is that each segment (typically a word) only needs to be measured once, in the setup phase. The canvas gets thrown away after that, and subsequent layout passes all reuse the cached measurements.
If you only perform layout once, it doesn't save any work. If you need to reflow many times, it saves a lot.
I'm sure the browser does do that, and plenty of other optimisations too!
This thing isn't trying to do standard text layout faster than the browser, it's trying to enable more exotic/dynamic/custom layouts while keeping reasonable performance. Take a look at the demos linked in the repo's readme; those are things which the browser's layout engine can't do on its own.
