There needs to be delay, because initially the read buffer on the socket will be empty, and when we have data, it may not be what we expect, however when we match something that we do expect, at that point we can match it and the load-balancing decision can be made, waiting for the rest of the delay is not needed.
I’ll explain based on the example in the blog post:
tcp-request inspect-delay 5s
tcp-request content accept if HTTP
use_backend ssh if { payload(0,7) -m bin 5353482d322e30 }
use_backend main-ssl if { req.ssl_hello_type 1 }
default_backend openvpn
Here we expect http, ssh or ssl, and we will default to openvpn if its none of the 3 expected protocol after 5 seconds. So that means, HTTP, SSH and SSL will be matched immediately, because we know what we are looking for. We cannot match openvpn though, so it is the default and an openvpn connection will have a 5 second delay here.
So, for your use-case, this means that TLS is fine; since it can be matched immediately no delay will occur. Whether your FIX protocol will see this delay depends on whether you are able to match it or if you have to use the fallback openvpn uses in the example above, with default_backend.
You may be able to get working results with just 2 or 3 seconds delay.