Кейс / Jira Data Center / материковый Китай

Загрузка страниц Jira в Китае: 7.0s 1.24s

Jira Data Center Производительность в материковом Китае RUM · n=513 → n=456 CDNetworks

Мы используем технологии CDNetworks — компании китайской группы Wangsu Science & Technology — для ускорения вашего бизнеса в материковом Китае.

ПлатформаJira Data Center
ОбластьПроизводительность в материковом Китае
ПроверкаRUM + внешние замеры
ИнфраструктураCDNetworks CDN Pro + Origin Fast Route
Система / Доставка в Китай

Контролируемый путь доставки с собственным слоем измерения и кэширования.

Мы объединяем инфраструктуру CDNetworks с программными разработками вокруг Jira Data Center: RUM по реальным пользователям, контроль кэша, конфигурацию через API и проверку трафика.

01 / OriginEU origin 02 / DeliveryNear-China edge 03 / Real trafficMainland users 04 / VerificationRUM evidence
01

Европейский origin

Jira Data Center и защищённые бизнес-данные остаются в существующей европейской инфраструктуре.

Jira Data CenterEU data centersProtected origin
02

Доставка и ускорение

CDN Pro доставляет статические файлы через Near-China edge. Origin Fast Route отдельно используется для выбранного трафика вложений между edge и европейским origin.

CDN ProNear-China edgeStatic filesOrigin Fast RouteAttachments
03

Инженерия кэширования

Наш Service Worker и release-инструменты нормализуют версионные ресурсы, удаляют устаревшие дубликаты, безопасно кэшируют статику и прогревают новые релизы через CDN API.

Service WorkerVersion-scoped cacheCacheFirstSingle-flightStale pruneEdge prefetch
04

Данные реальных пользователей

Наш RUM-плагин измеряет поведение браузера на реальном трафике: page load, TTFB, backend- и frontend-время, водопад ресурсов, JavaScript-ошибки и состояние кэша.

Real usersPage loadTTFBBackend / frontendResource waterfallJS errorsCache state
05 / CONTROL LOOP

Управление через API и наблюдаемость трафика

Через API мы управляем версионной конфигурацией CDN, валидацией, деплоем и прогревом edge. Access logs и отчёты показывают регион и ISP клиента, cache HIT или MISS, edge-ноду, response timing, объём трафика и использование OFR.

Property APIVersioned configValidateStaging → ProductionPrefetch APIAccess logsHIT / MISSEdge nodesTraffic volumesOFR up / down
01 / Проблема

«Jira медленно работает в Китае» — это симптом, а не диагноз.

Базовая выборка содержала около 8 400 продакшен-замеров загрузки страниц. Длинный хвост был сосредоточен в материковом Китае, а серверная обработка дольше пяти секунд практически отсутствовала. Узким местом был не медленный запрос к базе, а взаимодействие расстояния, сетевой доставки, веса фронтенда и браузерного кэширования.

Без данных из браузера каждый слой мог правдоподобно обвинять другой. Нужна была система, способная отдельно измерять серверную обработку, TTFB, выполнение фронтенда, водопад ресурсов, клиентские ошибки и состояние кэша в реальных сессиях.

~8,400продакшен-замеров загрузки
144экстремальных загрузки дольше 90 секунд
~0%загрузок с серверной обработкой дольше 5 секунд
02 / Система измерения

Сначала измерить. Изменить один слой. Измерить снова.

Система мониторинга работала внутри Jira Data Center и измеряла реальный пользовательский опыт, а не усреднённые показатели origin-сервера.

01

Встроенный RUM

Плагин Jira Data Center собирал из реальных браузеров время загрузки, готовность DOM, TTFB, разделение backend/frontend, водопад ресурсов, переданные байты, медленные ресурсы и JavaScript-ошибки.

02

Сопоставимые региональные выборки

Трафик материкового Китая ограничивался прямыми пользовательскими сетями. Hosting, proxy и VPN исключались, чтобы результат измерял именно изменяемую архитектуру доставки.

03

Послойная диагностика

Декомпозиция таймингов отделила обработку приложения от сетевого плеча и выполнения фронтенда. Инфраструктурное изменение не обосновывалось посторонней серверной метрикой.

04

Независимая перекрёстная проверка

Пользовательские выборки проверялись повторными распределёнными замерами из 130 точек материкового Китая и логами доставки, подтверждающими маршрут и поведение кэша.

03 / Инфраструктура

Два сервиса CDNetworks работали с разными участками пути доставки.

Сервисы оценивались как отдельные изменения. Основной результат по загрузке страниц относится к CDN Pro с доставкой Near-China, а не к смешанному инфраструктурному заявлению.

CDNETWORKS / 01

CDN Pro · Near-China delivery

CDN Pro с доставкой Near-China приблизила пользовательский слой доставки к материковому Китаю. Именно с этим изменением связан подтверждённый результат по снижению медианной загрузки страниц.

7.00 s → 1.24 s
CDNETWORKS / 02

Origin Fast Route (OFR)

Origin Fast Route был позднее включён для выбранного трафика вложений между edge и origin. Он оценивался отдельно и не входит в основное заявление о снижении загрузки страниц на 82%.

Измерялось отдельно
04 / Измеренный результат

Изменение региональной архитектуры с видимым и устойчивым эффектом.

Метрика До После Изменение Доказательство
Медианная загрузка 7.00 s 1.24 s −82% RUM · n=513 → n=456
Медианный TTFB 616 ms 263 ms −57% RUM · n=513 → n=456
Разрыв Китай / другие регионы 6–7× 1.17× Почти паритет Сопоставимые региональные выборки
Внешний замер 130 точек в материковом Китае

Два повторных прогона после изменения показали средние 1,034 и 0,939 секунды по 130 точкам материкового Китая против исходных приблизительно 6 секунд.

Поздний контроль продакшена n=395 · 1.20 s

Поздняя выборка из 395 реальных сессий материкового Китая показала медиану 1,20 секунды, p90 2,449 секунды и медианный TTFB 282 миллисекунды. Регрессии в этих медианах не наблюдалось.

05 / Что доказательства выявили дальше

После первого результата система измерения продолжила находить ограничения.

Вес фронтенда 31 MB → 9.9 MB

Анализ на уровне ресурсов выявил лишние плагинные бандлы. Условная загрузка сократила продакшен-JavaScript с 31 до 9,9 МБ.

Клиентское кэширование Повторная загрузка бандла ≈ 0 Б

Наш Service Worker сохраняет крупные неизменившиеся бандлы плагинов Jira в браузере, поэтому при повторных открытиях их не приходится снова загружать из Европы. Версионные ключи, очистка старых копий и сброс кэша сохраняют ускорение, не отдавая устаревшие ресурсы после релизов.

06 / Граница доказательств

Сильное утверждение заканчивается там, где заканчиваются сопоставимые данные.

Для отдельного изменения загрузки вложений после внедрения было получено только четыре китайских наблюдения с неоднородными результатами. Этой выборки недостаточно для причинного вывода, поэтому ускорение upload в кейсе не заявляется.

Переносимое доказательство / Системная ссылка

Возьмите доказательство с собой.

Отсканируйте код, чтобы открыть проверенный кейс об ускорении в Китае на другом устройстве. Финальный QR построен по точному публичному адресу кейса и полностью сканируется после сборки системы.

Открыть этот кейс
07 / Ваша система

Есть проблема производительности, которую не объясняют средние значения?

Обсудить доказательства