Hostinger’s CDN caches copies of your site’s static content on servers spread across multiple locations, so a visitor loads those files from a server near them rather than pulling everything from your site’s origin server every time. Hostinger’s own CDN panel describes three main benefits:
This is Hostinger’s own in-house CDN, not a Cloudflare integration, and that distinction matters for setup, covered further down.
Which Plans Actually Include It
Hostinger CDN is not available everywhere, and checking this before you go looking for it saves a wasted trip through hPanel.
| Plan type | CDN included |
| Premium Web Hosting | Yes |
| Business Web Hosting | Yes |
| Cloud Hosting | Yes |
| Agency Hosting | Yes |
| Single Web Hosting | No |
| VPS | No |
I confirmed this directly with Kodee, Hostinger’s support assistant. If you are on a Single or VPS plan, Hostinger’s own recommendation is to use Cloudflare instead, since its CDN is not built for those tiers.
I also asked whether higher tiers get a better or larger CDN network than lower ones. According to Kodee, they do not.
The available information does not point to extra edge locations, a different network, or guaranteed faster performance on higher plans; the CDN itself is the same regardless of which qualifying plan you are on. Plan tier changes your hosting resources, not your CDN.
If you want to find out more about Hostinger’s large array of plans and see a full breakdown comparison between them, our Hostinger review covers pricing and performance across the full range, while our daily updated Hostinger coupons page gives you a list of all available discount coupons.
How to Enable Hostinger CDN
Once you have a qualifying plan, turning the CDN on takes a few clicks inside the hPanel.
- Open your website’s dashboard. From Websites in the main hPanel menu, click into the specific site you want to manage
- Go to Performance, then CDN. This sits in the left sidebar alongside AI Troubleshooter, Object Cache, and Page Speed
- Check the current status. The CDN page shows whether the site is Active or Inactive, along with a short explainer of what the CDN does and the 40 percent speed claim
- Click Enable. The status flips to Active once it takes effect
Know this before you click Enable. Hostinger’s own CDN panel notes that DNS propagation after enabling can take up to 24 to 48 hours to fully complete, even though the toggle itself flips instantly.
If you plan to run your own speed test to check the impact, do not test right after enabling it. An early test can show flat or even worse results simply because the cache has not warmed up yet, not because the CDN failed. The performance section further down covers this in detail with real numbers.
A separate screen, Opt Out of Automatic CDN, matters if you manage multiple sites on one account. Hostinger enables the CDN automatically across your websites by default, so this page lets you select any specific site where you would rather keep it off.
Before enabling on any domain, confirm a few things first, since these prerequisites determine whether the CDN can actually activate:
- Your domain needs to use Hostinger’s nameservers
- Your domain needs to point to your hosting IP address
- Any third-party CDN, Cloudflare in particular, needs to be disabled first, since running two CDNs on the same domain can cause redirect loops and stale cached content
What You Can Configure Once It Is On
Clicking Manage next to an active CDN opens four tabs, each controlling a different part of how the CDN behaves.
Website Optimization
- WebP image compression. Automatically converts images to the more efficient WebP format to cut file size without changing any URLs
- Smart image optimization. Automatically resizes and compresses images separately for desktop and mobile visitors, with adjustable maximum width and quality settings for each
Traffic Blocking
- Block specific IP addresses individually
- Block or allow entire countries, switching between a blocklist approach and an allowlist approach depending on which is easier for your situation
Security
- Security level. A dropdown ranging from Essentially Off through Low, Medium, High, and a dedicated “I’m Under Attack” mode for challenging incoming requests based on how much of a threat they appear to pose
- TLS 1.3 toggle. Forces the latest TLS version only, with a note that some older devices and servers do not support it yet
- Traffic over TLS chart. Shows a breakdown of plain, TLS 1.2, and TLS 1.3 traffic over the past 24 hours
Analytics
- Cache statuses. Breaks down requests into Hits, Misses, Dynamic, Bypass, and Revalidated categories over a selectable time period
- Status codes. Tracks 2xx, 3xx, 4xx, 5xx, 429, and 444 response codes over the same window
- HTTP requests. A running total of requests over time
A Development Mode toggle also sits on the main CDN status page, useful for temporarily bypassing the cache while you are actively making changes to a site, without disabling the CDN outright.
Does It Actually Make Your Site Faster?
I ran GTmetrix tests on a live WordPress site hosted in Toronto, Canada, with the CDN off, then enabled it and tested again, from two different test locations.
Test 1, from Quebec City, close to the origin server
| Metric | CDN off | CDN on |
| GTmetrix Performance score | 90% | 89% |
| Structure score | 93% | 98% |
| Largest Contentful Paint | 1.5s | 1.6s |
| Total Blocking Time | 0ms | 6ms |
| TTFB | 738ms | 868ms |
| Fully Loaded Time | 1.6s | 1.6s |
Test 2, from Frankfurt, Germany, far from the origin server
| Metric | CDN off | CDN on |
| GTmetrix Performance score | 84% | 78% |
| Structure score | 96% | 97% |
| Largest Contentful Paint | 1.8s | 2.1s |
| TTFB | 834ms | 1.3s |
| Fully Loaded Time | 2.2s | 2.3s |
Both tests point the same way, and the second one is the more telling of the two. Frankfurt is exactly the kind of distant test location where a CDN should show its biggest advantage over a Toronto-hosted origin, and instead performance got worse across every metric, with TTFB jumping from 834ms to 1.3 seconds after enabling.
The most likely explanation is not that the CDN failed to help, but that the test ran too soon after enabling it to reflect how the CDN actually performs once it settles in.
Two things point to this:
- Hostinger’s own CDN panel states DNS propagation can take up to 24 to 48 hours after enabling, and this test ran only a few minutes after flipping the toggle on
- A CDN’s cache has to warm up. The first requests after enabling are cache misses, meaning the content still has to be pulled from the Toronto origin, but now through an added routing layer on top of that trip, which can actually be slower than a direct connection until the cache actually holds a copy
In other words, testing immediately after enabling a CDN is a common and easy mistake to make, and it produces exactly this kind of misleading result, a temporary dip that looks like the CDN is hurting performance rather than helping it.
The honest takeaway from both tests together is that a fresh CDN activation should not be judged on a test run minutes later. If you enable Hostinger’s CDN, the more reliable approach is to wait out that propagation window, let real traffic populate the cache, and then test, rather than checking immediately and assuming the first result reflects steady-state performance.
CDN, SSL, and DNS, What Changes
Turning the CDN on does not usually disrupt your existing SSL setup or DNS management, but a few specifics matter before you flip it on for a site with custom configuration already in place.
I confirmed the following with Kodee directly:
- Your domain must use Hostinger’s nameservers and point to your Hostinger hosting IP, the CDN cannot activate otherwise
- You cannot run Hostinger CDN and Cloudflare on the same domain at the same time
- Normal DNS management still happens in hPanel as usual, though any changes may still need to propagate
- Your existing Hostinger SSL setup usually continues working without extra steps
- If you plan to install a custom SSL certificate or make major DNS changes, disable the CDN first, make the change, then re-enable it afterward, rather than making changes while it is active
Should You Enable It?
Given that the CDN is included free on qualifying plans and Hostinger’s own claim of automatic enablement means it may already be on, the more useful question for most people is not whether to enable it, but whether to keep it on for a specific site.
A few situations where it makes the most sense:
- Your visitors are spread across multiple countries or continents
- Your site serves a lot of images or media that benefit from the built-in optimization
- You want the extra traffic blocking and security controls bundled in, separate from whatever your hosting plan already includes
And a few where disabling it, at least temporarily, makes sense:
- You are actively debugging a site and want to rule out caching as a variable
- You are about to install a custom SSL certificate or make major DNS changes
- Your entire audience is local and hosted in the same region as your origin server, where the distance-based benefit is smallest.
