Onshore hosting China — when ICP does not fix speed

Onshore hosting China does not automatically fix Mainland China hosting speed. ICP filing proves the origin may terminate in-country — it is not ICP hosting performance. China hosting slow after a filed origin is usually leftover overseas deps, DNS that still answers offshore, dynamic fetches that still cross the border, or a CDN that is not onshore. An onshore hosting China plan is clean deps + honest DNS + onshore cache/origin for the slow hop — not “we have ICP, so it must be fast.” Prove from Mainland China broadband and mobile; an HQ laptop is not proof.

What onshore hosting China actually proves

Hard names this still-slow decision will use:

• Onshore hosting China — You already chose Mainland China termination. The origin (or the filed edge the access provider binds) is in-country. That is the Host in Mainland China decision. This Guide starts after that choice.
• ICP filing is not speed — Filing lists the domain and the Mainland China service IPs. It proves the origin may terminate in-country. It is not ICP hosting performance. How you file: ICP filing — domain DNS.
• China hosting slow after filing — Usual class is leftover overseas hosts (fonts, tags, captcha, embeds, plugin CDNs), DNS that still answers offshore, dynamic HTML or API fetches that still cross the border, or a CDN that is not onshore. Failure class is performance after filing, not “skip ICP.”
• HTML 200 ≠ working — The filed origin can return 200 while the journey hangs. Same class as website accessible in China and website not working in China.
• Onshore cache vs origin — A China CDN / edge can help cacheable static. Dynamic origin fetch and chatty APIs still pay the border if that hop is overseas. Journey latency: SaaS performance in China.
• Wrong Guide — If you never went in-country, you are on the Hong Kong hosting China / SiteGround in China path — not this article. Hong Kong is not in-country.
• Common myth — “We have ICP, so Mainland China hosting speed is done.” Prove from Mainland China broadband and mobile.

Vocabulary first. Next: what must already be true before ICP looks like a speed fix.

What must be true before ICP looks like speed

Missing a clear still-slow hop stops your product team before another “we already filed, why is it slow” sprint is real work.

Precondition	Why your process stalls
In-country termination already chosen — origin or filed edge in Mainland China	This Guide is after that choice. Overseas-only / Hong Kong / shared-host origins belong on the Host, Hong Kong, and SiteGround Guides
Honest DNS — China-facing records answer at the filed in-country endpoints	Leftover overseas A / CNAME answers keep TTFB high while the footer shows a filing number
Still-slow hop named — hung page (deps) vs high HTML TTFB vs chatty APIs	Teams re-file ICP or buy another VM while fonts, tags, or origin fetch stay overseas
Host inventory — every hostname the journey calls	One leftover captcha, tag, embed, or plugin CDN hangs a “local” page
Cache vs origin named — onshore cache for static vs origin locality for dynamic	An overseas CDN in front of a filed origin is not Mainland China hosting speed
Mainland China vantage proof on origin and dep hosts — broadband + mobile; HQ laptop is not proof	Overseas QA “passes” while China users wait — same class as website not working in China

Product teams usually cannot treat “ICP approved” as the Mainland China hosting speed plan. Naming the slow hop is the floor.

After a filed origin — remap the still-slow hop

Stage	Decision / outcome
1. Confirm you actually went in-country	Filed origin / DNS answers in Mainland China? If no, leave this Guide — Host in Mainland China, Hong Kong hosting China, SiteGround in China
2. Classify the still-slow hop	Page still hangs (deps) vs HTML TTFB still high vs chatty APIs / SaaS
3. Inventory hosts	Fonts, tags, captcha, embeds, plugin CDNs on the hung page — website accessible in China, Google Tag Manager in China, captcha forms in China, WordPress in China as the stall class requires
4. Remap that hop	Clean deps; honest DNS; onshore cache or origin for the hop that is slow — China CDN / edge for cache vs origin
5. Prove from Mainland China	DNS / TLS / waterfall (or China Network Diagnostics) on origin and leftover hosts — broadband and mobile, not only HQ HTML 200
6. Cut over, then re-test	A later tag, plugin, or “global site component” can restore the stall

Hard gate — one still-slow class

Necessity: confusing these jobs wastes the quarter — either you re-run ICP while deps hang, or you treat a Hong Kong origin as if filing should have made it fast.

What you see	Usual class	Where the remap lives
Origin filed, page still hangs	Leftover overseas hosts (fonts, tags, captcha, embeds, plugin CDNs)	Accessibility + GTM / captcha / WordPress as needed
TTFB still high on HTML	DNS leftover overseas; origin not actually in-country; or dynamic origin fetch across the border	Host in Mainland China + China CDN / edge (cache vs origin)
APIs / chatty SaaS	Journey latency / API locality — not a hosting SKU	SaaS performance in China
You never went in-country	Hong Kong / shared-host myth path	Hong Kong hosting China / SiteGround in China — not this article

