CDN

Caching allows saving pages rendered on the server for later use to avoid computationally expensive rendering from scratch when possible. This is especially useful when the application has pages that require a lot of computation, make many API calls, or change infrequently. It not only reduces the load on the server but also significantly improves performance.

When a request from the end user using a web browser is being sent to the origin server (hosting the website) the page needs to be built on the server and sent back to the user. This process takes more time to render the content which is not an advantage when end user visits the website for the first time.

When a CDN feature is implemented, and the first visitor enters the website, the flow looks like follows:

• CDN verifies whether the content is cached; if not, the CDN reaches the origin server,
• The end user needs to wait for the website to be built on the origin server,
• When the website is built, the origin server sends a page to the CDN endpoint,
• CDN conducts the process to cache the page,
• Finally, CDN sends the content to the site's visitor
• Of course, this flow also takes a bit longer, but only for the first time. When the second, and further visitors enter the website for the same content, CDN replies immediately because the content is already cached. This is the biggest advantage of using SSR and CDN combined.

Using a CDN offers a few significant benefits:

• Load times performance improvements,
• Protections against common cyber-attacks, for instance DDoS,
• Reliability is increased.

Enable CDN

CDN is responsible for caching Storefront Application Responses. It is available only in instances that don't use Basic Auth. To enable CDN for your instance, click the toggle button on the right side of the CDN card so that it changes the state to enabled.

If you would like to learn more about CDN and SSR Cache, visit Alokai Cloud documentation here.

Query parameters

You can control how query parameters affect CDN caching by configuring allow lists or deny lists. Query parameters are used to build the cache key at the CDN level, which determines whether a request results in a cache hit or miss.

• Allow list: Only the specified query parameters are considered when generating the cache key. All other parameters are ignored, so requests differing only by ignored parameters will share the same cached response.
• Deny list: The specified query parameters are excluded from the cache key. All other parameters are included, so requests differing by denied parameters will still result in a cache hit.

This configuration helps you fine-tune caching behavior, ensuring that only relevant query parameters affect cache variation and improving cache efficiency.

Examples

Allow list example

Suppose your application uses the lang query parameter to determine the language of the page, but other parameters like utm_source are used only for analytics. You can set an allow list to cache separate versions only for different languages:

Allow list: lang

• Requests to /page?lang=en&utm_source=google and /page?lang=en&utm_source=facebook will share the same cached response.
• Requests to /page?lang=fr will have a separate cached response.

Deny list example

If you want to ignore certain tracking parameters (e.g., utm_source, utm_campaign) so they do not affect the cache, you can use a deny list:

Deny list: utm_source, utm_campaign

• Requests to /page?utm_source=google and /page?utm_source=facebook will share the same cached response.
• Requests to /page?ref=partner will have a separate cached response, since ref is not in the deny list.

These examples help ensure that only meaningful query parameters affect cache variation, improving cache efficiency and accuracy.

Named cookies

You can control how specific cookies affect CDN caching by providing a list of cookie names. Only the cookies specified in this list are considered when generating the cache key. All other cookies are ignored, so requests that differ only by ignored cookies will share the same cached response.

This configuration allows you to fine-tune caching behavior, ensuring that only relevant cookies affect cache variation and improving cache efficiency.

Example

Suppose your application uses a locale cookie to determine the language of the page, but other cookies are used for analytics or tracking. You can specify the locale cookie name so that cache variation only occurs for different locales:

Cookie names: locale

• Requests with locale=en and different tracking cookies will share the same cached response.
• Requests with locale=fr will have a separate cached response.

This approach ensures that only meaningful cookies affect cache variation, improving cache efficiency and accuracy.