Feature Request: HTTP-Early-Hints header

serpent_driver

Well-Known Member
#21
Sorry, unfortunately I have to contradict you again. The fetchpriority property is not a replacement for early hint, especially since this property does not influence the loading, but as mentioned, influences the display behavior. If I mentioned this property, only because I still believe that your interpretation of the Waterfall is wrong. The Waterfall shows you the request of a source, but this request is not superfluous by the Early Hint. What you see in the Waterfalls is the actual request with the status code 200. I currently assume that the Early Hints will not be displayed in the event of a waterfall, especially since they are shown in parallel to the Request of the Main Document should. At least that's what the logic wants to tell me. In order to be able to analyze the loading of sources at network level, a browser function is not sufficient. For this you need professional software such as "Wireshark".

Unfortunately, I can't get anything out of your tips, especially since your tips have nothing to have with the HTTP protocol used. My page is faster than 100 million others. If a page is loaded faster than it takes time to let the mouse button loose, the maximum is achieved. Every further improvement takes place in the microsecond area.
 
#22
Unfortunately, I can't get anything out of your tips, especially since your tips have nothing to have with the HTTP protocol used. My page is faster than 100 million others
I agree that it loads fast, but I also assure you that it will be even faster if you get rid of unnecessary font files using modern VFS and decompose the bundles, because there are no restrictions on the number of connections in HTTP2 (this is cool feature of protocol → try it now). And with Expires server heading to activete short-time browser cache you can get really instant magic (correct 304 heading you alredy used and its ok)

Every further improvement takes place in the microsecond area.
You can make tests from mobile browser or desktop throttling for best readability of results!

...analyze the loading of sources at network level ... professional software ...
My choice is chrome://net-export/ - for write protocol logs and netlog-viewer for read it. Please check new screenshot for proof of my arguments about the accuracy of waterfalls and my conclusions here: https://github.com/dimasites/modern-web-notes#13-http2-netlog-103-with-early-hints
______________

It seems to me that you a little underestimate the importance and charm of Early Hits )) But in my opinion, we should work together on this issue to increase the chances of their support from LiteSpeed!

In fact: developers need 103 support as soon as possible!
 
Last edited:

serpent_driver

Well-Known Member
#23
I agree that it loads fast, but I also assure you that it will be even faster if you get rid of unnecessary font files using modern VFS and decompose the bundles, because there are no restrictions on the number of connections in HTTP2 (this is cool feature of protocol → try it now).
What the hell is decompose? Decompose means to turn plants into compost, so what is your meaning with decompose?

I don't use unnecessary font files and the number of total sources to be loaded is based on actual needs. All fonts are in use. That includes the amount of CSS and Javascript or when was the last time you saw a page that got by under 50kb? Although each page has different formatting. In addition to the visible pages, there is also the account area and shop checkout. So you don't have to give me advice on how to optimize a page. I've been doing this job for 25 years.

I don't use the Expire header because I use the Cache-Control header instead. Both do the same thing, but cache-control is the more recent version of it. If I didn't organize the browser cache, you would notice when changing pages that all static ones were not in the browser cache. Also, for a 304 status code that has nothing to do with the Expire header, you would need ETags, and these in turn need a corresponding Response header to define the expiry time. I deliberately do not set ETag headers for static sources, especially since there is no advantage with static sources. Every browser has a natural desire to cache static sources after the first request. There is no need for a 304 status code, with the emphasis on static sources and not dynamic ones.

You can make tests from mobile browser or desktop throttling for best readability of reults!
Every kind of device gets different sources (Content, HTML, CSS, JS, images, ...). What more would you like to recommend me? In addition, you only requested my page with a desktop computer, but with a different browser. So why are you giving me such advice that you didn't give yourself?

btw. You should focus less on the early hints and more on your president. There are users from one country in this forum who would start a shitstorm if they knew which country you are from.
 
#24
What the hell is decompose? Decompose mean
Its mean, i recommend you split to separate files js-libraries which glued now together in one file. Like a CSS-sprites, it is old practice and antipattern on HTTP2 and 3, as like as CSS-sprites which you are not using and it is ok.

I don't use the Expire header because I use the Cache-Control header instead.
You can use it slight better: see the screenshot. I am about documents (pages) not about static resources. Just try my suggest before dispute and on 26 year of this job, you find more web perfomance of you site ever, again - just try!

So why are you giving me such advice that you didn't give yourself?
I made test on my WebPageTest private instance before deciding to give advice to you, a respected participant here is a form, please see proof screenshot with date and time (and you can check your server logs)

