When colleagues in China report that the global website is slow, start by turning that feedback into observations someone else can investigate.
A page that does not appear, slow images, missing video, and a form that gives no response may involve different parts of the website. Describe what happens before deciding what to change.
Record the conditions
Capture the URL, date and time, city, network provider or connection type, device, and browser. Note whether the connection uses a corporate network, proxy, or VPN.
A screenshot or short recording helps, but include a precise description:
The page text appears, but the video area stays blank. Selecting the product download does not open a document.
This is more useful than a general report that the site “does not work.” Clear conditions make comparison and follow-up easier.
Test the tasks visitors need to complete
Choose a small set of important pages and journeys: finding a product, opening a document, watching relevant content, or submitting an inquiry.
The following illustrates a reporting format, not actual test results:
| Visitor task | Observation | Question to investigate |
|---|---|---|
| Read product information | Text appears; some images are delayed | Where do the images come from? |
| Watch a video | The player does not appear | Which service and dependencies are involved? |
| Submit an inquiry | No clear response after selecting submit | What happens to the request and submission? |
Recording the affected task connects technical investigation with the work the website is meant to support.
Ask the technical team to examine dependencies
A page may load scripts, video, or analytics from other services. Third-party scripts can add network requests and browser processing work, so their actual impact needs examination. See web.dev’s guidance on third-party JavaScript.
Cross-border network paths can also affect latency and reliability. Hosting and request routing deserve investigation, without assuming they explain a particular failure. See Cloudflare’s China Network documentation.
Ask whether the main page request succeeds, which resources fail or take unusually long, and whether those failures affect important tasks.
Understand what a report establishes
A report should identify how its data was collected. Lab tests use predefined conditions, while field data reflects actual visits; their results can differ. See web.dev’s explanation of lab and field data.
A report without mainland China test conditions cannot establish that audience’s experience. A successful visit also does not represent every region or network.
Separate observed issues, possible causes, and questions that still require verification.
Plan improvements around the evidence
Discuss the impact and available options with the technical owners. An optional external resource may be reviewed for changes. A global form or CMS issue may need headquarters’ involvement. A larger hosting change needs its own assessment.
For each action, record the owner, the issue it is intended to address, and how the result will be checked. Retest important journeys under comparable conditions.
The useful outcome is a record of what happened, the evidence, who will act, and how improvement will be verified. Access problems alone do not establish lost revenue or prove an untested explanation.