CDN подключён, а карточка товара всё ещё медленная

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

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

Карточка товара состоит из основного HTML, стилей, сценариев, шрифтов, изображений и фоновых запросов. Один домен в адресной строке не означает один маршрут. Изображение может прийти из кеша CDN, HTML — с исходного сервера через CDN, а наличие в магазине — из отдельного API.

Показатель TTFB описывает время до первого байта конкретного ответа. В него попадают перенаправления перед запросом, установка соединения, путь по сети и ожидание обработки на сервере. Он не показывает, когда пользователь увидит главное изображение или сможет нажать кнопку покупки.

Поэтому фраза «страница отвечает за три секунды» слишком неопределённа. Уточните: какой URL, какой тип ресурса, новый или повторный запрос, кеш-попадание или промах, анонимный или авторизованный пользователь.

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

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

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

Даже при успешной раздаче статики источник продолжает участвовать в динамической работе магазина:

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

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

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

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

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

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

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

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

Проверьте последовательно:

Увеличение срока хранения полезно только после ответа на эти вопросы. Длинный срок не исправляет неверный ключ и повышает риск показывать устаревшую цену или остаток.

Если кеш-попадание быстрое, а промах медленный, работают в двух направлениях. Сначала уменьшают стоимость генерации на источнике: проверяют запросы базы, компоненты, внешний API и очистку прикладного кеша. Затем расширяют долю безопасных попаданий: стабилизируют адреса, ключ и срок хранения для действительно общих объектов.

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

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

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

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

CDN не заменяет оптимизацию приложения, но и медленная динамика не делает CDN бесполезным. Точный вывод появляется после разделения маршрутов: что отдал пограничный узел, что пришлось получить с источника и где пользователь действительно ждал. Тогда действие следует из причины — менять правила кеша, ускорять генерацию или разбирать браузер, а не увеличивать всё сразу.

After connecting the CDN, photos begin loading from the nearest node, yet the product card still displays an empty skeleton for several seconds. The provider's dashboard shows distributed traffic, a working cache, and seemingly no errors. This tempts one to declare the CDN useless or, conversely, to search for the problem solely in the browser.

Both conclusions can be hasty. The CDN accelerates only the part of the response it actually receives and can serve from the edge node. Dynamic HTML, personalized prices, the shopping cart, warehouse stock levels, and database queries often continue to wait for the origin server. First, you must determine which resource is slow and whether it was cached in that specific request.

A product card consists of main HTML, styles, scripts, fonts, images, and background requests. One domain in the address bar does not mean one route. An image may arrive from the CDN cache, HTML from the origin server via the CDN, and stock availability from a separate API.

The TTFB metric describes the time to the first byte of a specific response. It includes redirects before the request, connection establishment, network path, and waiting for server processing. It does not show when the user will see the main image or be able to click the buy button.

Therefore, the phrase "the page responds in three seconds" is too vague. Specify: which URL, which resource type, a new or repeat request, a cache hit or miss, and whether the user is anonymous or authenticated.

On a cache hit, the edge node serves the stored object without contacting the origin server or with minimal freshness validation—the exact behavior depends on the rules. On a miss, the CDN requests the resource from the origin, waits for the response to be generated, passes it to the user, and, if allowed, stores it for future requests.

If the first request is slow but the repeat request is noticeably faster, this does not prove the site is working correctly. You may have compared a miss with a hit. Such a difference is normal for a popular image; for HTML, you need to understand why the cache misses and whether caching this response is safe at all.

There is a nuance: a header or a panel labeled "HIT" confirms that caching works only for a specific object and a specific request. It says nothing about the neighboring API, the main HTML, or the next region. Diagnostic header names vary by provider, so their meaning must be verified against the documentation for the chosen CDN.

Even when static content is served successfully, the origin continues to participate in the store's dynamic operations:

If a slow database query takes two seconds, a nearby edge node cannot reduce those two seconds. It may shorten the network path after the response is generated, but the cause remains on the origin.

It is dangerous to "treat" this with a general public cache for authenticated pages. A response dependent on a session, contract, city, or cart contents requires a separate cache key or a prohibition on general caching. An error here is worse than a slow page: one visitor might see another visitor's data.

For diagnostics, a small matrix is sufficient if you change one condition at a time.

Keep the address, parameters, cache state, and time of the check identical. Do not compare the homepage in the morning with a product page in the evening and attribute the difference to the CDN.

In browser tools, start with the request waterfall. A long wait for the first byte of HTML with short static asset loading narrows the search area. If HTML arrives quickly but the main content appears late, check blocking scripts, styles, images, and the browser's main thread performance.

On the CDN side, you need the cache status, object age, the selected edge node, and the reason for cache bypass if the provider shows it. On the origin server, you need application time, database queries, external calls, and response generation time. It is useful to pass separate server durations in a diagnostic header, but only for safe aggregated stages without internal secrets.

Measurements should be matched by request ID and time. Otherwise, it is easy to mistake a slow background import for a CDN issue or miss that cache misses coincide with a mass cache clear after a catalog exchange.

The cause is not always an error. A personalized or authorized response may have a valid prohibition on general storage. The request method, cookie, authorization header, error response, or CDN configuration can also prevent caching. Sometimes the object is saved, but the cache key includes too many parameters, making almost every request appear new.

Check sequentially:

Increasing the cache duration is useful only after answering these questions. A long duration does not fix an incorrect key and increases the risk of displaying outdated prices or stock levels.

If a cache hit is fast but a miss is slow, work in both directions. First, reduce the generation cost at the source: check database queries, components, external APIs, and application cache invalidation. Then, expand the share of safe hits: stabilize addresses, keys, and durations for truly shared objects.

If both hits and misses are slow, check the route to the edge node, response size, compression, connection protocol, and client overload. If both responses are fast but the page feels slow, move to rendering and interactivity metrics—the server is no longer the primary suspect.

It is useful for a store to maintain separate metrics for at least three classes: generic HTML of an anonymous product card, personalized HTML or API responses, and static resources. A single average figure conflates fundamentally different modes.

After configuration, repeat the original matrix rather than a single successful request. Record the cache hit rate by resource class, TTFB on hits and misses, application time on the source, and the moment the main content appears in the browser. Compare identical periods and separately note catalog imports, cache clears, and advertising spikes.

Verify correctness: price, city, stock, authorization, and the shopping cart must not carry over between sessions. Then trigger a controlled product change and confirm that the main page updates within the agreed timeframe. A fast but stale response does not count as an improvement.

A CDN does not replace application optimization, nor does slow dynamics render a CDN useless. Precise output emerges after separating routes: what the edge node served, what had to be fetched from the source, and where the user actually waited. Only then does action follow cause—adjust cache rules, speed up generation, or inspect the browser, rather than scaling everything at once.