Even though you started this topic, if you now think that you don't need 103 Early Hints, then I appeal to the LSWS developers with the statement that they are definitely needed and should be supported!

btw. May be you should focus less of any president, and more about technologies, to remain a professional and positive person.
 

serpent_driver

Well-Known Member
#25
I don't know where you get your knowledge from, but as far as LiteSpeed is concerned, the source of your knowledge is not very credible. In any case, what you are complaining about is not based on expert knowledge of LiteSpeed and how to configure LiteSpeed. Also, I question your knowledge of the correct cache control settings. But what you cannot know is that I use ESI and when using ESI, the cache-control must not and cannot be public.

Why are you testing sites with a 3G simulation? Even in the jungle in Africa there is already 4G. Is Russia still so old-fashioned in the taiga? :)
 
#26
Why are you testing sites with a 3G simulation?
For more readability, as i said:
You can make tests from mobile browser or desktop throttling for best readability of results!
not based on expert knowledge of LiteSpeed
You are right, i new user for litespeed, however, I have enough experience (10+ years, but not enough to stop learning) to see that performance depends on many factors, and you cannot rely only on a web server if you need realy high speed for UX and SEO.

It is especially sad when your web server does not support modern technologies and you are simply forced to use another one, and write something here on the forum in the style of "please make Early Hints support in LiteSpeed"!

And when you look to taiga on google map, thousands of sites are already updating their technologies, decomposing bundles, using a short-term (and not only) browser cache and deferred resource loading for real performance…

At this point, let 's interrupt the discussion about your site and invite litespeed specialists to express their opinion about the support of 103 HTTP Headers !
 
Last edited:

serpent_driver

Well-Known Member
#28
It is especially sad when your web server does not support modern technologies and you are simply forced to use another one, and write something here on the forum in the style of "please make Early Hints support in LiteSpeed"!
However, the missing Early-Hints header in the LiteSpeed webserver does not mean that the LSWS is not more advanced than any other webserver. Early hints is just another feature, but it doesn't significantly determine the speed of a page. First and foremost, it's about the future-oriented technology of the LSWS, which clearly sets itself apart from nginx and Apache anyway. In combination with LScache, the LiteSpeed web server has been the fastest web server on the market for many years.
 
#29
Early hints is just another feature, but it doesn't significantly determine the speed of a page.
This is a very relative concept...

I'm afraid when you achieve DocumentComplete in 150-250 ms, the additional 50ms will become up to +30% speed for you. This is the reason why I switch to HTTP 3 from HTTP 2 (minus ping time thanks to Zero-RTT), and Early Hints can give a much greater increase than 50ms due to parallel hinted resource loading, especially when TTFB for objective reasons is not possible to provide on very high-speed (for example, faceted filter pages in online stores)

