Tuning Gcore CDN rules for dynamic application data caching
Caching services like content delivery networks (CDNs) can be a solid addition to your web stack. They lower response latency and improve user experience while also helping protect your origin servers through security features like access control lists (ACLs) and traffic filtering. However, if you’re running a highly dynamic web service, a misconfigured CDN might lead to the delivery of stale or, in the worst case, wrong data.
If you’re hosting a dynamic web service and want to speed it up, this guide is for you. It explains the common issues dynamic services have with CDNs and how to solve them with Gcore CDN.
How does dynamic data differ from static data?
There are two main differences between static and dynamic data:
- Change frequency: Dynamic data changes more often than static data. Some websites stay the same for weeks or months; others change multiple times daily.
- Personalized responses: Static systems deliver the same response for a given URL path. Dynamic systems, by contrast, can generate different responses for each user, based on parameters like authentication, location, session data, or user preferences.
Now, you might ask: Aren’t static websites simply HTML pages while dynamic ones are generated on-the-fly by application servers?
It depends.
A website consisting only of HTML pages might still be dynamic if the pages are changed frequently, and an application server that generates HTML responses can serve the same HTML forever and always provide everyone with the same content for a URL. The CDN network doesn’t know how you create the HTML. It only sees the finished product and decides how long it should cache it. You need to decide on a case-by-case basis.
How do cache rules affect dynamic data?
When using a CDN, you have to define rules that govern the caching of your data. If you consider this data dynamic, either because it changes frequently or because you deliver user-specific responses, those rules can drastically impact the user experience, ranging from the delivery of stale data to completely wrong data.
Cache expiration
First, consider cache expiration time. With Gcore CDN, you have two options:
- Let your origin server control it. This is ideal for dynamic systems using application servers because it gives you precise control without needing to adjust Gcore settings.
- Let Gcore CDN control it. This works well for static HTTP servers delivering HTML pages that change often. If you can’t modify the server’s cache configuration, using Gcore’s settings is easier.
No matter which method you choose, understand what your users consider “stale” and set the expiration time accordingly.
Query string handling
Next, decide how Gcore CDN should handle URL query parameters. Ignoring them can improve performance—but for dynamic systems that use query strings for server-side sorting, filtering, or pagination, this can break functionality.
For example, a headless CMS might use:https://example.com/api/posts?sort=asc&start=99
If the CDN ignores the query string, it will always deliver the cached response, even if new parameters are requested. So, make sure to disable the Ignore query string parameters setting when necessary.
Cookie bypassing
Cookies are often used for session handling. While ignoring cookies can boost performance, doing so risks breaking applications that rely on them.
For example:https://example.com/api/users/profile
If this endpoint relies on a session cookie, caching without considering the cookie will serve the same user profile to everyone. Be sure to disable “Ignore cookies” if your server uses them for authentication or personalization.
Cache key customization
If you need more detailed control over the caching, you can modify the cache key generation. This key defines the mapping of a request to a cache entry and allows you to manage the granularity of your caching.
The Gcore Customer Portal offers basic customization functionality, and the support team can help with advanced rules. For example, adding the request method (e.g., GET, HEAD, POST, etc.) to your cache key ensures a single URL has a dedicated cache entry for each method instead of using one for all.
GraphQL considerations
Most GraphQL implementations only use POST requests and include the GraphQL query in the request body. This means every GraphQL request will use the same URL and the same method, regardless of the query. Gcore CDN doesn’t check the request body when caching, so every query will result in the same cache key and override each other.
To make sure the CDN doesn’t break your API, turn off caching for all your GraphQL endpoints.
Path-based CDN rules for hybrid content
If your application serves both static and dynamic content across different paths, Gcore CDN rules offer a powerful way to manage caching more granularly.
Using the CDN rules engine, you can create specific rules for individual file paths or extensions. This allows you to apply dynamic-appropriate settings—like disabling caching or respecting cookies—only to dynamic endpoints (e.g., /api/**
), while using more aggressive caching for static assets (e.g., /assets/**
, /images/**
, or /js/**
).
This path-level control delivers performance gains from CDN caching without compromising the correctness of dynamic content delivery.
Summary
Using a CDN is an easy way to improve your site's performance, and even dynamic applications can benefit from CDN caching when configured correctly. Check that:
- Expiration times reflect real-world freshness needs
- Query strings and cookies aren’t ignored if they affect the response
- Cache keys are customized where needed
- GraphQL endpoints are excluded from caching
- CDN rules are used to apply different settings for dynamic and static paths
With the right setup, you can safely speed up even the most complex applications.
Explore our step-by-step guide to setting rules for particular files in Gcore CDN.
Related articles
Subscribe to our newsletter
Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.