Article
Why Your Website Is Slow in China (and What Fixes It)
September 22, 2026
TL;DR
- Sites hosted outside mainland China often take 15–30+ seconds to load for visitors there — or break partway through.
- Three causes compound: congested cross-border transit, DNS resolution outside the country, and blocked third-party scripts.
- Offshore CDNs, image compression, and VPNs do not fix it. Mainland hosting plus a China-tuned CDN does — and mainland hosting requires an ICP filing (typically 2–4 weeks).
Your website works well in Europe and the US. Then a colleague opens it from Shanghai and the website is slow in China: half a minute to the first pixel — or the page appears broken. This article explains why that happens, which quick fixes to skip, and what actually restores performance for China visitors. It deepens our infrastructure service overview into a diagnosis you can run on your own site.
The symptom: 15–30+ second loads and broken features
The pattern is consistent. A site hosted outside mainland China commonly takes 15–30+ seconds to load for visitors there. Many users bounce before the first pixel appears.
Speed is only half the problem. The second failure class is features that never arrive: the page renders, but an embedded map stays gray, a video player spins forever, a chat widget never initializes. These are two different problems, and they need different fixes:
- Slow everything. The HTML, CSS, and images arrive — late. Every request crosses the same congested international path. This is a transit problem.
- Broken parts. Some assets load fine while specific third-party components never do. The site is not blocked; a dependency is. This is a blocked-dependency problem.
Telling them apart is the first step: image compression and VPNs fix neither.
Why your website is slow in China: transit, DNS, and the Great Firewall
Three causes stack on top of each other.
1. Cross-border transit. Traffic between mainland Chinese networks and servers abroad crosses congested international links. For a global-only site, time-to-first-byte measured from China commonly lands at 2–8+ seconds before any other asset downloads.
2. DNS resolution outside the country. If your domain resolves through nameservers outside China, every new visitor's lookup adds round trips before the first request even starts.
3. The Great Firewall. The Great Firewall is the colloquial term for China's filtering of many global internet services. Requests to filtered services are not answered. A page that waits on them stalls until the browser gives up.
Each cause alone is noticeable. Together they compound into the 15–30+ second loads your China visitors report — and into features that fail outright.
Blocked third-party scripts: Google Maps, YouTube embeds, global APIs
Third-party scripts are where pages break most often. Google Maps, YouTube, and many global APIs are blocked or unreliable in mainland China. When your page calls them directly, the browser hangs on a request that will never complete.
The damage depends on how the dependency is wired in. A render-blocking script in the <head> stalls the whole page. An async embed spares the page but leaves a hole where the feature should be — a blank map area, a dead checkout button, missing fonts. Either way, the visitor sees a site that feels broken — and your analytics may never show it.
Audit before you optimize. The discovery phase of any serious China fix maps your stack and flags blocked dependencies separately from slow ones. Typical offenders on global sites:
- Google Maps embeds on location and contact pages
- YouTube or Vimeo embeds for product and brand videos
- Global font, icon, or tag-manager endpoints that are slow to unreachable
- Login, payment, or data APIs that China visitors cannot reach
Each blocked API has its own replacement path — a dedicated topic of its own. The strategy level is what matters here: find every external call your page makes, classify it as works, slow, or blocked, and treat the blocked ones as architecture decisions, not performance tweaks.
Website slow in China? What doesn't fix it
Teams usually try three things before calling for help. None of them address the causes above.
Offshore CDNs with no mainland edge. A global CDN without edge nodes inside mainland China still serves Chinese visitors from datacenters abroad. Caching may speed up repeat downloads of your own assets, but it does nothing about the cross-border hop, overseas DNS, or blocked third parties. What helps is a mainland CDN — edge caching on China networks to cut cross-border latency. The edge has to be inside the country for that definition to apply — what a mainland CDN actually requires.
Image compression and generic performance audits. Compressing images is good hygiene everywhere. It is not the answer here. Shaving 200 KB off a page does not change a multi-second transit path, and no srcset fixes a map tile from a blocked domain.
“Just use a VPN.” A VPN is not a fix for your visitors. It shifts the burden onto every individual user, and no business can ask its customers to install software to view a marketing site. For the audience that matters — real visitors on real networks — the underlying transit and blocked-dependency problems remain untouched.
What actually fixes it: mainland hosting plus a China-tuned CDN
The durable fix is to serve China visitors from inside China: mainland hosting on Alibaba Cloud or Tencent Cloud, with CDN configuration for static assets, media, and cache policies tuned for China ISPs. Mainland hosting and CDN improve time-to-first-byte and reliability — and with tuning, they cut load times from 30+ seconds to a usable experience.
The comparison we use on the infrastructure service page:
| Factor | Global-only | Mainland + CDN |
|---|---|---|
| Typical TTFB from China | 2–8+ s | < 1 s (with tuning) |
| Third-party APIs | Often blocked | Replaced or proxied |
| ICP requirement | Lower if not hosted in CN | Filing usually required |
Two rows deserve emphasis. First, mainland hosting removes the cross-border hop: your origin sits on the same networks as your visitors. Second, the third row is the trade: hosting inside China brings an obligation, the ICP filing. We cover it below — a scheduling constraint, not a blocker, when you plan for it.
Fix paths compared
Six fix paths, ordered from lightest touch to heaviest commitment. Effort bands are qualitative, and the table carries no timelines or prices: scheduling detail is in the ICP filing timeline, and entry-tier mainland hosting costs are a separate comparison.
| Fix path | What changes | Filing prerequisite | Effort band | Who operates it |
|---|---|---|---|---|
| DNS resolution move | Zone or nameserver location shifted to an in-country resolver | None | Low | Your team or DNS vendor |
| Dependency replacement | Front-end swap per SDK: maps to Amap or Baidu, video to domestic host, payments to WeChat Pay | None — global stack stays as-is | Low–medium per dependency | Your dev team |
| Reverse proxy for static assets | Server-side fetch configuration pulls assets through an intermediary | None — origin stays offshore | Medium | Your dev or ops team |
| Hybrid China edge (offshore-only acceleration) | New edge layer with conditional loader; edge serves from Hong Kong, Macau, or Taiwan only — see the Hong Kong vs mainland server trade-off | PSB filing instead of ICP — outside-mainland-only acceleration needs no ICP | Medium | Your ops team + CDN vendor |
| Mainland CDN (acceleration domain) | CDN enablement and cache-policy tuning on mainland edge nodes | ICP filing required per acceleration domain | Medium–high — filing is the critical path | MIIT-licensed CDN operator + your ops team |
| Mainland hosting (full origin move) | Origin server moved to Alibaba Cloud or Tencent Cloud mainland region | ICP filing usually required; mainland entity (typically a WFOE) needed | High — 2–4 week filing window when documents are complete | Your ops team on Alibaba Cloud or Tencent Cloud; consultancy coordinates filing |
Read this table two ways. First, the filing column is the gate: anything that puts assets on mainland servers requires an ICP filing, and the filing window sets the go-live date. Second, the effort column is not linear: dependency replacement is low effort per item but can involve many items; mainland hosting is high effort once but addresses transit and DNS in a single move. Filing work sits with the ICP compliance service; the bottom two rows with the infrastructure service; the payment-dependency swap with the WeChat ecosystem service.
Replace blocked dependencies
Mainland hosting fixes delivery of your assets. It does not make Google Maps load. Blocked dependencies need to be replaced or proxied, dependency by dependency:
- Maps. Use Amap or Baidu Maps in place of Google Maps embeds.
- Video. Domestic video hosts replace YouTube embeds so product and brand videos actually play.
- Payments and APIs. China-accessible payment APIs — WeChat Pay is the canonical example — replace global checkout and API calls where your funnel depends on them — see WeChat Pay merchant onboarding: paths and timelines.
This is where infrastructure work meets product decisions. A dependency audit tells you what is blocked; your team decides what the China visitor experience should be for each one. For payment flows in particular, the replacement often pairs with a WeChat-native checkout — see our WeChat ecosystem service. For the vehicle decision behind that checkout, see WeChat Mini Program vs H5 vs App: China Mobile Entry.
Hybrid architecture: keep your global stack, add a China edge
The first question engineering teams ask: “Do we have to re-platform?” No. Most brands keep their global website and add a China path — a China-facing edge layer with localized pages and replaced APIs where needed. The hybrid architecture links your global CMS or API to that edge layer, so content is authored once and delivered through two paths.
Consider a B2B SaaS company whose marketing site runs on a US headless CMS. Its product pages are authored once in the global CMS and cached at mainland edge nodes for China visitors. The embedded Google Map becomes an Amap map; the YouTube demo video moves to a domestic host. The application itself — behind a login — stays on the global stack. One codebase, two delivery paths, no migration project. Whether to stay off mainland hosting at all is its own decision — see reach China without an ICP filing — paths and trade-offs.
Hybrid is also the quicker route to a first result: the China path can go live while the broader China plan — entity, filing, full deployment — progresses in parallel.
The compliance prerequisite: an ICP filing
Mainland hosting requires paperwork. An ICP filing (Bei'an, 备案) is mandatory for most sites hosted on mainland servers, and an ICP license applies to commercial online platforms and paid services. With complete documents and a qualified mainland entity, the filing typically takes 2–4 weeks, varying by province and business category. Operating without a filing risks domain blocking and enforcement — which would put you back where you started.
Plan the filing into the project timeline rather than after it. If you are unsure whether your product triggers the filing only or the license as well, the ICP filing vs ICP license comparison settles the question. The ICP & compliance service handles this filing work.
How to diagnose your site
You can confirm the diagnosis in an afternoon:
- Load your site from a mainland connection. Ask a colleague in China, or use a mainland test point — and run each carrier line (Telecom, Unicom, Mobile) separately, since one line can time out while another loads fine (see the transit glossary entry). Record time to first render. Fifteen seconds or more matches the pattern described here.
- Open the browser network tab from that session. List every third-party domain your page calls. Note which requests time out — those are your blocked dependencies.
- Classify the failure. Everything late but complete → a transit problem; mainland hosting and CDN address it. Specific features missing → blocked dependencies; replacement addresses it.
- Check where your DNS resolves. Nameservers outside the country add avoidable lookup time for every new visitor.
- Inventory your compliance position. If mainland hosting is the fix, note who can hold the filing for you and start the document list early.
Bring that list to a first call and the architecture conversation starts from evidence, not guesswork. For the complete walkthrough — mainland test-point services, per-run recording, and benchmark numbers — see how to test your website from China.
Want this as a structured checklist across performance, dependencies, WeChat, and compliance? Run the 10-point China readiness check.
Diagnose the slowdown: decision matrix
Use this matrix to classify what you see before choosing a fix. Each row maps a symptom to its likely cause, the verification step that confirms it, and the fix path that addresses it.
| Symptom | Likely cause | Verification step | Fix path |
|---|---|---|---|
| Everything loads late; nothing missing; all carriers slow | Congested cross-border transit (and possibly overseas DNS) | Compare TTFB from mainland test points on Telecom, Unicom, and Mobile separately | Mainland hosting + China-tuned CDN |
| Page renders but map is gray, video spins, fonts missing, or checkout button dead | Blocked third-party dependency | Open browser network tab from a mainland session; note which third-party domains time out | Replace or proxy each blocked dependency |
| Render-blocking stall: nothing paints until timeout | Blocked third-party script wired render-blocking in the <head> | Check <head> for render-blocking calls to blocked domains; confirm in the network tab that the first request hangs | Move or replace head scripts; add a conditional loader |
| Domain unreachable from mainland entirely | Unfiled mainland serving (provider-level block) or filtered domain | Test from multiple mainland networks; check whether the provider returns a block page vs. a timeout | Complete the ICP filing before enabling mainland CDN or hosting; a filing does not un-filter a filtered domain |
| Slow on one carrier line only; fine on others | Per-carrier transit variance | Run the test once per carrier-line filter — Telecom, Unicom, Mobile — and compare TTFB per line | Measure per carrier to locate it; a mainland edge — hosting or China-tuned CDN — addresses the carrier-specific gap |
| Multi-second delay before the first request fires | Overseas DNS resolution | Trace DNS lookup time from a mainland resolver; compare to the authoritative nameserver location | Move DNS resolution to an in-country resolver |
| Own assets load fast now; third-party features still dead | Partial fix — hosting done, dependencies not replaced | Re-run the dependency audit after hosting change; confirm which third-party calls still time out | Dependency audit → replace or proxy each remaining blocked call |
| Slow on uncached paths; repeat visits fast on cached assets | Cache-policy gap | Compare first-visit vs. repeat-visit TTFB from mainland; check cache-hit headers on CDN responses | Tune CDN cache policies for China ISP patterns |
The first two rows cover the doctrine this article is built on: transit problems need infrastructure fixes; blocked-dependency problems need replacement. The remaining rows handle the cases teams hit after an initial fix attempt. For the full dependency-replacement walkthrough, see the blocked-API playbook. For per-carrier measurement as a testing doctrine, see the CN2 / CMI / transit glossary entry.
FAQ
Why is my global website slow in mainland China?
Cross-border latency and blocked scripts often cause 15–30+ second load times. Mainland CDN and hosting improve time-to-first-byte and reliability.
Do Google Maps, YouTube, and global APIs work in China?
Many Western services are blocked or unreliable in China. Use Amap or Baidu Maps, domestic video hosts, and China-accessible payment APIs.
Can we keep our global website and only optimize for China?
Yes — many brands add a China path with CDN, localized pages, and replaced APIs without replacing the global site.
Do I need an ICP filing for mainland hosting?
ICP filing (Bei'an) is mandatory for most mainland-hosted sites. With complete documents, it typically takes 2–4 weeks, varying by province and business category. The same filing gates CDN acceleration domains — see filing and account prerequisites for a mainland CDN.
Does WordPress (or my CMS) work in China?
It works but loads slowly or unreliably for the same three causes — cross-border transit, overseas DNS, and blocked third-party scripts. The fix is the same China infrastructure path, not a CMS swap. A WordPress site on a US host faces the same 15–30+ second load times as any other global-only site.
Why is my site still slow after adding a CDN or accelerator?
An offshore CDN edge does not touch the cross-border hop, and it does not fix blocked third-party dependencies. If your page still calls Google Maps, YouTube, or a blocked tag-manager endpoint, those requests stall regardless of where your own assets are cached. The CDN must have edge nodes inside mainland China, and the blocked dependencies must be replaced separately. See the CDN glossary entry for what a mainland CDN is — and what it is not.
Does hosting in China make my site work 100%?
No. Mainland hosting speeds up what you serve; it does not change what mainland networks block. Google Maps, YouTube, and other filtered services stay unreachable — treat the hosting project as the trigger to run the dependency audit, not as a substitute for it.
Does an ICP filing make my website faster?
No. An ICP filing is a registration prerequisite for mainland hosting, not a performance instrument. It gates whether a provider will serve your domain from mainland servers. The performance gain comes from the hosting and CDN configuration that the filing enables, not from the filing itself. See the ICP filing glossary entry for the definition.
Is my site blocked in China or just slow?
Classify by symptom. If the domain is unreachable from every mainland carrier, the cause is likely a filing or filtering issue. If the page loads but specific features are missing, a third-party dependency is blocked. If everything loads but slowly across all carriers, the cause is cross-border transit. The full classification walkthrough lives on the FAQ hub.
How do I test my website from China, and which metrics do I record?
Run tests from mainland test points on each carrier separately — Telecom, Unicom, and Mobile — using services like 17ce.com, ping.chinaz.com, or boce.com. Record the timestamp, network, first-render time, and TTFB for each run. Per-carrier measurement is the testing doctrine; averaged results hide carrier-specific transit problems. The complete walkthrough is in how to test your website from China.
How long until the fix is live?
The ICP filing is the critical path: with complete documents and a qualified mainland entity, it typically takes 2–4 weeks, varying by province and business category. A hybrid China path does not wait on it — the offshore edge can go live while entity, filing, and full deployment progress in parallel. See the ICP filing timeline for the phase-by-phase schedule.
Do we have to re-platform?
No. The hybrid pattern keeps your global stack as the system of record and adds a China-facing edge layer in front of it: localized pages, replaced dependencies, mainland or offshore caching. Delivery changes; your CMS and codebase do not. The hybrid architecture section above covers the trade-offs. When the full-mainland path is the destination, the provider decision is its own step — see how to choose between Alibaba Cloud and Tencent Cloud.
Will a VPN fix it for my visitors?
No. A VPN makes each visitor responsible for the fix: find, install, and keep one running on every device. That is not a request a business can make of its customers, and the visitors without one still hit the same transit and blocked-dependency failures. The GFW glossary entry covers why in full.
What happens if I run mainland-hosted without a filing?
Enforcement. Operating mainland-hosted without a filing risks domain blocking — the domain goes unreachable for the visitors you just moved closer. File before mainland serving starts, not after. See the CDN glossary entry on unfiled domains.
More questions? See the full articles index and the FAQ hub.
Next steps
A slow site in China is a diagnosis problem before it is a performance problem: identify the cross-border transit, the overseas DNS, and the blocked dependencies — then fix them in that order with mainland hosting, a China-tuned CDN, and dependency replacements. Start with the infrastructure service, or email hello@chinagateway.pro with your audit list.
Related articles
Why Your Site Breaks in China: The Blocked-API Playbook
When specific parts fail while the rest renders: dependency failures.
How to Test Your Website from China Without Flying There
Measure first-render time, DNS, and CDN edges from mainland vantage points.
China CDN for Foreign Companies: What It Requires First
The mainland-CDN prerequisite chain — the filing sets the go-live date.
Need a China performance audit?
hello@chinagateway.pro