Early Hints feedback

[freitasm]

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:

Anyone else seeing this?

[sdayman]

As I’m still waiting…waiting…

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?

[freitasm]

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.

[freitasm]

@sdayman

And when it comes time for page load, won’t those assets come from browser cache?

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.

[sdayman]

I didn’t see that in your boxed section of dev tools. It looks like it went through the whole DNS/TLS/Wait/Receive process.

[freitasm]

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:

[desmondgrey]

Just got admitted into the beta test and currently using rel=preconnect on my sites.

Testing Early Hints with Web Page Test (–enable-features=EarlyHintsPreloadForNavigation)

Without Flag Test

[freitasm]

I still can’t see any difference in how Early Hints change the way resources are downloaded - either via my own browser or webpagetest.

[rommes]

Since I activated Early Hints, I get massive 504 Gateway Timeouts in the analytics tab:

[desmondgrey]

Same here…

[freitasm]

Same here - from zero to thousands. Will post screenshot later.

[freitasm]

I don’t think this is a Cloudflare problem as my preload links include resources in other domains and they load only after the HTML.

If this was only happening with Cloudflare resources, we would see resources from other sources loading earlier.

Perhaps this indicates something happening on the client side, perhaps a malformed request?

I have opened a support request asking how to provide feedback for this beta, since there was no contact details in the welcome email.

[eva2000]

Yeah got the same 504 for nginx-ssl early hints user agent. Dug into my CF edge server logs via CF Enterprise logpush an have 1000s of entries.

example excerpt for one entry is

time pzcat /home/cfcmm-logs/20211013/*.log.gz /home/cfcmm-logs/20211014/*.log.gz /home/cfcmm-logs/20211015/*.log.gz | jq -r 'select(.BotScore <=100 and .ClientRequestHost == "blog.centminmod.com" and (.ClientRequestUserAgent| index("ssl")) and .ClientRequestPath == "/wp-content/themes/generatepress/assets/js/main.min.js" ) | "\(.ClientIP) \(.RayID)-\(.ParentRayID) \(.ClientRequestURI) \(.ClientRequestMethod) \(.ClientRequestReferer) \(.EdgeResponseStatus)-\(.EdgeResponseContentType) \(.OriginResponseStatus) \(.OriginResponseDurationMs)-\(.OriginResponseTime) \(.EdgeRequestHost) ctf-\(.CacheTieredFill) cs-\(.CacheCacheStatus) crs-\(.CacheResponseStatus)-\(.CacheResponseBytes) \(.EdgeColoCode) \(.ClientCountry) \(.ClientIPClass) \(.WorkerStatus)-\(.WorkerSubrequest)-\(.WorkerSubrequestCount) \(.BotScore) x \(.BotScoreSrc) \(.ClientRequestUserAgent) d-\(.ClientDeviceType) edgeip-\(.EdgeServerIP)"' 

3.219.212.117 69e4f7ea52f0578b-00 /wp-content/themes/generatepress/assets/js/main.min.js?ver=3.0.4 GET  504-text/html 0 0-0 blog.centminmod.com ctf-false cs-miss crs-504-1376 IAD us noRecord unknown-false-0 5 x Machine Learning nginx-ssl early hints d-desktop edgeip-

cs-miss crs-504-1376 IAD means cache status = miss with cache response status = 504 and response was 1376 bytes in size from IAD datacenter

504-text/html 0 means 504 edge response status with text/html content type and origin status code = 0

If I filter CF Firewall log on that log entry’s rayid get 2 firewall log entries for the same rayid! and they have identical timestamps!

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

Though that useragent also gets caught and logged in my CF Firewall allow rules for verified bots

Some Amazon AWS IP trying a PUT request and probably not getting a response back?

also GET requests

Allow CF Firewall rule requests for verified bots with nginx-ssl early hints useragent are logged for Google, Yandex and Apple Engineering ASNs

edit: oh I have Cloudflare Signed Exchanges beta enabled https://blog.centminmod.com/2021/10/13/2511/testing-page-speed-with-cloudflare-automatic-signed-exchanges-google-search-cache/ and also Crawler Hints beta enabled so not sure if that is related? @firat @akrivit

[freitasm]

Some additional insights.

1. As mentioned above, I can also see 504 errors that started happening when Early Hints was enabled on my domain:

2. To demonstrate relation, I have disabled Early Hints earlier today and 504 errors instantly disappeared:

3. 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.

4. 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).

5. 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:

5. We don’t have a direct feedback to the team implementing this feature so it’s harder to get to the root cause here.