Core Web Vitals China — measure before a rebuild

HQ PageSpeed Insights is not Core Web Vitals China. A green HQ lab report, or Chrome User Experience Report field data from overseas Chrome users, is not LCP, INP, and CLS on Mainland China broadband and mobile. CWV China and page speed China fail on vantage, DNS, and overseas deps — not a “Google is blocked” slogan. Name the vitals, name the slow hop, then remap. Do not rebuild first.

What Core Web Vitals China actually measures

Hard names this measurement decision will use:

• Core Web Vitals China — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) for ordinary Mainland China users. INP is stable; First Input Delay is retired. Thresholds live on Web Vitals. This Guide does not invent scores.
• HQ PageSpeed Insights is not that measurement — PageSpeed Insights is CrUX field data plus a Lighthouse lab run. CrUX is Chrome-originated. Lab is not a Mainland China node. A green HQ row is not Core Web Vitals in China.
• Vantage, DNS, overseas deps — page speed China usually fails because the tester sits outside Mainland China, DNS still answers offshore, or fonts, tags, DAM, and embeds hang paint — not a “Google is blocked” slogan.
• Name the slow hop before rebuild — origin versus CDN versus deps versus DNS. Already in-country and still slow lives on Onshore hosting China. This Guide is the measurement fork before that rebuild.
• HTML 200 ≠ vitals — The document host can return 200 while LCP waits on an overseas hero, tag, or DAM object. Same class as website accessible in China.
• Diagnostics is proof, not PSI — China Network Diagnostics proves DNS, HTTP, and ping from Mainland China nodes. It does not replace PageSpeed Insights or invent LCP, INP, or CLS scores.
• Common myth — “PSI is green, so Core Web Vitals China is done.” Prove from Mainland China broadband and mobile.

Vocabulary first. Next: what must already be true before an HQ green report looks like a China score.

What must be true before HQ PSI counts as a China score

Missing a Mainland China vantage stops your product team before another “we already passed PageSpeed” rebuild is real work.

Precondition	Why your process stalls
Job locked — ordinary Mainland China journeys vs HQ / Hong Kong residual lab	Wrong job treats an HQ PSI green as Core Web Vitals China
Mainland China vantage — broadband + mobile; HQ laptop and VPN are not proof	Overseas QA never sees the stall, so the ticket never opens
LCP / INP / CLS named from that vantage — not a single lab Performance score	Teams rebuild CSS while the LCP element is an overseas DAM object or tag
Slow hop named — origin vs CDN vs deps vs DNS	Teams move the origin while leftover Google Tag Manager still blocks paint
Host inventory — every hostname the LCP / INP path calls	One leftover font, tag, captcha, or CMS CDN hangs a “fast” page
Honest DNS — China-facing records answer where you claim they answer	Leftover overseas A / CNAME keeps TTFB high while PSI at HQ stays green — .cn domain when the TLD / resolver is the named hop

Product teams usually cannot treat “ship the same global PSI budget” as the Mainland China plan. Vantage and hop clarity are the floor.

From HQ green to a named Mainland China hop

Stage	Decision / outcome
1. Separate HQ PSI from China vitals	Keep PageSpeed Insights / Lighthouse as an HQ lab and CrUX as Chrome field history. Do not report them as Core Web Vitals China
2. Measure from Mainland China	LCP, INP, and CLS on ordinary broadband and mobile — not only an HQ laptop, not only Hong Kong
3. Name the three vitals	Which metric actually fails on that vantage. Do not collapse them into one “page speed” score
4. Name the slow hop	Origin vs China CDN / edge vs leftover deps vs DNS. Inventory hosts on the LCP / INP path
5. Remap that hop — then prove again	Clean deps; honest DNS; onshore cache or origin for the hop that is slow. Re-measure from Mainland China. Diagnostics can prove DNS / HTTP / ping; it is not a PSI replacement
6. Pick the rebuild Guide only after the hop is named	Already in-country and still slow → Onshore hosting China. Still overseas PaaS / herokuapp → Heroku in China. Chatty APIs → SaaS performance in China

Hard gate — HQ score versus China vantage

Necessity: confusing these two jobs wastes the quarter — either you rebuild the origin while HQ PSI was never the China score, or you ignore a real Mainland China stall because CrUX looked fine.

What you see	Usual class	Where the next decision lives
HQ PSI / Lighthouse green, China users wait	Wrong vantage — lab and CrUX are not Mainland China ordinary users	This Guide — measure from Mainland China, then name the hop
LCP slow, HTML 200	Leftover overseas hosts (fonts, tags, DAM, embeds) or an overseas LCP object	Website accessible in China; GTM when the head tag is the paint stall; enterprise CMS when DAM / CDN is the LCP element
TTFB high, document host overseas	Origin / DNS still offshore — including herokuapp and other PaaS defaults	Host in Mainland China; Heroku in China when that is the origin class
INP / APIs stall after paint	Journey latency — not a Lighthouse CSS ticket	SaaS performance in China
Origin already in-country, page still hangs	Leftover deps / leftover DNS / cache vs origin	Onshore hosting China — not this article’s rebuild

