How do you make a Netlify site fast and compliant in China?
If you came to make a Netlify site faster in China, the honest answer is that speed is only one of two gates — and it is not the gate that decides whether you may serve the mainland at all. Netlify is excellent global hosting, but its network sits entirely offshore, and that one fact sets both answers that matter for a China audience.
Netlify describes its fastest network as "Globally distributed nodes in every major geography" across "70+ global Points of Presence" — a footprint its own location lists bring no closer to the mainland than Singapore and Tokyo, both offshore. Two consequences follow for a public China-facing site. It is served from outside the country, so there is no licensed in-country host for an ICP filing (备案) to attach to (State Council Order 292; MIIT Order 33); and every mainland visitor's request — their real IP, request logs and any form data — crosses the border, which PIPL governs as a cross-border transfer of personal information (Articles 38–43). The table below sets Netlify's own wording against the rule each gate triggers.
This is a risk map, not a verdict — which gate binds first turns on whether you serve the public in China, your entity, and the data your site collects. Our China team can map your Netlify exposure and the filing path with you →
Why speeding up Netlify in China runs into a second gate
| Fact | Primary source |
|---|---|
| Netlify's fastest network is global by design, and even it stops at the border. Netlify describes its High-Performance Edge — "Only available in Netlify Enterprise plans" — as "Globally distributed nodes in every major geography" across "70+ global Points of Presence," a network it "dynamically adjusts … across the globe." "Every major geography" is the claim, and a node inside mainland China is not part of it — so even Netlify's premium tier reaches the mainland only from outside it. | Netlify — High-Performance Edge (netlify.com), retrieved 2026-10-07 |
| By Netlify's own location lists, the nearest nodes sit offshore, on the far side of the Great Firewall. On the company's support forum, Netlify staff say "We don't publish an authoritative list since things can change frequently," and the lists they have posted come no closer to the mainland than Singapore and Tokyo — no Beijing, Shanghai, Hong Kong or other mainland entry appears. Serving mainland visitors from Singapore or Tokyo does not remove the border crossing; it only moves where the crossing ends. | Netlify Support Forums — CDN points-of-presence thread (answers.netlify.com), retrieved 2026-10-07 |
| A public mainland site has to be ICP-filed, and an offshore edge gives the filing nothing to attach to. Serving a public website to people in mainland China requires an ICP filing (备案) bound to a hosting resource physically inside the mainland and to a mainland legal entity (State Council Order No. 292, Article 4; MIIT Order No. 33). A network whose points of presence are all offshore — however many "major geographies" it spans — has no in-country host for that filing. The gate is where the server sits, not how the site is built or deployed. | State Council Order No. 292 (Measures for the Administration of Internet Information Services), Article 4; MIIT Order No. 33 — retrieved 2026-10-07 |
| Serve the mainland from offshore and your visitors' data leaves the country with every request. A mainland visitor's real IP address is personal information, and so are their request logs — and more, if the page carries forms, logins or analytics. Carrying that out to an offshore node is a cross-border transfer under PIPL (Chapter III, Articles 38–43: notice, separate consent, and one permitted transfer mechanism — a CAC security assessment, the CAC standard contract, or certification). For a critical information infrastructure operator or a large-volume handler, that personal information must also be stored inside the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). | PIPL Chapter III, Articles 38–43 and Article 40; Cybersecurity Law Article 39 (formerly Article 37) — retrieved 2026-10-07 |
Sources verified by the 21YunBox compliance team on 2026-10-07.
Netlify is one of the best places in the world to build, deploy and ship a modern website, and nothing here asks you to leave it. Your site keeps its Git-driven deploys, its build pipeline and its global edge. This page is about the one thing a public, mainland-China audience adds on top — and why that thing is not, in the end, a speed problem. Serving the mainland clears two separate gates: your content has to arrive quickly and reliably, and you have to be permitted to serve it from inside the country at all. The second gate is a compliance question, and it is the half of “does Netlify work in China” that no amount of build tuning, image compression or CDN configuration can answer — because it was never the network’s job to answer it.
Netlify in China at a glance
| What decides it | In Netlify's own words — and China's own law |
|---|---|
| What Netlify is | A global build-and-deploy platform. Netlify's High-Performance Edge is “Globally distributed nodes in every major geography” across “70+ global Points of Presence.” It is superb global hosting — global by design, and that is exactly the point. |
| A mainland-China node? | No. Netlify publishes no mainland point of presence; on its own support forum staff say “We don't publish an authoritative list,” and the lists they have shared reach only as far as Singapore and Tokyo — both offshore, on the far side of the border. |
| Gate 1 — delivery | Served from offshore nodes, a mainland request still crosses a congested, filtered border. The site is usually reachable, but delivery is variable — the symptom teams report is inconsistency, not an outright block. |
| Gate 2 — the filing | A public site shown to mainland visitors needs an ICP filing (备案) bound to a licensed in-country host and a mainland legal entity (State Council Order 292, Article 4; MIIT Order 33). An offshore-only network has no in-country host for that filing to attach to. |
| Visitor data at the border | A mainland visitor's real IP is personal information. Carrying it offshore is a cross-border transfer PIPL governs (Articles 38–43) — so the compliant design keeps an in-country entry and sends a single fixed in-country IP to your origin. |
| The working design | Keep Netlify as your origin; add an ICP-filed, in-country entry in front of it for mainland visitors. An overlay, not a migration — no rebuild, no second codebase. |
Two gates, and passing one tells you nothing about the other
Most plans that arrive at “speed up Netlify in China” treat the mainland as a single problem — make the site faster — and it is really two problems wearing one coat. The mainland asks two questions that have little to do with each other: can the bytes arrive quickly and reliably, and are you allowed to serve them from inside the country in the first place. A site can answer the first and still fail the second, and a tuned build tells you nothing about where you stand on permission.
The two questions are joined at exactly one hinge. The only arrangement that genuinely removes the border crossing is delivery from inside mainland China — and delivery from inside mainland China is precisely the act that brings the ICP filing into scope. So every setup that sidesteps the filing does so by staying outside the country, which is the same reason it keeps the slow, filtered crossing. You cannot buy the in-country speed without also taking on the in-country permission.
That is why a Netlify site can be made genuinely quicker for China and still be the wrong answer for a serious operation: performance you obtain outside the filing regime is performance you have no standing to keep. The moment the compliance gate is actually enforced, the arrangement that delivered the speed is the arrangement that has to change. Treating the two as one decision from the start is cheaper than discovering the link after launch.
Gate 1: why an offshore origin is inconsistent in China
The delivery half is real, and it is worth being precise about, because it is usually misdiagnosed as “the site is slow.” It is better described as inconsistent: the same page is tolerable in the morning and unusable in the evening, and connectivity checks pass on a site that no visitor can actually use.
The cause is structural. Netlify’s network is global, and for a worldwide audience that is close to ideal — but its nodes nearest the mainland are in Singapore and Tokyo, both of which sit on the far side of the Great Firewall. Netlify says it “dynamically adjusts points of presence across the globe,” and that is true; it has simply never meant a point of presence inside the mainland. Serving a Chinese user from Singapore does not shorten the crossing. It only changes where the crossing ends.
Then there is the part that surprises most teams: a CDN accelerates what you own, and does nothing for what your page calls. A modern site pulls in fonts, analytics, consent banners, embedded video and form endpoints, and those third-party services have no mainland presence either. Each one can fail on its own schedule, so a page can “mostly load” and still convert nothing — which matters most on a lead-capture site, where the form submission is the conversion. Shrinking your bundle does not touch any of this, because the failure is a request that never returns rather than one that returns slowly.
So Gate 1 has a genuine fix, and it is the same fix every time: deliver from inside mainland China, and decide resource by resource which calls actually need that treatment. Which is exactly where Gate 2 is waiting.
Gate 2: the ICP filing a global edge can’t carry
Serving a public website to people in mainland China turns on a permission that has nothing to do with performance: an ICP filing (备案). Under State Council Order No. 292 (Article 4) and MIIT Order No. 33, that filing attaches to a hosting resource physically inside the mainland and to a mainland legal entity — a foreign company with neither cannot file in its own name.
This is where a global edge meets a boundary it was never built to cross. A network whose points of presence are all offshore, however many “major geographies” it spans, has no in-country host for the filing to bind to. That is a licensing fact, not a flaw in Netlify: the filing needs a licensed mainland host, and Netlify’s hosts are, by design and by its own description, everywhere except the mainland. “We already have an ICP” does not close the gap either, because a filing has to name the infrastructure actually serving the traffic today — a filing left pointing at the wrong host can be reclassified and cancelled.
The practical consequence is that the in-country delivery that answers Gate 1 is the same thing that answers Gate 2. You do not solve speed and then separately solve filing; the in-country presence is one object that carries both.
Visitor data at the border
There is a third fact that sits underneath both gates, and teams usually have it backwards. A mainland visitor’s real IP address is itself personal information under China’s Personal Information Protection Law, and so are their request logs — and more, if the page carries forms, logins or analytics. Carrying every visitor’s real client IP out of the mainland to an offshore Netlify node is a cross-border transfer of personal information, which PIPL governs (Chapter III, Articles 38–43: notice, separate consent, and one permitted transfer mechanism — a CAC security assessment, the CAC standard contract, or certification; Article 40, with Cybersecurity Law Article 39 (formerly Article 37), adds an in-country storage duty for a critical information infrastructure operator or a large-volume handler).
So the compliant design does the opposite of what a global edge does by default: it terminates mainland visitors at an in-country, ICP-filed entry and sends a single, fixed in-country IP onward to your Netlify origin, rather than forwarding each visitor’s real IP across the border. Your origin therefore sees one in-country address instead of every visitor’s own — and that is the lawful design working as intended, not a limitation to engineer around. Whether a particular site must also store personal data inside the mainland depends on your role and data volumes, which is a question for counsel rather than a default.
This is a risk map, not a verdict — which gate binds first, and how hard, turns on your entity, your data and who your visitors are, and it is worth settling with counsel rather than assuming.
Where 21YunBox fits — a compliant overlay, not a migration
You keep building and shipping on Netlify exactly as you do today — same deploys, same origin, same global platform. 21YunBox adds the one piece a global edge structurally cannot: compliant, ICP-filed delivery from inside the mainland, placed in front of your existing Netlify origin — no rebuild, no second codebase, and no move off Netlify. Our China team maps which obligations apply to your entity and your data, handles the ICP filing, and stands up the in-country entry that serves your mainland audience while Netlify stays your source of truth.
And because that in-country layer is the single thing that both removes the border crossing and carries the filing, it closes Gate 1 and Gate 2 together — so you end up with speed you are actually permitted to keep, instead of speed that unravels the first time the compliance gate is enforced.
Related reading:
