6 ms·

CloudFlare's New Dashboard

80 points by TimWolla 11y ago

thejameskyle 11y ago
Hi, I'm one of the engineers who worked on this new dashboard. If anyone has a question, feel free to ask me here :)
- SEJeff 11y ago
  Is it written in go, like most cloudflare things?
  - philip1209 11y ago
    As far as I understand, it's still in PHP.
  - thejameskyle 11y ago
    The WWW API is written in PHP which interacts with a lot of Go codebases elsewhere in CF. We're going to be publishing more engineering-related blog posts about the new dashboard in the coming days/weeks.
    - MichaelGG 11y ago
      Out of curiosity, why PHP?
      - thejameskyle 11y ago
        The API hasn't been completely rewritten like the front-end. It was already in PHP and so it stayed in PHP.
- rhc2104 11y ago
  Have you guys considered A/B testing different parts of the new design to figure out which parts of the new design are more effective?
- deleted 11y ago
  [deleted]
  - jbergknoff 11y ago
    "less usable than before" -- this is completely the opposite of my experience. Kudos to cloudflare for ditching the dysfunctional infinite scroll.
  - corobo 11y ago
    Forgive me for coming off as a jerk but I think you might be getting phased out of the comments as your site - at least the one pulled from your comment - is not amazingly designed for a UX/UI person. You're using #666 text on a black background on an almost too-minimal design, which is really hard to read even as someone that doesn't have much trouble in the vision department. Do you have any other sources of work to sell yourself a bit better on the design credibility side? You're also using a heck of a lot of hashtags on the page that aren't even links, what's behind that?
- TimWolla 11y ago
  What is this 'Shared Accounts'? Can one link an organization account to a personal account in the future, instead of sharing a password?
  - thejameskyle 11y ago
    We support having multiple users within an organization account, we're publishing a blog post about it later this week.
- manigandham 11y ago
  I actually just sent in a suggestion/support ticket last week but here's what I think would be an improvement: Right now the page rules system seems like an added feature but I think it should be the heart of the settings system. When a new site is created, it would be logical to just create a default page rule that covers everything like "example.com/*" Each rule can have a summary of settings as they do now and all the other separate pages can go away. Speed, Caching and ScrapeShield can just be settings for each rule instead of full pages. It'd be a lot faster to manage settings this way and more natural to view a site's settings as a cascading set of rules with their own configuration. Likewise, Traffic can probably just be made another tab under Firewall. Hope that makes sense.
  - terinjokes 11y ago
    We're working internally on a number of different ways of how to integrate Page Rules better into the user interface, include a few ideas on these lines.
  - rdl 11y ago
    Traffic actually originally was underneath Firewall, but Traffic will expand to other kinds of traffic/log related data in the future, so we decided to break it out now. (i.e. this is the 1.0 release...we have a LOT of stuff planned for the next months in various areas)
Caelish 11y ago
Does anyone else feel like this is a downgrade in terms of actual usability? I might just not be used to it yet, but I'm finding it takes a lot more clicks to get things done on the new dashboard. The dock of apps seems cluttered to me. Maybe it'll grow on me, but I'm not a huge fan of it at the moment. Since there's not a lot of images of the full dashboard page in the article, I made two quick additional screenshots to compare the two. [1] [1] https://imgur.com/a/bnx8j https://imgur.com/a/bnx8j
- rdl 11y ago
  Are you talking mainly about making changes across a bunch of sites in the same account?
  - Caelish 11y ago
    I suppose so, yes; I very often use the dashboard specifically to do that. I think part of it is just that I'm not used to the new one yet - it takes time to find options which I could previously find more easily - but at the same time, if I want to put a bunch of sites into development mode to name one example, I now need to individually go into each specific domain's page, click the "caching" nav icon, and change it there. I feel like it essentially takes a single page two-click mechanism and changes it to a three-click mechanism across multiple pages that forces me to think about where I'm going much more than previously.
    - rdl 11y ago
      Groups, bulk actions, etc. are something we're looking at. There's also a full API, so you can actually automate a lot of bulk actions (probably not so useful to end users, but if you have a lot of sites it might be worth it, and there could easily be tools.)
      - Caelish 11y ago
        Yeah, I'm at that weird spot where I need to do bulk actions often enough to be bothered by losing them, but not often enough to justify figuring the API out. Appreciate the reply though, definitely glad it's being looked at :)
