제3자 자원은 중국 안에서 도달 가능한가요?
중국 안 어디서 측정하느냐에 달려 있고, 그 차이는 전면적일 수 있습니다. 측정된 사실: 중국 본토의 데이터센터 프로브(Alibaba Cloud cn-zhangjiakou)에서 2026-08-28에 열두 시간 동안 10분마다 표본 추출 — 720회 측정 — 했을 때, fonts.googleapis.com과 www.googletagmanager.com은 둘 다 약 110ms에 100% 응답했고, 저희는 그것들을 직접 연결에 두라고 권했습니다. 2026-08-30에 한 자원봉사자가 같은 코드를 베이징 차이나모바일 가정용 회선에서 88 사이트, 264 페이지 로드에 걸쳐 돌렸습니다: www.googletagmanager.com은 112번 요청되고 한 번도 응답하지 않았으며; fonts.googleapis.com은 54번 요청되고 한 번도 응답하지 않았습니다. 이는 타임아웃의 산물이 아니었습니다 — 성공적으로 완료된 페이지 로드에서도 태그 매니저는 14번 중 14번 실패했습니다. 그 실행 전체에서 102개 호스트가 응답을 반환하지 않았고 그중 101개가 제3자였던 반면, 로딩을 끝내 완료하지 못한 57개 사이트는 하나하나 첫 바이트는 반환했습니다. 깨진 것은 보통 사이트가 아니라; 그것이 끌어오는 것입니다. 경로를 자원별로 결정하는 것은 귀사 방문자가 실제로 있는 곳에서 취한 측정으로만 의미가 있으며 — 넘기를 피하려고 본토 안에서 서비스하는 것이 ICP 비안 요건을 함께 가져옵니다.
중국의 제3자 자원에 대해 공표된 대부분의 수치는 단일 표본입니다. 저희는 전에도 단일 표본은 측정이 아니라고 주장했습니다 — 거기서 국경 간 행동은 하루 동안 두 자릿수 배 이상 달라지며, 오후 2시에 취한 숫자는 밤 9시에 대해 거의 아무것도 말해 주지 않습니다.
그래서 저희는 제대로 돌렸습니다: 다섯 가지 제3자 자원 범주를, 10분마다 표본 추출하여, 중국 본토 안의 프로브에서, 각각을 두 번씩 요청 — 한 번은 직접, 한 번은 저희 자신의 전송 네트워크를 통해. 열두 시간에 걸쳐 720회 측정, 운영자가 대비해 계획하는 저녁 피크를 포함.
그다음 더 중요한 일을 했고, 그것은 저희에게 하나의 권고를 대가로 치르게 했습니다.
갱신, 2026년 8월 30일. 아래 열두 시간 연구는 중국 안의 상용 클라우드 회선에서 돌렸습니다 — 이는 저희 것을 포함해 거의 모든 공표된 중국 측정이 취해지는 방식입니다. 저희는 당시 소비자 연결에서도 반복하고 결과가 불리하더라도 공표하겠다고 말했습니다. 이제 그것을 했고, 문제는 잘못된 권고보다 큽니다: 한 범주의 호스트 전체에 대해, 본토 클라우드 프로브와 본토 소비자 회선은 같은 나라를 보고하지 않습니다. 클라우드에서 100% 응답한 호스트가 베이징 가정용 회선에서는 0% 응답했습니다. 원래 데이터는 유효합니다 — 그것은 그 관측 지점을 충실히 묘사합니다. 그것이 묘사하지 않는 것은 방문자입니다. 프로브를 옮겼을 때 달라진 것을 보십시오.
무엇을 측정했는가
| 자원 | 범주 | 왜 목록에 있는가 |
|---|---|---|
fonts.googleapis.com | 웹 폰트 스타일시트 | 상당수 기업 페이지에 있음 |
fonts.gstatic.com | 웹 폰트 파일 | 실제 폰트 바이트 |
cdn.jsdelivr.net | 공개 JS CDN | 흔한 스크립트 호스트 |
www.googletagmanager.com | 태그 매니저 | 애널리틱스와 마케팅 태그 |
www.google.com/recaptcha | 폼 인증 | 폼 제출 가능 여부를 가둠 |
목록은 임의가 아닙니다. 중국 안에서 실제 벤더 웹사이트를 측정하고 어느 제3자 호스트가 실제로 응답을 멈췄는지 기록한 데서 나왔습니다 — 이 다섯 범주가 나타난 것입니다.
방법: 중국 본토 안의 프로브(Alibaba Cloud cn-zhangjiakou); 각 자원을 같은 라운드에서 직접 그리고 저희 네트워크를 통해 요청; 처리량은 본문 전송에 대해서만 계산하여 첫 바이트 시간(TTFB)을 제외함으로써 작은 파일이 연결 설정에 지배되지 않게 함; 30초 타임아웃; 타임아웃은 폐기하지 않고 결과로 셈. 셀당 72개 표본, 2026년 8월 28일. 아래 시각은 중국 현지 시간.
열두 시간에 걸친 결과
| 자원 | 경로 | 성공 | TTFB 중앙값 | TTFB p95 | 처리량 중앙값 |
|---|---|---|---|---|---|
| 폰트 스타일시트 | 직접 | 100% | 111ms | 137ms | 2.4 MB/s |
| 저희 네트워크 | 100% | 278ms | 303ms | 5.0 MB/s | |
| 폰트 파일 | 직접 | 100% | 102ms | 121ms | 4.9 MB/s |
| 저희 네트워크 | 100% | 195ms | 208ms | 0.8 MB/s | |
| 공개 JS CDN | 직접 | 100% | 660ms | 1,757ms | 4.0 MB/s |
| 저희 네트워크 | 100% | 103ms | 114ms | 16.1 MB/s | |
| 태그 매니저 | 직접 | 100% | 118ms | 143ms | 13.5 MB/s |
| 저희 네트워크 | 100% | 312ms | 327ms | 4.1 MB/s | |
| 폼 인증 | 직접 | 0% | — | — | — |
| 저희 네트워크 | 100% | 169ms | 263ms | 1.5 MB/s |
셀당 72개 표본.
무엇을 결론했고, 무엇을 틀렸는가
이 데이터로 저희는 Google Fonts와 태그 매니저를 있는 그대로 두어야 한다고 썼습니다. 둘 다 시도의 100%에서 도달 가능했고, 둘 다 직접 약 110밀리초에, 추가 홉을 거치면 약 300에 응답했으며, 저희는 — 그 숫자로는 올바르게 — 이미 건강한 호스트를 다른 곳으로 라우팅하는 것은 아무 이득 없이 모든 요청마다 치르는 지연세라고 주장했습니다.
추론은 건전했습니다. 관측 지점이 아니었습니다. 저희는 같은 글에서 *“이 호스트가 상하이에서 밤 9시에 건강한가”*는 다른 어디서도 답할 수 없는 질문이라고 써 놓고 — 그다음 데이터센터에서 답했습니다.
중국에서 실제로 웹사이트를 운영해 본 사람이라면 저 표에 이미 눈썹을 치켜올릴 텐데, Google 소유 호스트는 중국 소비자 연결에서 일반적으로 쓸 수 없고, 거기서 일하는 누구도 그것을 알려 줄 측정이 필요 없기 때문입니다. 바로 그것이 이 결과를 공표할 가치가 있게 만듭니다. 저희는 그 호스트들이 방문자에게 실패한다는 것을 발견한 게 아닙니다. 저희는 저희 프로브가 그렇지 않다고, 111밀리초에, 72번 중 72번 말했다는 것을 발견했습니다.
본토 클라우드 인스턴스는 중립적 관측소가 아닙니다. 그것은 자체 협정을 가진 상용 네트워크이며, 적어도 한 범주의 호스트에 대해 그 협정은 명백히 집에서 귀사 페이지를 로드하는 사람에게는 미치지 않습니다.
중국에서 소프트웨어를 만드는 누구나 이 모양을 이미 아는데, 그것이 툴체인의 일상 경험이기 때문입니다. 세계의 나머지가 당연하게 여기는 업스트림 소스는 본토에서 쓸 수 없으므로, 국내 클라우드는 자체 대체물을 돌립니다: 컨테이너 레지스트리, 패키지 레지스트리, 언어 런타임. 저희도 이에 의존합니다 — 자원봉사자가 돌린 측정 패키지는 브라우저와 런타임을 국내 미러에서 내려받는데, 업스트림 소스가 그것을 돌리던 곳에서 도달 불가하기 때문입니다. 깨진 경로를 조용히 작동하는 경로로 대체하는 환경은 구축하기에 매우 편리한 곳입니다. 측정하기에는 매우 나쁜 곳입니다.
저희는 이 특정 호스트들의 구체적 메커니즘을 추측하지 않겠습니다 — 저희는 그것을 측정하지 않았고, 뒷받침할 수 없는 설명은 뒷받침할 수 있는 관측보다 가치가 덜합니다. 이 발견은 불일치 그 자체에 서 있고, 그 불일치는 전면적입니다: 클라우드에서 72 중 72, 가정용 회선에서 112 중 0.
일반화가 유용한 부분입니다. 귀사의 중국 측정이 본토 클라우드 인스턴스에서 온다면 — 거의 모든 공표된 중국 측정이 그렇습니다 — 그것이 방문자가 보는 것을 묘사한다고 가정할 수 없습니다. 여기에는 저희 것도, 저희가 이것들을 점검한 방식으로 점검하기 전까지는 포함됩니다.
프로브를 옮겼을 때 달라진 것
2026년 8월 30일, 베이징의 한 자원봉사자가 저희 측정 스택을 차이나모바일 가정용 광대역 회선에서, 저희 데이터센터 프로브와 같은 코드, 같은 60초 상한, 같은 사이트당 3회 실행 설계로 돌렸습니다. 그 실행은 88개 실제 웹사이트 — 264회 페이지 로드 — 를 로드하고, 요청별로 응답을 결코 반환하지 않은 모든 호스트를 기록했습니다.
같은 다섯 호스트가 한 일은 다음과 같습니다:
| 호스트 | 데이터센터 회선(12시간, 각 72표본) | 베이징 가정용 회선(2026-08-30) |
|---|---|---|
www.googletagmanager.com | 100% 성공, 118ms | 112 요청, 112 무응답 |
fonts.googleapis.com | 100% 성공, 111ms | 54 요청, 54 무응답 |
fonts.gstatic.com | 100% 성공, 102ms | 6 요청, 6 무응답 |
www.google.com(reCAPTCHA 호스트) | 0% 성공 | 18 요청, 18 무응답 |
cdn.jsdelivr.net | 100% 성공, 660ms 중앙값 | 36 요청, 0 실패 |
있는 그대로 두라고 말씀드린 두 호스트가 한 번도 응답하지 않은 두 호스트입니다. 더 느린 게 아니라. 간헐적인 게 아니라. 각각 112 중 0, 54 중 0 응답.
이것은 타임아웃의 산물이 아니다
명백한 반론은 이 요청들이 60초 페이지 로드가 포기될 때 아직 비행 중이었고, 더 주어졌으면 완료되었으리라는 것입니다. 그러지 않았을 겁니다. 점검은 성공적으로 완료된 페이지 로드만 보고 그 같은 호스트들이 그 안에서 무엇을 했는지 묻는 것입니다:
| 호스트 | 완료된 페이지 로드에서의 등장 | 무응답 |
|---|---|---|
www.googletagmanager.com | 14 | 14 |
geolocation.onetrust.com | 12 | 12 |
www.google.com | 4 | 4 |
페이지는 완료되었습니다. 호스트는 여전히 한 번도 응답하지 않았습니다. 이것들은 시간이 다 된 요청이 아니라; 그 연결에서 애초에 응답될 리 없던 요청입니다.
아무도 경고해 주지 않는 호스트
그 264회 페이지 로드 전체에서, 102개의 다른 호스트가 응답을 일절 반환하지 않았고, 그중 101개 — 99% — 가 제3자였지, 요청된 사이트 자체가 아니었습니다. 102개 중 Google 소유는 13개뿐. 그것들을 이미 이해된 것으로 제쳐 두면, 89개 호스트가 남습니다. 이것이 상식이 아닌 부분이고, 행동에 옮길 가치가 있는 부분입니다:
| 호스트 | 하는 일 | 요청됨 | 무응답 |
|---|---|---|---|
geolocation.onetrust.com | 동의 배너 지오로케이션 | 50 | 50 |
c.go-mpulse.net | 실사용자 모니터링 | 12 | 12 |
use.typekit.net | 웹 폰트 전송 | 11 | 11 |
cdn.optimizely.com | 실험 | 9 | 9 |
px.ads.linkedin.com | 광고 픽셀 | 9 | 9 |
d3e54v103j8qbb.cloudfront.net | 사이트 빌더 자산 CDN | 9 | 9 |
static.hotjar.com | 세션 애널리틱스 | 6 | 6 |
epsilon.6sense.com | 어카운트 인텔리전스 | 6 | 6 |
동의 배너 호스트가 두 번 보아야 할 것입니다. 동의 스크립트는 보통 페이지의 다른 무엇보다 먼저 돌고 흔히 해석될 때까지 렌더링을 막습니다; 그래서 결코 반환되지 않는 지오로케이션 조회는 빠진 쿠키 배너가 아니라, 시작하지 않는 페이지입니다.
간헐적 호스트가 죽은 호스트보다 더 흥미롭습니다, 간헐적이 아무도 대비하지 않는 경우이기 때문입니다:
| 호스트 | 요청됨 | 실패 | 실패율 |
|---|---|---|---|
fast.wistia.com | 15 | 6 | 40% |
widget.trustpilot.com | 9 | 3 | 33% |
cdn.weglot.com | 9 | 3 | 33% |
challenges.cloudflare.com | 12 | 3 | 25% |
uhf.microsoft.com | 12 | 3 | 25% |
play.vidyard.com | 15 | 3 | 20% |
rum.hlx.page | 18 | 3 | 17% |
네 번에 한 번 실패하는 호스트는 페이지를 한 번 로드해서는 진단할 수 없는데, 그것이 거의 모두가 점검하는 방식입니다. 또한 어림짐작으로도 고칠 수 없는데, 그 규칙이 대부분의 경우 옳은 호스트에 대해 옳아야 하기 때문입니다.
이 모든 실패의 4분의 3이 한 가지 특정 종류였습니다: 요청이 보내졌고, 아무것도 돌아오지 않았으며, 어떤 오류도 결코 일어나지 않았습니다. 거부도 아니고, 리셋도 아니고 — 침묵. 페이지의 어느 것도 문제를 보고하지 않는데, 브라우저의 관점에서 아직 아무것도 잘못되지 않았기 때문입니다.
그리고 사이트 자체는 대부분 괜찮았습니다: 로딩을 끝내 완료하지 못한 57개 사이트 중, 하나하나 모두 첫 바이트를 반환했고, 3분의 2는 멈추기 전에 화면에 무언가를 그렸습니다. 어느 것도 도달 불가는 아니었습니다. 중국에서 페이지를 깨뜨리는 것은 보통 페이지가 아닙니다.
폼이 작동하는지를 결정하는 결과
www.google.com/recaptcha는 한 번도 응답하지 않았습니다. 데이터센터 회선에서 72 요청 중 성공 0회, 표본을 추출한 매 시각에, 오후 중반부터 저녁 피크를 지나 자정 너머까지. 저희 네트워크를 통해서는 72 중 72. 베이징 가정용 회선에서 같은 호스트는 그것에 닿은 18 요청 모두에서 실패했습니다.
이것은 지연 발견이 아니고, 그러데이션도 아닙니다. 폼 인증은 제출의 관문입니다: 위젯이 결코 로드되지 않으면, 제출 버튼이 결코 활성화되지 않습니다. 그 상태의 페이지는 느린 것이 아닙니다. 그것은 단 하나의 리드도 받지 못하는 폼이며, 페이지의 어느 것도 오류를 보고하지 않는데, 요청이 발행되었으나 그저 응답되지 않았기 때문입니다.
귀사 중국 사이트에 가둬진 문의 폼이 있고 이 특정한 것을 결코 측정한 적이 없다면, 그것이 가장 먼저 점검할 가치가 있는 것입니다.
시간이 지나야만 드러나는 결과
공개 JS CDN은 데이터센터 회선에서 두 경로 모두 시도의 100%에서 도달 가능했고, 가정용 회선에서 36 요청 중 하나도 실패하지 않았습니다. 도달 가능성은 유용한 것을 아무것도 말해 주지 않았습니다. 분포는 말했습니다:
| 중국 현지 시간 | 직접 TTFB(중앙값) | 저희 네트워크 | 비율 |
|---|---|---|---|
| 16:00 | 477ms | 103ms | 4.6× |
| 17:00 | 932ms | 99ms | 9.4× |
| 19:00 | 987ms | 104ms | 9.5× |
| 21:00 | 1,076ms | 102ms | 10.5× |
| 23:00 | 548ms | 103ms | 5.3× |
| 01:00 | 728ms | 110ms | 6.6× |
직접 첫 바이트 시간은 표본 추출한 가장 조용한 시각과 21:00 피크 사이에 두 배 넘게 늘었습니다. 같은 열두 시간에 걸쳐 전송 경로는 99에서 110밀리초 사이에 머물렀습니다 — 11밀리초의 폭.
그것을 포착하는 단일 숫자는 95분위수 대 중앙값의 비율입니다:
| 자원 | 직접 | 저희 네트워크 |
|---|---|---|
| 공개 JS CDN | 2.7× | 1.1× |
| 폰트 파일 | 1.2× | 1.1× |
| 태그 매니저 | 1.2× | 1.0× |
중앙값 660ms에 대한 p95 1,757ms는 스무 요청 중 하나가 거의 2초 걸린다는 뜻이며 — 그런 요청이 열두 개 있는 페이지에서, 그중 하나가 그 꼬리에 떨어지는 것만으로 렌더링을 붙잡기에 충분합니다. 이것이 평균이 중국에 잘못된 요약 통계인 이유이고, 한 번 표본 추출한 수치가 거의 가치 없는 이유입니다.
이것이 합쳐서 뜻하는 것
네 가지 실패 양상, 그리고 그중 하나만이 사람들이 보통 “중국에서 느림”으로 뜻하는 것입니다:
- 어떤 호스트는 정말로 괜찮습니다 — 그러나 어디서인지 말해야 합니다. 공개 JS CDN은 두 관측 지점 모두에서 버텼습니다. 그것은 이제 하나가 아니라 두 개의 데이터 포인트로 할 수 있는 주장이고, 이 목록에서 그것을 얻어낸 유일한 호스트입니다.
- 어떤 호스트는 도달 가능하지만 불안정합니다. 중앙값은 견딜 만해 보이고; 꼬리가 페이지가 실제로 깨지는 곳입니다. 하루에 걸쳐 표본 추출하지 않고는 이것을 볼 수 없습니다.
- 어떤 호스트는 아예 응답하지 않습니다. 오류 없음, 타임아웃 이벤트 없음, 신호 없음 — 그리고 그 호스트가 귀사 폼 인증이라면, 사업상 결과는 열화가 아니라 전면적입니다.
- 어떤 호스트는 중국 안 한 곳에서는 완벽하게 응답하고 다른 곳에서는 결코 응답하지 않습니다. 이것이 전에 없던 것이고, 저희 자신의 권고를 뒤집은 것입니다. 같은 나라의 데이터센터 회선과 소비자 회선은 같은 네트워크가 아닙니다.
실질적 결과는 “전부 라우팅” 또는 “아무것도 라우팅 안 함”보다 좁고 더 유용합니다. 경로는 자원별로, 귀사 방문자가 실제로 있는 곳에서 취한 측정으로 결정되어야 합니다 — 그리고 클라우드 회선에서 통과하는 호스트가 가정용 회선에서 통과한다고 밝혀진 것은 아닙니다. 이미 빠른 호스트를 건드리지 않고 두는 것은 그것이 귀사 방문자에게 정말로 빠를 때 여전히 올바른 조치입니다. 달라진 것은 그 호스트가 어느 것인지에 대한 저희 확신, 그리고 그렇게 말하는 데 얼마나 많은 증거가 드는지입니다.
왜 이것이 전송만의 문제가 아닌가
위의 모든 것은 어느 요청이 완료되느냐에 관한 것이고, 그것은 전송 문제입니다. 그러나 사람들이 손을 뻗는 해법 — 요청이 아예 국경을 넘지 않도록 중국 본토 안에서 서비스하기 — 은 순수하게 기술적 결정이 아닙니다. 중국 사용자에게 본토 인프라에서 서비스하는 것이 ICP 비안 요건을 작동시킵니다: 비안은 본토 법인에게 발급되고 귀사 호스팅 방식에 묶이며, 비안되지 않은 사이트는 본토 접속 제공자가 적법하게 실어 나를 수 없습니다.
그래서 같은 아키텍처 결정이 두 질문에 한 번에 답하며, 두 번째를 늦게 발견하기보다 함께 답할 가치가 있습니다: 귀사의 어느 요청이 실제 방문자에게 완료되는가, 그리고 그것이 완료될 그곳에서 서비스하도록 허가받았는가.
한계
- 소비자 측정은 자원봉사자 한 명, ISP 하나, 하룻밤입니다. 베이징의 차이나모바일 가정용 회선, 2026년 8월 30일 밤새 실행. 두 번째 ISP와 두 번째 도시가 있으면 데이터 포인트가 아니라 발견이 될 것입니다. 호스트별 결과는 그러데이션이 아니라 100%와 0%이고, 가장 큰 둘 뒤에 112와 54 요청이 있으며, 이것이 이 표본 크기에서 공표하는 이유입니다 — 그러나 단일 관측 지점은 단일 관측 지점입니다.
- 열두 시간 연구는 데이터센터 회선입니다. 상용 클라우드의 국제 트랜짓은 소비자 연결보다 실질적으로 낫기 때문에, 이 글 전반부의 모든 직접 경로 수치는 낙관적입니다. 후반부가 그 낙관이 치르는 비용입니다.
- 다른 브라우저 빌드. 데이터센터 프로브는 Debian의 Chromium 151.0.7922.173을; 자원봉사자는 Chrome for Testing 151.0.7922.77을 돌렸습니다. 완료와 첫 바이트 시간은 그 차이에 둔감합니다; 페인트 타이밍은 방향성으로만 읽어야 합니다.
- 다섯 자원, 88 사이트. 흔하고 이전 실패 데이터에서 나타났기 때문에 고른 것이지, 망라적이기 때문이 아닙니다.
- 처리량은 TTFB를 제외합니다, 작은 파일을 비교하는 공정한 방식이지만 처리량 열과 TTFB 열은 따로 읽어야 한다는 뜻입니다.
- 열두 시간 테스트는 모든 자원을 두 경로로 밀어 넣었는데, 비교가 요구하는 것이지 사이트가 전송되는 방식이 아닙니다. 거기의 전송 경로도 운영 환경 구성이 아니라 측정 가능성을 위해 지어진 단순화된 구성입니다.
다음에 측정할 것
다른 본토 ISP의 두 번째 소비자 관측 지점으로, 베이징 결과를 데이터 포인트에서 발견으로 옮길 유일한 것입니다. 저희는 또한 소비자 실행을 여기 보고된 88 사이트 너머로 확장하고 있습니다.
저희는 권고가 뒤집히는 것을 공표하는 편이, 저희 것이라는 이유로 그것을 세워 두는 편보다 낫다고 봅니다. 이 글 전반부의 힘으로 아키텍처 결정을 내리고 있다면, 후반부가 귀하의 생각을 바꿔야 할 부분입니다.
이 숫자들 뒤의 방법은, 저희가 처음에 틀렸던 여덟 가지를 포함합니다. 더 넓은 그림은 중국 안에서 측정한 280개 사이트 센서스에 있습니다. 그리고 귀사 자신의 사이트가 어느 제3자 호스트에 의존하는지 보고 싶으시면, 저희 중국 방화벽 테스트가 본토 안에서 자원별로 보고합니다.
자주 묻는 질문
제3자 자원은 중국 안에서 도달 가능한가요?
호스트에 그리고 중국 안 어디서 측정하느냐에 달려 있습니다. 데이터센터 프로브(Alibaba Cloud cn-zhangjiakou, 열두 시간 720회 측정, 2026-08-28)에서는 fonts.googleapis.com, www.googletagmanager.com, fonts.gstatic.com, cdn.jsdelivr.net이 모두 100% 도달 가능했고, www.google.com/recaptcha만 실패했습니다. 베이징 차이나모바일 가정용 회선(88 사이트, 264 페이지 로드, 2026-08-30)에서는 앞의 셋이 단 한 요청도 응답하지 않았고 — 각각 112, 54, 6 시도 — cdn.jsdelivr.net은 36 중 하나도 실패하지 않았습니다. 같은 나라의 클라우드 회선과 소비자 회선은 같은 네트워크가 아니며, 한쪽에서 통과하는 호스트가 다른 쪽에서 통과한다고 밝혀진 것은 아닙니다.
왜 기업 문의 폼이 중국에서 실패하나요?
흔히 제출을 가두는 인증 위젯이 결코 로드되지 않기 때문입니다. 저희 측정에서 www.google.com/recaptcha는 72 시도 중 성공 응답이 0회였습니다. 그런 일이 생기면 폼은 정상적으로 렌더링되고 제출 버튼은 결코 활성화되지 않습니다 — 페이지는 느린 것이 아니라, 단 하나의 리드도 받지 못하는 폼입니다. 아무것도 오류를 내지 않는데, 요청이 발행되었으나 그저 응답되지 않았기 때문입니다.
중국 전송 계층은 항상 더 빠른가요?
아니요, 그리고 그래서는 안 됩니다. 귀사 방문자의 네트워크에서 정말로 도달 가능하고 빠른 호스트의 경우, 그것을 추가 홉으로 라우팅하는 것은 아무 이득 없이 약 170~200밀리초를 치릅니다 — 저희 자신의 데이터센터 측정이 두 호스트에 대해 바로 그것을 보였습니다. 저희가 틀린 것은 확신이었습니다: 그 같은 두 호스트가 베이징 소비자 회선에서는 한 번도 응답하지 않았으므로, "이미 빠름"은 클라우드 프로브가 아니라 귀사 방문자가 쓰는 관측 지점에서 확립되어야 합니다. 경로는 자원별로 결정되고, 하나를 건드리지 않고 두는 증거는 올바른 곳에서 와야 합니다.
왜 평균이 중국 성능에 잘못된 통계인가요?
꼬리가 페이지가 깨지는 곳이기 때문입니다. 공개 JS CDN은 직접 첫 바이트 시간 중앙값 660ms와 95분위수 1,757ms — 2.7의 비율 — 를 측정했습니다. 스무 요청 중 하나가 거의 2초 걸리는 것은 그런 요청이 열두 개 있는 페이지에서 렌더링을 붙잡기에 충분합니다. 같은 열두 시간에 전송 경로는 중앙값 103ms에 p95 114ms, 1.1의 비율로 돌았습니다. 그 두 비율의 차이는 어떤 평균에도 보이지 않습니다.
중국의 국경 간 성능은 시간대에 따라 달라지나요?
상당히. 저희가 표본 추출한 공개 JS CDN의 경우, 직접 첫 바이트 시간이 중국 현지 시간 16:00의 477ms에서 21:00의 1,076ms로 올랐다가 밤새 떨어졌습니다. 같은 시각들에 전송 경로는 99에서 110밀리초 사이에 머물렀습니다. 한 번 표본 추출한 수치는 그것이 취해진 순간의 산물입니다.
이 측정은 어떻게 취해졌나요?
다섯 가지 제3자 자원을 중국 본토 안의 프로브에서 열두 시간 동안 10분마다 표본 추출하여, 각각을 라운드당 두 번씩 요청 — 한 번은 직접, 한 번은 저희 전송 네트워크를 통해 — 하여 총 720회 측정했습니다. 처리량은 본문 전송에 대해서만 계산하여 첫 바이트 시간을 제외함으로써 작은 파일이 연결 설정에 지배되지 않게 했습니다. 타임아웃은 30초이고 타임아웃은 폐기하지 않고 결과로 셉니다. 프로브는 데이터센터 회선으로, 그 국제 트랜짓은 기업 광대역 연결보다 실질적으로 나으므로, 직접 경로 수치는 낙관적입니다.
왜 사이트 자체는 응답하는데도 중국에서 페이지가 실패하나요?
실패가 보통 페이지가 아니라 페이지가 끌어오는 것에 있기 때문입니다. 베이징 가정용 회선에서 88 사이트, 264 페이지 로드에 걸쳐(2026-08-30), 102개의 다른 호스트가 응답을 반환하지 않았고, 그중 101개가 제3자 — 태그 매니저, 애널리틱스 엔드포인트, 동의·지오로케이션 서비스, 폰트 호스트, 광고 픽셀 — 였습니다. 한편 로딩을 끝내 완료하지 못한 57개 사이트는 하나하나 첫 바이트는 반환했고, 3분의 2는 멈추기 전에 화면에 무언가를 그렸습니다. 이 실패의 4분의 3은 어떤 오류도 내지 않았습니다: 요청이 보내졌고 아무것도 돌아오지 않았습니다. 이 참조들은 보통 문서 head에 앉아 있으므로, 결코 반환되지 않는 하나가 그 뒤의 모든 것을 붙잡습니다.