Sooner or later, someone building your website tells you to “put it on Cloudflare”. You do, your DNS moves, the site looks the same, and you have no idea what you switched on.
What it does splits into three parts, and separating them makes it clear.
1. It sits between you and your visitors
Normally a visitor types your domain, DNS says where your server is, and they connect to it directly.
With Cloudflare, DNS returns a Cloudflare address instead. The visitor connects to whichever Cloudflare location is nearest them, and that location fetches from your server and passes it on.
Your server’s address is no longer public, which is the base layer of value: what cannot be reached is hard to attack directly.
The cost is that every request your server sees now comes from Cloudflare. If your software records visitor IP addresses it has to read them from a request header rather than the connection. This is the most common problem after switching over, and it shows up as every visitor appearing to have the same IP.
2. It keeps a copy near your visitors
Most people assume this is all it does, and it is the most valuable part.
Cloudflare has hundreds of locations; the closest to New Zealand is in Auckland. Your server might be in Sydney, Singapore or the United States. The first visitor arrives, the location has nothing, so it fetches a copy and keeps it. Everyone after that is served from Auckland.
What that saves is one physical round trip. Auckland to Sydney and back is about 110 milliseconds — that is what the distance costs at the speed of light, and no amount of optimisation changes it. A cached request skips the journey.
Two things need stating, or you will expect too much:
By default it caches images, stylesheets and scripts, not your pages. It cannot know whether your pages look the same for everyone. If your site assembles pages on each request — WordPress and similar — then every visit to your home page still goes back to your server. Caching pages requires configuring it deliberately.
Cache duration is a ceiling, not a promise. Storage at each location is shared across all sites and evicted by how often things are requested. On a low-traffic site, a copy disappears within hours whatever you configured. That is why a site can feel instant and then sluggish, which we covered separately.
3. It absorbs some of the bad traffic
A large share of internet requests are not people: vulnerability scanners, password guessers, scrapers, comment spammers. Small sites get scanned too, because scanning is automated and indiscriminate.
The free tier turns away a meaningful portion of that, and the server resources saved are real.
Know what it does not stop, though: nothing at the application layer. Flaws in your own software, weak passwords, plugins left unpatched — Cloudflare addresses none of them. It is a guard at the door, not a lock on the cabinet.
Is the free tier enough
For most business websites, yes.
It includes global distribution, an SSL certificate, basic attack protection, and unmetered bandwidth. The last one matters more than it sounds for image-heavy sites, where transfer is billed separately elsewhere.
Paid tiers mostly buy finer rule control, better logs, more analytics and some targeted acceleration. Until a site has settled traffic, there is little to apply them to.
Four things that commonly go wrong afterwards
The wrong SSL mode. Several modes decide whether the leg from Cloudflare to your server is encrypted. Choose Flexible and the visitor’s connection is encrypted, the connection to your server is not, and the browser still shows a padlock. That is a false sense of security. If your server has a certificate, the setting should be Full (strict).
Caching what should not be cached. Configure page caching without excluding admin paths and you get one of two symptoms: logging in shows you someone else’s cached page, or you edit content and the live site does not change. Admin, login and API paths must be excluded, as must any request carrying a login cookie.
It caches 404s. An image has not been uploaded yet, someone requests it once, and Cloudflare remembers there is nothing there. You upload the image and visitors keep seeing nothing until the cache expires. We have hit this twice and lost time to it both times. Diagnose it by adding a random query parameter — if that works, it is a caching problem rather than a missing file.
Edited files that stay old. Once stylesheets and scripts are cached, you change the file on your server and Cloudflare keeps serving the previous one. The fix is versioning the address: a new URL is a new file, so the cache expires by itself. Do not live on manual cache purges — that depends on someone remembering, and eventually nobody does.
A quick check
Open your site with the network panel of developer tools and look for the cf-cache-status response header.
HIT means it came from a location directly. MISS means that request went to your server. DYNAMIC means Cloudflare decided this should not be cached and always fetches.
If your pages are permanently DYNAMIC, you are using the protection and the SSL but not the caching — which is not wrong, but you may believe your site is faster than it is.
The sites we deliver come configured for all of this: cache rules, versioning strategy, excluded paths. There is nothing secret in the configuration — the above is essentially the whole of it. The difference is whether someone actually set each item and then verified it.