Serving static content from a different domain (not subdomain)

{redacted} Hello,

Reading your terms of use (mainly part 2.8), I’m not sure if we can serve static content from a separate domain, which is our case. We have a separate domain which only contains our static and media files (js, css, jpg, png, svg, …). It’s not a real CDN, we just went for a completely separate domain to make the transition easier if we need to migrate to a real CDN sometimes later on. The “cdn” domain points to the exact same IP address as our main domain, and it’s actually the exact same server serving all of our static content. Would it be possible to make this kind of setup with CloudFlare? We would also put our main domain under CloudFlare although it’s only serving dynamic (HTML) content, but CloudFlare would still help us with optimised traffic routing, and we also understand it’s necessary to comply with your terms.

I can’t seem to find an answer to this question, so I’d really appreciate any kind of help. Does anyone else use this kind of setup? Should I just add those 2 domains to our CloudFlare account and configure them separately? I know it’s possible to set up serving static content from a different subdomain, but I’m not sure if this also works with a completely different domain. The domain name is just the name of our main domain suffixed by cdn, so it’s ***cdn.com where we have static.***cdn.com and media.***cdn.com.

Any help would he appreciated, thanks in advance!

Short answer - yes.

Therefore you could, hm, not the best scenario, to use a CNAME and point it to other domain to load resources, hopefully the cached “by default” (Cache Level: Standard).

  • if using the same domain, better to just create an A sub-domain record …

If I may post my experience(s) and my examples here:

  1. I used the same domain but as a sub-domain like static.mydomain.com or cdn.mydomain.com - all on the same origin host / server.
    Just, for that specific sub-domain, I configured Cache Level: Cache Everything using a Page Rule just in case (actually not needed as there were CSS, JS, images and fonts mostly which are cached by default with the Cache Level: Standard option).

  2. Other example, where I use(d) Google Cloud Storage bucket, where I uploaded my files (again - the CSS, JS, images, fonts) and I have had a CNAME record setup and proxied (:orange:) sub-domain like static.mydomain.com which was pointed to that Google Cloud Storage bucket, with the Page Rule for that sub-domain hostname containing the Cache Level: Cache Everything option and Edge Cache TTL set to maximum to spare traffic as far as the GCS costs per GB egress to different regions on download). That way, everything is being cached at Cloudflare Edge and served by Cloudflare (no need to go to the GCS Bucket for each request).

    • instead of a GCS bucket, you can try to use some other like BackBlaze B2, Amazon, or some third one, if it allows you to use it and setup like that …

In both cases of course, the Full (Strict) SSL working and the resources being cached at Cloudflare and served through it to the end-users (visitors) of my Website(s).

I believe, it could handle 10.000s of thousands of images due to WordPress Website(s) containing files for the published news, etc. at least what I have used so far this kind of a setup (for testing and development purposes).

1 Like

Thank you very much for your reply @fritexvz!

In our case, if we wanted to move it under the same domain (just a separate subdomain), it would be actually pretty simple. We could just tell nginx to serve these files on these subdomains directly from the filesystem, as it’s all located on the same server. But we’d highly prefer having it on a completely separate domain if that’s possible.

So what’s I’m curious about is if that’s allowed. To add 2 separate domains in our account and continue having it separated. The terms of service could also be interpreted in a way which makes it forbidden, because it’s basically a different “site” for which we would just be serving the static content without any HTML at all. So I’m a bit worried if we won’t be banned because of this.

In your cases it seems like you were always serving your static content from the same domain, which is completely complying with the terms of service.

But on the same or different server?

Just to add here, keep in mind any CORS related (also the Access-Control-Allow-Origin) or CSP Policy (if you use it) in between as far as loading fonts from one domain to another could cause some issues of not loading the resources.

Yeah, yeah, but your developers were so preoccupied with whether or not they could that they didn’t stop to think if they should.

Back in the day, the YSlow guidance said you should use a cookie free domain. That is definitely not the case any more. You will get better performance from a single hostname, you eliminate cross origin issues, and HTTP2 multiplexing will significantly improve user experience.

Why?

2 Likes

On the same server, different domain.

Yes, the website is already running in the mentioned configuration, so we already had to resolve these issues.

There are multiple reasons. Having the static content just on a different subdomain wouldn’t help with HTTP2 multiplexing and cross origin issues, and having it on the same domain and subdomain as our dynamic content also wouldn’t help because we’re serving the static content on pages from multiple subdomains (e.g. blog, forum, …). And the main reason for having it on a completely separate domain is that we’re using Quantcast for consent, and they’re setting HUGE cookies on *.domain.com, so we don’t want the cookies in these requests.

@MoreHelp please. Can I use a separate (second level) domain for serving static content of a website? Would this still be allowed by the terms of service (2.8)? I would need to create a separate site in our account to do this, so I’m not sure if it’s allowed to have this separated. I would also add the main domain (dynamic HTML content) under CloudFlare.

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