randomdrake 11y ago
We've been using Cloudflare for over a year now and couldn't be happier. I've recommended them to numerous friends and every one of them couldn't be happier. The value is simply tremendous and these changes make their offerings even that much more amazing. The dashboard, while useful, always felt like it was put together rapidly to integrate a bunch of disparate parts of such a huge service like Cloudflare. Compared to the incredible service offerings, the dashboard was not one of the best parts of Cloudflare. Some data points were a bit off, some charts didn't work quite right, and you had to hop in and out of various parts of Cloudflare to get things done. Some stuff in settings, over there, some stuff in the charts over there, some stats here, but not there. Now, the dashboard is just as amazing as the service. Kudos to the overall implementation of the information architecture and user desires for the service. What a tremendous upgrade to an already valuable offering. All of the important settings and information are now within arm's reach and easy to find. The new charts, stats, and graphs are absolutely amazing and insightful without being frivolous. There's much more detail and new data to work with. The responsiveness of the dashboard itself has also increased a huge amount, which I'm sure was no small technical feat. Very well done to all involved. I can feel even more comfortable continuing to recommend Cloudflare. Excited to read the followups on how they managed to create such a different and successful overhaul to the main window into their service.
thisishugo 11y ago
I've been using the beta of this dashboard for about a month now and I've been really pleased with how much faster it is to use, and how much more helpful information is placed in-line in the new design - most "wtf does this button do?" questions can be answered without opening the Cloudflare docs in another tab. I'm only using the free plan with ~20 domains so I can't speak to what it's like as a "proper" user, but for my purposes the new interface is a clear improvement. Also, the responsiveness of the development team to feedback has been very positive; every issue I've raised was responded too quickly and clearly (even pedantic niggles[0]). [0] But seriously, what algorithm is the domain list sorted with? It's a total mystery, please fix it.
adwf 11y ago
This is a big improvement for me. The inline help in particular is much better than the previous links to the knowledge base.
glesica 11y ago
Why not use more of the screen width? It's not the worst refresh ever, but it feels like everything shrunk. Or maybe I'm just getting old and grumpy. Overall, CF is still amazing and it's not like I have to use the dashboard daily, so whatever.
fineline 11y ago
Hey, you trendy designers, engineers worked hard to implement border-radius! But seriously though, nice work on the reorg, and the inline help and responsive on mobile rocks. Well done!
exelius 11y ago
I've always wondered about how companies handle increasing complexity of their user base. One route is to do what CloudFlare has done: create the "pro" UI where you have every setting imaginable across multiple namespaces. Another is to simply make an API for everything and let your customers implement their own UI (usually integrating your product with the 15 other vendors they probably use). I'm increasingly in favor of the second approach. A pro-user UI is great, but most of your customers who are complex enough to need a truly pro interface would be better served by an API. That was honestly the revolution that Amazon brought to the infrastructure space: they had an API you could use to provision... Well, anything. So IMO the API is the new expert mode. There are just too many platforms out there (AWS, CloudFlare, Akamai, etc) that are often used in tandem that a vendor-provided interface will never be enough for the most advanced users.
- thedg 11y ago
  Or you could do both. Here are our api docs. The new dashboard is built on this version of the api. https://api.cloudflare.com/ https://api.cloudflare.com/
