Running an Optimizely Site in China: China CDN vs In-Country Hosting vs a Delivery Layer

The short version. An Optimizely site needs two things to work in mainland China. First, a Chinese legal entity with an ICP filing; without it the site can’t be served in China at all. Second, a way to deliver the whole page to a visitor inside China: the Optimizely Graph calls, forms, Experimentation and analytics scripts, video and third-party resources, not just the static files. There are three delivery options. A China CDN caches static files only. In-country hosting redeploys the front end to Azure China and still calls Graph across the border on every page load. A delivery layer (the 21YunBox Optimizer) keeps the site where it is and carries every request on a licensed path. For a SaaS CMS site that uses Graph, forms, search, bookings or Experimentation, only the third option covers the whole page. Details, a side-by-side table and an FAQ below.

“China CDN is not a silver bullet for every use case.” That’s not us talking. That’s John Håkansson, Optimizely’s product lead for the DXP Cloud platform, in Optimizely’s own guidance on China from 2021. He was right, and five years on it’s truer than when he wrote it.

His post makes three points worth keeping. A China CDN gives cached content a big boost. Dynamic content is often better served from an origin close to China than through the CDN. And you need an ICP license before the CDN can be used at all. His advice: “Test and verify your use cases before you move ahead with the ICP license.”

Two things have changed since. SaaS CMS and Optimizely Graph mean the content on a modern Optimizely site arrives at runtime, so testing your use cases now mostly tells you the CDN won’t cover them. And the question his readers asked in the comments, who actually files the ICP, still has no answer on that page.

So when someone asks for “a China CDN line item,” the honest response is the one Optimizely gave in 2021: it helps with part of the problem. This is the rest of it.

Two gates, in order

Every China site has to get through two gates. The order matters, and a CDN sits in neither.

The first gate is legal. Without it, your site isn’t slow in China — it can’t legally be served at all. The second gate is technical. Optimizely’s SaaS platform, Optimizely Graph, your editors’ login, your forms and your scripts all live outside China, and something has to make each of them work from inside.

A China CDN answers a narrow slice of the second gate: it moves your static files closer. It does nothing for the first gate and nothing for the rest of the second. That’s why it looks cheap.

Gate one: can you legally operate?

In mainland China, a website needs a government filing before it can be served. It’s called an ICP filing (备案). Without it, the domain can’t be served from inside China, full stop. No CDN and no hosting setup gets around it.

To get one you need three things:

1. A Chinese legal entity. The filing is issued to a company registered in China, not to your global parent. If you have a China subsidiary or a WFOE, that’s usually the one.
2. The filing itself. It’s tied to the infrastructure that serves the site, so whoever delivers the site in China is involved in the paperwork. It takes weeks, not days, and under the Measures for the Administration of Internet Information Services it has to be renewed and kept current.
3. Someone who owns it. Not a one-time project. Domain changes, entity changes and annual reviews all touch it.

This is the part a CDN quote never mentions. A China CDN can be switched on in an afternoon, which is exactly why it feels like the easy first step. Then the domain doesn’t resolve in China, and the question of who owns the entity and the filing lands on the project six weeks before launch.

One practical note for Optimizely projects: because the filing is tied to the China infrastructure, it’s worth settling the architecture before starting the paperwork. Filing against a CDN and then moving to a delivery layer means doing parts of it twice. We set the filing up on your entity and manage the renewals. If you already have one, we work with it.

Gate two: does it actually work?

This is the part Håkansson was describing: cached content wins, dynamic content doesn’t, and a modern Optimizely site is almost all dynamic.

Here’s the thing about Optimizely’s SaaS platform: it runs on global infrastructure and it isn’t going to run in China. Your content lives in Optimizely. Your front end (usually Next.js on Netlify or Vercel) calls Optimizely Graph for that content at runtime. Your editors log in to the Optimizely UI. None of that is in China, and none of it moves. There are three ways to deal with that.

On the older PaaS setup (CMS 12 on Azure), some teams solved this by standing up a separate China instance. That’s the thing SaaS was supposed to end: two CMSs, two codebases, two publishing workflows. Nobody wants to go back to it.

So every China option for an Optimizely site is really an answer to one question: how does a visitor in Shanghai get the page, the content from Graph, the form, the video and the scripts, and on whose road?

A China CDN. This is the option that shows up as a line item. Cloudflare China, Akamai China, Alibaba’s CDN. The CDN caches your static files (JavaScript, CSS, images) on servers inside China, so those load fast. Everything else on the page still goes where it always went: the Graph query to Optimizely, the form post to HubSpot, the YouTube embed, the Google Tag Manager call. The CDN doesn’t see those, so it doesn’t help them. For a brochure site with no runtime content, that can be enough. For an Optimizely site built the way Optimizely sites are built now, it isn’t.

A delivery layer over your existing site. Your site stays exactly where it is. A licensed delivery layer inside China handles the visitor, carries every request on the page across the border on a compliant path (static, Graph, forms, third-party), and leaves anything that already works alone. One CMS, one codebase, one deploy, no China fork, and the global and China sites stay in parity. This is our 21YunBox Optimizer, and it’s what we recommend for most Optimizely sites.

