Cloudflare releases updates weekly. Most are invisible to you. Some break your build pipeline. A few actually make your site faster or safer. As a support engineer, I see the same three issues repeat: cache hits dropping, TLS handshakes failing, and WAF rules blocking legitimate traffic. This guide skips the marketing fluff. It focuses on the specific configuration changes that impact your latency and security posture right now.
Edge Caching and TTL Strategy
The most common latency complaint isn't the network. It's the origin server doing work it shouldn't. Cloudflare's edge network is fast, but only if it can serve content from the edge. If your HTTP headers tell Cloudflare to revalidate every request, you're paying the round-trip cost to your origin for every page view.
Check your Cache-Control headers. In many WordPress setups, the theme or a plugin overrides the default caching behavior. You want static assets (CSS, JS, images) to have a long max-age. Dynamic HTML pages can have a shorter TTL, but they shouldn't be no-cache unless absolutely necessary.
Verifying Cache Status
You can check the response headers from your browser's Developer Tools or via curl. Look for the cf-cache-status header.
curl -I https://yourdomain.com/style.css | grep -i cf-cache-status
If you see MISS, the file wasn't in the edge cache. If you see HIT, it was served from the edge. A high ratio of MISS on static files indicates a caching misconfiguration. Update your .htaccess or Nginx config to set explicit Expires and Cache-Control headers for asset directories. Cloudflare respects these directives. If you set max-age=31536000 on your CSS files, Cloudflare will hold them for a year unless you purge them.
Purging vs. Waiting
When you deploy new code, you need to purge the cache. But don't purge the entire zone if you only changed one script. Use the targeted purge API or the dashboard's "Purge Specific Files" option. Purging the entire zone causes a temporary spike in origin traffic as the cache repopulates. For high-traffic sites, this can look like a DDoS attack on your server. Schedule purges during low-traffic windows if possible.
TLS and Certificate Management
TLS handshake time directly impacts Time to First Byte (TTFB). Modern browsers support TLS 1.3, which reduces the number of round trips needed to establish a secure connection. Cloudflare supports this by default, but your origin server might be lagging behind.
Enforcing TLS 1.2/1.3
Go to your Cloudflare dashboard under SSL/TLS > Edge Certificates. Ensure "Always Use HTTPS" is enabled. This redirects all HTTP traffic to HTTPS, saving one redirect hop. More importantly, check the Minimum TLS Version setting. Set it to 1.2. If your origin server supports it, Cloudflare can negotiate 1.3 with the client and 1.2 or 1.3 with the origin, depending on your "SSL Mode."
In support tickets, I often see "Full (Strict)" mode failing because the origin server has an expired or self-signed certificate. If you use "Full (Strict)", Cloudflare verifies the origin certificate. If it fails, the connection drops. If you're using a Let's Encrypt cert on your origin, ensure the renewal process is working. A single expired cert can take down your entire site if you're in Strict mode.
Origin CA Certificates
If you manage your own VPS or cPanel hosting, you can generate an Origin CA certificate directly from Cloudflare. This cert is valid for 15 years and is signed by Cloudflare's intermediate CA. It simplifies renewal headaches. Install this cert on your origin server, and set your Cloudflare SSL mode to "Full (Strict)". This ensures end-to-end encryption and prevents man-in-the-middle attacks between Cloudflare and your server.
Web Application Firewall (WAF) Tuning
The WAF is powerful, but it's not magic. The default ruleset blocks common SQL injection and XSS attempts. However, it can also block legitimate users, especially those using aggressive browsers or corporate proxies. If your error logs show 403s from Cloudflare, you're likely hitting a WAF rule.
Reviewing Firewall Events
Go to Security > Firewall > Events. Filter by "Blocked" actions. Look for patterns. Are you blocking a specific IP range? Is a particular rule ID causing issues? If you see a spike in blocks from a single IP, it might be a compromised bot or a misconfigured crawler. You can whitelist trusted IPs or adjust the rule sensitivity.
For WordPress sites, the "Managed Ruleset" is a good starting point. It covers OWASP Top 10 vulnerabilities. But if you have custom login forms or API endpoints, you may need to create custom rules. For example, if your API accepts JSON payloads with certain characters, the default XSS rule might flag them. Create a custom rule to skip WAF inspection for /api/* paths if you've implemented your own validation.
Rate Limiting
Brute force attacks are common on login pages. Cloudflare's Rate Limiting feature can mitigate this. Set a rule to limit requests to /wp-login.php to 10 per minute per IP. If an IP exceeds this, Cloudflare blocks it for a set duration (e.g., 10 minutes). This is more effective than a generic WAF rule because it's based on behavior, not content. Test this rule in "Monitor" mode first to see what it would block without actually blocking it.
DNS and Propagation
DNS changes can take time to propagate. If you switch your nameservers to Cloudflare, you're relying on their global anycast network. But if you have stale DNS records elsewhere, users might still hit your old IP. This causes split-brain issues where some users see the new site and others see the old one.
Checking DNS Propagation
Use a tool like dig or nslookup to verify which IP address is being resolved for your domain. Compare the result with the IP shown in your Cloudflare dashboard.
dig +short yourdomain.com
If the IP doesn't match, wait for the TTL to expire. You can lower the TTL to 300 seconds (5 minutes) before making changes to speed up propagation. After the change, you can raise the TTL back to 1 hour or more. Don't leave it at 300 seconds permanently; it increases DNS query load on Cloudflare's resolvers.
CNAME Flattening
If you use a CNAME record for your root domain (@), Cloudflare supports CNAME flattening. This means it returns an A record instead of a CNAME for the root domain. This is required by RFCs and prevents some browsers from rejecting the connection. Ensure your DNS setup uses A records for the root domain if you have issues with CNAME flattening. Most modern DNS providers handle this automatically, but older setups might need manual adjustment.
Security Headers and HSTS
Your site's security isn't just about blocking attacks. It's about enforcing secure connections. HTTP Strict Transport Security (HSTS) tells browsers to only connect via HTTPS. If a user types http://yourdomain.com, the browser automatically redirects to https://yourdomain.com without the initial HTTP request. This saves time and prevents SSL stripping attacks.
Enabling HSTS
Go to SSL/TLS > Edge Certificates and enable "HSTS". Set the max-age to at least 1 year (31536000 seconds). You can also include the includeSubDomains directive if all your subdomains use HTTPS. Be careful: once you enable HSTS, browsers will remember it. If you ever need to serve HTTP (which you shouldn't), it will be difficult to disable. Only enable HSTS when you're confident all your content is served over HTTPS.
Content Security Policy (CSP)
CSP is a powerful tool for preventing XSS attacks. It tells the browser which sources of content are allowed to execute. A strict CSP can break your site if you load scripts from third-party CDNs or inline scripts. Start with a report-only policy. Add the Content-Security-Policy-Report-Only header with your desired policy. Monitor the violation reports in your server logs or via a reporting endpoint. Once you've identified all allowed sources, switch to the strict Content-Security-Policy header.
What to check first
Before diving into advanced configurations, verify these three items:
- Cache Status: Ensure static assets are returning
cf-cache-status: HIT. If not, fix yourCache-Controlheaders. - TLS Mode: Confirm you're using "Full (Strict)" with a valid origin certificate. Check for expired certs in your hosting panel.
- WAF Events: Review recent blocked requests. If you see legitimate users being blocked, create custom exclusion rules.
These three checks address 80% of the performance and security issues I see in support tickets. They don't require expensive add-ons or complex scripting. They just require attention to detail. Cloudflare is a tool, not a magic wand. It amplifies what you do. If your origin is slow, Cloudflare can't make it fast. If your code has vulnerabilities, the WAF might block the exploit, but it won't fix the code. Use the platform to reduce latency and harden your perimeter, but keep your origin server optimized and your code secure. That's where the real wins are.