01 European origin
Jira Data Center and protected business data remain in the existing European infrastructure.
Jira Data CenterEU data centersProtected origin
Case Study / Jira Data Center / Mainland China
Jira page load in China: 7.0s 1.24s
We use CDNetworks technology—backed by its China-based parent company, Wangsu Science & Technology—to accelerate your business in mainland China.
PlatformJira Data Center
ScopeMainland China performance
VerificationRUM + external testing
InfrastructureCDNetworks CDN Pro + Origin Fast Route
Evidence runtime
PW / RUM-CHINA-0701 / Median page load −82%
Before · n=513 7.00 s
After · n=456 1.24 s
02 / Median TTFB −57%
Before616 ms
After263 ms
03 / External verification 130 mainland locations
A 1.034 s B 0.939 sSystem / China delivery stack
A controlled delivery path with our own measurement and caching layer.
We combine CDNetworks infrastructure with software built around Jira Data Center: real-user instrumentation, cache control, API-driven configuration, and traffic verification.
01 / OriginEU origin 02 / DeliveryNear-China edge 03 / Real trafficMainland users 04 / VerificationRUM evidence
02 Delivery and acceleration
CDN Pro delivers static files through a Near-China edge. Origin Fast Route is used separately for selected attachment traffic between the edge and European origin.
CDN ProNear-China edgeStatic filesOrigin Fast RouteAttachments
03 Caching engineering
Our Service Worker and release tooling normalize versioned resources, remove stale duplicates, cache safe static bundles, and pre-warm new releases through the CDN API.
Service WorkerVersion-scoped cacheCacheFirstSingle-flightStale pruneEdge prefetch
04 Real-user evidence
Our RUM plugin measures browser behavior across real traffic: page load, TTFB, backend and frontend time, resource waterfalls, JavaScript errors, and cache state.
Real usersPage loadTTFBBackend / frontendResource waterfallJS errorsCache state
05 / CONTROL LOOP API control and traffic observability
We manage versioned CDN configuration, validation, deployment, and edge prefetch through APIs. Access logs and reporting expose client region and ISP, cache HIT or MISS, edge node, response timing, traffic volume, and OFR usage.
Property APIVersioned configValidateStaging → ProductionPrefetch APIAccess logsHIT / MISSEdge nodesTraffic volumesOFR up / down
01 / The problem
“Jira is slow in China” was a symptom, not a diagnosis.
The baseline contained approximately 8,400 production page-load samples. The long tail was concentrated in mainland China, while server processing above five seconds was effectively absent. The bottleneck was not a slow database query: it was the interaction between distance, network delivery, frontend weight, and browser caching.
Without browser-level evidence, each layer could plausibly blame another. We needed a measurement system capable of separating backend processing, time to first byte, frontend execution, resource waterfalls, client errors, and cache state for real sessions.
~8,400production page-load samples
144extreme loads above 90 seconds
~0%loads with server processing above 5 seconds
02 / Measurement system
Measure first. Change one layer. Verify again.
The monitoring system ran inside Jira Data Center and measured what users actually experienced rather than relying on origin-side averages.
01 In-product RUM
A Jira Data Center plugin captured page load, DOM readiness, TTFB, backend/frontend split, resource waterfalls, transferred bytes, slow resources, and JavaScript failures from real browsers.
02 Comparable regional cohorts
Mainland traffic was segmented to direct consumer ISPs. Hosting, proxy, and VPN paths were excluded so the result measured the delivery architecture being changed.
03 Layer-by-layer diagnosis
Timing decomposition separated application processing from the network leg and frontend execution. This prevented infrastructure changes from being justified by an unrelated server metric.
04 Independent cross-checks
Real-user cohorts were cross-checked with repeated distributed measurements from 130 mainland locations and delivery logs confirming route and cache behavior.
03 / Infrastructure
Two CDNetworks services addressed different parts of the delivery path.
The services were evaluated as separate interventions. The headline page-load result belongs to CDN Pro with Near-China delivery, not to a blended infrastructure claim.
CDNETWORKS / 01 CDN Pro · Near-China delivery
CDN Pro with Near-China delivery moved the user-facing delivery layer closer to mainland users. This is the primary intervention associated with the verified reduction in median page-load time.
7.00 s → 1.24 sCDNETWORKS / 02 Origin Fast Route (OFR)
Origin Fast Route was enabled later for selected attachment traffic between the edge and origin. It was evaluated separately and is not included in the headline 82% page-load claim.
Measured separately04 / Measured result
A regional architecture change with a visible, sustained effect.
Metric Before After Change Evidence
Median page load 7.00 s 1.24 s −82%
RUM · n=513 → n=456Median TTFB 616 ms 263 ms −57%
RUM · n=513 → n=456China / non-China gap 6–7× 1.17× Near parity
Comparable regional cohortsTwo repeated post-change runs averaged 1.034 seconds and 0.939 seconds across 130 mainland locations, compared with an approximately 6-second baseline.
A later sample of 395 real mainland sessions measured 1.20-second median load, 2.449-second p90, and 282-millisecond median TTFB. No regression was visible in those medians.
05 / What the evidence exposed next
The measurement system kept finding constraints after the first win.
Resource-level analysis identified unnecessary plugin bundles. Conditional loading reduced the production JavaScript payload from 31 MB to 9.9 MB.
Our Service Worker keeps large, unchanged Jira plugin bundles in the browser, so repeat visits do not download them again from Europe. Version-aware keys, stale-version pruning, and cache resets preserve the speed benefit without serving outdated resources after releases.
06 / Evidence boundary
Strong claims stop where comparable evidence stops.
A separate attachment-upload change produced only four post-change mainland samples with mixed timings. That sample was too small for a causal performance conclusion, so no upload speed-up is claimed in this case study.
Portable evidence / System link
Take the evidence with you.
Scan to open the verified China performance case on another device. The final QR is generated from the exact public case URL and remains fully scannable after the system assembles it.
Open this case07 / Your system