- kijin 11y ago
  I disagree. Going API-only for the advanced features might be okay for something like AWS, but it will alienate a lot of users for the vast majority of online services out there. CloudFlare is not just for highly experienced programmers who can whip up a Ruby script to do whatever they want. A large percentage of their customers are probably just average "webmasters" who are using CloudFlare to improve security and page load times for their WordPress sites and whatnot. They're comfortable with clicking around the website to get the result they want, but if you just gave them an API and some npm packages to access it, it would take them several hours to get the same thing done. They might do better the next time, but if that initial friction hurts CloudFlare's conversion rate, why bother? We've been seeing the same problem for several years already with *nix desktop environments and applications. Some rockstar programmers and designers collectively decided that they'll optimize the graphical UI for newbies and hide all advanced features in a bunch of manually editable config files, command-line flags, or (heaven forbid) the source code itself. Result: newbies are happy because the UI is simple and streamlined. Advanced users are happy because they can still do what they want to do. But a lot of semi-advanced, I'm-still-learning users in the middle of the bell curve are pissed off because they see no reason why they shouldn't be able to use a mouse to get work done. And since we're talking about a bell curve, that's a lot of pissed-off users. Many people here on HN have warm fuzzy feelings toward the concept of mashing keyboards all day long. The rest of the business world, on the other hand, is still very attached to the mouse. They're like, "Duh, why would you write <foo bar="yes" /> when you can just click on 'Yes'?"
voltagex_ 11y ago
OT: where can I learn to build (HTML) UIs like this?
snowplay 11y ago
We too have been a very satisfied Cloudflare user. Although analytics is not the reason we use Cloudflare, it's interesting to note that in their new analytics, the primary metric for measuring traffic has changed from page views to requests. Since Cloudflare is the source of serving the pages, it seems like it would have the greatest opportunity for capturing accurate pageview counts. I wonder what the story is behind the change.
- dangrossman 11y ago
  Any client-side analytics you set up by hand would have a greater opportunity for capturing accurate pageview counts. A proxy or host like Cloudflare can only guess, based on things like content-type headers and file extensions, which requests are page views. Most requests are not; they're resources needed to build the page like images and stylesheets, AJAX responses, API requests, etc. A copy of Google Analytics you put into a header/footer template, so it only gets served once per page when actual clients load a whole page, has a better idea of how many page views are happening.
  - manigandham 11y ago
    This is actually the reason why CloudFlare has better analytics. Their system is more advanced than a regular reverse proxy and they can tell what requests are actually pageviews based on the HTML loaded. Client-side stuff is unreliable and is open to everything from javascript blockers to network connections in the middle. CloudFlare even had a post about how their tracking was better (cant find it now). EDIT: Yes I know newer ajax sites are completely different and there's probably no perfectly accurate way to track them unless the devs setup analytics properly, and even then its up to the same issues all client-side tracking faces.
chrissnell 11y ago
I'm so over Cloudflare. I've tried their service twice: The first time, I used a demo account at their Enterprise service level and compared it to our existing CDN (Akamai). Our page load times increased across the board. When I asked them about implementing the L7 customizations that we have in our Akamai setup, I was told that it would take custom development and that we would have to pay for it--stuff that we were able to implement at Akamai using their XML configuration. Akamai is not an awesome company to work with and the XML configuration format is a nightmare but the service is fast and we didn't need custom dev work to get it running. The second time I tried Cloudflare was a few months ago for a personal project. I run a moderately popular vBulletin forum in my spare time and I wanted to see if CF could speed up my site. The results were similar--Cloudflare actually slowed things down. I was at the free tier and perhaps I would have seen improvement at the $200/mo plan with Railgun but I wasn't going to waste any more time to find out. The nail in the coffin was when I discovered that they provided CDN services to ISIS propaganda sites and openly oppose any efforts to shut down the sites. I'm all for freedom of expression on the internet and it's certainly their right to support the distribution of jihadi videos featuring the beheading innocent aid workers but I'm not going to support it with my money.
- blfr 11y ago
  What kind of customizations do you use?
- buro9 11y ago
  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.
jdubs 11y ago
Great work. A huge step in the right direction!! As a long time user of the "new" dashboard I would love to see a way to version control my cloud flare configuration for a domain. The team and I are always scared of pushing the wrong button due to the lack of confirmation buttons.

