Adlago Posted October 3, 2019 Share Posted October 3, 2019 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 voron121 and sobrenome 2 Link to comment Share on other sites More sharing options...
Colonel_mortis Posted October 6, 2019 Share Posted October 6, 2019 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. sobrenome and voron121 2 Link to comment Share on other sites More sharing options...
Dll Posted October 6, 2019 Share Posted October 6, 2019 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. voron121, sobrenome and ptprog 2 1 Link to comment Share on other sites More sharing options...
Adlago Posted October 6, 2019 Author Share Posted October 6, 2019 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 sobrenome 1 Link to comment Share on other sites More sharing options...
Adlago Posted October 6, 2019 Author Share Posted October 6, 2019 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. sobrenome 1 Link to comment Share on other sites More sharing options...
Dll Posted October 6, 2019 Share Posted October 6, 2019 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. sobrenome 1 Link to comment Share on other sites More sharing options...
Adlago Posted October 6, 2019 Author Share Posted October 6, 2019 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. sobrenome 1 Link to comment Share on other sites More sharing options...
Dll Posted October 7, 2019 Share Posted October 7, 2019 (edited) You really need to think more about real users rather than just online test results. Edited October 7, 2019 by Dll DawPi, sobrenome, opentype and 2 others 5 Link to comment Share on other sites More sharing options...
Lucas James Posted October 7, 2019 Share Posted October 7, 2019 @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? sobrenome 1 Link to comment Share on other sites More sharing options...
Ryan Ashbrook Posted October 7, 2019 Share Posted October 7, 2019 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). Dll and sobrenome 2 Link to comment Share on other sites More sharing options...
Adlago Posted October 7, 2019 Author Share Posted October 7, 2019 (edited) 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 October 7, 2019 by Adlago sobrenome 1 Link to comment Share on other sites More sharing options...
sobrenome Posted April 18, 2020 Share Posted April 18, 2020 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 comment Share on other sites More sharing options...
Adlago Posted April 18, 2020 Author Share Posted April 18, 2020 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. sobrenome 1 Link to comment Share on other sites More sharing options...
sobrenome Posted April 18, 2020 Share Posted April 18, 2020 Why preconnect is not working for webmanifest? Link to comment Share on other sites More sharing options...
Adlago Posted April 18, 2020 Author Share Posted April 18, 2020 5 minutes ago, sobrenome said: Why preconnect is not working for webmanifest? 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." sobrenome 1 Link to comment Share on other sites More sharing options...
sobrenome Posted April 18, 2020 Share Posted April 18, 2020 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 comment Share on other sites More sharing options...
Adlago Posted April 18, 2020 Author Share Posted April 18, 2020 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 sobrenome 1 Link to comment Share on other sites More sharing options...
sobrenome Posted April 26, 2020 Share Posted April 26, 2020 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 ptprog 1 Link to comment Share on other sites More sharing options...
Adlago Posted April 26, 2020 Author Share Posted April 26, 2020 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 comment Share on other sites More sharing options...
ptprog Posted May 2, 2020 Share Posted May 2, 2020 @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 comment Share on other sites More sharing options...
Recommended Posts