The lowest bound would be the size of the texture the page is rendered into, no ? If you're on a 4k screen an uncompressed rgba pixmap is already 31MB... And that's really just the raw pixel storage which needs to be associated with your process
(You need additional display-list items for things like the #ff6600 bar at the top and the #f6f6ef background, but those occupy insignificant space even compared to the 2144 characters. The Yahoo/Y-combinator logo and the arrows also add a little bit.)
Of course #notallpages are mostly text, and many of them will require intermediate storage for large photos, <canvas>es, or screenshots of faked Tweets.
If you're on a smaller computer you might render one scan line at a time from a display list consisting of strings rather than individual characters. Those 2144 characters are in 29 lines, so the display list might be under 3K, and a 400-pixel 1-bit-per-pixel scan line is 50 bytes. If you're generating PAL this way you have 64 μs to render each line, which is about 1000–6000 instructions on current microcontrollers, and you can maybe manage 450 color pixels, another 2K or so of raw pixel storage.
... but... the GPU shader will need a surface to render into, no ? do you know of any OS where asking for a 1000x1000 surface does not allocate space for that in normal, non-GPU RAM ? I believe that this uses RAM on any mainstream desktop OS
I'm not sure it's fair to charge that framebuffer to the browser, though. The windowing system needs to use the same 31MB before you start the browser up, after all.
I don't know the answer to your question about mainstream desktop OSes and space allocation for shaders for windows that aren't being displayed. Maybe someone who knows more than you or me can chime in.
every process needs its own surface for compositing though. If you open 200 4k windows you'll get 200*31MB, they aren't going to share the memory with the desktop one