The trouble is that, particularly on 68k, the the bottleneck on HTTPS is the CPU, opposed to network speed for plain HTTP. Of course, even network speed is not so much of a problem these days either, compared to when these features were first introduced into IBrowse
. In reality, on 68k, there is not going to be a big difference in total page loading speed with 1 secure connection or 16, because the CPU will be saturated in either case, because the SSL algorithms are more complex and slower now then they were in the past. In fact, with multiple connections battling for CPU time, it may end up being slower because SSL renegotiations are triggered, ultimately leading to timeouts.
For IBrowse 2.5.3, I'm currently working on adding SSL session caching, which allows handshaking to be bypassed after the first connection, which I hope will help speed up things on 68k, especially for TLSv1.3 which has an even better caching method than previous versions.
No GIF datatype from me - since one came supplied with OS3.5 (or was it 3.9?) or later, I never saw the point, as there is not much room for optimisation. Thanks for trying the WarpDTs.