Jump to content

Community

Adlago

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

Share this post


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.

Share this post


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. 

 

 

Share this post


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

Share this post


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

Share this post


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. 

Share this post


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.

Share this post


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?

Share this post


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).

Share this post


Link to post
Share on other sites
Posted (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 by Adlago

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...