Каталог запчастей открывается медленно у дилеров в другом регионе. Фотографии и инструкции каждый раз скачиваются с центральной площадки, хотя они одинаковы для всех. Рядом работает личный кабинет: там уже свои цены, договоры и история обращений. Поставить CDN перед всем сайтом технически несложно. Считать все эти ответы одинаково пригодными для общего кэша — гораздо более опасное решение.
Начинать стоит с разделения содержимого. Публичная фотография хорошо подходит для многократной выдачи из близкой к пользователю копии. Персональное предложение требует проверки доступа и понимания, кому предназначен ответ. Ускорение не должно незаметно менять эти правила.
Что CDN действительно приближает
CDN — сеть узлов, через которые доставляют содержимое. Если нужная копия уже есть в подходящем узле и её разрешено использовать, запросу не приходится каждый раз доходить до исходного сервера, origin. Это сокращает часть сетевого пути и снимает повторную работу с центральной площадки.
Если копии нет или она требует обновления, обращение к origin всё равно понадобится. CDN также может улучшать соединения и доставку некэшируемых ответов, но не устраняет время расчёта внутри приложения. Если дилер ждёт сложный подбор оборудования, а не загрузку фотографий, причина задержки может остаться прежней.
Edge computing добавляет возможность выполнять некоторую логику на распределённых узлах: выбирать маршрут, преобразовывать изображение, проверять допустимость запроса. Это другая задача, хотя её часто продают вместе с CDN. Поддерживаемые операции, доступ к данным и ограничения надо проверять для конкретной услуги.
Одинаковый адрес не всегда означает одинаковый ответ
Цена по одному адресу может зависеть от языка, валюты, организации или авторизованного пользователя. Ключ кэша определяет, какие запросы считаются эквивалентными. Если значимое различие не учтено, одному дилеру можно выдать ответ другого. Если включить в ключ всё подряд, копии перестанут переиспользоваться, и ожидаемая разгрузка исчезнет.
Поэтому перечень параметров ключа — часть проектирования ответа. Для публичной инструкции, изображения и персональной цены правила будут разными. Возможности включения параметров, заголовков и других признаков описаны, например, в документации Cloudflare по ключам кэша.
Разделение ключей не заменяет авторизацию. Даже правильно отделённую копию закрытого файла нельзя выдавать человеку без необходимых прав. Нужна проверка доступа на обслуживающем пути, а прямой доступ к origin не должен позволять обойти обязательные ограничения.
Три похожих слова в настройках означают разное
В HTTP директива private запрещает общему кэшу хранить ответ, но не обязательно запрещает личный кэш браузера. no-cache допускает хранение, однако требует проверки у источника перед повторным использованием. no-store запрещает хранение соответствующего ответа. Значения определены в RFC 9111; названия легко понять неверно, если смотреть только на переключатели панели.
Провайдерские правила могут переопределять обычное поведение, поэтому нужно проверять фактические ответы, а не только намерение приложения. Особенно полезен тест двух разных дилеров: войти каждым, запросить один адрес и убедиться, что персональные данные не пересекаются. Затем повторить без входа и после выхода.
Ни одна директива сама по себе не является полной защитой информации. Правила доступа, передача по защищённому соединению и обращение с уже скачанным документом остаются отдельными вопросами. Отозванное разрешение нельзя свести к обещанию «мы почистим кэш».
Как обновлять каталог, не выдавая смесь версий
Для неизменяемых файлов удобно включать версию содержимого в имя. Новая фотография или файл интерфейса получают новый адрес, а страница начинает ссылаться на него. Старую версию не нужно немедленно удалять: открытая ранее страница может ещё обращаться к ней.
У документа с постоянным адресом другой жизненный цикл. Надо определить срок свежести, проверку обновлений и принудительное удаление копий, если ждать нельзя. При этом очистка CDN не очищает автоматически браузер пользователя или корпоративный прокси. Разницу между инвалидированием и версионированием файлов объясняет документация CloudFront.
Проверяйте и ошибочные ответы. Если файл временно отсутствовал и этот ответ сохранился по правилам CDN, последующая загрузка на origin не обязательно сразу исправит результат для клиента. Для содержимого и ошибок могут потребоваться разные сроки и процедуры обновления.
После очистки кэша нагрузка возвращается в центр
Популярный каталог может почти не обращаться к origin в обычном режиме. После широкого удаления копий или выпуска новых адресов множество запросов снова пойдёт за исходными файлами. Центральная площадка должна пережить этот режим, а не только спокойную выдачу из прогретого кэша.
Процент попаданий в кэш недостаточен для оценки. Тысячи маленьких значков и один тяжёлый файл влияют на ресурсы по-разному. Полезно смотреть на объём данных, запросы к origin, ошибки и задержку реальных пользователей. Региональные результаты тоже важны: средний показатель может скрывать группу, у которой почти ничего не ускорилось.
При недоступности источника иногда допустима выдача устаревшей публичной инструкции. Для отозванного документа или подтверждения доступности оборудования такое поведение может быть неприемлемым. Разрешение на старые данные должно соответствовать сценарию, а не общей настройке «повысить доступность».
Не переносите вычисление отдельно от его данных без причины
Если edge-функция на каждом шаге обращается к той же далёкой базе, близость самой функции не гарантирует быстрого результата. Появляются ещё один участок исполнения, его разрешения, журналы и правила выпуска. При копировании данных на узлы нужно уже решать их актуальность и согласованность.
Для каталога разумно начать с повторяемых публичных файлов и измерить результат на обычной загрузке, обновлении и промахе кэша. Стоимость включает доставку, обращения к origin, преобразования и сопровождение правил. Перенос персональной логики стоит обсуждать отдельно, когда видно, какую конкретную задержку он убирает и как сохраняет проверку прав.