My understanding is that QUIC will not help much if your page is self contained (no references to outside resources). Because this page is the only resource and QUIC is all about parallelizing multiple resources. In regards to congestion control QUIC is very similar to TCP [1].
Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that.
QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat
Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that.
QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat
[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recove...