I tested Namecheap’s Supersonic CDN on EYEscan, a Sitejet-built website hosted on Namecheap Stellar shared hosting. My goal was to see how easily the CDN connects to an existing website and how much it improves loading speeds.
The Free plan was straightforward to purchase, but DNS activation initially caused a 502 error. Once the website recovered, performance results were mixed: London’s server response improved, but full-page loading times increased in both test locations.
Read on as I examine Supersonic’s features, performance, ease of use, pricing, and support.
I evaluated Namecheap Supersonic CDN using the HostAdvice hosting rating methodology, adapting its pricing, features, performance, ease-of-use and support criteria to a CDN service.
My scores reflect the Free plan I tested, the GTmetrix results from Chicago and London, and my experience with Namecheap’s support and documentation.
Generous 50 GB Free plan; flexible upgrade options
Read MoreUseful SSL, caching, and analytics controls
Read MoreLondon TTFB improved, but full loads were slower
Read MoreEasy purchase; extra DNS steps and initial 502 error
Read MoreFast live chat and useful guides; no confirmed resolution
Read MoreGood overall value, practical features, and promising performance
Generous 50 GB Free plan; flexible upgrade options
Read MoreUseful SSL, caching, and analytics controls
Read MoreLondon TTFB improved, but full loads were slower
Read MoreEasy purchase; extra DNS steps and initial 502 error
Read MoreFast live chat and useful guides; no confirmed resolution
Read MoreGood overall value, practical features, and promising performance
Supersonic CDN comes in Free, Basic, Medium and Advanced plans. The main published distinction is monthly traffic: 50 GB, 250 GB, 500 GB and 1,000 GB respectively.
Other differences and limits matter too, particularly for websites that expect traffic spikes or need more protection.
I tested Free on Namecheap Stellar shared hosting; I did not purchase the paid plans, so I separate what I observed in my account from the provider’s published specifications.
The Free order was genuinely $0.00 throughout checkout, and the completed receipt confirmed that nothing was charged. Apps → Subscriptions subsequently displayed auto-renewal for November 14, 2026, again at $0.00.
I could purchase without adding SSL, email or another hosting product, despite the upsells presented in the cart.
For the buyer, price is only part of the decision. The question is how easily the plan connects to an existing domain, what happens at its traffic limit and if the included controls work when you need them.
My Free subscription gave me access to cache, SSL and analytics settings. CDN delivery was eventually confirmed by an HTTP 200 response from the London edge, although that request bypassed caching. I cover the checkout screens and the setup failure in Ease of Use.
A CDN should make a website faster for visitors, not just add another service to the hosting account.
I wanted to see what Supersonic actually changed on my EYEscan website, so I measured the page before enabling the CDN and again after Supersonic successfully started serving it.
I focused on Chicago and London: one location where the original site was already quick, and another where there was more room to reduce the wait for a response.
The headline result was mixed. London received the first byte sooner after activation, but the full page took longer to load. Chicago also showed a longer loading time than in the original test. Here’s how I tested those differences and what they do, and don’t, establish.
To assess Namecheap Supersonic CDN’s performance, I tested my EYEscan website before and after enabling the service. The website was built using Sitejet Builder and hosted on Namecheap’s Stellar shared hosting plan. I wanted to see how the CDN affected loading speed in different locations, particularly where the original website was already performing well.
I used GTmetrix for both rounds of testing, keeping the browser and testing environment consistent. Here’s how I approached the tests:
I kept the same website and hosting plan throughout the comparison. The switch to the www hostname was necessary for Namecheap’s shared-hosting CDN configuration. Although GTmetrix reported 0 ms of redirect time in the after-CDN tests, the different hostnames mean the testing conditions weren’t perfectly identical.
I also checked the website’s HTTP response headers and confirmed that requests were passing through Supersonic using x-supersonic-pop. However, I hadn’t independently verified that static resources were being served from the CDN cache.
Each location had one recorded test before and after activation, so the results represent individual measurements rather than averages. With that established, let’s compare how the website performed in Chicago and London.
| Metric | Chicago Before | Chicago After | London Before | London After |
|---|---|---|---|---|
| Performance | 100% | 97% | 94% | 93% |
| Structure | 96% | 96% | 94% | 95% |
| TTFB | 263 ms | 377 ms | 568 ms | 330 ms |
| FCP | 638 ms | 827 ms | ~1.2 s | 1.3 s |
| LCP | 672 ms | 1.1 s | ~1.2 s | 1.3 s |
| Total Blocking Time | 12 ms | 0 ms | 0 ms | 0 ms |
| Cumulative Layout Shift | 0 | 0 | 0 | 0 |
| Time to Interactive | 731 ms | 1.2 s | 1.3 s | 1.3 s |
| Fully Loaded Time | 869 ms | 2.0 s | 1.6 s | 2.4 s |
I started in Chicago because the original Stellar-hosted site had already set a strong benchmark. Without Supersonic, GTmetrix gave EYEscan 100% Performance and 96% Structure.
The server responded in 263 ms, the largest visible content appeared in 672 ms, and Fully Loaded Time was just 869 ms. Total Blocking Time was 12 ms and Cumulative Layout Shift was zero. For a small demonstration site, those were excellent starting figures.
After Supersonic was active, I ran GTmetrix from Chicago again. The Performance score was still strong at 97%, with Structure unchanged at 96%, but the timing metrics had worsened.
TTFB increased to 377 ms, FCP to 827 ms, LCP to 1.1 seconds, and Fully Loaded Time to 2.0 seconds. The new report recorded zero Total Blocking Time and zero layout shift, so responsiveness and visual stability remained good.
In absolute terms, the first byte took 114 ms longer and the page’s Fully Loaded Time increased by approximately 1.13 seconds. That is a substantial difference in these two captures, especially given how fast the original website had been.
It does not prove that Supersonic always slows Chicago visitors down. Each condition was measured once, and browser, server, network and third-party resource variation can influence one run.
The London baseline gave me a useful contrast. Before enabling Supersonic, the site scored 94% for Performance and 94% for Structure.
TTFB was 568 ms, LCP was around 1.2 seconds, and the page finished loading in 1.6 seconds. Total Blocking Time and layout shift were both zero. London was slower to receive the first byte than Chicago, but the complete page still loaded quickly.
After activation, London produced a different pattern from Chicago. TTFB dropped to 330 ms, a 238 ms improvement over the baseline. The Structure score also rose slightly, from 94% to 95%.
However, Performance slipped from 94% to 93%, LCP increased from approximately 1.2 to 1.3 seconds, and Fully Loaded Time rose from 1.6 to 2.4 seconds. FCP was 1.3 seconds, and both Total Blocking Time and Cumulative Layout Shift remained at zero.
The improvement in TTFB is encouraging: the page began responding about 42% sooner than it did in the original London run. But that faster initial response did not translate into a faster fully loaded page; the new result was 800 ms longer overall.
The available summary does not identify the exact resources responsible for the additional loading time. I would need a careful waterfall comparison and repeated tests before attributing it to caching behavior or network routing.
The performance reports are only useful if the after-CDN requests actually travel through Supersonic. Earlier in the setup, the website briefly returned HTTP 502 from the Frankfurt edge.
After that failure cleared, I opened the EYEscan homepage again and checked its HTTP response directly. The page returned HTTP/2 200, x-supersonic-pop: LHR, x-upstream-status: 200 and the same 86,938-byte HTML content length observed from Stellar hosting. That established that the London edge could retrieve and serve the correct site.
One detail limits what I can conclude: the HTML response contained supersonic-cache-status: BYPASS. In other words, that homepage request was delivered through Supersonic but not served as a cached HTML hit.
This does not rule out caching of the site’s images, stylesheets or scripts; I simply had not verified HIT responses for those resources.
The GTmetrix results therefore measure the observed page-loading experience with the CDN connected, not a confirmed fully cached page.
The original Stellar-hosted EYEscan site performed well without a CDN. After enabling Supersonic, London TTFB improved from 568 to 330 ms, while Chicago TTFB increased from 263 to 377 ms.
In both locations, the single captured after-CDN Fully Loaded Time was longer: 869 ms to 2.0 seconds in Chicago, and 1.6 to 2.4 seconds in London. The new pages still scored 97% and 93% for Performance, with no measured layout shift or Total Blocking Time, but I cannot say the CDN made this website faster overall.
These are preliminary comparisons, not definitive benchmarks: there was only one captured run per location in each condition, the tested hostname changed from the root domain to www, and static-file cache hits were not verified.
The reports do not identify why the page’s total load increased. I would repeat the tests and inspect the waterfall before assigning a final Performance score or making a general claim about Supersonic’s network.
For this part of the review, I wanted to answer a practical question: how much work does it take to get Supersonic serving a website that is already hosted by Namecheap?
Buying a CDN is only the beginning. The real test is connecting the domain, keeping HTTPS working, finding the controls you need and getting the first visitor through the edge network without breaking the site.
I followed the process in the order a customer would encounter it. I bought the Free plan, located its management panel, connected my Stellar-hosted Sitejet website, completed the shared-hosting redirect and applied the CDN DNS records.
At every stage, I checked what worked before moving on. That sequence also revealed where the interface was convenient and where its reassuring status messages concealed work still to be done.
I began in my existing Namecheap account. Supersonic was easy to find under Security → CDN, and the product page separated the paid plans from its Get Free – Forever offer.
Because I already had Stellar hosting and a live EYEscan demo on 2test.website, I could begin with Free rather than buying more traffic allowance before I knew the service would work.
Selecting the free offer added Supersonic CDN – Free to the cart at $0.00. Namecheap placed hosting, business email, WordPress hosting, SSL and other upgrades below the order. I could ignore them, but they made a simple purchase screen longer than necessary.
The order review kept the total at $0.00, even though the confirmation button was labelled Pay Now. I checked the plan and amount once more before proceeding.
I submitted the order using the billing details already on the account. Namecheap displayed an order-processing screen while the Free subscription was provisioned.
When processing finished, the receipt confirmed a $0.00 charge and displayed Manage beside the new subscription. There was no surprise payment or paid add-on attached to the order.
After the confirmation, I clicked Manage expecting to start connecting the website.
Instead, Namecheap opened Apps → Subscriptions. The Free plan was listed at $0.00, with auto-renew enabled for November 14, 2026. It confirmed that I had a subscription, but it was not yet the place to configure content delivery.
I switched to My Apps, where Supersonic appeared as an installed application. Clicking its icon opened the CDN’s own sign-in page rather than the setup wizard.
The next page let me log in with Namecheap, and I could continue with the account already active in the browser. That avoided creating new credentials, but it still added a second authentication handoff before I could manage the CDN.
The first dashboard said there was one website to set up. It also gave the Free subscription an Active label. That wording can be confusing: it indicated an active subscription, not proof that a website was already receiving CDN traffic. From there, I chose Set up website rather than purchasing another plan.
The setup wizard detected 2test.website automatically in my account. I selected it from the dropdown and continued.
Namecheap’s shared-hosting documentation explains that the main domain on a hosting plan does not require manually entering its server IP, and that matched my experience: the wizard took me directly to Activate now.
I checked that the selected domain was 2test.website and proceeded to the final confirmation screen. The Activate now button made it clear which website I was about to connect, without asking me to enter a server IP.
After I clicked Activate now, Supersonic displayed a success notification saying the website had been added and the remaining configuration was being finished. The site had a green indicator, although the dashboard still showed 0 B and zero requests.
There was also an Important warning telling shared-hosting customers to create a redirect before setup was finished. I did not treat the green status as the end of the process. Without the required redirect and correct DNS routing, customers would not necessarily reach a functioning CDN.
Next, I checked which nameservers the domain used. The Namecheap domain-management page showed Web Hosting DNS, and the company’s shared-hosting CDN guide says this configuration needs a redirect from the bare domain to the www address in .htaccess. BasicDNS or PremiumDNS users follow a different DNS path, so changing nameservers just to bypass this step would not have been sensible.
I opened cPanel File Manager and inspected the website’s .htaccess file before touching it. Although EYEscan was built with Sitejet Builder, that file contained LiteSpeed Cache and WordPress rewrite blocks from an earlier configuration.
I left those sections unchanged rather than risk disturbing active routing rules.
After confirming that https://www.2test.website/ already loaded the EYEscan homepage securely, I made a backup of .htaccess and added a separate 302 rule for non-www requests.
The bare domain then redirected to the www version, and the site still loaded. I kept the redirect temporary while testing instead of locking in a permanent 301 too early.
At this point I returned to Supersonic. The Overview screen said Online, yet its bandwidth and request charts still showed zero.
Under Quick Actions, I found DNS Records → Apply, a separate step that had not appeared in the earlier activation wizard.
I selected Apply to complete the DNS routing. Namecheap immediately displayed a green notification saying the records had been successfully applied.
The change was not an uncomplicated success. Both public addresses now led to a Supersonic-branded error screen saying it could not connect to the origin server.
The page reported 502 Bad Gateway and identified the Frankfurt edge. The website that had loaded moments earlier was no longer accessible through its public URL.
I confirmed the failure using curl. The www address resolved to Supersonic and returned HTTP/2 502, including x-supersonic-pop: FRA and x-upstream-status: 502.
The root domain still resolved to Stellar and returned the expected 302 redirect to www, so the earlier .htaccess rule had not stopped working. The request was now failing after visitors reached the CDN.
Rather than change settings at random, I compared the generated Supersonic origin with the actual Stellar website.
Its origin hostname resolved to the correct shared-hosting IP, 198.xx.xxx.49. I then bypassed the CDN and addressed the Stellar server directly over HTTPS using the www host name. It returned HTTP/2 200 and the correct 86,938-byte EYEscan page.
A separate HTTP request to the generated origin hostname returned HTTP/1.1 200, but the content was only 163 bytes and carried a different Last-Modified date.
That was a valuable clue: the hostname resolved, but the server did not appear to serve the same website when contacted under that name. I could not establish from those tests alone if the cause was virtual-host matching, the Host header, the origin protocol or another CDN-side issue.
The CDN Settings page also showed an HTTP origin protocol, while the SSL page displayed Custom SSL as Protected for visitors. I deliberately left both settings unchanged until support could check the correct origin configuration.
The mismatch was enough to take to Namecheap live chat as a reproducible technical problem, without risking further damage to the website.
The comparison table below brings together the checks that established where the failure occurred.
| Diagnostic | Observed response | What It Establishes |
|---|---|---|
| www via Supersonic | HTTP/2 502 · Frankfurt | CDN receives requests, but cannot serve site |
| Root-domain request | HTTP/2 302 to www | Temporary apex redirect works |
| Generated origin DNS | 198.54.115.49 | Points to Stellar hosting IP |
| Direct www over HTTPS | HTTP/2 200 · 86,938 bytes | Correct EYEscan website available at origin |
| Generated origin via HTTP | HTTP/1.1 200 · 163 bytes | Different content served for origin hostname |
| CDN overview | Online · 0 B · 0 requests | Dashboard alone doesn’t confirm delivery |
The Free plan was quick to buy, domain selection was automatic and the interface exposed useful controls. But setup required a manual redirect, a separate app login and another DNS action.
The DNS change initially left the site returning 502 despite an Online badge. It later recovered and delivered the original homepage through Supersonic’s London edge, without a confirmed explanation from support. This was ultimately a functioning setup, but not a seamless one.
I would not generalize this temporary failure to every Supersonic installation. It happened with the specific Sitejet website, Stellar origin and Web Hosting DNS configuration I tested. The support section examines the agent’s response and the limits of what that conversation established.
When a CDN stops serving a website, the quality of support matters as much as its features. I checked the ways customers can get help before putting Namecheap’s support to the test.
Namecheap advertises round-the-clock live chat and email assistance, offers a support-ticket route, and maintains an online knowledgebase. It does not provide telephone support.
| Support channel | Availability | What customers can use it for |
|---|---|---|
| Live chat | 24/7 | Real-time help with urgent setup and site errors |
| Email / support ticket | 24/7 | Written technical requests and file attachments; responses vary by complexity |
| Knowledgebase | Anytime | Self-service guides covering Supersonic setup, DNS, SSL and caching |
| Phone | Not offered | No telephone support; use chat or email instead |
For this review, I tested the two routes that were directly relevant to my Supersonic setup: live chat and the knowledgebase.
I used the real HTTP 502 error that appeared after applying the CDN DNS records, then checked how closely the written instructions matched the interface I had just used. I did not submit a separate email ticket, so I cannot independently judge email response times.
The support test began after Supersonic started returning 502 Bad Gateway for 2test.website.
I had already verified that the www DNS record led to Supersonic’s Frankfurt edge, while bypassing the CDN and connecting directly to my Stellar server returned the actual EYEscan homepage with HTTP 200.
I also found that the generated CDN origin hostname returned a different 163-byte response. Rather than ask a generic question, I sent these findings to support and asked them to check origin routing, the virtual host, HTTP Host header, and protocol settings.
I opened the chat at 12:55 PM on October 14. Suzy Q immediately acknowledged the problem, summarized the checks I had already completed, and asked about recent .htaccess changes, security plugins, firewalls, and custom redirects.
Those were relevant questions because I had added a temporary non-www to www redirect as required by Namecheap’s shared-hosting CDN guide.
However, the first response was still a triage step rather than a technical diagnosis.
Bohdan K. joined during that same minute and asked for five to ten minutes to examine the earlier conversation.
Around 1:00 PM, he returned with a screenshot link and said the website was loading from his side, then asked how he could reproduce the 502.
That was a reasonable request given that the error appeared intermittent or had already started recovering. It also showed he had checked the public website rather than simply copying a troubleshooting article.
The weakness was that the chat did not get far enough to establish what caused the failure.
Bohdan did not provide a confirmed explanation of the generated origin hostname, Host header, or upstream protocol in the replies I received.
He followed up when I did not respond, and the session expired after I missed his messages. That part of the incomplete conversation was due to my absence, not a refusal by Namecheap to continue troubleshooting.
I later checked the website again myself. EYEscan loaded correctly and curl returned HTTP/2 200 through Supersonic’s London edge, with x-upstream-status: 200.
The same response reported supersonic-cache-status: BYPASS, so it confirmed working content delivery rather than a cache hit. The website recovered, but neither the chat transcript nor my subsequent checks established the precise cause of the original 502. I therefore cannot credit the agent with implementing a verified fix.
I also went through Namecheap’s Supersonic CDN knowledgebase, focusing on the articles a Stellar shared-hosting customer would actually need. The collection includes purchase and activation instructions, shared-hosting setup, an overview of CDN controls, SSL installation, and service removal.
The articles are broken into steps with screenshots and links to related guidance, so I could move from the initial setup instructions to the specific DNS and SSL details without starting my search over.
The most useful article was How to setup Supersonic CDN with Shared hosting. It explains that a primary domain attached to a hosting package may skip the manual origin-IP entry, exactly as I observed when I selected 2test.website. More importantly, it states that domains using Web-Hosting DNS need an .htaccess redirect to the www version. That specific instruction helped me make the redirect safely while leaving my existing rewrite rules untouched.
The Supersonic CDN overview gave me context for the Origin Address, cache lifetime, query-string handling, and global cache purging. It made the dashboard easier to interpret and helped me separate the available controls from the tests I had not yet performed.
I also checked the dedicated SSL guide, which describes using Fetch from Hosting to bring an existing certificate from Namecheap shared hosting into Supersonic.
Where the knowledgebase fell short was in matching my actual account journey. The shared-hosting article describes a route from purchase into the setup dashboard, but I first landed in Apps → Subscriptions, then had to open My Apps and sign into Supersonic separately.
It also describes an SSL upload-or-skip step during activation; I did not see one. My SSL page already showed Custom SSL as Protected.
These differences do not mean every customer sees the same screens I did, but they matter when a reader is following the instructions click by click.
The instructions also did not prepare me for the separate DNS Records → Apply action in my dashboard or explain how to verify that an Online status actually meant the website was serving through the CDN.
When that DNS change initially led to HTTP 502, the setup article did not give me a targeted diagnostic sequence for checking the CDN edge, origin hostname and direct hosting response. I had to compare those independently from my terminal. More explicit verification and recovery guidance would make the documentation considerably more useful for real deployments.
Namecheap makes assistance easy to reach. Its live chat connected me to a human quickly, and the knowledgebase supplied the key instructions for configuring Supersonic with Stellar shared hosting. Those are meaningful strengths, especially for someone setting up a CDN for the first time.
Still, I would separate responsiveness from resolution. The agent checked my website and requested a way to reproduce the error, but we did not complete that investigation before the chat expired.
The site later recovered independently, and the available evidence does not show what fixed the upstream problem. Meanwhile, some knowledgebase screens and steps differed from the live interface.
My overall assessment is that Namecheap offers accessible, useful support for basic setup, but this test did not establish how effectively it resolves a difficult CDN-origin fault end to end.
Yes, I would recommend Namecheap Supersonic CDN to website owners looking for an affordable way to add CDN functionality, particularly those already using Namecheap hosting. Its Free plan includes 50 GB of monthly traffic alongside useful caching, SSL, and analytics controls, making it an attractive starting point for smaller websites.
My experience wasn’t entirely smooth. Although purchasing and activating the service was straightforward, the DNS configuration initially caused a 502 error. The website eventually recovered, and I confirmed that Supersonic was successfully delivering content through its London edge.
Performance results were also mixed. London recorded a faster server response after activation, but fully loaded times increased in both Chicago and London during my tests. These were limited, single-run comparisons, so I wouldn’t treat them as conclusive evidence of the CDN’s overall performance.
Overall, Namecheap Supersonic CDN offers a compelling Free plan, practical management features, and accessible support. I would recommend trying it on a small website, provided you’re comfortable checking DNS settings and verifying performance after activation. For performance-critical websites, I’d want more testing before relying on it as the primary CDN.
| Description | Expert Review |
|---|---|
| Prisgunstig delt hosting med solid ytelse og enkle administrasjonsverktøy. | Read Shared Hosting Review |
| Read Email Hosting Review | |
| Optimalisert WordPress-hosting med raske hastigheter, forbedret sikkerhet og støtte. | Read Wordpress Hosting Review |
| Skalerbar VPS-hosting med dedikerte ressurser og full root-tilgang. | Read VPS Review |
| Kraftige dedikerte servere med full kontroll, tilpasning og høy ytelse. | Read Dedicated Server Review |
| Skalerbar forhandlerhosting med white-label-alternativer og fleksible planer. | Read Reseller Hosting Review |
| Read Domain Registration Review | |
| Read Namecheap MCP Review | |
| Read PremiumDNS Review | |
| Read AI Website Builder Review | |
| Read API Review | |
| Read cPanel Hosting Review |
Yes. Namecheap offers a Free plan with 50 GB of monthly traffic. I activated it without paying anything, and both my receipt and renewal details showed $0.00. Paid plans are available for websites that need more bandwidth.
Yes. I successfully connected Supersonic to my Namecheap Stellar shared hosting account. However, because my domain used Web Hosting DNS, I had to configure a www redirect and apply the CDN’s DNS records. The website initially encountered a 502 error but later worked correctly.
Yes. Supersonic needs your domain’s traffic directed through its CDN network. In my test, I used the DNS Records Apply option in the dashboard. I recommend checking that your website loads correctly after making these changes.
Yes. My Free account displayed an active Custom SSL certificate with a Protected status, and the website loaded successfully over HTTPS. However, my origin connection was configured to use HTTP, so HTTPS protection between visitors and the CDN did not mean the connection to the hosting server was encrypted.
My results were mixed. London’s Time to First Byte improved from 568 ms to 330 ms, but Fully Loaded Time increased in both Chicago and London. Both locations still achieved strong GTmetrix Performance scores of 97% and 93%, respectively. These were single-run comparisons, so more testing is needed to establish consistent speed improvements.
Yes. The dashboard includes a Purge All option, alongside controls for cache lifetime, query strings, and excluded paths. These settings can help manage content updates, although I did not independently complete a cache-purge verification test.
Namecheap’s shared-hosting setup documentation states that subdomains are not supported through its standard Supersonic configuration. My testing covered the primary domain, 2test.website, rather than a separate subdomain. Check the current compatibility requirements before purchasing a plan for a subdomain.
Besvar noen enkle spørsmål og finn den perfekte løsningen for deg!
Start hosting-søk
