As a best practice to improve performance, after the integration of the Universal CDN, you can allow the CDN network to automatically cache static content for a long period of time.
To manage Cache expiration settings for a CDN zone, follow the steps outlined below:
1. Log in to the Universal CDN Control panel at my.ucdn.com.
2. Navigate to the My Zones tab located in the top left corner.
3. Click on the cogwheel icon 
next to your CDN zone.
4. Click on the Cache tab.
5. Check the box next to “Cache my files in CDN network for a limited time only”.
6. Specify the desired time for caching in the “Cache expire time” field.
7. You can reuse the cache from a different CDN zone that has the same files (optional).
8. To enable reusing cache, check the box next to “Reuse cache from one of my other zones“.
9. Click on the Save Changes button.
Universal CDN respects Cache-Control and Expires headers set up for your resources if you do not override them by limiting the Cache expire time for a specific CDN zone by enabling the “Cache expire time” feature from the Universal CDN Control Panel.
General Information About the Cache-Control Header
Cache-Control is an HTTP header that determines the browser’s caching behavior. In summary, when a visitor accesses your website, their browser will save certain assets, such as images, videos, website data, etc., in a temporary storage area (local cache).
Next time, when that visitor revisits your website, the Cache-Control HTTP header places the rules which define whether that visitor will have those assets loaded from their local cache, or whether the browser will have to send another request to the server for fresh ones.
Browser caching
As stated above, browser caching is when a web browser saves website resources as a result it does not have to fetch them again from the server.
The assets will be stored from the browsers only for a specified period of time, referred to as Time To Live (TTL, the expiry time of cached data).
Any requests to a cached asset after the expiration of the TTL will instruct the browser to reach the server again and download a fresh copy of the asset.
How do a browser and server know the TTL for each resource? This is where HTTP headers are involved.
HTTP headers
HTTP headers allow the client and the server to pass additional information with an HTTP request/response. They contain a lot of important information about client-server communication.
In general, the request headers contain:
- Information on what asset is being requested
- Information on what is the client’s browser
- Information on what are the data formats that will be accepted by the client
In general, the response headers include information on:
- Whether or not the request is being successfully fulfilled
- The language and the format of the resources in the body of the response
The Cache-Control header can appear on both sides – HTTP requests and responses.
The HTTP header consists of two things:
- the case-insensitive name followed by a colon ( : )
- value – if there is whitespace before the value it will be ignored
Example:
Cache-Control: max-age=31536000
The example means that the returned resource will be valid for 31536000 seconds (one year), after that (after the specified time) the server has to request a newer version.
These headers contain a lot of important information about each communication.
Cache-Control header
The Cache-Control HTTP header contains instructions (directives) for caching in both requests and responses. Let’s go through some of the common Cache-Control directives:
Cache-Control: private
The response may be stored only by a browser’s cache, and never by an intermediary agent, such as a Content Delivery Network.
Cache-Control: public
Oppositely, with the Cache-Control: public the response may be stored by any cache.
Cache-Control: no-store
The response may not be stored in any cache, meaning that every time a user requests a resource, the request must be sent to the origin server for a new copy.
Cache-Control: no-cache
The response may be stored in any cache, even if the response is normally non-cacheable. The stored response must always go through validation with the origin server. This is usually done using an ETag. The ETag HTTP response header identifies the specific version of a resource – it is changed on the origin server every time when the resource is updated.
Cache-Control: max-age=<seconds>
The maximum amount of time for which the resource is considered fresh. This directive is relative to the time of the request.
Why is Cache-Control so important?
Browser caching is an effective way to save resources and improve users’ experience on the Internet but without using Cache-Control headers, it would be not reasonable.
Cache-Control adds the versatility that makes browser’s caching really useful, letting you to dictate how each resource will be cached, and also to set special rules for intermediaries such as Universal CDN.
You can find more detailed information for Cache-Control headers at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
Limit Access Using a Secret Key