How to Enable the Kinsta CDN on WordPress

Kinsta CDN is included in every Kinsta plan and serves your site’s static files from a global network of edge locations, reducing load times for visitors far from your origin server. Enabling it takes three steps in MyKinsta and adds no extra cost to your plan. For the broader picture of what Kinsta includes and how it compares to other managed WordPress hosts, see our Kinsta hosting guide.

The CDN is one of three caching layers Kinsta runs by default; the wider picture (page cache, Redis object cache, and how the layers interact) is in the Kinsta WordPress optimization guide.

What Is Kinsta CDN?

Kinsta CDN is a content delivery network built on Cloudflare’s global infrastructure, which spans over 260 cities worldwide. When the CDN is active, static files such as images, CSS stylesheets, and JavaScript are cached at the edge location nearest to each visitor. Instead of every request traveling to your primary server, most requests are answered locally at the edge, which reduces time to first byte (TTFB) and improves Core Web Vitals metrics, especially Largest Contentful Paint for image-heavy pages.

Kinsta CDN is included in all hosting plans at no additional charge. Unlike third-party CDNs that require a separate account and DNS record changes, it is configured entirely inside MyKinsta.

Before You Enable Kinsta CDN

Kinsta CDN is tied directly to your site’s domain. If you are planning any domain changes, such as switching from HTTP to HTTPS or changing the domain name itself, complete those changes first. Enabling the CDN on a domain you later change requires removing and re-adding the CDN integration, which is extra work that is easy to avoid.

If you want to measure your site’s baseline performance before enabling the CDN, the Kinsta APM tool lets you capture PHP transaction and database timings so you can compare before and after.

How to Enable Kinsta CDN on WordPress

Step 1 - Log In to MyKinsta

Log into your MyKinsta dashboard and click Sites in the left navigation.

Step 2 - Select Your Site and Open Kinsta CDN

Click on the WordPress site where you want to enable the CDN. In the left panel, click Kinsta CDN.

Step 3 - Enable and Wait for Propagation

Click Enable Kinsta CDN. Kinsta automatically creates a CDN zone and assigns a CDN domain to your site, such as a random subdomain ending in kinstacdn.com. During setup, three things happen in sequence: the CDN zone is created, the CDN domain propagates, and an SSL certificate is issued for the CDN domain. The full process takes up to 15 minutes. A progress screen in MyKinsta tracks each step. If any step does not complete, contact Kinsta support immediately.

How to Verify Kinsta CDN Is Working

After enabling the CDN, confirm it is actively serving files before assuming it is working:

1. Open your site in a browser and press F12 to open developer tools. Go to the Network tab.
2. Reload the page and click on a static asset such as an image or CSS file.
3. In the response headers, look for cf-cache-status. A value of HIT means the file was served from the CDN cache rather than the origin server. A value of MISS on the first load is normal and changes to HIT on subsequent requests.
4. Check that the asset URLs in your page source reference the CDN domain rather than your origin server address.

CDN Management Options After Enabling

Once the CDN is active, MyKinsta provides three options:

• Disable CDN: turns the CDN off without removing the configuration. Use this for temporary troubleshooting to confirm whether a site issue is CDN-related.
• Clear CDN Cache: purges all cached files from the CDN zone. Use this after making significant changes to static files, particularly when the updated file has the same filename as the cached version.
• Remove Kinsta CDN: fully removes the CDN integration from your domain. Required if you move to a new domain or migrate from HTTP to HTTPS after the CDN was already enabled.

Fixing Mixed Content After Enabling Kinsta CDN

If your site shows a padlock warning or broken styles after enabling the CDN, you may have mixed content: some assets are loading over HTTP while the page is served over HTTPS. To fix this:

• Check your WordPress settings under Settings and confirm both the WordPress Address and Site Address use HTTPS.
• Run a search-replace in your database to update any hard-coded HTTP asset URLs. The Better Search Replace plugin handles this without breaking serialized data.
• Clear your Kinsta site cache and CDN cache after making changes, then reload the page to confirm the warning is gone.

For sites with heavy database load, pairing the CDN with Redis Object Cache on Kinsta covers both static asset delivery and database query performance.

What Kinsta CDN Does Not Cache

Kinsta CDN caches static files only. It does not cache HTML pages, which means your WordPress PHP responses always come from the origin server. This is intentional: HTML content is dynamic (logged-in users, cart state, personalised content) and caching it would break functionality. Files that are cached include images, CSS, JavaScript, web fonts, PDF files, and other binary assets that do not change per request.

Practically, this means the CDN improves load times for asset-heavy pages but does not reduce PHP execution time for uncached page renders. For reducing server load on dynamic pages, that is where Redis object caching on Kinsta provides the most value, by reducing database query overhead for repeat requests.

Kinsta CDN and Core Web Vitals

