Serving static assets using cookie-free domain

When running a YSlow report, I get a suggestion to use cookie-free domains. It then lists the assets that are not cookie-free - which are mostly js and css. The cookies are adding to the page load time. I have the CDN set up (Google) along with SSL.

I could set up a storage bucket (under a subdomain) with all the static assets, but is there a more efficient/better way?

Thanks!

That report is giving an outdated advice, there is no need to serve static assets in cookie free domains when using HTTP 2.

YSlow last commit was over 5 years ago.

5 Likes

Thanks for that @Falco!

@Falco while we are on HTTP/2, do you know if Discourse uses multiplexing connections and server push to serve assets?

This doubly does not matter because if you use a CDN the CDN domain will (or at least easily can be) cookieless.

2 Likes

Well, yes. I don’t see a way to use HTTP/2 and not do that. It’s the most important feature of the protocol!

I did write a plugin and a change to core to enable this. As it’s not available in nginx, you need to add another thing in the stack, be it a CDN with push (Fastly, Cloudflare) or a more modern reverse proxy (Caddy, H20).

But my benchmarks showed a negligible difference in the page render time, and if you add the fact that is isn’t cache aware (only H20 has a workaround on that) it’s pretty bad.

I’m hopeful that with the RFC 8297 this will be better as you won’t wait for all middleware to do their thing before returning with the homework for the user agent, but that RFC didn’t get much attention so far.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.