Статические ресурсы сайта — изображения, CSS, JS — можно отдавать не с собственного сервера, а через сеть распределённых серверов CDN, физически ближе к посетителю. Разберём, как подключить CDN к сайту на 1С-Битрикс и на что обратить внимание при настройке.
Что реально ускоряет CDN
CDN снижает задержку загрузки статики за счёт физической близости сервера CDN к посетителю (меньше времени на прохождение сетевого пакета туда и обратно) и снимает часть нагрузки с собственного сервера, освобождая его ресурсы для обработки динамических запросов, требующих реальной работы PHP и базы данных. Для посетителей из отдалённых от сервера регионов эффект особенно заметен — без CDN каждый запрос статики идёт до основного сервера, независимо от того, как далеко физически находится посетитель.
Способ подключения: поддомен для статики
# DNS
static.example.ru CNAME cdn-provider.example.net
Распространённый подход — вынести статические ресурсы на отдельный поддомен, DNS которого указывает на CDN-провайдера, — шаблон сайта при этом генерирует ссылки на изображения, CSS и JS уже с этим поддоменом вместо основного домена, что требует правки путей в шаблоне или настройки на уровне CDN-провайдера, прозрачно проксирующего запросы к оригинальному серверу и кеширующего результат.
Нужна помощь с Битрикс?
Настройка через CDN-провайдера в режиме proxy
Многие современные CDN-сервисы работают в режиме reverse-proxy перед всем сайтом, а не только для отдельного поддомена статики, — весь трафик идёт через CDN, который сам определяет, что кешировать (статика), а что передавать напрямую на сервер без кеширования (динамические страницы, формы). Такой подход не требует изменения путей в шаблоне сайта, но добавляет CDN-провайдера как промежуточный слой для всего трафика, а не только статических ресурсов.
Кеш-заголовки для правильной работы CDN
# nginx конфигурация для статических файлов
location ~* \.(jpg|jpeg|png|css|js)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}
CDN ориентируется на HTTP-заголовки кеширования, отдаваемые
исходным сервером, — без корректного Cache-Control
и Expires CDN может кешировать статику на неоптимальный
срок или, наоборот, слишком часто перезапрашивать файл с исходного
сервера, теряя часть выигрыша от использования CDN вовсе.
Инвалидация кеша CDN при обновлении статики
Замена файла с тем же именем на сервере (например, обновлённая версия CSS с тем же путём) не гарантированно мгновенно отразится на CDN — большинство сервисов требуют явного запроса на очистку (purge) конкретного пути в кеше CDN, либо используют версионирование имени файла (добавление хеша содержимого в имя), чтобы изменённый файл автоматически получал новый уникальный путь, не требующий ручной инвалидации кеша вовсе.
HTTPS и сертификат для поддомена CDN
Если статика вынесена на отдельный поддомен, для него отдельно требуется корректный SSL-сертификат — либо от самого CDN-провайдера (большинство современных сервисов предоставляют это автоматически), либо собственный, если провайдер этого не делает. Смешанный контент, разобранный отдельно, возникает и в этом сценарии, если статика на CDN отдаётся по HTTP при HTTPS-версии основного сайта.
Влияние на SEO
Изображения, отдаваемые с отдельного поддомена CDN, технически
доступны поисковым системам так же, как с основного домена, —
но стоит убедиться, что файл robots.txt и настройки
индексации не блокируют случайно поддомен CDN от индексации
поисковыми роботами, если важна индексация изображений
в картиночном поиске.
Частые ошибки
- Заголовки кеширования не настроены на исходном сервере. CDN не может эффективно кешировать статику без корректных Cache-Control заголовков.
- Обновление файла не вызывает инвалидацию кеша CDN. Посетители продолжают получать устаревшую версию файла до истечения срока кеша.
- Смешанный контент на поддомене CDN без HTTPS. Та же проблема, что и с основным доменом, но применительно к вынесенной статике.
Итог
Подключение CDN к сайту на 1С-Битрикс — либо через выделенный поддомен для статики с изменением путей в шаблоне, либо через reverse-proxy режим CDN-провайдера перед всем сайтом. Эффективность CDN напрямую зависит от корректных заголовков кеширования на исходном сервере и продуманной стратегии инвалидации при обновлении файлов — версионирование имени файла через хеш содержимого решает проблему инвалидации надёжнее, чем расчёт на ручную очистку кеша CDN при каждом изменении.