80 points by TimWolla 11y ago

thejameskyle 11y ago

Hi, I'm one of the engineers who worked on this new dashboard. If anyone has a question, feel free to ask me here :)

SEJeff 11y ago
Is it written in go, like most cloudflare things?
- philip1209 11y ago
  As far as I understand, it's still in PHP.
- thejameskyle 11y ago
  The WWW API is written in PHP which interacts with a lot of Go codebases elsewhere in CF. We're going to be publishing more engineering-related blog posts about the new dashboard in the coming days/weeks.
  - MichaelGG 11y ago
    Out of curiosity, why PHP?
    - thejameskyle 11y ago
      The API hasn't been completely rewritten like the front-end. It was already in PHP and so it stayed in PHP.
rhc2104 11y ago
Have you guys considered A/B testing different parts of the new design to figure out which parts of the new design are more effective?
deleted 11y ago
[deleted]
- jbergknoff 11y ago
  "less usable than before" -- this is completely the opposite of my experience. Kudos to cloudflare for ditching the dysfunctional infinite scroll.
- corobo 11y ago
  Forgive me for coming off as a jerk but I think you might be getting phased out of the comments as your site - at least the one pulled from your comment - is not amazingly designed for a UX/UI person. You're using #666 text on a black background on an almost too-minimal design, which is really hard to read even as someone that doesn't have much trouble in the vision department. Do you have any other sources of work to sell yourself a bit better on the design credibility side? You're also using a heck of a lot of hashtags on the page that aren't even links, what's behind that?
TimWolla 11y ago
What is this 'Shared Accounts'? Can one link an organization account to a personal account in the future, instead of sharing a password?
- thejameskyle 11y ago
  We support having multiple users within an organization account, we're publishing a blog post about it later this week.
manigandham 11y ago
I actually just sent in a suggestion/support ticket last week but here's what I think would be an improvement: Right now the page rules system seems like an added feature but I think it should be the heart of the settings system. When a new site is created, it would be logical to just create a default page rule that covers everything like "example.com/*" Each rule can have a summary of settings as they do now and all the other separate pages can go away. Speed, Caching and ScrapeShield can just be settings for each rule instead of full pages. It'd be a lot faster to manage settings this way and more natural to view a site's settings as a cascading set of rules with their own configuration. Likewise, Traffic can probably just be made another tab under Firewall. Hope that makes sense.
- terinjokes 11y ago
  We're working internally on a number of different ways of how to integrate Page Rules better into the user interface, include a few ideas on these lines.
- rdl 11y ago
  Traffic actually originally was underneath Firewall, but Traffic will expand to other kinds of traffic/log related data in the future, so we decided to break it out now. (i.e. this is the 1.0 release...we have a LOT of stuff planned for the next months in various areas)

Caelish 11y ago

Does anyone else feel like this is a downgrade in terms of actual usability? I might just not be used to it yet, but I'm finding it takes a lot more clicks to get things done on the new dashboard. The dock of apps seems cluttered to me. Maybe it'll grow on me, but I'm not a huge fan of it at the moment. Since there's not a lot of images of the full dashboard page in the article, I made two quick additional screenshots to compare the two. [1] [1] https://imgur.com/a/bnx8j https://imgur.com/a/bnx8j

rdl 11y ago
Are you talking mainly about making changes across a bunch of sites in the same account?
- Caelish 11y ago
  I suppose so, yes; I very often use the dashboard specifically to do that. I think part of it is just that I'm not used to the new one yet - it takes time to find options which I could previously find more easily - but at the same time, if I want to put a bunch of sites into development mode to name one example, I now need to individually go into each specific domain's page, click the "caching" nav icon, and change it there. I feel like it essentially takes a single page two-click mechanism and changes it to a three-click mechanism across multiple pages that forces me to think about where I'm going much more than previously.
  - rdl 11y ago
    Groups, bulk actions, etc. are something we're looking at. There's also a full API, so you can actually automate a lot of bulk actions (probably not so useful to end users, but if you have a lot of sites it might be worth it, and there could easily be tools.)
    - Caelish 11y ago
      Yeah, I'm at that weird spot where I need to do bulk actions often enough to be bothered by losing them, but not often enough to justify figuring the API out. Appreciate the reply though, definitely glad it's being looked at :)

