Feature Request: HTTP-Early-Hints header
- Thread starter serpent_driver
- Start date
Hi all!
We're laggards now! Crome remove server push and we lost about 30% page load time!
https://developer.chrome.com/blog/removing-push/ we need 103 Early Hints emergency!
We're laggards now! Crome remove server push and we lost about 30% page load time!
https://developer.chrome.com/blog/removing-push/ we need 103 Early Hints emergency!
I think you're exaggerating a bit. I'm a fan of Server Push myself, but Server Push won't make your site 30% faster, or slower without it. Early hints are not and cannot replace server push, as they are only hints. Nothing is actually subpoenaed. Hints only indicate that certain sources should be loaded with priority, again they should be prioritized. Whether the browser ultimately does this is up to the browser. You will therefore have to look for another way, or consider where you can save amounts of data, because only that will actually bring anything.
I didn't say you were a theorist.
Server Push is still supported by LSWS and it works. Firefox still supports it, but Chrome has stopped for it.
The problem with server push was, or is, that very few know how to deal with it and that was exactly the reason why Google stopped supporting it in the Chrome browser. At least the LSWS offers all possibilities to use server push sensibly. Even if LiteSpeed did support early hints, the advantage over server push is negligible because, as the name suggests, these are just hints and you can't preload anything with hints alone. The Early Hints only make sense together with the <link rel="preload"... and only together with that you achieve something similar to Server Push.
Server Push is still supported by LSWS and it works. Firefox still supports it, but Chrome has stopped for it.
The problem with server push was, or is, that very few know how to deal with it and that was exactly the reason why Google stopped supporting it in the Chrome browser. At least the LSWS offers all possibilities to use server push sensibly. Even if LiteSpeed did support early hints, the advantage over server push is negligible because, as the name suggests, these are just hints and you can't preload anything with hints alone. The Early Hints only make sense together with the <link rel="preload"... and only together with that you achieve something similar to Server Push.
You're right! There were nuances with the Server Push, but now it's in the past (in fact) and now I don't even have the tools to check if I can make a replacement for it. May be 103 header is only hints, but in Chrome dev's blog written about alternatives, and i want to check how chrome actually implements the support for client hints, but my favorite web server does not give me this opportunity!
And I really think this is an urgent problem right now.
And I really think this is an urgent problem right now.
Of course, i using not only <link rel="preload"... tag, i even send HTTP Header "Link" with list of resources for preload from my backend, because its faster (browser dont need parse html for searching <link> tags), but this is not same compare with early send HTTP 103 code before send 200 code, whitch must be supported by my webserver!
Last edited:
Hi @serpent_driver , may be i missed any good news about 103 headers? In many cases use CDN or cache proxy not a best way and we need on-board Early hints soluton!
P.S. Why LiteSpeed team cant apply this feature? It's about perfomance, and that is feature, LSWS made for...
Apache support this feature, but without API for backend control. Directly from PHP we cant send two headers. NGINX not support 103. This thing may be cool kill-feature for LSWS!
P.S.2 Can we tag anyowe from LSWS team here?
P.S. Why LiteSpeed team cant apply this feature? It's about perfomance, and that is feature, LSWS made for...
Apache support this feature, but without API for backend control. Directly from PHP we cant send two headers. NGINX not support 103. This thing may be cool kill-feature for LSWS!
P.S.2 Can we tag anyowe from LSWS team here?
In 9 out of 10 cases, a CDN is worse than without because people have a misconception about a CDN.
Good question, next question....
There is no need for a special control this feature. On/Off is enough if it is handeled like preload (HTTP/2 Server Push)
This forum is read by LiteSpeed, at least I hope so, so there's no need to tag anyone. Just need more people asking for the 103 header. The more interest the greater the motivation, at least I hope so.
HTTP server push is still supported by LSWS, but only Firefox still supports it. Chrome removed this property.
Good question, next question....
There is no need for a special control this feature. On/Off is enough if it is handeled like preload (HTTP/2 Server Push)
This forum is read by LiteSpeed, at least I hope so, so there's no need to tag anyone. Just need more people asking for the 103 header. The more interest the greater the motivation, at least I hope so.
HTTP server push is still supported by LSWS, but only Firefox still supports it. Chrome removed this property.
Thanks for answer!
At least, on/off will be great, for real... But for get full power of 103 headig, i see two ways (and best together):
Please LiteSpeed staff comment in this topic!
At least, on/off will be great, for real... But for get full power of 103 headig, i see two ways (and best together):
- Server must cache "Link" headings for each uri and return immidiately in 103 response (unlike Server Push when where it was not so important, because Push immediately transferred files over the network, and not just hints with links that the client will still have to download after receiving)
- For fast 103 response server must have ability fo send additional request to backend (or backend controlled cache engine like redis, or API-controlled any server's own storage) for get content of needed for response Link heading (list of resources with "rel" and other directives)
Please LiteSpeed staff comment in this topic!
It's nice to read your further ideas on early hints, but what you wish for is not in the nature of early hints. The early hints are primarily about prioritizing static sources and not about compensating for the inadequacies of an application. Neither do the early hints serve any caches. It is the responsibility of each application to provide the dynamic data as quickly as possible, even without tools (DB cache or others). Unfortunately, development by using PHP frameworks didn't really do anything to make anything better. On the contrary, it has even been made worse.
In my opinion (based on tests), the kill feature of Early Hits is that they allow you to provide links to related resources (CSS, Fonts or LCP image etc.) even before the body (html) of the page is loaded. And then they will be loaded in parallel, not sequential! It gives not only downloading benefits, but also parsing.
This behavior cannot be provided by a PHP application. I conducted a lot of tests, of course it is impossible to achieve the maximum effect and speed that Server Push gave, but since the smart people from Chrome decided to disable Server Push because many of my colleagues did not use it correctly or did not use it at all \_(ツ)_/, I want to use its "replacement" at full capacity.
In any case, the web standard with 103 header already de-facto has been approved and also supported by browsers, and it must be supported by a web server that wants to continue to be positioned as a tool for providing a fast web, which is what OLS and LSWS focused.
This behavior cannot be provided by a PHP application. I conducted a lot of tests, of course it is impossible to achieve the maximum effect and speed that Server Push gave, but since the smart people from Chrome decided to disable Server Push because many of my colleagues did not use it correctly or did not use it at all \_(ツ)_/, I want to use its "replacement" at full capacity.
In any case, the web standard with 103 header already de-facto has been approved and also supported by browsers, and it must be supported by a web server that wants to continue to be positioned as a tool for providing a fast web, which is what OLS and LSWS focused.
I don't mean to imply anything, but I don't think you fully understand how early hints work. The functionality of the early hints is not completely different from that of HTTP/2 server push. The principle of both techniques is to load sub-resources (CSS, JS, ...) before the main document is loaded. With both methods there is no parallel loading and must therefore be serial. Otherwise, neither the early hints nor the push would have an advantage.
PHP has no influence here, because before PHP can do anything, it needs an HTTP status code 200 and that's way too late. The sub-resources must be loaded before there is a 200 status. That's why Early-Hints sends a 103 status code and it is sent before the 200 status.
The reason why Google no longer supports push is that all web servers except for the LSWS do not integrate a mechanism to prevent "over-pushing" from occurring. The problem with push is that the sub-resources are pushed with every request. However, this can be easily solved by binding the preload of the sub-resources to a cookie. This prevents sub-resources such as CSS and JS from being pushed multiple times. Browsers that support server push are unable to decide whether or not to reload already loaded subresources. The early hints are different. With this header, the browser can decide for itself whether the sub-resources that are already in the browser cache should be loaded again. If no cookie is used, but the LSWS automatically sets this cookie, server push has the criticized disadvantage compared to early hints. To solve the problem, Google simply needed to use its market power and notoriety and educate people on how to properly use HTTP/2 server push.
PHP has no influence here, because before PHP can do anything, it needs an HTTP status code 200 and that's way too late. The sub-resources must be loaded before there is a 200 status. That's why Early-Hints sends a 103 status code and it is sent before the 200 status.
The reason why Google no longer supports push is that all web servers except for the LSWS do not integrate a mechanism to prevent "over-pushing" from occurring. The problem with push is that the sub-resources are pushed with every request. However, this can be easily solved by binding the preload of the sub-resources to a cookie. This prevents sub-resources such as CSS and JS from being pushed multiple times. Browsers that support server push are unable to decide whether or not to reload already loaded subresources. The early hints are different. With this header, the browser can decide for itself whether the sub-resources that are already in the browser cache should be loaded again. If no cookie is used, but the LSWS automatically sets this cookie, server push has the criticized disadvantage compared to early hints. To solve the problem, Google simply needed to use its market power and notoriety and educate people on how to properly use HTTP/2 server push.
Ok 
Let me give you the confirmations.
As I said above, I am not a theorist, and I have used server push with NGINX perfectly in the past (and yes, I used setting cookies to prevent push resending) and I also generated a list of resources for Push on the PHP side (and this was a good fit for PUSH).
And I assure you that both Pushed and Early Hinted resources via HTTP2 and HTTP3 are loaded in parallel. Please check screenshots from waterfalls to make sure: https://github.com/dimasites/modern-web-notes
I'm using Early Hints (and Push for FF) just now (without LiteSpeed, and not as happy as I could be). And i see how EH's behavior is very different from Server Push, because after receiving the 103 header, browser makes an additional request to the server, and the link can refer to dynamic content (even CSS and JS) generated from PHP), this was not possible with server push, but in my opinion, this feature not enough for orgnize full backed-controlled Early Hints. And i try to explain more below.
In the case of Server Push, I can add the Link rel=preload header in one response from PHP and the web server will do a Push, then in the case of Early Hints, to control which resources should be sent, I would not want to use hardcode in configs, but wanted to generate a set of resources also dynamically, for then an ideal web server could make an additional request to the PHP backend to get a list of resources (as I wrote above). Or provided an API in some other form to automate the formation of a list of resources for CH.
Let me give you the confirmations.As I said above, I am not a theorist, and I have used server push with NGINX perfectly in the past (and yes, I used setting cookies to prevent push resending) and I also generated a list of resources for Push on the PHP side (and this was a good fit for PUSH).
And I assure you that both Pushed and Early Hinted resources via HTTP2 and HTTP3 are loaded in parallel. Please check screenshots from waterfalls to make sure: https://github.com/dimasites/modern-web-notes
I'm using Early Hints (and Push for FF) just now (without LiteSpeed, and not as happy as I could be). And i see how EH's behavior is very different from Server Push, because after receiving the 103 header, browser makes an additional request to the server, and the link can refer to dynamic content (even CSS and JS) generated from PHP), this was not possible with server push, but in my opinion, this feature not enough for orgnize full backed-controlled Early Hints. And i try to explain more below.
In the case of Server Push, I can add the Link rel=preload header in one response from PHP and the web server will do a Push, then in the case of Early Hints, to control which resources should be sent, I would not want to use hardcode in configs, but wanted to generate a set of resources also dynamically, for then an ideal web server could make an additional request to the PHP backend to get a list of resources (as I wrote above). Or provided an API in some other form to automate the formation of a list of resources for CH.
Unfortunately I have to disagree with you again. Even if the waterfall would have you believe that the static sources and the HTML would be loaded in parallel, then there are only 2 possibilities. Either you misinterpret the waterfall or early hints doesn't work. If it were like you think, then the early hints wouldn't work. As you can see from the image below, this image represents the methodology of early hints. And yes, it is known that the early hints require another round trip, however, a round trip is not a request in the true sense. But a round trip means a delay in any case, so the early hints don't reach the performance of server push. Even if Google wants us to believe so.
https://developer.chrome.com/blog/early-hints/
https://developer.chrome.com/blog/early-hints/
Ohh... Thank you for an additional explanation that is never superfluous, but I think I understand perfectly how both EH and Push work. And even show it for you (and others) my own rest results (not from manuals or ads): please see new example and screenshot (now from WPT) about parallel -requested hinted resource: #1.2. HTTP2 103 Early Hints resource separate request in my github notes. You can send PR with the results of your own experiments!
And Yes, as you said, 103 header does not reach Server Push perfomance (and i disappointed that chrome disabled it), but we must go ahead and work with what we have. EH can boost first load, whatever significantly speed up pages, however LiteSpeed does not give us the tools and we are forced to use other products, because LiteSpeed-hosted site will be slower without Early Hints in comparison with the same, but with HTTP 103 support.
And that's why we request LiteSpeed to listen to the developers and implement RFC 8297 as soon as possible!
And Yes, as you said, 103 header does not reach Server Push perfomance (and i disappointed that chrome disabled it), but we must go ahead and work with what we have. EH can boost first load, whatever significantly speed up pages, however LiteSpeed does not give us the tools and we are forced to use other products, because LiteSpeed-hosted site will be slower without Early Hints in comparison with the same, but with HTTP 103 support.
And that's why we request LiteSpeed to listen to the developers and implement RFC 8297 as soon as possible!
I think I know what the problem is. The waterfall reflects something that doesn't match the actual sequence of requests. The reason for this lies in the rendering, or in which order the sources are rendered by the browser. If you have a large amount of static sources, then these will not be loaded at the same time, but divided into several round trips. The number of sources loaded at the same time varies depending on the browser. Chrome limits this amount much more than Firefox. In addition, there are different priorities for all sources. However, these priorities do not affect the loading behavior, but the display behavior. For example, CSS files have high priority, while images have either normal or low priority. In your test you use images for the early hints. If images have a low priority, then this could affect the waterfall and will apparently load later in it, even though the image is preloaded via early hints. However, loading a resource is not synonymous with displaying or rendering. That's why I believe that the said priority has an influence on the waterfall after all. Also, I believe the Early Hints request is not showing up in the waterfalls
I would change 2 factors in your test. Only use early hints on images that are defined "above-the-fold". Use the fetchPriority property on the <img> tag. Set fetchpriority="high" for above-the-fold images and set fetchpriority="low" for all other images, then test again. I would not only test images, but especially CSS files and test it with PageSpeed. On my site (https://www.cachecrawler.com/) you can see how I use Server Push, fetchPriority property and loading="lazy".
btw. You can display the priority value for each source in the browser in the Dev Console. For Firefox you have to activate the fetchPriority property in about:config so that the FF can use this property.
https://web.dev/fetch-priority/
I would change 2 factors in your test. Only use early hints on images that are defined "above-the-fold". Use the fetchPriority property on the <img> tag. Set fetchpriority="high" for above-the-fold images and set fetchpriority="low" for all other images, then test again. I would not only test images, but especially CSS files and test it with PageSpeed. On my site (https://www.cachecrawler.com/) you can see how I use Server Push, fetchPriority property and loading="lazy".
btw. You can display the priority value for each source in the browser in the Dev Console. For Firefox you have to activate the fetchPriority property in about:config so that the FF can use this property.
https://web.dev/fetch-priority/
If we started talking about what and how to write in tags, then by this point both Push and Hints have already worked. Fetch priority in html tags — too late feature for our discussion!
Waterfalls from my screenshots is formed from real browsers, this is not a simulation! So you can trust the data you see.
If what you see does not match your ideas, then it's time to correct them, and start believing what you saw on waterfalls.
Your site uses Push, as I see, but does not use all the advantages of HTTP2 (and 3) - try to decompose CSS and JS bundles, minify manually written JS code (click and scroll handlers, what's in the middle of the bundle) and also use variable font instead of four OpenSans files and you will get more more productivity.
And that's not all. To get more power from prefetch (instant), you must enable the browser cache for at least 1-3 minutes by parsing the expires headers from the server, and then the pages will open really instantly.
I hope you will use the tips and add speed to your site, and also make sure that I myself understand a little what I'm talking about ;-)
But I hope even more that LiteSpeed will give us Early Hints support!
Thank you for the discussion, we will be waiting for good news from LSWS and OLS!
Waterfalls from my screenshots is formed from real browsers, this is not a simulation! So you can trust the data you see.
If what you see does not match your ideas, then it's time to correct them, and start believing what you saw on waterfalls.
Your site uses Push, as I see, but does not use all the advantages of HTTP2 (and 3) - try to decompose CSS and JS bundles, minify manually written JS code (click and scroll handlers, what's in the middle of the bundle) and also use variable font instead of four OpenSans files and you will get more more productivity.
And that's not all. To get more power from prefetch (instant), you must enable the browser cache for at least 1-3 minutes by parsing the expires headers from the server, and then the pages will open really instantly.
I hope you will use the tips and add speed to your site, and also make sure that I myself understand a little what I'm talking about ;-)
But I hope even more that LiteSpeed will give us Early Hints support!
Thank you for the discussion, we will be waiting for good news from LSWS and OLS!