Perhaps a silly idea / question, but could browsers support some kind of an optimization meta tag that tells to fetch the resource without sending cookies? something like `<img src="..." data-no-cookies=true>` or even a directive that applies to all static resources unless specified otherwise, e.g. `<meta no-cookies-for="jpg;css;js">` ??
In HTTP/2 (SPDY) the only headers that need to be sent are ones that changed since the last request on the connection. So once that is more common you'll actually be better off just attaching the cookies to all requests since that will mean they only get sent once per TCP connection.
I've been suggesting a move towards HTTPS only (for security) with SPDY/HTTP2 support.. for my own usage, 2/3 of the clients support SPDY... so having more resources from the initial domain is a better win.. with PUSH resources for CSS/JS with initial connection it gets better still.
If ES6 (including modules) were supported in browser, it would be pretty awesome as an addition to SPDY... I think we're reasonably 5-6 years off before any broadly available sites can really use it, but it's cool. Similar compared to Web Sockets a few years back.
Given that a lot of interactive data is now pushed to dedicated API services, and images are offloaded for CDN, it's far easier to deliver CSS and JS with the markup on the same deployment(s).
Comments
Perhaps a silly idea / question, but could browsers support some kind of an optimization meta tag that tells to fetch the resource without sending cookies? something like `<img src="..." data-no-cookies=true>` or even a directive that applies to all static resources unless specified otherwise, e.g. `<meta no-cookies-for="jpg;css;js">` ??
In HTTP/2 (SPDY) the only headers that need to be sent are ones that changed since the last request on the connection. So once that is more common you'll actually be better off just attaching the cookies to all requests since that will mean they only get sent once per TCP connection.
I've been suggesting a move towards HTTPS only (for security) with SPDY/HTTP2 support.. for my own usage, 2/3 of the clients support SPDY... so having more resources from the initial domain is a better win.. with PUSH resources for CSS/JS with initial connection it gets better still.
If ES6 (including modules) were supported in browser, it would be pretty awesome as an addition to SPDY... I think we're reasonably 5-6 years off before any broadly available sites can really use it, but it's cool. Similar compared to Web Sockets a few years back.
Given that a lot of interactive data is now pushed to dedicated API services, and images are offloaded for CDN, it's far easier to deliver CSS and JS with the markup on the same deployment(s).