CGI weren't all that slow even 25 years ago if you minded exactly the things you mention. That is: Compiled, statically linked code, that also took advantage o

CGI weren't all that slow even 25 years ago if you minded exactly the things you mention. That is: Compiled, statically linked code, that also took advantage of the fact the process would die (which meant e.g. not freeing memory, or doing any other unnecessary cleanup), and get external APIs out of band where possible unless their latency were low. I built a webmail service like that back then, and we measured vs. FastCGI and other options and it performed well. Wouldn't necessarily do it again, because it was a product of competing against slow interpreted languages on a whole server park slower than my laptop, where you could recover from the process creation overhead just by being faster. Things like the static linking gave us a double digit percentage reduction in latency over the "naive" CGI approach, and cut the advantage of persistent processes right down. Being able to drop almost all memory frees helped a lot too (we'd only free particularly large objects, otherwise just let the OS free everything at once when the process died) Overall we were mostly IO bound despite using CGI even with the significantly worse process creation overhead of Linux back then (it was never "bad" compared to e.g. Windows as far as I remember, but there were significant efforts to improve it)