Debuging early hints in Chrome

[tomas.cerkasas]

So I learned how to debug ealy hints in server. Few options:
a) https://code103.hotmann.de/
b) curl -k -v —http2 mydomain.com | grep 103

Cool!

Now I want to debug how that affects my page rendering in Chrome. Here the four challanges I am facing:

a) performance.getEntriesByName('https://mydomain.com/asset.jpg')[0].initiatorType → this is the closest I got to extracting any infro from chrome on early hints. My problem with this is sometimes it returns link, sometimes early-hints. Am wondering if it’s related to wether the resources was loaded from browser cache or to what?

b) In Chrome 107 beta after each pageload of url with early hints I get a warning message: The resource <url> was preloaded using link preload in Early Hints but not used within a few seconds from the window's load event. What does it mean and how to get rid of it?

c) How to get any profiling data? And chrome devtools those assets are shown as stated to load after the initial response been delivered. I want to see the change as shown here: Early Hints update: How Cloudflare, Google, and Shopify are working together to build a faster Internet for everyone (https://blog.cloudflare.com/content/images/2022/06/image3-18.png vs https://blog.cloudflare.com/content/images/2022/06/image5-9.png ) either in visual, or in profiling metrics. I cant reproduce this in any way. Any ideas how to achieve this proof that early hinted assets started loading earlier?

d) Last, not least - I’d like to see lighthouse producing that profiling data, will dig into this and update if I manage to extract anything on early hints from there.

Thanks a lot!

P.S. Similar discussion, leaving as a reference: HTTP 103 Early Hints: How to diagnose if they are correctly set by Cloudflare and respected by Chrome? - #19 .

[M4rt1n]

@tomas.cerkasas

a) https://code103.hotmann.de/

Yeah, that’s my tool, thanks for using it! It does not track anything and is freely available. If you find a bug, please PM me.

Just some thoughts from me:

• if you want to get some debugging of such “niche” functions you really should write to one of the Chromium Mailing-lists. If your request is well written you very likely get some qualified feedback.
• Debugging it is possible if you compare “with EH” against “without EH”, especially if you take a look at the whole HAR (in a HAR viewer). But will be some manual work to do.
  You can even configure WebPageTest to send EarlyHint-Compatible requests and to not send EarlyHint-Compatible requests. Then compare the waterflow-chart of both. But dunno anymore how it was done.

For understanding how efficient EHs are you need to know how they work:
They are ‘link’ headers, which are usable before receiving the actual 200 response code - nothing more. But as they are so super easy to implement, just go with them. So it comes down to: they are the absolute same as ‘link’ headers beside, when your server needs a long to generate the response. Then they have an effect, otherwise not!
So especially at the first request they would be super important to speed up things, but as you probably noted by using my web-tool, Cloudflare does nearly never trigger EHs on the first (cold) request and therefore you will barely ever see any difference compared to normal ‘link’ headers. Sad but true.

In some other edge-cases EHs at Cloudflare might give you some little boost, for example, when you change your content, but the links to the static assets, which you preload stay the same. So your server takes a little longer to generate the request and here is where the EHs make sense, but just as Cloudflare knows them already. If you clear cache the benefit might be gone.

So Early Hints performance wise do not even get close to its predecessor the HTTP/2 Push but it is more like a little polished version of ‘link’ headers.
So it will be hard to analyse them

@tomas.cerkasas

My problem with this is sometimes it returns link, sometimes early-hints. Am wondering if it’s related to wether the resources was loaded from browser cache or to what?

This just tells you what the initiator it, so if it is early hints it for sure was triggered from an early hint, but if it is link it could be from cache, and therefore not from an early hint or there just was no early hint.

@tomas.cerkasas

The resource <url> was preloaded using link preload in Early Hints but not used within a few seconds from the window's load event. What does it mean and how to get rid of it?

That actually just means that you preloaded something you did not use quickly. early hints are there to really just speed up the very most important static assets, not any low priority stuff you need somewhen later. So if you lazyload pictures you should not early hint them. As they might not be used immediately. If you see these notices, please reconsider/recheck if that ressource will be used immediately and if it really shall be early hinted.

Feel free to update this thread if you get some more infos.

[tomas.cerkasas]

@M4rt1n

This just tells you what the initiator it, so if it is early hints it for sure was triggered from an early hint, but if it is link it could be from cache, and therefore not from an early hint or there just was no early hint.

Martin - thanks a lot for creating and sharing the tool! And for replying to this thread as well!

• if you want to get some debugging of such “niche” functions you really should write to one of the Chromium Mailing-lists. If your request is well written you very likely get some qualified feedback.

I was getting desperate, so out of 10 people/companies/e-locations I’ve reached out - one was https://groups.google.com/a/chromium.org/g/chromium-discuss . For some reason my message did not get posted - luckily other sources were very helpful

