Early Hints feedback

Also noticed a huge number of allowed traffic for UA nginx-ssl early hints showing in the firewall logs - not reaching the server though so I suppose it’s internal traffic only. Still looks strange seeing those.

1 Like

Looks like the 504 are CF logs/analytics glitch.

Regarding the broken header I think is some sort of issue between SGX andh HTTP Header Link set at the origin via NGINX.

Today I received a lot of errors in Search Console for SGX and what happen is the same as above for all. The response only show a broken link header.

Things are even weirder… I’ve decided to turn Early Hints on again to see if Cloudflare has changed anything after all this feedback.

Not only the 504 errors appear again but now my firewall shows some traffic to cloudflarestorage:

I can’t imagine what’s going on with this specific project/product. The team has not contacted myself or this community after our feedback and it looks like just not interested in engaging. Disappointing for some feature that promise so much.

1 Like

Strange CF R2 related ??

I haven’t found Early Hints 103 much benefit for already static cached assets. Seems it more beneficial for non-cached assets.

This is with Early Hints Disabled and just normal preload for Wordpress post feature image etc which are all cached at CF CDN level.

Nope, I don’t use R2.

We can Check the header in “Curl”

curl "https://example.com/" -LIXGET


HTTP/2 103
link: <https://example.com

HTTP/2 200

It is easy to check the 103 working.


However, We will be find out issue.
Sometimes 103 has not been sent.


That issue is irregular, i guess…

When Google Page Speed Insights and GTMetrix is working time,
Perhaps 103 have not been sent.

It is my speculation, 103 is not working well.

1 Like

There are also other problems.

The way to add Chrome’s access token is not provided by Cloudflare.
In short we can not participate in “USING ORIGIN TRIAL”.

“Chrome-103 Early Hints”

Even if you request a token as in this guide and insert “Origin-Trial: ** Your TOKEN **” into the header, the token is not cached in 103 requests, so you can not test it to the wide area user.

Or is this too irregular bugs?

It may not be necessary to confirm, but this feature is a beta version and hardly is not provided in a browser.
What I would like to say to those who opened the thread with interest is that “I cannot recommend this now yet”.

The problem may be more serious than imagined.
But I am looking forward to your feedback. :smiley:

1 Like

Correct. I would expect Cloudflare would put in a configuration field in the UI so we could add the token but then it would enable Early Hints to all browsers and the rule from the Chromium project is to only do it for a subset of clients. The way to test it is for some of your visitors to use a shortcut to Chrome with a start parameter to enable Early Hints on the client.


Hmmm. Not seeing this when I retrieve a page using curl.

1 Like

I do not understand what is not displayed, but …
As possible reasons, CURL version problems or command syntax are incorrect.

New version curl download

You can try command

curl 'https://example.com/' -LIXGET
curl "https://example.com/" -LIXGET
curl https://example.com/ -LIXGET

As a known issue, “103” may not be transmitted.

If not resolved, what is the output on the screen?

I think it’s probably a bug on Cloudflare’s side that only 200 is output instead of 103.
Sometimes 103 is output.


It is an anomalous way, but using the “HTTP3 check” site, it was possible to confirm whether there is a 103 Early Hints header.

HTTP3 Check

This behavior is a bug, so I think it is not possible to use forever, but share.

Also, as mentioned earlier, Sometimes “103” work and sometimes it does not work.
The regularity is unknown.



What is this…

A BIG warning to anyone enabling Early Hints - do NOT do so with preload links on a production webpage! We figured out after a week of mysteriousness that Early Hints was causing the following problems:

  • Google Search Console reported “no content” while crawling pages
  • Twitter and Reddit link previews (through opengraph meta tags) failed to show up
  • Google Ads failed approvals due to inaccessible site

Finally figured out when the w3c HTML validator failed saying the site was returning status 103

Until these issues are resolved I don’t think anyone should be enabling this feature. I would suggest adding some sort of warning about how this can really mess things up


I agree to your opinion.
Some crawlers and BOTs have error by 103.

I write for the person who saw, but this problem is not due to Cloudflare.
But, Cloud Flare should warn.

Some crawlers and BOTs handle queries after GET Requests. Perhaps, At that moment, they do not judge 200 OK or 103.
A 103 is misidentified as a final request and an error has occurred.

It is considered that it is the “current normal implementation”.

Many clients need to be renovated, which is considered to take lots of time.
Perhaps a few months are needed.

There are many people who have Early Hints without thinking anything.
Cloud Flare should warn.

The fact that it is a beta version is not an excuse to allow fatal bugs, and this is below the alpha version level.

Also, and this is unrelated, but CloudFlare please give me a t-shirt. :rofl:

1 Like

Can confirm, this broke Google crawl on my site. Both the rich snippets tool and Google search console were unable to retrieve content, and the crawl response time went from milliseconds up to many seconds. Definitely a major issue.


Cloudflare advises me the Google crawl issue has been raised with Google


That’s right.

I think it is a problem of receiving 103 as mentioned earlier.

Fastly’s 103 test sites do not work with Googe PageSpeed Insights and GTMetrix.

Early Hints Client Tests - Fastly

However, something strange is indexed.
Is that site branched output with a user agent…?

1 Like

Hi everyone - thanks for all the testing and feedback here! I’ve escalated the crawler/indexing issue to Google.


Thanks for escalating with Google. But what about other crawlers/indexers? Are you working with the other major search engines and crawlers to make sure they work well with 103 responses?

To update here, having a lot of calls with companies that run large crawlers and other intermediaries. In short, many of these services rely on the (incorrect) assumption that 1 request = 1 response. As a temporary fix, we’re working on releasing a gate that will not send 103s to these crawler’s (etc) UA so that indexing doesn’t break while we wait for these companies to make some changes on their side. I’ll update here when this goes out. Thanks again everyone for all the testing here! Really appreciate the effort and helps us know where we need to fix on our side or talk with others to make sure everyone can see the benefits of EH :slight_smile: