I have a question regarding the HTTP/2 Pusher interface and how it handles PUSH_PROMISE and the data transmission.
>From the comments in the interface code: // Handlers that wish to push URL X should call Push before sending any // data that may trigger a request for URL X. This avoids a race where the // client issues requests for X before receiving the PUSH_PROMISE for X. This means that the "optimal" way to use it, according to this comment, is by calling Push() before sending the HTML document. However, I measured TTFB to HTML via Google Lighthouse and checked overall site performance and it seems that Push() not only sends PUSH_PROMISE but also the data when the call happens. My website is loading much slower than if I put the Push() call after the HTML transmission. This fixes TTFB and the site loads quickly again, but it can occasionally lead to data races as described in the comment or in this GitHub gist: https://gist.github.com/blitzprog/266fb40a8f3811cce183e21cd1b94315 Correct me if I'm wrong, but it seems the Pusher interface gives me only 2 options: Variant 1: 1. PUSH_PROMISE 2. Push resource data 3. Write HTML Variant 2: 1. Write HTML 2. PUSH_PROMISE 3. Push resource data The actually optimal variant would be... Variant 3: 1. PUSH_PROMISE 2. Write HTML 3. Push resource data Am I correct in assuming that the optimal Variant 3 is not possible via the HTTP/2 Pusher interface? (I am basing this assumption on the TTFB numbers and slow loads when calling Push beforehand) If that is indeed the case, how can I fix this behavior? If that is not the case, why is the site loading so much slower and showing a much higher TTFB by calling Push() before the HTML transmission? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