Debugging it is possible if you compare “with EH” against “without EH”, especially if you take a look at the whole HAR (in a HAR viewer).

This crossed my mind, but never tried. Thanks for direction! Will sure try it at some point. As for debugging, i’ve learned from authors of https://blog.cloudflare.com/early-hints/ and https://blog.cloudflare.com/early-hints-on-cloudflare-pages/ that WebPageTest actually does the job. EH are reflected in the waterfall, also the 103 response body is shown (screen attached, courtesy of GregB!) - having reflection in two places gives enough confidence. At the time of writing, GTMetrix and DebugBear were considering supporting early hints, but not there yet.

when your server needs a long to generate the response

All my responses are 100% cached and hot-loaded, but with workers and html rewriter - for me it’s long enough to use early hints on every request. TTFB is 200ms - is it a long time to generate a response or not?

Cloudflare does nearly never trigger EHs on the first (cold) request

But it’s the same as with cache right? If i’d manage to hot-load my page with a script at each colo, then 100% of my requests for visitors would be served from cache + early-hints. Exluding those cases described Support for status code 103 "Early hints" - #11 by M4rt1n when CF gets response from cache earlier and sends 200 instead of 103. Am I right?

So Early Hints performance wise do not even get close to its predecessor the HTTP/2 Push

Interesting. Never played with it.

This just tells you what the initiator it, so if it is early hints it for sure was triggered from an early hint, but if it is link it could be from cache, and therefore not from an early hint or there just was no early hint.

Thanks a lot for clarifying, makes total sense!

early hints are there to really just speed up the very most important static assets, not any low priority stuff you need somewhen later.

I’m trying to push the limits of performance, so 1ms that might be reduced is too much. Let’s say I do not use lazy loading. And have 30 jpg/svg/ico in my page, and the request uses http/2 (async) - would would not I add all the 30 assets as early hints Let’s say they are all included using simple tag. What’d be the best approach here?

As they might not be used immediately. If you see these notices, please reconsider/recheck if that ressource will be used immediately and if it really shall be early hinted.

That’s my point - my page is empy page with single image which is loaded in screen… Really annoying, will need to do test and trial.

Thanks again for discussion @M4rt1n, I do hope this thread will be useful for those who come accross it!

Kindest regards!

[M4rt1n]

@tomas.cerkasas

Martin - thanks a lot for creating and sharing the tool! And for replying to this thread as well!

You are very welcome!

@tomas.cerkasas

TTFB is 200ms

That depends on what the internal delay “process time” is. The TTFB itself could be related to your connection or so. But generally speaking: TTFB 200ms is definitely in the range where you profit from EHs.

@tomas.cerkasas

But it’s the same as with cache right?

Yes and no. It was, but EHs at Cloudflare changed a little (improved) as I noticed over time. Pretty sure they also wrote about somewhere. I see EHs now way more often than before, with the exception of the first cold start. So some things I mentioned back in time are not accurate anymore due to that change.

@tomas.cerkasas

Interesting. Never played with it.

Is also not possible anymore as deprecated and discontinued, but was really powerful in term of performance (and insecure)!

@tomas.cerkasas

Let’s say I do not use lazy loading. And have 30 jpg/svg/ico in my page, and the request uses http/2 (async) - would would not I add all the 30 assets as early hints Let’s say they are all included using simple tag. What’d be the best approach here?

Just early hint the ones that are “above the fold” So just the ones that are already visible when you access your page from a normal desktop machine. The assets that are not visible without scrolling do not have an early hint. In general just hint as much as is possible for an average device to render within about 2 seconds.

Also take into consideration to use “fetchpriority” as link headers are compatible with. You can set how important things are.

@tomas.cerkasas

I had a quick look at your pages.dev page and noticed the synthetic delay, which seems also to be applied on all static assets? Which could cause the yellow warning

“The resource was preloaded using link preload in Early Hints but not used within a few seconds from the window’s load event.”

as even if you turn it off, the static assets still seem to be very slow - slower than anything Cloudflare will ever get slow. If you want to improve performance beyond using EHs, feel free to search for older posts of @eva2000, @fritex or myself on how to improve websites in general, any static asset and some other cool tricks

If you preload any font, please include the crossorigin attribute, as otherwise it will create some discrepancies. In general you can take a quick look at the page I made for a friend of mine: https://www.heldmayer.com
Feel free to benchmark/debug/abuse it in any way you want.

@tomas.cerkasas

Thanks again for discussion @M4rt1n, I do hope this thread will be useful for those who come accross it!

Thats what this community forum is all about
ㅤ
ㅤ

Hope the best for you and have a good day!

[eva2000]

@M4rt1n

Just early hint the ones that are “above the fold”

+1 That’s all you need to do really - focus on critical render path assets