Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article7 min readViews1

CDN Connected, Yet the Product Card Remains Slow

CDN can accelerate images while barely affecting the wait for the first HTML. We examine how to distinguish edge node operations from the origin server, cache misses from a slow application, and network latency from rendering time.

АльбинаCommunity author★ 141
Comments 0

Fast edge node with blue cables and an overloaded origin server in the background
In this article

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.

Break down the page into individual responses, not a single stopwatch

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.

Request path diagram for a CDN cache hit and for a request to the origin server
On a cache miss, the edge node waits for the origin; on a cache hit, it responds with the stored object.

Cache hit and cache miss lead to different servers

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.

What almost always remains on the origin server

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

  • launches the application and page template;

  • reads product data, prices, and stock from the database or application cache;

  • checks region, authorization, permissions, and price type;

  • queries search, recommendations, and external systems;

  • creates a cart, calculates a discount, and places an order;

  • generates responses that the CDN must not mix between shoppers.

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.

Conduct four comparisons

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

  1. Compare the main HTML with a large image from the same card. A fast image with slow HTML indicates dynamic content or an HTML route, not full-page delivery.

  2. Repeat the request to the same URL and record the cache status. A large difference between a miss and a hit helps evaluate the cost of hitting the origin.

  3. Check both anonymous and authenticated sessions. A personalized version may legally bypass the shared cache, but its load time still needs to be measured.

  4. Compare a request from a region near the origin with one from a remote region. If latency drops only when far away, the CDN is solving the network part; if the time to first byte is long everywhere, look at generation and cache misses.

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.

Conditional comparison of response stages on cache hit and cache miss
Comparison is meaningful for a single resource with a fixed cache state.

Find the boundary between the network and the application

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.

Why HTML does not enter the cache

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:

  • whether the response policy allows shared caching;

  • which cookies, headers, and parameters are included in the key;

  • whether the main resource address remains the same after redirects;

  • whether the cache is cleared after every import or minor change;

  • whether the expiration time elapses before the next user arrives;

  • whether the source returns different variants without proper cache separation.

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.

Separate delivery acceleration from generation acceleration

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.

Verification after changes

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.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.