Now that this is available to some it’s time to give feedback. The welcome email doesn’t provide a way to give feedback it so I will post it here.
Using webpagetest with the proper command-line argument I can see the requests to some resources are initiated by the client when parsing the HTML instead of preloading from an early hint.
Our pages have preload statements at the start of head as well as the new Link response header. The tracing shows that all resources are being preloaded by the HTML statements instead of being initiated by the client preloader.
This is easy to see by looking at the waterfall - it shows the preload happens after onload instead of after the connection. I was expecting to see early hints loaded at the blue line below but it is happening at the red line:
Shouldn’t there be a 103 response first? And then your browser preloads those assets? And when it comes time for page load, won’t those assets come from browser cache?
There should be a 103 response but it doesn’t look like it will appear in the Dev Tools (although you can look at Initiator to see if a resource request was initiated from HTML or Early Hint).
As it is, I am not seeing this happening - at least not yet.
Most resources should come from the browser cache, even if the browser initiate it from a 103. In these cases the 103 will ensure the resource is in memory instead of disk cache.
Exactly my point. The boxed section started at the red dotted line during onload (after receiving the full HTML from the server) when in fact it should’ve started at the blue dotted line just after the connection was established (when the 103 response should’ve been received).
Also the screenshot for one of the resources shows the loading started when the client parsed the HTML (line 8 is where the resource is declared for the first time).
Those two things make me think the early hint was not received by the client despite the switch being passed:
Pluck IP 3.219.212.117 into filtering my CF Firewall and it seems it’s caught and logged in my simulate/log (don’t block/challenge) only firewall rule I setup
The errors would not be caused by malformed client requests. I believe these errors are the Early Hints module not correctly caching/responding the headers. This means the headers are never sent out, hence no difference in behaviour on the client side as reported in the first post in this thread.
The volume of 504 errors wouldn’t be influenced by client requests (as I previously wondered) because it’s an opt-in feature. For this volume of errors it would have to be a mainstream feature since very few people are using the command line args to launch the browser (in my case).
Question: what is the “nginx-ssl early hints” user agent mentioned before? It hits the domain as soon as Early Hints is enabled and stopped when disabled:
First seeing that for GSC inspection! FYI, Early hints 103 also breaks Google PageSpeed Insights and GTMetrix with non-HTML content type errors so could be similar to what GSC picked up?
That’s normal for SXG cached version AFAIK. Edit: actually re-checking might not be? Are you setting link headers via origin end or via something like CF Workers ? I am using CF Workers and not seeing it in SXG cached version.
