Feature Request: HTTP-Early-Hints header

serpent_driver

Well-Known Member
#41
Basically, you are right and a CDN is not generally an advantage. This is especially true if the visitors to a site come predominantly from your own country, because then direct access to the origin host is faster. However, if you have a lot of international access, you benefit significantly from a CDN, because resolving the IP address takes the most time on the first access. In such a case, whether your site is well or poorly optimized does not matter, because as long as the main document is not loaded, no static sources are loaded. This also applies if Early Hints headers are used. You can optimize your site as much as you like, but if the connectivity of your site is poor or inadequate, then the effort spent on optimization is worthless.

If it seems like I am promoting CDN, then only in the specific case of Early Hints. Unfortunately, LiteSpeed does not yet support these headers, but CloudFlare supports these headers in combination with the <link rel="preload"> tag.

When it comes to optimizing a page, regardless of a CDN, you should find out more about PageSpeed or any other web page test site. Loading any kind of source is irrelevant for PageSpeed and scoring. PageSpeed is about speed, but the measurement of speed refers to the display time and this begins from the moment AFTER sources have been loaded. The actual loading and the time required for this is irrelevant for PageSpeed. If PageSpeed took the time required for loading into account, the PageSpeed test would be falsified. The distance between server and client has a significant influence on the loading time, especially if the client (browser) has not yet resolved the IP address. This would mean that the PageSpeed test would be to the disadvantage of the hosts whose distance to the PageSpeed server is the greatest. Or to put it another way, a poorly optimized page but with a short distance to PageSpeed would be rated better than a host far away with the best possible optimization.

It should be obvious that loading sources does not play a role for PageSpeed and should not play a role. Otherwise it would not be an accurate measurement. PageSpeed therefore only measures the display time from the moment when all the sources required for display have been loaded.

If you want to find out more about this, then invest a few minutes of time and study these two posts:

https://www.cachecrawler.com/Knowledgebase/PageSpeed/PageSpeed-Loading-Time::6568.html
https://www.cachecrawler.com/Knowledgebase/PageSpeed/Loading-Time-versus-Display-Time::6569.html
 
#42
with a short distance to PageSpeed would be rated bette
Yes, in this reason i suggested later to use WebPageTest with Worker located near to website targeted users. Or near to hosting, for test real optimization.

Here another suggests:
• check real user expierence with Chrome UX reports and with web-analytics software.
• WebPageTest (i use private instance, its free) also includes Google Lihthouse reports, but we can also use Lighthouse tests separately with Docker, to

But let's get back to the topic: is LiteSpeed planning to support 103 headers, or does it also suggest using other software or external services for the full operation of the HTTP protocol on the hosting?

P.S. Yor links dont works becuse CF setting too strict, i mean, see attached screenshot. And this is one of reasons, why CF proxy is not best for all cases solution. (I just click to link from your post, with no any hacks)
 

Attachments

serpent_driver

Well-Known Member
#43
P.S. Yor links dont works becuse CF setting too strict, i mean, see attached screenshot. And this is one of reasons, why CF proxy is not best for all cases solution. (I just click to link from your post, with no any hacks)
No, it isn't too strict. The rule is exactly what is defined for. Your country is not very popular in the world!

But let's get back to the topic: is LiteSpeed planning to support 103 headers, or does it also suggest using other software or external services for the full operation of the HTTP protocol on the hosting?
I have no idea....
 

Yogurteg

Active Member
#44
@serpent_driver, @dimasites
Actually, it measures:
2024-08-06 141323.jpg
This poor synthetyc result and your real-user-expiriense for desktop speaks about CF as CDN is bad for TTFB and entire page loading.

I have 20-50 ms in synth and same TTFB in R-U-E on mobile (as your desktop) without CF CDN.
 

serpent_driver

Well-Known Member
#45
This poor synthetyc result and your real-user-expiriense for desktop speaks about CF as CDN is bad for TTFB and entire page loading.

I have 20-50 ms in synth and same TTFB in R-U-E on mobile (as your desktop) without CF CDN.
TTFB depends on user and closest CDN node location, so it is not fix for every request. When I do a PageSpeed test, no bad TTFB is reported.

pagespeed_1.png
pagespeed_2.png

pagespeed_3.png

pagespeed_4.png
 
Last edited:

serpent_driver

Well-Known Member
#47
Who cares about TTFB?! Not me. It says nothing about how fast a page is loaded and displayed. Do you get better results as cachecrawler.com? I don't think so!

Get rid of the idea that every CMS has to be bloated. I use custom code for my CMS and only load what is actually necessary for display. That doesn't mean that my pages are weightless.
 

Yogurteg

Active Member
#48
Who cares about TTFB?! Not me. It says nothing about how fast a page is loaded and displayed. Do you get better results as cachecrawler.com? I don't think so!

Get rid of the idea that every CMS has to be bloated. I use custom code for my CMS and only load what is actually necessary for display. That doesn't mean that my pages are weightless.
Google cares, for example, users also) Of course, TTFB is most important for page loading and displaying. And yes, i think i have better results, but u didn't have R-U-E on mobile)
Why u think about what i don't think)) Of course you use, i just said, for your pageweight this scores is poor.
 
Top