Jump to content

Community

Manifest and cookie-free domain


Recommended Posts

When a cookie-free domain  is used, all resources are loaded by that cookie-free  domain, including links in the contents of the manifest file.
But, the initiator for loading manifest.webmanifest does not change and manifest is loaded from the primary domain.
This causes:
- DNS lookup
- new connecting
- new SSL,
or about 200 ms delay for loading manifest file.
If possible, include a cookie-free domain for loading manifest file,  when used - this will speed up the loading site.

Thanks

Link to post
Share on other sites

I don't disagree, and I think it makes sense. However, I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead. Even if you have keep-alive disabled (as ips did for a while, although they may have changed that now), the dns lookup will always have been cached and if you are running an up to date version of openssl and nginx/apache you can get 0- or 1-rtt tls session resumption, so there should only be 1-2 round trips of overhead.

Resending the cookies is still a reasonable concern, but the others are not.

Link to post
Share on other sites

Http/2 actually means that using a cookieless domain isn't worth the pay off any more. Previously, the concern was the additional bandwidth and therefore loss of speed by including a few kb of cookies in each request. But now with http/2 the additional overhead of making a new connection, the lookup, the ssl handshake etc is actually slower than having everything requested off of the same domain, even if that means each request includes cookies - particularly since http/2 compresses them.

https://blog.theodo.com/2019/09/cookieless-domain-http2-world/

https://www.hostnexus.com/blog/http2-site-optimization/

So, the optimal way to do it would appear to be to drop the cookieless domain entirely. 

 

 

Link to post
Share on other sites
4 hours ago, Colonel_mortis said:

I don't disagree, and I think it makes sense. However, I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead. Even if you have keep-alive disabled (as ips did for a while, although they may have changed that now), the dns lookup will always have been cached and if you are running an up to date version of openssl and nginx/apache you can get 0- or 1-rtt tls session resumption, so there should only be 1-2 round trips of overhead.

Resending the cookies is still a reasonable concern, but the others are not.

There is no logic when all resources are loaded by a cookie-free domain, incl. and links from the contents of the manifest file, to load the manifest file from the main domain ...
I have no problem with speed loading, just I share what I notice - and here's to see for yourself - how to load a manifest file. And yes, I use 100% keep-alive

1596772705_Screenshotat2019-10-06164612.thumb.png.1454f05ed431c67e3471c211c012b211.png

2059172599_Screenshotat2019-10-06165402.thumb.png.ba1c785c7d712c778ba682b50d07d993.png

Link to post
Share on other sites
1 hour ago, Dll said:

Http/2 actually means that using a cookieless domain isn't worth the pay off any more. Previously, the concern was the additional bandwidth and therefore loss of speed by including a few kb of cookies in each request. But now with http/2 the additional overhead of making a new connection, the lookup, the ssl handshake etc is actually slower than having everything requested off of the same domain, even if that means each request includes cookies - particularly since http/2 compresses them.

https://blog.theodo.com/2019/09/cookieless-domain-http2-world/

https://www.hostnexus.com/blog/http2-site-optimization/

So, the optimal way to do it would appear to be to drop the cookieless domain entirely. 

 

 

Cookie-free domain is free, ie anyone can create it on their own server and they will not pay for it.

http2 is a very good working protocol. But besides the fast loading site there are other things. A cookie-free domain , for example, improves the YSlow and consequently the overall performance. When analyzing with Pingdom, at least for my site, perfor incremance ased by 5 points.

225212519_Screenshotat2019-10-06175115.thumb.png.31cfbcd34c499f5e965b1e43c57fb16d.png

Link to post
Share on other sites

Many of those tools were built pre-http/2. Read the links I posted (and there are numerous more on the net), most people think that http/2 negates the need for a cookieless domain. It doesn't hurt much to use one though, if you already are. 

On top of this, the manifest file is best on the root domain of the site as it can cause CORS issues if not. For a developer, it's easy to work around and put a policy in place for, but I can see why Invision would keep it on the root domain since it ensures it'll work out of the box. 

Link to post
Share on other sites
24 minutes ago, Dll said:

Read the links I posted

Yes, I read these articles. They look at specific site architectures, and probably used a cookie-free domain  before optimizing this site - If use a cookie-free domain  if the site was not optimized - images, css and js, html5 errors, and more is really pointless and has no effect.
A cookie-free domain  only makes sense when everything else on the site is optimized - ie. used at the end of the optimization process, or then used by CDN - depending on site need.

In my observations and analysis of different sites using the IPS suite, after site optimization, the use of a cookie-free domain  improves site performance and speed, especially for PSI tests relevant to sites using Google ads and other sources.

Link to post
Share on other sites

@Adlago

Quote

If you are currently using Cloudflare CDN then you need to disable it to disappear the warning to use cookie-free domains. The reason is that you can’t disable cookies served through CloudFlare CDN. Moreover, they also include their security cookie in your website header.

Source: https://authoritywebsiteincome.com/4-ways-to-use-cookie-free-domains/

So, a cookie-free domain is NOT an option for sites running via Cloudflare. Your comments?

Link to post
Share on other sites
On 10/6/2019 at 11:02 AM, Dll said:

On top of this, the manifest file is best on the root domain of the site as it can cause CORS issues if not. For a developer, it's easy to work around and put a policy in place for, but I can see why Invision would keep it on the root domain since it ensures it'll work out of the box.