Enabling Kinsta CDN most directly improves Largest Contentful Paint (LCP), the Core Web Vitals metric that measures how quickly the largest visible element loads. For most WordPress sites, the LCP element is a hero image or above-the-fold photo. When that image is served from a CDN edge location close to the visitor instead of from a single origin server in one region, time to first byte for that image drops significantly.

The CDN also improves Time to First Byte (TTFB) for cached static assets and helps Cumulative Layout Shift (CLS) indirectly, since faster-loading CSS and web fonts prevent late style changes that shift page elements. For pages where JavaScript is the LCP element, CDN delivery of cached JS files reduces blocking time.

After enabling the CDN, run a PageSpeed Insights test on your URL to measure the before-and-after difference in LCP. If LCP remains high after CDN activation, the bottleneck is likely uncached PHP response time rather than asset delivery, and the fix is server-side: upgrading the server tier, enabling object caching, or reviewing slow database queries with the Kinsta APM tool.

Kinsta CDN and Automatic WebP Conversion

When Kinsta CDN is active, Kinsta automatically converts images to WebP format for browsers that support it. WebP images are typically 25 to 35 percent smaller than equivalent JPEG or PNG files at comparable quality. For image-heavy pages, this single change often reduces total page weight by 150 to 400 KB without any quality loss visible to visitors.

The conversion happens at the CDN layer, not in your WordPress media library. Your original uploaded images remain unchanged on the server. Browsers that support WebP (Chrome, Edge, Firefox, Safari 14+) receive the WebP version automatically. Older browsers receive the original format as a fallback. You do not need a separate image optimisation plugin to get WebP delivery once the CDN is enabled.

What WebP conversion does not cover:

• Images served from domains or URLs that bypass the CDN (external CDN URLs, third-party embeds, or images loaded by JavaScript from a non-CDN origin)
• Images in formats that are already efficiently compressed (existing WebP files, SVGs)
• GIF files converted to animated WebP (static GIFs are converted; animated GIFs are left as-is)

To verify WebP is working, use browser developer tools: load a page, click an image in the Network tab, and check the Content-Type response header. A value of image/webp confirms delivery. If you see image/jpeg or image/png, either the CDN is not active on that asset or the browser does not support WebP.

How Much Does Kinsta CDN Actually Improve Page Speed?

The answer depends on where your visitors are relative to your Kinsta data center and how image-heavy your pages are. Real-world patterns:

• Visitors near the data center (same region): Modest improvement. Your origin server is already fast for these visitors. Enabling the CDN mostly moves static assets to CDN delivery without a dramatic TTFB reduction.
• Visitors far from the data center (different continent): 200 to 600ms TTFB reduction for cached static assets. If your server is in the US and a significant share of visitors are in Europe, Asia, or Australia, CDN activation is one of the highest-leverage changes you can make.
• Image-heavy pages: Combined with WebP auto-conversion, total page weight often drops 20 to 40 percent. A page that previously transferred 2 MB of images may transfer 1.3 MB after CDN activation, with the remaining assets served from edge locations close to the visitor.
• LCP improvement: For pages where the Largest Contentful Paint element is a hero image, enabling the CDN often shifts LCP from the 3 to 4 second range to under 2.5 seconds for remote visitors. This crosses the Google Core Web Vitals “Good” threshold.

To measure the actual improvement for your site: run a PageSpeed Insights or GTmetrix test before enabling the CDN, note the LCP and total transfer size, enable the CDN, wait 15 minutes for propagation, then run the same test again from the same location. Use a test server location that represents your most distant significant audience segment for the most accurate comparison.

Kinsta CDN vs Adding Cloudflare to Kinsta

Kinsta CDN and Cloudflare serve different purposes and are not mutually exclusive. Kinsta CDN handles static asset delivery from within your Kinsta account, with no DNS changes required. Cloudflare sits in front of your entire domain, handling DNS, DDoS protection, bot filtering, and HTML caching (with Cloudflare page rules or Workers).

The main practical difference is HTML caching. Kinsta CDN does not cache HTML. Cloudflare (with appropriate page rules on a paid plan) can cache HTML for logged-out visitors, which reduces the number of PHP requests that reach your Kinsta server. For high-traffic blogs or marketing pages, this is meaningful. For WooCommerce or membership sites, HTML caching at the CDN level requires careful exclusion rules for cart, checkout, and member pages.

For most WordPress sites on Kinsta, enabling Kinsta CDN is the right first step. Adding Cloudflare on top makes sense if you need DDoS mitigation, stricter security rules, or HTML caching for pages that receive sustained high traffic from distributed visitor locations.

Final Word: Enabling Kinsta CDN on WordPress

Kinsta CDN is included in every plan and takes three clicks to enable in MyKinsta. For most WordPress sites, it immediately improves load times for visitors outside the primary data center region and helps Core Web Vitals scores. After enabling, verify the CDN is active using browser developer tools and clear your site cache if you notice stale content. For a full look at Kinsta’s features and plans, see the Kinsta review.