Почему сайт загружается медленно, даже если у CDN есть узлы в Южной Америке?

CDN развернут в Южной Америке, но сайт по-прежнему работает медленно. Обычно следует проверить три момента: подключаются ли посетители к подходящему узлу, попадают ли запросы в кэш и насколько эффективно работает обращение к источнику при отсутствии попадания в кэш. Наличие южноамериканских узлов на карте размещения означает лишь, что сервис может обслуживать этот регион, но не доказывает, что конкретный запрос действительно был ускорен.

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

Сначала определите, что именно работает медленно: соединение, получение первого байта или отображение страницы

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

• Заметные задержки на этапах DNS, подключения или TLS: сначала проверьте разрешение доменного имени, распределение запросов по узлам и маршрут доступа.
• Долгое ожидание первого байта: причиной могут быть обработка на граничном узле, отсутствие попадания в кэш, сеть между CDN и источником либо вычисления на исходном сервере. Не следует сразу списывать проблему на производительность сервера.
• Документ загружается быстро, но содержимое долго не отображается: проверьте крупные изображения, блокирующие отображение скрипты, шрифты и сторонние компоненты.

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

Наличие узлов в Южной Америке не гарантирует, что запрос будет направлен в подходящую точку

Взаимодействие сетей в разных странах, городах и у разных операторов Южной Америки отличается. Узел, расположенный географически ближе, не обязательно обеспечивает более быстрый маршрут доступа; в некоторых сетях трафик может проходить через другие регионы. На распределение запросов также могут влиять рекурсивный DNS, взаимодействие сетей операторов и нагрузка на узлы.

Сначала проверьте в панели управления CDN, включён ли целевой регион для домена. Затем проверьте настройки авторитетного DNS-сервера и убедитесь, что фактический результат разрешения доменного имени в регионе соответствует требованиям поставщика услуг. При подключении через CNAME проверьте, не указывает ли запись на старую платформу или исходный сервер.

Затем сопоставьте идентификатор узла в заголовках ответа, журналы CDN и результаты локальных тестов, чтобы выяснить, где именно обрабатывается запрос. Значение идентификаторов узлов зависит от платформы: нельзя полагаться только на геолокационную базу IP-адресов или считать один тест ping полной оценкой работы страницы.

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

Высокий общий процент попаданий в кэш не означает, что конкретная страница обслуживается из кэша

Общий процент попаданий в кэш в панели управления может быть высоким из-за большого числа небольших изображений, тогда как рекламные посадочные страницы и страницы с описаниями товаров всё ещё часто обращаются к исходному серверу. Проверяйте состояние кэша именно у медленного запроса. В качестве подсказок используйте Cache-Control, Age и предоставляемые платформой заголовки попадания в кэш; интерпретировать их нужно с учётом правил конкретной платформы.

К повторным обращениям к источнику могут приводить, например, следующие ситуации: исходный сервер возвращает private или no-store; наличие Cookie в запросе активирует правило обхода кэша; параметры URL включены в ключ кэширования; для разных языков и мобильной версии создаётся слишком много отдельных копий кэша. Страницы с низкой частотой посещения также могут повторно обращаться к источнику после истечения срока действия или вытеснения из кэша.

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

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

Если при попадании в кэш всё работает быстро, а без него медленно, продолжайте проверку по цепочке обращения к источнику

Повторите запрос одного и того же ресурса в одном регионе и примерно в одно время, а затем сравните длительность с учётом статуса кэширования. Если без попадания в кэш запрос заметно медленнее, а при попадании скорость возвращается к норме, сосредоточьтесь на обращении к источнику. Однако при первом посещении на результат могут влиять DNS и установление соединения, поэтому не делайте выводы только по субъективному сравнению двух загрузок.

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

Если исходный сервер расположен в Азии, а основные клиенты находятся в Южной Америке, динамические запросы всё равно могут требовать длительного межрегионального обмена данными. Дополнительное кэширование статических ресурсов не устранит это ожидание. В зависимости от задач бизнеса можно рассмотреть региональные исходные серверы, многоуровневое кэширование или оптимизацию динамического маршрута. При переносе сервера необходимо также учитывать другие рынки, синхронизацию данных и затраты на обслуживание.

Страница может открываться, но маркетинговые компоненты всё равно способны замедлять работу

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

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

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

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