Setting this aside, the manifest file is generated dynamically based on various setting, rather than as a static file. Moving it to a cookie-less domain would require downloading a static file every time any of those settings have changed (of which, there are many spread throughout the suite).

Link to post
Share on other sites
28 minutes ago, Ryan Ashbrook said:

Moving it to a cookie-less domain would require downloading a static file every time any of those settings have changed (of which, there are many spread throughout the suite).

The content that is generated from the manifest file is now the following

 "scope": "\/",
    "name": "...",
    "theme_color": "...",
    "short_name": "...",
    "start_url": "\/",
    "description": "...",
    "background_color": "...",
    "display": "standalone",
    "icons":...

These settings are made when activated and very rarely are subject to change.
There is nothing stopping when a site administrator chooses to use a cookie-free domain, loading a manifest file should also be from that domain.
When a cookie-free domain  is used now, links in the contents of a manifest file (for android chrome icons) are generated with an address for a cookie-free domain - and there is no issues.
So I think loading a manifest.webmanifest file from a cookie-free domain will create an improvement.

PS. You can check - the contents of my manifest file are loaded without issue when loaded with a link cookie-free domain

https://str.nophelet.com/manifest.webmanifest/

 

Edited by Adlago
Link to post
Share on other sites
  • 6 months later...
On 10/3/2019 at 1:23 PM, Adlago said:

When a cookie-free domain  is used, all resources are loaded by that cookie-free  domain, including links in the contents of the manifest file.
But, the initiator for loading manifest.webmanifest does not change and manifest is loaded from the primary domain.
This causes:
- DNS lookup
- new connecting
- new SSL,
or about 200 ms delay for loading manifest file.
If possible, include a cookie-free domain for loading manifest file,  when used - this will speed up the loading site.

Yes, manifest.webmanisfest is taking a lot time to load. What if we preconnect it in the header?

<!-- Webmanifest -->
<link href="https://domain.com/manifest.webmanifest/" rel="preconnect">

 

Link to post
Share on other sites
51 minutes ago, sobrenome said:

Yes, manifest.webmanisfest is taking a lot time to load. What if we preconnect it in the header?


<!-- Webmanifest -->
<link href="https://domain.com/manifest.webmanifest/" rel="preconnect">

 

I have now made the experiment you suggested.
On my site there is no difference in the different tests I made. Ie adding that doesn't make sense.
There will only be improvement for ISlow if IPS adds the link loading manifest to work with a cookies-free domain  as well.
Here is a picture of my test without this preconnect ( the same with preconnect).
But you pay attention - after many experiments and splitting of different templates, as well as finding the exact location of Google's code analytics, as well as a new script to delay loading images, after a time of "onload" - I have achieved maximum reconciliation in resources and acceleration loading site.

190570269_Screenshotat2020-04-18205402.thumb.png.7b69ce7acf082283b7a32add83375687.png

Link to post
Share on other sites
Just now, Adlago said:

Because

"<link rel="preconnect"> informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible."

So the only way to avoid the SSL handshake to webmanisfest is by cookie-free domain?

On 10/6/2019 at 6:00 AM, Colonel_mortis said:

I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead

My server seems to be correctly configured and I have the same loading delay with webmanifest SSL handshake:

URL: https://domain.com/manifest.webmanifest/
Host: domain.com
IP: 104.26.7.35
Error/Status Code: 200
Priority: LOW
Protocol: HTTP/2
HTTP/2 Stream: 1, weight 183, depends on 0, EXCLUSIVE
Request ID: 27319.111
Client Port: 46188
Discovered: 1.399 s
Request Start: 1.802 s
Initial Connection: 331 ms
SSL Negotiation: 68 ms
Time to First Byte: 58 ms
Content Download: 1 ms
Bytes In (downloaded): 0.3 KB
Uncompressed Size: 1.9 KB
Bytes Out (uploaded): 1.4 KB

 

Link to post
Share on other sites
4 minutes ago, sobrenome said:

So the only way to avoid the SSL handshake to webmanisfest is by cookie-free domain?

I think if IPS creates a cookies-free domain admission for manifest file, then it will improve the YSlow of the loading site, which will actually improve the overall loading speed of the site. And this is very tangible and important for mobile loading - which has recently been tolerated by all search engines, led by Google

Link to post
Share on other sites
1 hour ago, sobrenome said:

Hello @Adlago, have you tried 


crossorigin = "use-credentials"

to avoid another SSL handshake?

https://stackoverflow.com/questions/58937502/why-my-manifest-json-loading-require-new-ssl-handshake

If the manifest.json file is a real existing file in root, this will help.
But in the IPS suite, a manifest.json is created with this command

<link rel="manifest" href="{url='app=core&module=system&controller=metatags&do=manifest' seoTemplate='manifest'}">


ie it is not possible to use crossorigine directly, i. produces an error.

Link to post
Share on other sites

@Adlago if you replace the line you show with

<link rel="manifest" href="{url='app=core&module=system&controller=metatags&do=manifest' seoTemplate='manifest'}" crossorigin="use-credentials">

the new connection issue is solved.  (I tested this, and it solved the issue in my case.)

 

BTW, after start using SSL and HTTP/2, my tests (using RUM) showed that the use of cookie-free domains was only slightly beneficial when I was using a CDN.  Otherwise it was degrading performance, despite most of the synthetic tests (like YSlow and Webpagetest) giving better results.

This was before TLS 1.3 was available.  It is possible that with TLS 1.3 the results change.

Link to post
Share on other sites
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy