CDN settings for a faster website: a practical step-by-step guide

CDN Settings for a Faster Website: A Practical Step-by-Step Guide

Yes, correct CDN settings significantly speed up a site, reduce TTFB and LCP, and lower the risk of outages. The key steps come in this order: preparing your DNS records, choosing the Full (Strict) SSL mode, setting up cache rules for static and dynamic content, configuring your WAF without blocking Googlebot, and finally, thorough testing. Every one of these steps directly affects loading speed and how Google indexes your site.

In short:

• A correctly configured CDN can reduce page load time by 30 to 50 percent, improving both user experience and search engine indexing.
• The key steps are preparing DNS records and using Full (Strict) SSL, correctly caching content, and properly configuring a WAF for security without blocking Googlebot.
• The process includes routing content from the nearest edge node for faster data delivery and using newer protocols, like HTTP/3, to reduce TTFB.
• Regardless of site size, careful testing and monitoring of response headers is needed to ensure correct caching, security, and good SEO.
• For larger or business projects, it's advisable to find an expert partner to handle correct setup, maintenance, and ongoing configuration monitoring.

Table of Contents

• How a CDN actually works, and why it affects speed
• Preparing DNS and subdomains before turning on the CDN
• SSL/TLS: why Full (Strict) is the only real choice
• Cache rules that actually speed up a site
• Security settings that don't block your own traffic
• What to test after launch, and which tools to use
• The mistakes that hurt SEO the most, and how to fix them
• A checklist for a safe implementation
• When to set up a CDN yourself, and when to get help
• How Moxy Web helps with CDN implementation
• Useful resources for further reading
• Frequently asked questions

How a CDN actually works, and why it affects speed

A CDN isn't just a "faster server." It's a network of edge points of presence (PoPs), spread across the world, that hold copies of your content closer to the visitor. When someone in Ljubljana opens your site, the content doesn't need to be sent from a data center in Frankfurt or Virginia — they get it from the nearest node instead. The technology that makes this possible is called Anycast: a single IP address maps to multiple locations, and traffic automatically routes to the geographically closest node.

Every cached file has its own cache key — a unique identifier that tells the CDN which version of the content to serve. A cache key can include language, country, or even the visitor's device, so a Slovenian user can be served a different version of a page than a German one, without any impact on speed.

Newer protocols further reduce time to first byte. HTTP/3, built on the QUIC protocol, does away with slower TCP handshakes and allows for faster session setup, as explained in the RFC 7234 technical standard on HTTP content caching. Early Hints send the browser hints about resources (CSS, fonts) before the full HTML response is even ready.

In practice, this means:

• content travels a shorter path to the user
• a correctly set cache key prevents a user from receiving the wrong language version
• newer protocols reduce TTFB before caching even comes into play

Preparing DNS and subdomains before turning on the CDN

Before turning on your CDN, you need to protect your existing connections. A mistake in your DNS records can knock out email or connected services for hours or days, and that's far more expensive to fix than to prepare for properly in advance.

1. List and save all your existing DNS records. Export the zone file from your registrar before changing anything. This is your backup if something goes wrong.
2. Check your MX records and other email settings. If your CDN provider takes over DNS management, you need to manually transfer your MX, SPF, DKIM, and DMARC records, otherwise email simply stops working.
3. Decide between proxying the whole domain or just a subdomain for static files. The lower-risk approach is routing only a subdomain (such as cdn.yourdomain.si) through the CDN for images, CSS, and JavaScript, while the main domain stays pointed at the origin server.
4. Set the proxy status correctly for every record. With providers that use an "orange cloud" icon or similar proxy-on indicator, it should only be enabled for records meant to go through the CDN — not for MX or other service records that need a direct connection.

This step is tedious, but skipping it risks leaving your email down for a week while you hunt for what went wrong.

SSL/TLS: why Full (Strict) is the only real choice

CDN providers typically offer three encryption modes between the edge node and your origin server: Flexible, Full, and Full (Strict). Flexible only encrypts the path between the visitor and the CDN, while traffic from the CDN to your server stays unencrypted. That's a security gap that's simple to close, so it's best avoided.

Full (Strict) mode requires a valid SSL certificate on the origin server and encrypts the entire path from visitor to origin, as confirmed by Cloudflare's explanation of how SSL/TLS works. It's the only mode that actually closes the security gap between edge and origin.

What you need for Full (Strict):

• a valid certificate on the origin server — not self-signed or expired
• automated certificate renewal (Let's Encrypt, or a provider's origin certificate with a long validity period)
• confirmation that the domain in the certificate matches the domain at the origin

Pro tip: Before enabling HSTS (HTTP Strict Transport Security), make sure HTTPS works flawlessly on every subdomain and path. HSTS forces the browser to never attempt an HTTP connection again, so a configuration mistake means your site will be unreachable for a while, even after you fix the certificate.

Cache rules that actually speed up a site

Caching is the heart of any CDN configuration, and it's also where most mistakes happen. A correctly configured CDN can reduce LCP by 30 to 50 percent and improve TTFB, which directly affects the Core Web Vitals signals Google factors into ranking.

Different content types call for different rules:

• Static files with a version in the filename (images, CSS, JS with a hash in the path, e.g. style.a3f9c1.css) should have a very long Cache-Control: max-age=31536000, immutable. Since the filename changes with every new version, there's no risk of a user getting stale content.
• HTML pages should use a shorter TTL, for example Cache-Control: s-maxage=300, stale-while-revalidate=60. That means five minutes of fresh caching, plus an extra minute during which the CDN can serve the old content while fetching a new version in the background.
• Dynamic paths (cart, login, admin) should be excluded from caching entirely with a bypass cache rule.

To automate clearing the cache with every publish, use your CDN's API or a webhook that automatically triggers a purge of specific paths when content changes, instead of doing it manually. The combination of stale-while-revalidate and a short TTL for HTML is considered the best balance between content freshness and speed, as a technical review of CDN configuration for SEO also confirms.

Security settings that don't block your own traffic

A WAF (Web Application Firewall) and DDoS protection are important additions, but they need to be rolled out gradually, not with a single click on "block everything suspicious."

1. Observation phase (log only). Rules only log suspicious traffic at first, without blocking it, so you can see what they'd actually catch.
2. Challenge phase. Suspicious requests get shown a challenge (a CAPTCHA or similar test), while legitimate traffic is let through.
3. Blocking phase. Only once you're confident a rule isn't catching legitimate users do you switch it into actual blocking mode.

When setting up rate-limiting rules, make sure to add an exception for known crawlers. A WAF and bot-management tools can unintentionally block Googlebot, so it's recommended to regularly check your CDN logs for 403 or 429 responses on Googlebot's user agents, as an analysis of CDN impact on indexing warns. Add Googlebot's verified IP ranges to your allowlist.

Pro tip: "Under Attack Mode" or a similarly aggressive setting should only be a temporary measure during an active attack, since it presents every visitor — including crawlers — with an extra challenge, which temporarily hurts user experience and indexing.

What to test after launch, and which tools to use

After turning on your CDN, don't just assume "it's faster now" without measuring it. Use a combination of WebPageTest, Google's PageSpeed Insights, and GTmetrix to compare before and after.

Key metrics to track:

• TTFB (time to first byte) — shows how quickly the server or edge node responds at all
• LCP (largest contentful paint) — the main Core Web Vital for perceived loading speed
• FCP (first contentful paint) and CLS (cumulative layout shift)

Check cache status through response headers like CF-Cache-Status or X-Cache, which show whether a request was served from cache (HIT) or passed through to the origin (MISS). Practical guides recommend measuring both before and after optimization, since a correct CDN setup can bring a 10 to 20 percent speed gain, and in some cases, substantially more.

For further help interpreting this data, see also this guide to Core Web Vitals for developers and marketers.

The mistakes that hurt SEO the most, and how to fix them

A handful of mistakes come up in nearly every CDN implementation, and these are exactly the ones that do the most damage to search visibility.

• Incorrect canonicals on edge nodes. If the CDN serves pages under a different URL (with a region parameter, say), check that the canonical tag still points to the right main URL.
• Blocked robots.txt at the CDN level. Some providers block access to robots.txt on certain paths by default, which can prevent crawlers from reading the rules.
• Caching pages with a Set-Cookie header. Login, cart, or checkout pages must never be cached, since one user could end up seeing another user's data.
• Mixed content (HTTP inside HTTPS). With SSL termination at the CDN edge, check that every resource (images, scripts) loads over HTTPS, otherwise the browser will show a warning.
• CORS errors for resources on other subdomains. If fonts or API calls come from a different subdomain, check that the correct CORS headers are set at the origin.

