With client authentication the client sends the certificate after the client and server hello.
Is it possible to send it already with the client hello, so the server does not even answer with a hello but instead rejects the connection?
TL;DR: This is not possible with a standard conforming implementation.
The TLS 1.2 and TLS 1.3 standards clearly describe the sequence of communication inside the TLS handshake. A client certificate can not be send inside the ClientHello since the structure of the ClientHello record does not have a place for it. It is instead sent within a Certificate record, similar to how server certificates are sent. Only a Certificate record from the client is supposed to be sent only after the server explicitly requested it with a CertificateRequest. (see TLS 1.3 spec, sections CertificateRequest, and Certificate for the definition of this behavior)
Note that in order to prove that the client actually owns the certificate it needs to sign some challenge - and this signature (CertificateVerify) can be then checked by the server (see CertificateVerify). The challenge should not be set by the client itself since this would allow replay attacks. Therefore the challenge must at least in part be defined by the server - similar on how the same kind of challenge for the server certificate is partially defined by the client. To have this kind of input the client must have data from the server first, i.e. the CertificateVerify can not be send w/o an initial data exchange.
Even if the protocol allowed you to send a Certificate message along with your ClientHello, it would not save you round-trips on a successful handshake. This does not mean that the protocol could be designed in a way that the certificate is sent immediately but verified only later. This way the server could early reject a certificate which would be not acceptable no matter if the (later) validation failed or not. Only, the protocol is not designed this way. On reason might be that the server wants to notify the client which CA are acceptable so that the client can select the appropriate certificate. Other reason might be that using a valid but still wrong certificate is unlikely, so an optimization for this case is not actually needed.