Теряете пользователей в Индии и Бразилии? Сначала протестируйте на дешёвом телефоне

Сайт загружается за 1,2 секунды на MacBook Pro. На Android-телефоне за $90 через 3G в Мумбаи тот же сайт загружается 11 секунд. Панель аналитики показывает «показатель отказов: 78%». Разработчики не видят бага. Бага и нет — просто разрыв между устройствами, который никто не тестировал.

Настоящая проблема: телефоны разработчиков — не телефоны пользователей

Большая часть разработки ведётся на флагманских устройствах с быстрым Wi-Fi. У большинства пользователей в Индии и Бразилии нет флагманских устройств. У них бюджетные Android-смартфоны с 2–3 ГБ оперативной памяти, более медленными процессорами и нестабильным интернет-соединением.

Ключевой момент: разрыв в производительности между телефоном разработчика и телефоном пользователя на развивающихся рынках составляет не 20–30%. Зачастую это 300–500%.

По данным BrowserStack, около 90% мирового интернет-населения выходит в сеть с мобильных устройств. Страницы, загружающиеся в течение двух секунд, имеют средний показатель отказов 9%. При загрузке в пять секунд показатель отказов подскакивает до 38%.

Статистика об уходе 53% пользователей из исследования Google по-прежнему актуальна: 53% посещений мобильных сайтов прерываются, если страница загружается дольше 3 секунд.

Что происходит на дешёвом телефоне

Десктопные страницы в среднем загружаются за 2,5 секунды. Мобильные страницы в среднем — за 8,6 секунды, что на 70,9% дольше, по данным SiteQwality. На бюджетных устройствах ситуация усугубляется из-за трёх накладывающихся факторов:

• Троттлинг процессора. Парсинг и выполнение JavaScript занимают в 3–5 раз больше времени на MediaTek Helio G35 по сравнению со Snapdragon 8 Gen 2.
• Ограниченная оперативная память. Браузер агрессивно закрывает фоновые вкладки и с трудом справляется со страницами с большим DOM.
• Нестабильность сети. Соединения в городах второго и третьего уровня теряют пакеты, добавляют задержку и переключаются между 3G и 4G.

Walmart обнаружил, что каждая секунда улучшения скорости загрузки страницы увеличивает конверсию на два процента. Amazon подсчитал, что каждые 100 миллисекунд дополнительной задержки обходятся им в один процент продаж — что сейчас составляет примерно $3,8 миллиарда в год.

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

Как на самом деле тестировать на дешёвом телефоне

Вариант 1: Купить реальное устройство

Купите Xiaomi Redmi 10A или Samsung Galaxy A04 за $80–100. Это лучшая инвестиция для работы над производительностью, нацеленной на развивающиеся рынки. Ни один эмулятор не воспроизводит реальный термальный троттлинг, нагрузку на память и поведение сетевого стека бюджетного чипсета.

Вариант 2: Троттлинг в Chrome DevTools

Откройте Chrome DevTools → Performance → CPU throttling (замедление в 4 раза) и Network throttling (Slow 3G). Это грубое приближение. Оно не симулирует нехватку оперативной памяти и термальный троттлинг.

# Сетевые пресеты Chrome DevTools:
# Slow 3G: 400мс RTT, 400 кбит/с загрузка, 400 кбит/с отдача
# Fast 3G: 150мс RTT, 1,6 Мбит/с загрузка, 750 кбит/с отдача

Вариант 3: sitespeed.io на реальном Android-телефоне

В документации sitespeed.io представлено полное руководство по тестированию на реальных устройствах. На Linux-хосте с Docker:

docker run --privileged -v /dev/bus/usb:/dev/bus/usb \
  -e START_ADB_SERVER=true --rm \
  -v "$(pwd):/sitespeed.io" \
  sitespeedio/sitespeed.io:39.5.0 \
  -n 1 --android --browsertime.xvfb false \
  https://your-site.com

Частая ошибка: запуск Android-тестов из Docker на macOS. Это работает только на Linux-хосте из-за ограничений проброса USB.

Для сетевого троттлинга, имитирующего условия развивающихся рынков, используйте параметры TSProxy:

--rtt=200 --inkbps=1600 --outkbps=768

Вариант 4: BrowserStack или Page-oscope

BrowserStack предлагает тестирование на реальных устройствах в облаке. Page-oscope от MobileMoxie предоставляет бесплатное тестирование на более чем 50 устройствах iOS и Android — три раза в день без регистрации или с бесплатным пробным периодом на семь дней.

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