For a thorough review of these issues, a tool that analyzes cache headers and canonicals is useful, as recommended by the technical guide on CDN's impact on ranking.

A checklist for a safe implementation

Setting up a CDN isn't a one-time task — it's a process that requires ongoing monitoring of analytics and security logs, and adjusting rules based on traffic patterns. The order of steps below has been proven across dozens of business-site implementations.

1. Preliminary steps: export your DNS records, make a full backup of the site, and test on a separate staging address before changes go to production.
2. Rollout routine: choose a low-traffic time window, make the change, immediately trigger a cache purge, and after a few minutes measure Core Web Vitals to compare against the baseline.
3. Maintenance: a monthly log review, checking the 5xx error rate, and an agreed response time (SLA) for outages — for example, responding within an hour for a critical error.

Pro tip: Keep a simple table with the date of every configuration change and the measured TTFB before and after. When something starts running slower six months down the line, you'll quickly be able to spot which change caused it.

When to set up a CDN yourself, and when to get help

For a smaller brochure site with low traffic, a basic configuration is enough: correct DNS, Full (Strict) SSL, and default caching. Once traffic grows, once you add an online store with a payment process, or once security requirements get stricter, any wrong cache rule setting can mean a lost order or exposed data.

For business sites, a managed service usually pays for itself, since it saves time on urgent fixes and reduces the risk of human error in production changes.

— Ziga

How Moxy Web helps with CDN implementation

Moxy-web is the alternative to spending evenings trying to untangle CDN settings yourself, buried in documentation and risking a mistake in production. Since Moxy-web builds web solutions custom, without pre-made platforms, we can tailor the CDN configuration precisely to your architecture, rather than a generic pattern built for the average case.

Our Support & Maintenance service includes an assessment of your existing setup, implementing DNS, SSL, and cache configuration, and ongoing monitoring after launch. The workflow is straightforward: we first review the site's current state and traffic patterns, then propose a specific set of settings, roll them out in a test environment, and only then in production, measuring before and after.

If you want your site running faster without risking email downtime or blocked indexing, check out the offering at Moxy-web and get in touch for an assessment of your current configuration.

Useful resources for further reading

For a deeper technical dive, we recommend the following resources:

• An overview of caching plugins for WooCommerce for those combining a CDN with a WordPress store
• A guide to optimizing web images, which complements CDN settings for improving LCP

Frequently asked questions

What are CDN settings, and why do they matter?

CDN settings are the configurations that determine how your content is cached, encrypted, and served across a network of edge nodes. A correct configuration can reduce LCP by 30 to 50 percent, directly improving Core Web Vitals and the user experience.

Which SSL mode should I use with a CDN?

Full (Strict) mode is recommended, since it requires a valid certificate on the origin server and encrypts the entire path between visitor and origin, as Cloudflare's explanation of SSL/TLS describes. Flexible mode leaves part of the path unencrypted and should be avoided.

How do I check whether the CDN is actually caching content?

Check response headers like CF-Cache-Status or X-Cache, which show whether a request was served from cache (HIT) or passed through to the origin (MISS). For precise measurement, use WebPageTest or PageSpeed Insights.

Can a CDN block Googlebot?

Yes — a WAF or bot-management rules can unintentionally block Googlebot, so it's important to regularly check your CDN logs for 403 or 429 responses to Googlebot's user agents. It's recommended to add Googlebot's verified IP ranges to your allowlist, as an analysis of CDN's impact on crawling notes.

Do I need a managed service, or can I set up a CDN myself?

For a small site with low traffic, a basic DNS, SSL, and caching configuration is enough, and you can set it up yourself. For business sites with a store or stricter security requirements, a managed service pays off through time saved and a lower risk of mistakes.

Recommended

• How to Speed Up a Site Without Losing Functionality
• A Guide to Optimizing Web Images for Faster Sales
• How to Improve Website Speed
• Page Loading Speed: A Business Guide for Decision-Makers