In-country hosting. The third option, and the one that gets called a CDN when it isn’t. You redeploy your front end (the rendering host) to a cloud inside China, usually Azure China. Visitors hit a server in-country, and that server calls back across the border to Optimizely Graph on every page load. Products like Arc by Dataweavers do this. It’s a real option when your organization has decided the front end must physically sit inside China. The cost is a second deployment target with its own pipeline and releases, the Graph call still crosses the border (from the server instead of the browser), and everything in the next section is still yours to solve. Ask who holds the license for that crossing.

None of the three is wrong. They fit different sites. The trouble starts when a CDN, or a hosting product described as one, gets quoted for a site that needs the delivery layer, and nobody finds out until the booking form fails in Shanghai.

What a China CDN doesn’t touch

When a client first asks about China, they ask about hosting, a CDN and the ICP filing. That’s the part above the waterline. What decides whether the site actually works sits below it, in the application layer, and it’s the part a CDN conversation never reaches.

Say the CDN is on and the ICP is done. Here’s what’s still broken on an Optimizely site, because none of it is a static file.

Optimizely Graph. This is the one that surprises people. On SaaS CMS, the front end doesn’t have the content baked in; it asks Optimizely Graph for it at runtime, over GraphQL. Every page load from Shanghai is a cross-border API call. Slow Graph means the page renders late. Blocked Graph means it renders empty. A CDN caches the shell; it has no idea the shell is waiting on Graph. We’ve watched this exact failure on a SaaS build: the page loads, the content doesn’t.

Search and anything dynamic. Site search, product or hotel listings, availability, personalization. Same pattern: a runtime call to a service outside China that the visitor’s browser has to complete.

Your forms. The form is on the page, but the submission goes somewhere. Optimizely Forms posts to Optimizely. HubSpot and Marketo forms post to HubSpot and Marketo. All outside China. If the browser can’t reach that endpoint, the form fails silently, and you find out when someone asks why China leads dried up.

Your editors. Your China content team logs in to the Optimizely UI, which isn’t reliably reachable from inside China. The usual advice is a VPN. We don’t recommend that, and we’d be careful about any vendor who puts it in writing. We give editors a managed, licensed connection instead. No VPN, no China IT team pulled into it.

Experimentation and analytics. Optimizely Web Experimentation is a script the visitor’s browser loads from outside China. So are Google Analytics, Adobe Analytics, your tag manager and your ad pixels. Blocked scripts mean your experiments don’t run in China and your dashboards show a China audience that doesn’t exist, which usually gets read as “nobody in China visits us.”

Your video. YouTube and Vimeo are blocked outright, and there is no compliant way to unblock them. We don’t route around the Firewall, and neither should anyone you work with. The fix is to host the video on a platform that is reachable inside the mainland and remove the blocked embed. Wistia, Brightcove and Vidyard are third-party players that may or may not load, and those the delivery layer can carry. A page with a YouTube embed is a page with a blank box on it, whatever sits in front of it — the choices are laid out in our guide to video playback in China.

Your other third-party scripts. Google Fonts, Google Maps, chat widgets, consent banners. Each one is a call from the browser to a server outside China. Some are blocked, some time out, and the page hangs while it waits. This is what usually breaks a China site in practice.

Your personal data. You’ll be told that personal data “must stay in China.” That’s one option, and the heaviest one. China’s privacy law (PIPL) regulates the cross-border transfer of personal information; it doesn’t ban it. For a marketing site with modest form volumes, nothing is usually required. As volumes grow, there’s a filing route with the regulator (the CAC) that lets you keep sending leads to your global CRM. Forced localization is for when volume, sensitivity or your own risk appetite calls for it. We help you pick the lighter one that still complies. (For how far this reaches across a typical stack, we read 763 SaaS tools against China’s own rules.)

China CDN vs in-country hosting vs delivery layer, side by side

Here’s how we’d sort it. Be honest about which column your site is in.

If your China site is a handful of static pages and nothing on it talks to a server, a China CDN is a reasonable place to start. If you’re an Azure shop with a mandate that the front end sits in-country and the entity and ICP already sorted, in-country hosting is a reasonable choice. In both cases, budget for everything below the waterline separately, because neither includes it.

If your site uses Graph, has a form that matters, runs Experimentation, or needs a booking or search flow to work, the CDN will load the shell and the rest will fail. That’s most of the Optimizely sites we see, and the Optimizer is the fit. The same framework, for a Sitecore stack, is in How to Run SitecoreAI in China: Hosting, Licensing, and Everything Else.

Where to start

If China’s on the roadmap, don’t start with a CDN line item. Start with two questions: do you have a Chinese entity, and does your site do anything at runtime that matters (Graph, forms, search, Experimentation, video, bookings)? The answers decide the architecture, and the architecture decides the filing.

If you’d like a second opinion on where your site stands today, send us the URL and we’ll run the in-China assessment. No cost, no commitment, and you’ll get real numbers either way.

hello@21yunbox.com