LiteSpeed web server has been the fastest web server on the market
I targeting for fastest website load, not only fastest webserver response, and without support modern features and approved (by browsers, but that's enough) stardats it is impossible on LiteSpeed today and for stay best perfomance speed, LiteSpeed must implement Early Hints!

Without 103 Header support LiteSpeed slowing down websites in Chrome now (because its disabled Server Push, but we can't change that for website visitors) both Desktop and Mobile. Thats facts just now!
 

serpent_driver

Well-Known Member
#30
This is a very relative concept...
That's not relative. Relative is whether you're able to use early hints. 9999 out of 1000 users don't know what early hints are, what they could be used for and how to use them. This finding excludes 99.99% of all users from the advantages of early hints. Especially since it is necessary to modify the CMS used in order to use the Early Hints, because every CMS and every theme (Wordpress) is different. Nevertheless, the early hint is not a game changer. It can improve what already exists, but ultimately it is only part of a holistic optimization strategy.

I'm afraid when you achieve DocumentComplete in 150-250 ms, the additional 50ms will become up to +30% speed for you. This is the reason why I switch to HTTP 3 from HTTP 2 (minus ping time thanks to Zero-RTT), and Early Hints can give a much greater increase than 50ms due to parallel hinted resource loading, especially when TTFB for objective reasons is not possible to provide on very high-speed (for example, faceted filter pages in online stores)
As I have pointed out to you on several occasions, your understanding of the early hints is not only flawed but also patchy. The early hints are about prioritizing the sources necessary for the display, so that the display above-the-fold in particular is faster, because something that loads faster does not mean that something is displayed faster. This is still your biggest misunderstanding.

Also, the early hints don't change anything on the TTFB, because that's measured on the main document with status 200 and not on whether and when you get something displayed in the browser.

I targeting for fastest website load, not only fastest webserver response, and without support modern features and approved (by browsers, but that's enough) stardats it is impossible on LiteSpeed today and for stay best perfomance speed, LiteSpeed must implement Early Hints!

Without 103 Header support LiteSpeed slowing down websites in Chrome now (because its disabled Server Push, but we can't change that for website visitors) both Desktop and Mobile. Thats facts just now!
As mentioned several times, your understanding of what makes a website fast is wrong because you are unable to differentiate between loading and displaying. As long as you are not in a position to do this, I deny you any competence. Sorry, you have so far provided me with any evidence that your knowledge is insufficient.
 
Last edited:
#34
Still not possible?
In LiteSpeed and openLiteSpeed — no. And while litespeed team cant offer this even on paid version, LiteSpeed-based website will be slower then 103-code supported hosting. In some cases (not suitable for me) you can use third-party additions like proxy-server with Early Hints support, but with some side-effects, and it will not be best way for all cases.

But without native 103 Early Hints support from LiteSpeed, we are now non-compatible with modern wide-used web standarts and laso most popular web browsers.

IMHO, this situation looks like CDN-providers stops progress for making money on paid services, which adds normal protocol support, because no web server in TOP-3 (N... , A... , LiteSpeed) still not supported Early Hints. You can find this and this topics on other webserver forums and my posts.

P.S. For my websites, i found solution with another webserver out of TOP-3 because i cant and dont want waiting more. OpenSource world moreover waiting too, and on this background may be LiteSpeed can even lost TOP-3 raiting position by popularity in future...
 

serpent_driver

Well-Known Member
#35
P.S. For my websites, i found solution with another webserver out of TOP-3 because i cant and dont want waiting more. OpenSource world moreover waiting too, and on this background may be LiteSpeed can even lost TOP-3 raiting position by popularity in future...
Why switching to other web server? If you already have <link rel="preload" ....> in your page just use CF Early Hints with 1 click.
 
#36
just use CF Early Hints with 1 click.
And this is problem, this way slowdowns my projects because CF (CloudFlare CDN, third-party service) is proxy and large chain of requests with more pings not better way for dynamic content sites like e-shops, corporate sites with personalized content and others with SSR - server side rendering.

I need best PageSpeed results (for SEO, UX and conversion), fastes page loads as possible and i have fastest hosting close to my auditory. Any CDN and other third-party are slowdowns!

We have a web standard (HTTP protocol, including 103 header) and a web server + browser. Why are we obliged to use intermediaries in this scheme?

Currently, LiteSpeed is not fully compatible with the current wide-used features of actual HTTP protocol. It was outdated until it began to support the 103 header, so I decided to change it, unfortunately. I hope litespeed team read this forum, knows about this problem, and can offer solution in future!
 

serpent_driver

Well-Known Member
#37
And this is problem, this way slowdowns my projects because CF (CloudFlare CDN, third-party service) is proxy and large chain of requests with more pings not better way for dynamic content sites like e-shops, corporate sites with personalized content and others with SSR - server side rendering.
That's hard to imagine and even if it were true, it would be hard to measure. With a proxy (not a CDN) it would be more possible, but CF is a CDN. Therefore, you save a huge amount of time resolving the IP address and this benefit is far greater!
 
#38
it would be hard to measure
In fact, it is quite simple to measure, just use WebPageTest with worker, located near to your-site clients.

resolving the IP address
I can agree that the DNS from CF is fast, and i use it as one of several.

But let's not confuse the CDN (additional static cache layer + proxy + optinal geo) and DNS (ip resolving) functions. DNS is required for website working (as a webserver, like LiteSpeed or other modern, compatible with actual web standarts like 103 Early Hiths header), but CDN - optional and can slowdown by design, because in fact, it is proxy/middleware for browser-webserver requests and responses.
 

serpent_driver

Well-Known Member
#39
I need best PageSpeed results (for SEO, UX and conversion), fastes page loads as possible and i have fastest hosting close to my auditory. Any CDN and other third-party are slowdowns!
Did you know that the delay if a CDN or proxy used don't matter for PageSpeed or any other web page test?
 
#40
Did you know that the delay if a CDN or proxy used don't matter for PageSpeed or any other web page test?
Any additional delay which decreases page load time, together decrease test results score, with no variants. That's what I know.

But i dont know, why are you advertising CDN, instead of promoting the idea of supporting an up-to-date web standard (103 HTTP Header) in an LiteSpeed web server directly, without anyone else. Please explain if you can, thx/
 
Top