Some web pages can't keep up with a moderately fast typist, even though it's all rendered locally.
It seems obvious that how quickly a web page can refresh is entirely down to the skill of the developers who created it. There's nothing inherently slow about a web page - plenty of pages update quickly enough. Browsers are fast. Some userspace code is not. If you're using a page that doesn't work fast enough that's down to the developer, not the web itself.
Of course back then you could also use emacs on a printing terminal, which surely won’t work any more.
Printing terminal mode with similar in that it showed only the line you were on, and, IIRC, optionally the line above or below. This worked pretty well in Emacs where search is extremely lightweight and is (for most people at least) the primary cursor movement tool. Of course deletion couldn't display properly so you would get a marker on the screen (#?) to indicate, and then ^L would draw the then current copy of the line.
You could write this support today, and perhaps someone has, but I wonder if it could possibly be worth it.
This same reason is why the unix terminal driver by default starts up with # as the delete character command and @ deleted the whole line. That line discipline dates back to Multics, which had more efficient I/O as the Multics hardware had channel controllers (all our I/O is done with channel controllers these days, though we don't call them that).
Actually, speaking of channel controllers: Emacs had a third mode: if you used the SUPDUP protocol (stood for super duper: roc 739, 746, 749) a bunch of the IO and screen update was done by your local host, not the remote machine on which you were running Emacs (or whatever). It implemented an abstract display and could even interpret a few commands to display the local buffer properly like a souped-up channel controller! This all predated Unix on the arpanet so later approaches went in a different direction.
But remember this was back when you could have dozens of people using networked computers with clock speeds in the hundreds of kilohertz or less, back before the cross continent backbone was upgraded to ~56 Kbps.
I'm editing a file on an embedded system in a PuTTY serial window (115.2 kbps). I'm in a remote desktop connection over a VPN to get to that PuTTY window. (1920x1200 resolution). Everything is responsive; no complaints.
(I'm using BusyBox vi. OMG, it has poor optimization of refresh. I just switched to 9600 bps for fun and opened a small file in the editor. So most of the lines are filled with the tilde character, characteristic of Vi. When I type Ctrl-R to refresh the screen, BusyBox is repainting those ~ lines in their entirety. It's printing all the spaces! It has no knowledge of the "clear to end of line" or "clear from here to bottom of screen" escape sequences. It also scrolls the buffer by repainting, even single line scrolls when you move the cursor down from the bottom line or up from the top line. At 115200 bps, you don't notice any of this.)