randomdrake 11y ago

We've been using Cloudflare for over a year now and couldn't be happier. I've recommended them to numerous friends and every one of them couldn't be happier. The value is simply tremendous and these changes make their offerings even that much more amazing. The dashboard, while useful, always felt like it was put together rapidly to integrate a bunch of disparate parts of such a huge service like Cloudflare. Compared to the incredible service offerings, the dashboard was not one of the best parts of Cloudflare. Some data points were a bit off, some charts didn't work quite right, and you had to hop in and out of various parts of Cloudflare to get things done. Some stuff in settings, over there, some stuff in the charts over there, some stats here, but not there. Now, the dashboard is just as amazing as the service. Kudos to the overall implementation of the information architecture and user desires for the service. What a tremendous upgrade to an already valuable offering. All of the important settings and information are now within arm's reach and easy to find. The new charts, stats, and graphs are absolutely amazing and insightful without being frivolous. There's much more detail and new data to work with. The responsiveness of the dashboard itself has also increased a huge amount, which I'm sure was no small technical feat. Very well done to all involved. I can feel even more comfortable continuing to recommend Cloudflare. Excited to read the followups on how they managed to create such a different and successful overhaul to the main window into their service.

thisishugo 11y ago

I've been using the beta of this dashboard for about a month now and I've been really pleased with how much faster it is to use, and how much more helpful information is placed in-line in the new design - most "wtf does this button do?" questions can be answered without opening the Cloudflare docs in another tab. I'm only using the free plan with ~20 domains so I can't speak to what it's like as a "proper" user, but for my purposes the new interface is a clear improvement. Also, the responsiveness of the development team to feedback has been very positive; every issue I've raised was responded too quickly and clearly (even pedantic niggles[0]). [0] But seriously, what algorithm is the domain list sorted with? It's a total mystery, please fix it.

adwf 11y ago

This is a big improvement for me. The inline help in particular is much better than the previous links to the knowledge base.

glesica 11y ago

Why not use more of the screen width? It's not the worst refresh ever, but it feels like everything shrunk. Or maybe I'm just getting old and grumpy. Overall, CF is still amazing and it's not like I have to use the dashboard daily, so whatever.

fineline 11y ago

Hey, you trendy designers, engineers worked hard to implement border-radius! But seriously though, nice work on the reorg, and the inline help and responsive on mobile rocks. Well done!

exelius 11y ago

I've always wondered about how companies handle increasing complexity of their user base. One route is to do what CloudFlare has done: create the "pro" UI where you have every setting imaginable across multiple namespaces. Another is to simply make an API for everything and let your customers implement their own UI (usually integrating your product with the 15 other vendors they probably use). I'm increasingly in favor of the second approach. A pro-user UI is great, but most of your customers who are complex enough to need a truly pro interface would be better served by an API. That was honestly the revolution that Amazon brought to the infrastructure space: they had an API you could use to provision... Well, anything. So IMO the API is the new expert mode. There are just too many platforms out there (AWS, CloudFlare, Akamai, etc) that are often used in tandem that a vendor-provided interface will never be enough for the most advanced users.

