Ziproxy is optimized and expected to be fast. In many (perhaps most) cases, there won't be the need extra care for performance and Ziproxy will work just fine.
In certain scenarios, with many users and/or high user bandwidth, certain aspects of the hardware and other configurations may require extra attention.
If you have a scenario here Ziproxy is under heavy load, consider the following options:
Run Ziproxy with a machine with at least 1 MB of L2 CPU cache per core, 2 MB (or more) the better. Many MHz won't save a CPU with 256kB L2 cache and performance will suffer, badly. As an example, a Sun Ultra 30 (UltraSPARC II, 300MHz, 2MB L2) runs Ziproxy much faster than a x86 Athlon XP 2600 (2.13GHz, 256kB L2).
Use SIMD-optimized (x86's SSE/SSE2 etc) libjpeg and libjasper libraries, it really makes a difference.
Run Ziproxy in daemon mode. Running under (x)inetd is (naturally) much slower and only viable for personal use (and even so, it's a bad idea).
If you have considerable latency in your main (fast) data link to the Internet, you may want to disable HTMLopt and PreemptDNS so the HTML pages will be streamed directly to the user while being loaded by Ziproxy (Gzip may be applied during streams, no problem). This way you will lower the latency experienced by the user since you cannot start loading the pictures in parallel before the HTML page arrives.
If you have a lot of users sharing the same compressed data link, it might be a good idea to use a caching proxy at their side. This way the bandwidth issue will be addressed by both compression and caching, and that's a good thing. That's quite obvious, but worth remembering anyway.
Seriously consider installing a good DNS caching system serving Ziproxy if it has a very high number of users. Ziproxy does not have an internal DNS caching system, it tries to resolve the hostname of each request received.