Проверено в продакшене. Эти четыре изменения дают наибольший эффект на бюджетных устройствах:

1. Сжимайте изображения. Инструменты вроде TinyPNG или Squoosh уменьшают размер изображений без видимой потери качества. Необработанные изображения — самая частая причина медленной загрузки мобильных страниц.

2. Сокращайте JavaScript. Каждый килобайт JS стоит дороже на медленном процессоре, чем на быстром. Проведите аудит бандлов. Удалите неиспользуемые библиотеки. Отложите загрузку некритичных скриптов.

3. Достигайте целевых показателей Core Web Vitals. Google обновил Core Web Vitals 12 марта 2024 года, заменив First Input Delay (FID) на Interaction to Next Paint (INP). Только 65% сайтов достигают хорошей производительности INP на мобильных, по сравнению с 93%, которые ранее соответствовали стандартам FID.

4. Отдавайте ресурсы, подходящие для региона. Используйте CDN с граничными узлами в Индии и Бразилии. Отдавайте изображения в формате WebP. Включите сжатие Brotli.

Проблема INP, о которой никто не говорит

Переход от FID к INP в качестве метрики отзывчивости Google изменил правила игры. FID измерял только задержку первого взаимодействия. INP измеряет каждое взаимодействие на протяжении всего жизненного цикла страницы.

Простыми словами: страница может ощущаться быстрой при первом нажатии, но зависнуть на третьем скролле или клике по кнопке. Бюджетные телефоны с медленными процессорами обнажают проблемы INP, которые флагманские устройства полностью маскируют.

Только 65% сайтов проходят проверку INP на мобильных. Это падение с 93% соответствия FID означает, что многие сайты потеряли статус «хорошо» по Core Web Vitals, не изменив ни строчки кода.

Попробуйте сами

Выберите одну страницу, которая получает трафик из Индии или Бразилии. Прогоните её через Chrome DevTools с замедлением CPU в 4 раза и сетевым троттлингом Slow 3G. Посмотрите, как загружается страница. Посчитайте секунды. Если загрузка занимает больше трёх секунд — именно это причина показателя отказов, а не контент, не тексты и не ценообразование.

Если это работает на дешёвом телефоне — это работает везде. Если это работает только на MacBook разработчика — это не работает нигде, где это важно.

Часто задаваемые вопросы

Почему моё приложение нормально работает на моём телефоне, но тормозит на более дешёвых устройствах?

Телефоны разработчиков обычно имеют в 4–8 раз больше вычислительной мощности, в 2–4 раза больше оперативной памяти и более быстрое хранилище, чем бюджетные устройства. Выполнение JavaScript, рендеринг DOM и декодирование изображений — всё это зависит от аппаратных возможностей. Страница, которая рендерится за 1 секунду на флагмане, может загружаться 5–8 секунд на бюджетном телефоне.

Почему интернет-соединение и производительность отличаются на развивающихся рынках, таких как Индия и Бразилия?

Сетевая инфраструктура в городах второго и третьего уровня часто опирается на перегруженные сотовые вышки с нестабильным покрытием 3G/4G. Среднее время двусторонней задержки составляет 150–300 мс по сравнению с 20–50 мс на западном широкополосном доступе. Потеря пакетов и обрывы соединения — обычное дело, что делает каждый дополнительный HTTP-запрос более затратным.

Как эффективно тестировать приложение на разных типах устройств и в различных сетевых условиях?

Самый надёжный метод — тестирование на реальном бюджетном оборудовании. Android-телефон за $90 покажет больше, чем любой симулятор. Дополняйте физическое тестирование троттлингом в Chrome DevTools (CPU в 4 раза, Slow 3G), sitespeed.io на реальных устройствах или облачными сервисами вроде BrowserStack, которые предоставляют доступ к фермам реальных устройств.

Почему я теряю пользователей в определённых географических регионах и как это отладить?

Сегментируйте аналитику по типу устройства и скорости соединения, а не только по географии. Используйте отчёты Google Analytics по категориям устройств или JavaScript-библиотеку web-vitals для сбора метрик реальных пользователей (RUM). Сравните показатели Core Web Vitals между разными категориями устройств. Разрыв между «быстрыми устройствами» и «медленными устройствами» обычно объясняет региональное падение показателей.