Ми часто стикаємося з ситуацією: застосунок чудово працює на тестовому Wi-Fi, але користувачі масово скаржаться на гальма. Причина — неоптимальна мережева взаємодія, яка виявляється тільки при профілюванні мережі мобільного застосунку. В одному з наших проєктів при відкритті стрічки надсилалося 47 запитів, з яких 12 дублювалися, а 8 завантажували дані, що вже лежали в локальному кеші. Кожна зайва секунда очікування знижує конверсію на 20%, і без профілювання ви ризикуєте втратити до 30% аудиторії. Аналіз HTTP-запитів та оптимізація API допоможуть уникнути цих втрат.
Наша команда має 6+ років досвіду в оптимізації мобільних застосунків і провела профілювання мережі для 40+ проєктів. Ми використовуємо сучасні інструменти та методики, щоб гарантувати швидкий і стабільний користувацький досвід. Оптимізація мережі не тільки покращує UX, але й скорочує витрати на серверний трафік до 40% — у грошовому еквіваленті це економія від 100 000 до 300 000 гривень на рік для середньостатистичного застосунку. Зниження трафіку на 30% може заощадити до 200 000 гривень на серверних рахунках за рік. Вартість профілювання від 15 000 грн за проєкт. Замовте профілювання та отримайте детальний звіт з рекомендаціями.
Які інструменти використовуємо?
Charles Proxy / Proxyman
Перехоплюють весь HTTP/HTTPS-трафік пристрою. Charles Proxy — кросплатформенний стандарт (Charles Proxy на Wikipedia), Proxyman — нативний macOS-інструмент з кращим UX для iOS-розробників. Налаштування: встановити кореневий сертифікат на пристрій, виставити проксі в налаштуваннях Wi-Fi.
Зазначимо: що шукаємо в Charles:
- Дубльовані запити — один і той же URL декілька разів за короткий період
- Розмір відповідей — ендпоінти, що віддають явно зайві дані (10 KB там, де потрібно 500 байт)
- Час відповіді — повільні серверні відповіді vs клієнтська затримка
- Помилки та ретраї — скільки запитів завершується помилкою і як обробляється retry
Throttling в Charles (Proxy → Throttle Settings) — симуляція 3G, Edge, повільного Wi-Fi. Charles Proxy пропонує 4 профілі throttling (3G, EDGE, DSL, WiFi) проти 2 в Proxyman — це в 2 рази більше варіантів для тестування. Обов'язковий крок: перевірити застосунок на 400 Kbps перед релізом. Поведінка на поганому з'єднанні часто не тестується і містить серйозні баги.
Для коректного перехоплення HTTPS-трафіку необхідно встановити кореневий сертифікат Charles на пристрій та довіряти йому. На iOS це робиться через Налаштування → Основні → Профілі. На Android — через Безпека → Встановити сертифікат.
Android Network Profiler
Вбудований в Android Studio. Показує запити в хронології, тіло запиту/відповіді, час DNS resolution, SSL handshake, waiting, downloading. Особливо корисний Connection View — видно, скільки паралельних з'єднань відкрито та чи є черга очікування.
Для OkHttp додаємо EventListener для точних метрик:
val client = OkHttpClient.Builder() .eventListener(object : EventListener() { override fun connectStart(call: Call, inetSocketAddress: InetSocketAddress, proxy: Proxy) { Log.d("NET", "connectStart: ${call.request().url}") } override fun responseBodyEnd(call: Call, byteCount: Long) { Log.d("NET", "responseBodyEnd: $byteCount bytes") } }) .build() Xcode Network Instruments + URLSessionTaskMetrics
URLSessionTaskMetrics — вбудований механізм iOS для збору метрик кожного запиту:
func urlSession(_ session: URLSession, task: URLSessionTask, didFinishCollecting metrics: URLSessionTaskMetrics) { for transaction in metrics.transactionMetrics { print("DNS: \(transaction.domainLookupEndDate! - transaction.domainLookupStartDate!)") print("TLS: \(transaction.secureConnectionEndDate! - transaction.secureConnectionStartDate!)") print("TTFB: \(transaction.responseStartDate! - transaction.requestStartDate!)") } } Це дає breakdown: DNS lookup, TCP connect, TLS handshake, TTFB (Time to First Byte), transfer time. Якщо TLS handshake займає 300 мс на кожному запиті — немає HTTP persistent connections або неправильно налаштовано Certificate Pinning без session reuse. Детальніше: URLSessionTaskMetrics.
Порівняння інструментів
| Інструмент | Платформа | Особливості | Коли використовувати |
|---|---|---|---|
| Charles Proxy | macOS/Windows | HTTP/HTTPS, throttling, rewrite | Універсальне рішення |
| Proxyman | macOS | Нативний UI, швидке налаштування | iOS-розробка |
| Android Studio Profiler | Android | Хронологія запитів, Connection View | Android-застосунки |
| Xcode Instruments | iOS | URLSessionTaskMetrics, Network | iOS-застосунки |
Як ми оптимізуємо мережевий шар?
Аналіз та виявлення проблем
Ми перевіряємо HTTP/2 multiplexing — чи використовується протокол або застосунок працює на HTTP/1.1 з 6 паралельними з'єднаннями. URLSession та OkHttp підтримують HTTP/2 автоматично, якщо сервер його підтримує. Видно в Charles: Protocol: h2 vs http/1.1. HTTP/2 multiplexing дозволяє завантажувати до 100 паралельних запитів, що в 16 разів більше, ніж HTTP/1.1 (6 потоків).
Compression: сервер повинен повертати Content-Encoding: gzip або br (Brotli) для JSON. Якщо ні — JSON-відповіді йдуть у сирому вигляді. Різниця для типових API-відповідей: 3–5x за розміром.
Connection reuse: TLS handshake — дорога операція (50–200 мс). Persistent connections перевикористовують встановлене з'єднання. Якщо кожен запит починається з нового handshake — проблема в конфігурації URLSession (декілька інстансів замість shared) або в серверному keepalive timeout.
Як проводиться профілювання: покроково
- Встановлюємо сниффер (Charles/Proxyman) та кореневий сертифікат на пристрій.
- Налаштовуємо throttling для симуляції повільного з'єднання (3G або 400 Kbps).
- Запускаємо застосунок та відтворюємо типові сценарії користувача.
- Записуємо весь трафік та аналізуємо кожен запит в Charles: шукаємо дублікати, великі відповіді, високий час DNS/TLS.
- Складаємо звіт зі знайденими проблемами та рекомендаціями.
Типові проблеми та рішення
| Проблема | Ознака | Рішення |
|---|---|---|
| Дубльовані запити | Один URL завантажується декілька разів | Кешування, об'єднання запитів |
| Відсутність стиснення | JSON без gzip | Налаштувати Content-Encoding на сервері |
| Повільний TLS Handshake | Затримка >100 мс щоразу | Persistent connections, HTTP/2 |
| Некешований DNS | Затримка при кожному запиті | DNS prefetch, єдиний URLSession |
Практичний кейс
Наш клієнт звернувся з проблемою: кожен запит до API займав 800 мс. Профілювання через Charles показало, що кожен запит мав DNS lookup 120–180 мс. Причина — DNS не кешувався через короткий TTL (60 секунд) і URLSession не перевикористовував DNS resolution між сесіями. Рішення: URLSessionConfiguration.urlCache з кастомним DNS prefetch + перехід на єдиний URLSession.shared замість створення нового інстансу в кожному сервісному класі. Після оптимізації час запиту знизився до 200 мс — прискорення в 4 рази. Зв'яжіться з нами для консультації — оцінимо ваш проєкт за 1 день.
Що входить у профілювання?
Профілювання включає повний цикл: аналіз поточної мережевої взаємодії застосунку, виявлення дубльованих запитів, надлишкових даних, повільних ендпоінтів. Ми перевіряємо DNS-кешування, стиснення, HTTP/2, persistent connections. Готуємо детальний звіт зі знайденими проблемами та рекомендаціями, допомагаємо з їх виправленням (кешування, об'єднання запитів, налаштування сесії). Після впровадження проводимо підсумкове повторне профілювання для підтвердження покращень.
Терміни
Профілювання мережі та підготовка звіту — 1–2 дні. Виправлення виявлених проблем — 2–5 днів. Вартість розраховується індивідуально залежно від складності проєкту. Отримайте консультацію — ми розповімо, скільки часу займе оптимізація саме вашого застосунку.
Перевірте налаштування HTTP/2, стиснення відповідей та DNS-кешування — ці прості кроки можуть прискорити застосунок у рази. Замовте профілювання мережі та переконайтеся, що ваш застосунок працює максимально швидко. Гарантуємо результат: після оптимізації час завантаження даних скоротиться мінімум на 30%.