These machines had extremely low overhead for everything you did. If the framebuffer is just a piece of memory, and the screen is monochromatic, then a 512x342

These machines had extremely low overhead for everything you did. If the framebuffer is just a piece of memory, and the screen is monochromatic, then a 512x342 display consists of 175104 one-bit pixels, which is just about 21KiB of memory (which is probably even distinct from main memory). A single pixel update could presumably be done with a single instruction. If we assume maybe 4x looping overhead, then updating the entire screen by individually poking each pixel could be done in about 700k instructions. In practice, there will likely be special hardware and instructions for copying entire blocks of pixels onto the screen in a much faster way ("bit blitting", although I don't know exactly how the Mac did it). Modern machines have huge overheads because of the indirection, virtualisation, and protection mechanisms we desire. On a webpage, you obviously don't have direct access to the framebuffer, but are drawing into some in-memory canvas. Drawing a single pixel in Javascript is going to go through many function calls, with probably orders of magnitude more instructions than you would have on an old Mac. There are still ways of getting (near) direct graphics access that is screaming fast, since people do write games and play videos and such, but there is much more ceremony to it now.