I'm so ignorant about modern graphics programming that I don't know what backing layers are or why they should be tiled. Googling doesn't help. Maybe they're offscreen pixel buffers you draw into? I guess VBOs are vertex buffer objects? How can a web developer create a rasterized document fragment at all, much less one ten thousand pixels high? Do you mean, like, creating a huge offscreen <canvas> and drawing stuff on it? (But in that case how would CSS layout be involved at all?)

I think TeX typically takes in the ballpark of ten million machine instructions per page of text (say, 256-1024 words) to do the layout and produce the .dvi output. To guarantee reproducibility, it doesn't use floating-point. (It also doesn't use multithreading because when it was written in the 01980s multiprocessor computers were an exotic rarity, and threading libraries even rarer.) As a test, I downloaded the source files for https://arxiv.org/abs/1709.08841 and rendered them with valgrind --tool=cachegrind latex final_acc.tex, which took 2,440,969,752 instructions (in 1.1 seconds when run without valgrind), about half of them in startup stuff (loading TikZ, hyperref, amsmath, and so on) and the other half to render the 18 pages themselves, about 12000 words of text.

That's about 70 million instructions per page or a hundred thousand instructions per word, including all the parsing and bibliographic database querying but none of the rasterizing --- TeX thinks of letterforms as just boxes and leaves the pixels to dvipdf or xdvi or whatever. (dvi2fax takes 1.7 seconds to convert the .dvi to G3 fax images.) I think this is an unusually slow document. I have the impression that this is about one to two orders of magnitude faster than doing CSS layout on common web pages, but usually the TeX results look better. But maybe I'm wrong about that?

You say you think TeX is concerned with "fewer dimensions of layout". What kind of dimensions are you thinking about? Like, Z-order? My naive view of the pipeline is that you have some kind of "document" or "form" which specifies the things you want to display and how they relate to each other; then a layout algorithm (normally incremental) processes this document into a set of boxes, each of which has dimensions (x, y, w, h, layernum), like TeX in my example above; and then a rasterizer (like dvi2fax) uses these boxes to paint things like character glyphs and icons onto one or more layers (pixel buffers), at least the visible part of them, that then get alpha-composited together, maybe transformed using things like blurs and rotations and reflections and stuff. Am I suffering from some kind of basic misconception? Because that naive vision makes it really puzzling to think that blurring a background could affect the performance of the layout algorithm.

I mean, rendering the blurred pixels themselves takes time, of course, both because computing the filter takes time and because you're rendering two layer pixels for every output pixel. But it doesn't affect the layout. Does it?

I have the impression that, in my naive pipeline above, it's not the rasterizer or compositor that is the bottleneck in web pages, but the layout algorithm. I mean, I remember when scrolling text over a nonscrolling background image in a browser was slow, but that was a long time ago, and alpha-compositing together a screenful of two layers hardly seems like it should stretch the capabilities of even modern CPUs, much less modern GPUs; but, again, maybe I'm suffering from some basic misconceptions about what is involved. Isn't it the same problem as rendering a translucent HUD in a game UI while the 3-D world keeps getting rendered behind it? You don't have to actually iterate over pixels (or, you know, packed 128-bit vectors of pixels) for any images or letterforms that are outside the viewport, do you?

I definitely do not mean to deprecate the difficulty of implementing CSS, much less implementing it efficiently; as you said elsewhere, if it were easy, we'd be seeing new CSS engines that weren't just forks of KHTML. But I suspect that CSS is hard to implement efficiently in large part because CSS is badly designed, and that a better design could simultaneously admit more efficient implementations and be more expressive. Cassowary might be an actual existing example of this.