Why a filed origin still leaves China hosting slow

Engineering and ops constraints you must design around:

Constraint	What breaks	What to do
Leftover overseas deps	Fonts, tags, captcha, embeds, and plugin CDNs hang paint or submit while the filed HTML host returns 200.	Inventory hosts. Fix the dependency class — website accessible in China; GTM; captcha forms; WordPress when CMS/plugin CDNs are the stall.
DNS leftover overseas	Filing number in the footer, production answers still offshore. TTFB stays high.	Cut China-facing records to the filed endpoints. Depth: ICP filing — domain DNS.
Dynamic fetch across the border	Onshore HTML still waits on an overseas origin, API, or uncached path.	Name cache vs origin. Onshore cache does not move a chatty origin — China CDN / edge; SaaS performance in China.
Overseas CDN in front of a filed origin	Edges outside Mainland China (including Hong Kong) are not onshore nodes.	Treat CDN locality as a separate fork — China CDN / edge.
HQ laptop QA	Testers outside Mainland China never see the stall, so the ticket never opens.	Prove origin and deps from Mainland China broadband and mobile.

Still-slow ≠ skip ICP. When termination is in-country, filing stays in scope. This Guide does not claim ICP is optional or fake.

HQ admin OK → false confidence. A laptop outside Mainland China can still open the filed origin while Mainland China users wait on leftover hosts.

Reporting Hong Kong residual as Mainland China hosting speed → wrong stack. Hong Kong is not in-country. If that is still the origin, you are on the Hong Kong hosting China map.

What stalls teams that treat ICP as performance

• ICP-as-speed-switch — Product treats the filing number as Mainland China hosting speed before deps, DNS, and cache/origin are honest.
• Re-filing instead of inventory — Teams restart ICP while fonts, tags, or captcha still hang the page.
• HQ laptop QA — Testers outside Mainland China never see China hosting slow, so the ticket never opens.
• Hong Kong conflated with Mainland China — Outside-Mainland China performance is reported as onshore hosting China working.
• Plugins and tags that re-inject overseas hosts — Fonts, captcha, analytics, and builder CDNs restore the stall after “the origin is local.”
• CDN-as-origin — An overseas CDN in front of a filed origin is staffed as if TTFB will recover. It will not, if the slow hop stays offshore.
• API stall treated as a hosting ticket — Chatty SaaS is sent back to the VM SKU instead of SaaS performance in China.
• No owner for the remap — The fork stalls because nobody owns host inventory and the slow hop — only “make ICP faster.”

What “fixed” means: Mainland China users can complete the journeys you claim on a filed in-country origin; leftover overseas deps are gone from that client path; DNS answers at the filed endpoints; onshore cache or origin sits on the hop that was slow; proof is from Mainland China broadband and mobile. “We have ICP” with a hung spinner is not fixed.

China landing partner when the slow hop is the product

Most product teams exploring Mainland China entry need a China landing partner once ICP is on the path and the page is still slow — to inventory hosts, keep a dependency allowlist, cut DNS to filed endpoints, place onshore cache or origin on the slow hop, run Mandarin consoles, and prove the journey from Mainland China broadband and mobile. Your team still owns which hostname is China-facing and which hop is actually slow; the partner path makes that remap executable when those rails are not already in-house. Having filed ICP does not remove the need for that China landing partner on the still-slow path.

What we can offer?

Onshore hosting China work after ICP is a still-slow-hop decision before any “we already filed, so it must be fast” sprint. Chinaready helps your product team remap the hung hop on a filed in-country origin — not another ICP checkbox hope:

1. China Readiness Assessment — Decide whether the origin is actually in-country, which journeys still hang, and which dep, DNS, cache, and origin gates sit on the critical path before a remap date.
2. China Access Acceleration — Attack the proven bottleneck (leftover hosts, leftover DNS, or cache vs origin) so Mainland China hosting speed moves for users, not only for an HQ laptop. Acceleration does not turn ICP into performance by itself.
3. China Product Hosting — Keep the China-critical origin on filed Mainland China termination and place onshore cache or origin on the hop that is still slow, with DNS that matches the filing.
4. Mobile App Distribution — Align any China app that still wraps the marketing site in a WebView with the same origin, dep, and DNS gates — not mistake a filed HTML host inside an app for Mainland China hosting speed.

Contact us when ICP is on the path and Mainland China users still wait — before you staff another filing or VM sprint.