Может ли глобальная CDN повысить скорость доступа к независимому сайту из разных регионов?

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

Наличие узлов не означает, что сетевой маршрут стал короче

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

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

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

Политика кеширования определяет, сколько контента можно ускорить

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

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

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

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

При измерении скорости отделяйте ожидание сети от отрисовки страницы

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

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

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

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

Проверка после запуска и откат изменений

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

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