thedg 11y ago
Or you could do both. Here are our api docs. The new dashboard is built on this version of the api. https://api.cloudflare.com/ https://api.cloudflare.com/
kijin 11y ago
I disagree. Going API-only for the advanced features might be okay for something like AWS, but it will alienate a lot of users for the vast majority of online services out there. CloudFlare is not just for highly experienced programmers who can whip up a Ruby script to do whatever they want. A large percentage of their customers are probably just average "webmasters" who are using CloudFlare to improve security and page load times for their WordPress sites and whatnot. They're comfortable with clicking around the website to get the result they want, but if you just gave them an API and some npm packages to access it, it would take them several hours to get the same thing done. They might do better the next time, but if that initial friction hurts CloudFlare's conversion rate, why bother? We've been seeing the same problem for several years already with *nix desktop environments and applications. Some rockstar programmers and designers collectively decided that they'll optimize the graphical UI for newbies and hide all advanced features in a bunch of manually editable config files, command-line flags, or (heaven forbid) the source code itself. Result: newbies are happy because the UI is simple and streamlined. Advanced users are happy because they can still do what they want to do. But a lot of semi-advanced, I'm-still-learning users in the middle of the bell curve are pissed off because they see no reason why they shouldn't be able to use a mouse to get work done. And since we're talking about a bell curve, that's a lot of pissed-off users. Many people here on HN have warm fuzzy feelings toward the concept of mashing keyboards all day long. The rest of the business world, on the other hand, is still very attached to the mouse. They're like, "Duh, why would you write <foo bar="yes" /> when you can just click on 'Yes'?"

voltagex_ 11y ago

OT: where can I learn to build (HTML) UIs like this?

snowplay 11y ago

We too have been a very satisfied Cloudflare user. Although analytics is not the reason we use Cloudflare, it's interesting to note that in their new analytics, the primary metric for measuring traffic has changed from page views to requests. Since Cloudflare is the source of serving the pages, it seems like it would have the greatest opportunity for capturing accurate pageview counts. I wonder what the story is behind the change.

dangrossman 11y ago
Any client-side analytics you set up by hand would have a greater opportunity for capturing accurate pageview counts. A proxy or host like Cloudflare can only guess, based on things like content-type headers and file extensions, which requests are page views. Most requests are not; they're resources needed to build the page like images and stylesheets, AJAX responses, API requests, etc. A copy of Google Analytics you put into a header/footer template, so it only gets served once per page when actual clients load a whole page, has a better idea of how many page views are happening.
- manigandham 11y ago
  This is actually the reason why CloudFlare has better analytics. Their system is more advanced than a regular reverse proxy and they can tell what requests are actually pageviews based on the HTML loaded. Client-side stuff is unreliable and is open to everything from javascript blockers to network connections in the middle. CloudFlare even had a post about how their tracking was better (cant find it now). EDIT: Yes I know newer ajax sites are completely different and there's probably no perfectly accurate way to track them unless the devs setup analytics properly, and even then its up to the same issues all client-side tracking faces.

chrissnell 11y ago

I'm so over Cloudflare. I've tried their service twice: The first time, I used a demo account at their Enterprise service level and compared it to our existing CDN (Akamai). Our page load times increased across the board. When I asked them about implementing the L7 customizations that we have in our Akamai setup, I was told that it would take custom development and that we would have to pay for it--stuff that we were able to implement at Akamai using their XML configuration. Akamai is not an awesome company to work with and the XML configuration format is a nightmare but the service is fast and we didn't need custom dev work to get it running. The second time I tried Cloudflare was a few months ago for a personal project. I run a moderately popular vBulletin forum in my spare time and I wanted to see if CF could speed up my site. The results were similar--Cloudflare actually slowed things down. I was at the free tier and perhaps I would have seen improvement at the $200/mo plan with Railgun but I wasn't going to waste any more time to find out. The nail in the coffin was when I discovered that they provided CDN services to ISIS propaganda sites and openly oppose any efforts to shut down the sites. I'm all for freedom of expression on the internet and it's certainly their right to support the distribution of jihadi videos featuring the beheading innocent aid workers but I'm not going to support it with my money.

blfr 11y ago
What kind of customizations do you use?
buro9 11y ago
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.

jdubs 11y ago

Great work. A huge step in the right direction!! As a long time user of the "new" dashboard I would love to see a way to version control my cloud flare configuration for a domain. The team and I are always scared of pushing the wrong button due to the lack of confirmation buttons.