Как на практике измерить прирост скорости доступа в Латинской Америке благодаря глобальной сети ускорения?

Зарубежный сайт, размещённый на независимом домене, нормально открывается в Китае, но посетители из Латинской Америки сообщают, что изображения товаров долго не отображаются, а страницы с формой запроса медленно загружаются. Такие проблемы ухудшают работу рекламных целевых страниц и могут привести к неверной оценке качества трафика маркетинговой командой. Насколько заметно глобальная сеть ускорения повышает скорость доступа в Латинской Америке? Ответ зависит от местных сетей доступа, покрытия узлами ускорения, маршрута до исходного сервера и состава ресурсов страницы. Нельзя судить об этом только по факту «подключения к глобальным узлам».

Эффективный метод практического тестирования — провести парные тесты одного и того же сайта с включённым и выключенным ускорением в нескольких городах Латинской Америки и в сетях разных операторов, одновременно отслеживая время запросов, загрузку страниц и долю ошибок. Сначала определите, какой именно этап ускорение улучшило, а затем оцените, затронуло ли это основные регионы клиентов.

Сначала зафиксируйте условия сравнения

Перед тестированием чётко определите, что входит в решение: кэширование статических ресурсов, оптимизация маршрутизации динамических запросов или и то и другое. Ускорение только изображений и скриптов не обязательно сократит время отправки запроса; близкое расположение периферийного узла также не означает, что запросы, не попавшие в кэш, будут быстрее доставляться до исходного сервера.

Выберите страницу сведений о товаре, рекламную целевую страницу и один динамический интерфейс только для чтения. В обеих группах должны использоваться один и тот же исходный сервер, версия страниц, объём ресурсов и конфигурация серверной части. Не включайте ускорение в одной группе, одновременно меняя формат изображений или обновляя сервер: в таком случае невозможно определить причину результата.

• Сохраняйте реальный маршрут доступа: по возможности переключайте конфигурацию для одного домена и убедитесь, что она вступила в силу. Если используются два тестовых домена, проверьте, совпадают ли сертификаты, перенаправления, правила кэширования и адреса ресурсов.
• Проверяйте разные состояния кэша: отдельно учитывайте пустой кэш браузера, отсутствие ресурса в кэше периферийного узла и наличие ресурса в нём. Первый визит в браузере не означает, что в кэше периферийного узла нет нужного ресурса.
• Контролируйте переменные браузера: используйте одинаковые устройства, версии браузера, размеры области просмотра и условия ограничения скорости сети. Фиксируйте, повторно ли используется соединение, чтобы не сравнивать повторное использование соединения в одной группе с новым установлением соединения в другой.

Как выбрать точки тестирования в Латинской Америке, чтобы результаты были репрезентативными

Выбирайте точки тестирования с учётом распределения клиентов, а не только исходя из удобства доступа к одному облачному центру обработки данных. Можно выбрать соответствующие рынку города, например Сан-Паулу в Бразилии, Мехико в Мексике и Сантьяго в Чили, а затем добавить местные проводные или мобильные сети основных рынков. Страну, город, оператора и тип сети необходимо указывать в записях о тестировании.

Облачные серверы подходят для многократного выполнения тестовых запросов, однако качество их международных каналов и соединений с другими сетями может отличаться от условий обычных пользователей. Используйте облачные точки тестирования для диагностики маршрута, а затем проверяйте результаты в сетях местных пользователей или по данным о производительности для реальных пользователей. Выход VPN отражает только маршрут через этот выход и не может напрямую служить показателем качества доступа для местных посетителей.

Проводите несколько серий тестов в разные дни, в часы пиковой и непиковой нагрузки в регионе, чередуя базовую группу и группу с ускорением, чтобы уменьшить влияние колебаний сети. Предварительным запуском определите размер выборки для каждой серии. После официального тестирования не удаляйте медленные запросы только потому, что результат «выглядит недостаточно хорошо».

Измеряйте в двух масштабах: от запроса до страницы

На первом уровне измеряйте отдельные запросы. С помощью curl можно вывести время DNS-запроса, TCP-подключения, TLS-рукопожатия, получения первого байта и полное время, а также фиксировать код состояния, размер тела ответа, IP-адрес удалённого узла и заголовки кэширования. Метод запроса и настройки сжатия должны быть одинаковыми; тайм-ауты и ошибки также необходимо сохранять.

Параметры curl time_namelookup, time_connect, time_appconnect и time_starttransfer обычно показывают накопленное время с начала запроса, поэтому их нельзя напрямую складывать как время отдельных этапов. При прямом HTTPS-подключении без перенаправлений разность между соседними временными отметками можно использовать для оценки времени подключения и рукопожатия. Этап до получения первого байта всё ещё включает сетевые задержки и обработку на сервере, поэтому он не равен чистому времени выполнения на серверной стороне.

На втором уровне загрузите страницу целиком в браузере и сохраните водопад запросов. Проверьте, проходят ли через ускорение HTML, основное изображение, скрипты и интерфейсы, а также не загружаются ли сторонние ресурсы по другим маршрутам. Время срабатывания события загрузки страницы можно использовать для дополнительного наблюдения, но оно не заменяет LCP; динамическая страница может продолжать запрашивать важный контент и после срабатывания события загрузки.

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

Ведите отдельную статистику по сочетанию «город + оператор + страница + состояние кэша» и не объединяйте сначала все точки тестирования в одно среднее значение. Процентное улучшение времени рассчитывается по формуле (время в базовом режиме − время после включения ускорения) ÷ время в базовом режиме × 100%; одновременно указывайте разницу в миллисекундах. Отрицательное значение означает замедление. Показатели в рамках одной формулы должны рассчитываться по одной и той же методике, например в обоих случаях сравнивайте P50.

Критерий «заметного улучшения» следует определить до тестирования: сокращение типичного времени в основных регионах, уменьшение задержек медленных запросов и отсутствие ухудшения доли ошибок. Конкретный порог зависит от текущего пользовательского опыта и требований бизнеса; единого процента, подходящего для всех сайтов, не существует. При достаточном размере выборки для оценки стабильности различий можно использовать доверительные интервалы, а не ориентироваться только на самый быстрый результат одного теста.

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

Если показатели улучшаются неравномерно, найдите проблемный участок маршрута

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

В итоговой оценке сохраняйте данные по регионам, состояниям кэша и ошибкам, а затем проверьте работу на небольшой части сайта, наблюдая за реальными пользователями. Изменения количества запросов и заказов можно учитывать при последующем анализе бизнеса, однако на конверсию также влияют источники трафика и содержимое страниц, поэтому нельзя напрямую приписывать изменения конверсии ускорению сети. Расширять внедрение целесообразно только тогда, когда результаты лабораторных тестов подтверждаются данными о реальном доступе на основных рынках.