Although this particular case is related to Usage-Based Billing, I believe this is a more general question about whether or not it is allowed to share the resources of one domain with others, considering that others will make indirect use of Cloudflare’s features from the first one.
Problem
A customer wants to enable Argo for various websites in order to improve the TTFB for pages not cached in the edge, but couldn’t pay the bill if it was globally enabled due to the bandwidth consumed by media files.
Workaround
Since it isn’t possible to selectively enable Argo only for certain hostnames or paths, we are considering separating media files from all websites into a dedicated domain.
Necessary changes
Before:
website3.com/photos/floripa.jpg
After:
website3-com.media-domain.net/photos/floripa.jpg
Expected benefits
Possibility to enable Argo for all websites, since their domains would respond only to the requests for page (.html) and layout (.js, .css, .svg, …) files, wich consume less bandwidth;
Flexibility to optimize the media domain through hosting and Cloudflare specific settings;
Result
Website pages that were not cached in the edge would be loaded faster thanks to the TTFB improvements that would be provided by the Argo Smart Routing feature;
Media files would continue to be served optimally since the media domain would also make use of the Cloudflare Pro Plan, providing all the features inherent in it.
Question
What does Cloudflare think about this practice? Could it violate the Terms of Service?
(I am neither a Cloudflare employee, nor a lawyer.)
I cannot see how this would violate the Terms of Service. The TOS relates to an Account, not a domain. You are still going to serve the same volume of content, and not use the service as a hosting provider for media, video etc.
It used to be a well documented best-practice to serve assets through a different domain to the HTML, so what you are proposing to do is not unusual. The traditional reason was that the asset hostname was cookie-free, therefore saving a few bytes in each request.
We (as an small agency) also thought about providing a centralized media domain to our customers so they could opt for the above solution without having to acquire new domains (which would also facilitate our efforts to maintain it). However this could fit as a hosting service and would probably infringe the TOS. - Right?
Same disclaimer as @michael above. Not a CF employee, nor a lawyer. As I am an MVP I have been here for a while though.
I can tell that very rarely I have seen domains pushed out due to TOS violations of that kind, especially if paying (Argo) or on a plan above the Free one.
You could also reduce the actual caching length or prevent it at all in case.
If you go this route I would strongly recommend going for the Business plan which would allow the almost certainty of all POPs everywhere, improving performances a bunch in some areas (this can depend on your market though).
Thanks for sharing! This makes us much more confident in delivering the solution.
Unfortunately we couldn’t afford a Business Plan yet. As an initial solution, we would consider a gTLD with the Pro Plan, which would allow us to cover all our customers who need this kind of setup. We hope this is not an impediment to getting started.
Most definitely no. I don’t really know what benefit you would get from the Pro plan if you are simply hosting content. Pro plan gets WAF (useless for only static files), HTTP/2 prioritization (no HTML, JS, CSS, right?).
Improvements would be better SSL support (get the 5$/month dedicated cert), finer Analytics (this is cool and helpful) and better support reply time.
… preventing unwanted requests from reaching and consuming your resources:
WAF (Access);
Firewall Rules (More);
Managed Rules (Access);
User Agent Blocking Rules (More);
I fully agree with Analytics and Support, but can’t understand the Dedicated SSL benefits.
Some time ago I opened a ticket asking about the difference between Universal SSL and Dedicated SSL ($5) and the support told me it was just the fact that the second display the hostname of the website instead of ssl123456789.Cloudflaressl.com.
If this is the only difference, I believe it would be indifferent to a domain serving only static files, since the end user will never see this information.
The difference exists only on the lower tier plan, the free one, that as far as I know has less support for older browsers. Agreed that users don’t normally see it, it doesn’t really matter. Only for higher browser support in case.
