The order of operations when it comes to speed optimization:

1. Actually notice that there might be a performance issue.
2. Profile to find where the issue is focused.
3. Research the options with respect to algorithms that might improve upon the performance of the hotspots discovered in profiling.
4. Benchmark the various algorithmic options.
5. Implement the better algorithm.
6. Test the implementation to ensure you haven't regressed in some way.
7. If there's still an issue, repeat step 2.

If there's no better algorithm, then it's time to trim cycles (paraphrasing Tom Duff).

You mentioned CGI, and you are correct that many have discovered (probably through profiling) that the startup cost of CGI is high, particularly for short-running scripts (which CGI usually entails). This is one area where the profiling's been done again and again, there is a better algorithm, and the better algorithm is known. The better algorithm for that scenario is to eliminate the repeated start-ups. This can be done with something like mod-perl, or more modernly, through a persistent application framework that sits on top of a back-end like mod-perl, FastCGI, or some other persistent daemon. The modern frameworks such as Dancer, Catalyst, and Mojolicious attempt to do this (and much more).

To summarize, if you have determined that startup time is your foe, the effectiveness of the micro-optimization of trimming cycles from startup pales in comparison to the algorithmic optimization of moving the startup cost out of the individual request cycle by creating a persistent process.