Cloudflare’s free plan is one of the few things in this industry that is genuinely as good as it sounds, which naturally makes people suspicious of it. This is an honest account of what it gives you, where the limits actually bite, and the settings that most often cause a site to break after somebody enables them enthusiastically.
DNS hosting. Fast, reliable, free, and worth having even if you use nothing else. Moving your DNS to Cloudflare does not by itself put your traffic through Cloudflare; that is a separate per-record setting.
A shared certificate and HTTPS. Traffic between your visitor and Cloudflare is encrypted without you doing anything. Note carefully that this is not the same as your own server having a certificate, which matters, and which we come back to below.
Caching and a global network. Static files are served from a location near your visitor rather than from your server. For images, stylesheets and scripts this is a real and immediate improvement, particularly for visitors a long way from where your site is hosted.
Unmetered DDoS protection. This is the headline item and it is not qualified by plan. A site behind Cloudflare on the free plan gets the same volumetric attack absorption as a paid one.
A basic managed security ruleset, plus a small number of your own firewall rules and a small number of page or configuration rules.
The published limits are not the ones that catch people out. In practice there are three.
The custom firewall rule allowance is small. The free plan allows only a handful of your own rules, and each rule can hold a long expression. That sounds fine until you want to block a list of bad crawlers, allow a payment provider, restrict an admin path and handle a country block, at which point you are out of rule slots. The workaround is to combine unrelated conditions into a single rule with a long expression, which works but makes the rules considerably harder to read six months later. Write a clear description on every rule; you will need it.
Caching HTML is not the default. By default Cloudflare caches static files and passes everything else to your server. That is the right default, and it means the free plan does far less for your slowest pages than people assume. Caching HTML is possible with a cache rule, but on a site with logins, baskets or checkouts it must be done carefully or you will serve one customer’s page to another. That is not a theoretical risk.
You cannot see much. Analytics are sampled and the retention is short. When something intermittent is happening, the free plan often cannot tell you enough about it after the fact.
Flexible SSL. This encrypts the visitor to Cloudflare and then talks to your server over plain HTTP. It makes a padlock appear on a site with no certificate, which is why people choose it, and it is the wrong answer. It leaves the connection from Cloudflare to your server unencrypted, and it frequently causes redirect loops with any application that knows it should be running over HTTPS. Your server should have its own certificate, which on our hosting it does, free and renewed automatically, and the mode should be Full (strict).
Rocket Loader and aggressive minification. These change how your JavaScript loads. Sometimes they help. Sometimes they break a slider, a cookie banner or a checkout in a way that only shows up in one browser. If you turn them on, click through the site properly afterwards, including a real checkout.
Security level set too high. Raising it puts an interstitial challenge in front of more visitors. Legitimate people fail those more often than you would think, particularly on mobile networks and corporate connections, and search engine crawlers can be caught by them too. A page that answers with a challenge instead of content is a page that cannot rank.
Blocking bots by user agent without thinking. Blocking scrapers is reasonable. Blocking anything with “bot” in the name will eventually catch a payment provider’s callback, a monitoring service or a search engine.
Purging the cache by URL does not always evict what you expect, particularly where a page has variants. When you have made a change and cannot see it, purging everything is the reliable move, and on a free plan the cost of doing so is a brief increase in requests to your server rather than anything worse.
Yes, for DNS and for DDoS protection at the very least. It is a genuinely good free product. Treat the security settings as things to enable deliberately, one at a time, with a proper look at the site afterwards, rather than as a checklist to work down on a Friday afternoon.
If you host with us we can set this up for you and configure it sensibly, including making sure your origin certificate and SSL mode are right. Open a ticket and ask.