I'm a CloudFlare customer, and now I work for CloudFlare... I've been a customer for years and an employee for months. I too originally tried CloudFlare and le

I'm a CloudFlare customer, and now I work for CloudFlare... I've been a customer for years and an employee for months. I too originally tried CloudFlare and left, tried again and left again, before eventually trying it about 18 months ago and staying. I too run highly dynamic sites, the same as you a few were vBulletin forums and I also had a Django web app that has a login form on every page. In both cases the pages are not able to be cached. The vBulletin page has personalisation or CSRF tokens (login form) depending on your login state, and the Django web app CSRF tokens again act to prevent caching there. It is obvious to me now, as it is to you, that any asset (page in this case) that isn't cacheable is only resulting in an additional hop and the additional delay that introduces. The reason I eventually remained a customer is Railgun. Railgun is the missing link that allows dynamic content to be mostly cached with only the diff between requests passing over the wire between origin and CloudFlare. Dynamic content still isn't cacheable from the perspective of the origin or the end user, but Railgun doesn't send 99% of the page over the wire, just the diff (this is a simplistic explanation but works well enough for this). Railgun is the only thing that I personally felt took my highly dynamic sites and made them feel dramatically faster than going direct to the origin. It also works really well for APIs. Additionally, for vBulletin I'd recommend setting up a page rule so that your attachment.php file is aggressively cached. Especially if your vBulletin is configured to store attachments in the database as this will spare your database server. Of course, if you're running WordPress, Drupal, or a CMS designed to produce cacheable sites then Railgun isn't needed. CloudFlare does act like a silver bullet in those cases and by default the caching is very good and the speed improvement the end user experiences is dramatic. But for dynamic sites, Railgun and Page Rules help to get the best out of the service. Hmm, it may be worth us producing Knowledge Base articles for "gold configurations" for common web applications, or better still to provide some way for us to let you just tell us how you're using something like vBulletin so that we can configure some things for you and recommend the other things (Railgun) that will make a difference. On ISIS sites, it's likely true that amongst the millions of sites there are some that are probably related to terrorism, or to carders, or whatever else is unwelcome. We have a trust and safety team and of course they work with law enforcement and courts in all jurisdictions in which we operate. Our service is to protect customers from DDoS and other attacks, so to some extent yes we are a shield for our customers as we do protect origin servers. However any valid legal request from a court or law enforcement agency is respected. That's the way to have something removed, not a subjective policy applied in a non-transparent way by a private company.