Why HQ Lighthouse is not CWV China

Engineering constraints you must design around:

Constraint	What breaks	What to do
Vantage	PSI lab and CrUX field data do not sit on Mainland China broadband and mobile. Chrome-originated field history is not ordinary China-user proof.	Measure LCP, INP, and CLS from Mainland China. An HQ laptop is not proof.
Overseas deps on the LCP path	Fonts, GTM, captcha, embeds, and CMS / DAM CDNs hang paint while the HTML host returns 200.	Inventory hosts. Fix the dependency class — website accessible in China; enterprise DAM / CDN on enterprise CMS.
DNS leftover overseas	HQ PSI stays green; China TTFB stays high. A .cn cutover without honest answers is still a hop.	Name DNS as a hop when it is. Depth: .cn domain; in-country bind: Host in Mainland China.
CDN locality confused with origin	An overseas PoP (including Hong Kong) is not an onshore node. Cache does not move a chatty origin.	Split cache vs origin — China CDN / edge.
HQ laptop QA	Testers outside Mainland China never see the stall, so the ticket never opens.	Broadband + mobile from Mainland China. Diagnostics for DNS / HTTP / ping — not as a fake vitals score.

Green PSI ≠ Core Web Vitals China. Field data is Chrome history; lab data is not a China node.

One Performance score ≠ LCP / INP / CLS. Name which vital fails on the China vantage before you staff a rebuild.

“Google is blocked” as a slogan ≠ a hop. The usual class is vantage, DNS, and leftover overseas hosts — prove those, then remap.

Diagnostics ≠ PSI. China Network Diagnostics names whether DNS, HTTP, and ping work from Mainland China nodes. It does not replace PageSpeed Insights.

Already-onshore still-slow ≠ this fork. Once termination is in-country, leftover deps live on Onshore hosting China.

What stalls teams that treat PSI as page speed China

• HQ-green-as-done — Product treats a PageSpeed Insights pass as Core Web Vitals China before Mainland China broadband and mobile exist.
• Rebuild before the hop is named — Teams move origin or buy CDN while the LCP element is still an overseas tag, font, or DAM object.
• One score instead of three vitals — LCP, INP, and CLS collapse into a lab Performance number, so the wrong layer gets the sprint.
• HQ laptop QA — Testers outside Mainland China never see page speed China fail, so the ticket never opens.
• Hong Kong conflated with Mainland China — Outside-Mainland China lab or residual Chrome traffic is reported as CWV China working.
• herokuapp vantage reported as China — An overseas PaaS origin can look fine in HQ PSI and still stall Mainland China users — Heroku in China.
• GTM / tags re-injected as LCP deps — Head tags and child hosts restore the paint stall after “the origin is local.”
• CrUX insufficient-data ignored or over-read — Empty field data is treated as a pass; overseas Chrome history is treated as China users.
• No owner for the vantage — The fork stalls because nobody owns Mainland China measurement — only “make PSI greener.”

What “fixed” means: Mainland China users complete the journeys you claim; LCP, INP, and CLS are named from Mainland China broadband and mobile; the slow hop is remapped; leftover overseas deps are gone from that client path; HQ PSI is no longer reported as Core Web Vitals China. A green lab URL with a hung spinner in Shanghai is not fixed.

China landing partner when the vantage is the product

Most product teams exploring Mainland China entry need a China landing partner once HQ PageSpeed Insights is no longer treated as the China score — to run Mainland China broadband and mobile measurement, inventory LCP / INP hosts, keep a dependency allowlist, cut DNS to honest endpoints, place onshore cache or origin on the hop that is actually slow, and prove DNS / HTTP / ping from Mainland China nodes. Your team still owns which journeys must pass and which hop is in scope; the partner path makes that vantage and remap executable when those rails are not already in-house. A green HQ Lighthouse report does not remove the need for that China landing partner on the Core Web Vitals China path.

What we can offer?

Core Web Vitals China work is a vantage-and-hop decision before any “PSI is green, so rebuild the stack” sprint. Chinaready helps your product team measure LCP, INP, and CLS from Mainland China and remap the named hop — not another HQ lab checkbox:

1. China Readiness Assessment — Decide whether HQ PageSpeed Insights is being treated as Core Web Vitals China, which journeys still wait, and which origin, CDN, dep, and DNS gates sit on the LCP / INP path before a rebuild date.
2. China Access Acceleration — Attack the proven bottleneck (vantage, leftover hosts, leftover DNS, or cache vs origin) so page speed China moves for users, not only for an HQ Lighthouse run. Acceleration does not turn PSI into a China score by itself.
3. China Product Hosting — Place China-critical origin or onshore cache on the hop that measurement named, with DNS that matches what you claim — after the hop is named, not as a hope that hosting will green HQ PSI.
4. Mobile App Distribution — Align any China app that still wraps the marketing site in a WebView with the same vantage and hop gates — not mistake an HQ PSI pass inside an app WebView for Core Web Vitals China.

Contact us when HQ PageSpeed Insights looks fine and Mainland China users still wait — before you staff a rebuild.