Cloudflare for Client Websites: Speed, Security, and DNS in One Place

Most client websites I ship pass through Cloudflare before they reach the origin server. Not because the stack is incomplete—but because DNS, TLS, caching, and basic protection should not be rebuilt project by project.

This is the baseline I use when a business site goes live on a VPS, shared hosting, or static build.

What Cloudflare actually gives you

Think in layers:

1. DNS — fast propagation, easy record management, optional proxy (orange cloud).
2. CDN edge cache — static assets served closer to visitors.
3. TLS — free certificates and HTTPS redirects at the edge.
4. Security rules — bot filtering, rate limits, WAF on higher plans.
5. Observability — traffic analytics without installing another tool on day one.

For small business sites, layers 1–3 alone often improve perceived speed and uptime.

Step 1: Move DNS correctly

Before switching nameservers:

• export existing records (A, AAAA, CNAME, MX, TXT);
• lower TTL a day ahead if the domain was elsewhere;
• add the site to Cloudflare and verify ownership;
• recreate MX and SPF/DKIM exactly—email breaks silently if these are wrong.

Only after records match, point the domain to Cloudflare nameservers.

Step 2: SSL/TLS settings I use

On the SSL/TLS tab:

• mode: Full (strict) when the origin has a valid certificate;
• enable Always Use HTTPS;
• enable Automatic HTTPS Rewrites;
• turn on TLS 1.3.

If the origin is a bare IP or self-signed cert, fix the origin first—do not stay on “Flexible” long term.

Step 3: Caching without breaking dynamic pages

Default caching helps CSS, JS, fonts, and images. Dynamic PHP/WordPress admin must stay uncached.

Rules of thumb:

• cache static extensions aggressively (css, js, woff2, webp, jpg);
• bypass cache for /wp-admin/*, cart/checkout, and authenticated cookies;
• use Cache Rules (or Page Rules on older setups) instead of “cache everything” blindly.

For Astro/static sites, the entire HTML document can often be cached at the edge with short TTL—or served directly from origin if deploys are frequent.

Step 4: Performance toggles worth enabling

Under Speed / Optimization:

• Brotli compression;
• HTTP/2 and HTTP/3 (with QUIC) when available;
• Early Hints if the origin supports them;
• Polish or modern image pipelines only after testing—auto optimization can surprise designers.

I avoid stacking Cloudflare optimizations on top of a broken origin. Fix heavy images and blocking scripts first; CDN amplifies good architecture, it does not replace it.

Step 5: Basic security before marketing launch

Minimum security checklist:

• enable Bot Fight Mode or equivalent on free plans where appropriate;
• add a rate limit on login and form endpoints;
• block obvious countries/ASNs only when the business truly has no audience there;
• review Security Events after the first traffic spike.

For WordPress sites, also restrict /wp-login.php and consider a separate admin hostname.

Step 6: Page Rules / Cache Rules I repeat often

Examples:

Pattern	Action
*.css, *.js, fonts	Cache Everything, long edge TTL
/wp-admin/*	Bypass cache
/api/*	Bypass cache
Marketing home /	Short TTL or bypass if A/B testing

Document these in the project handover so the next maintainer knows why a page behaves differently.

Common mistakes I see

• Flexible SSL with HTTPS on the public site but HTTP to origin—fix with Full (strict).
• Caching admin or cart — causes “ghost” logins and empty carts.
• Forgetting MX records after DNS migration.
• Orange-clouding mail-related subdomains that should stay DNS-only.
• Enabling Rocket Loader on apps with fragile inline scripts—test first.

How this pairs with PageSpeed work

Cloudflare reduces latency and bytes over the wire. It does not fix:

• huge hero JPEGs;
• render-blocking font chains;
• unused JavaScript bundles;
• layout shift from missing dimensions.

Use Cloudflare after the origin is sane. Then measure again with PageSpeed Insights and real-device tests.

Handover checklist for clients

• Cloudflare account access documented (or agency-managed with client visibility).
• DNS records exported as backup.
• SSL mode recorded (Full strict).
• Cache bypass paths listed.
• Email records verified after NS change.
• 404/redirect behavior tested through the proxy.

Closing thought

Cloudflare is not magic—it is infrastructure hygiene. For client websites, that hygiene means faster first loads, fewer brute-force knocks on the origin, and one dashboard when something breaks at 10 p.m.

Start with DNS + Full (strict) + sensible cache rules. Add security tuning once real traffic shows what actually gets attacked.