Pull and Push: two ways to feed the edge
With the Pull model, cdn.com.tr fetches each object from your existing origin the first time it is requested, then caches it at the edge for the TTL you set; you change nothing on the origin except DNS. With the Push model you upload assets into cdn.com.tr storage and the edge serves directly from there, which is ideal when you do not want to keep an origin server online at all. Most customers start with Pull because it requires zero migration, and later move heavy media to Push or Object Storage. Both models share the same cache rules, purge tools, and reporting.
Cache rules, TTL, and cache keys you control
The real work of a CDN is deciding what is safe to cache and for how long, and that is exactly what the panel exposes. You set TTLs by path or file extension, choose whether to respect or override the origin Cache-Control header, and control which query strings and cookies are part of the cache key so that /list?page=2 and /list?page=3 are cached separately while tracking parameters do not fragment the cache. Getting the cache key right is what turns a low hit ratio into a high one, and the reports make it visible so you can tune it instead of guessing.
Origin offload and shielding
Every request answered from the edge is a request your origin never sees, so a busy content page that used to hammer your server with hundreds of image and asset hits collapses to a handful of origin fetches per TTL window. Because visitors resolve to the edge rather than your origin IP, the origin also stops receiving direct traffic, which reduces both bandwidth cost and exposure. This offload is what keeps a site standing when a campaign, a news spike, or a social share sends a sudden flood of visitors at once.
Automatic image optimization: AVIF and WebP
Image optimization is a switch for your whole account or a single delivery rule. The edge converts JPEG and PNG images to WebP, or to AVIF and WebP if you choose WebP + AVIF for the account, and each browser gets a format it accepts; browsers that accept neither get the image in its original format. With WebP + AVIF the answer comes from the same URL, with Vary: Accept; with WebP alone, browsers that accept WebP are redirected to a .webp copy. Either way your HTML keeps the same image URLs. At full size, a newly converted image goes out only when it is smaller than the original. If a conversion fails, the edge serves the original image instead. Processing counts toward your monthly quota.
You choose the format once for the account: WebP, or WebP + AVIF. Measured on 5 October 2026 with the image optimizer behind CDN.com.tr, a 262,025-byte JPEG news photo goes out as 86,936 bytes of AVIF, and a 105,078-byte PNG screenshot as 27,942. Your media library stays as it is. Our AVIF vs WebP guide has the full measurements, and the image format checker shows what your own pages send today. For how format negotiation, resizing and caching work in general, see the image CDN guide.
Caching dynamic content safely
Caching is not only for static files. Many pages that feel dynamic, such as category listings, product pages, or article bodies, change only every few minutes and can be micro-cached with a short TTL to absorb traffic while staying fresh. cdn.com.tr lets you cache these responses with rules that exclude logged-in sessions and personalized paths, so anonymous visitors are served from the edge while a user's own cart or account page always goes to origin. The result is CDN-level speed on pages most platforms leave uncached.
Measuring the win: hit ratio and load time
You cannot improve what you cannot see, so the panel reports the cache hit ratio, bytes served from edge versus origin, and per-response cache status. A healthy static-heavy site should reach a high hit ratio once the cache warms; a low ratio usually points to a cache key including a volatile cookie or query string, which you can then fix in the rules. Watching these numbers after each change closes the loop between configuration and the actual speed your visitors feel.
How to set it up, step by step
Add your domain to the CDN account
In the panel open the domain area, add your hostname (for example www.example.com), and choose whether cdn.com.tr acts as a Pull origin against your existing server or a Push target you upload files to. For most sites Pull is the fastest start: no file migration is needed.
Point DNS to the edge
Update the CNAME (or the apex record if you host DNS with us) so traffic resolves to the cdn.com.tr edge instead of your origin IP. Once resolution propagates, every request enters an edge node first and is answered from cache when possible.
Set your cache rules
Define TTLs per path or extension: long TTLs (days) for versioned assets like /assets/*.css, /*.js, images and fonts; short or bypass rules for /cart, /checkout, or anything with a session cookie. You can honor the origin Cache-Control header or override it from the panel.
Enable image optimization
Turn on image optimization for the whole account or for a single delivery rule, and choose the account's image format: WebP, or WebP + AVIF. JPEG and PNG images are converted at the edge; your source files stay untouched.
Verify cache is working
Load a page and inspect the response headers for the cache status (HIT/MISS) and age. A second request to the same URL should return a HIT served from the edge. Use the panel reports to watch the cache hit ratio climb as the edge warms up.
Purge when content changes
After a deploy or content edit, purge the affected URLs (or everything) from the panel or the purge API so visitors immediately get the new version instead of waiting for the TTL to expire.
Example scenarios
A news or blog site serves its images, CSS, and JavaScript from the edge with long TTLs, dropping origin traffic sharply and cutting page load time for readers far from the origin.
During a flash sale, product listing pages are micro-cached and static assets are fully cached, so a sudden traffic spike is absorbed at the edge instead of overwhelming the store's origin.
A vendor distributes installers and update packages via Push storage at the edge, delivering large files quickly to users while shielding the origin from bandwidth spikes.
Frequently asked questions
How do I know whether a request was served from cache?
Each response carries a cache status header showing HIT (served from the edge) or MISS (fetched from origin), plus an age value. Load a URL twice: the second request to a cacheable resource should return a HIT. The panel reports also aggregate this into an overall cache hit ratio.
Will caching serve stale content after I update my site?
Cached objects live only until their TTL expires, but you do not have to wait. Purge the changed URLs or the whole zone from the panel or the purge API right after a deploy, and the edge fetches fresh copies on the next request while continuing to serve everything else from cache.
Can I cache pages that use cookies or query strings?
Yes, with control. You decide which cookies and query parameters are part of the cache key, so essential ones create separate cached variants while tracking parameters are ignored. Session or logged-in requests can be set to bypass cache entirely so personalized content always reaches the origin.
Does WebP or AVIF conversion change my original image files?
No. Conversion happens in the delivery path and your stored originals stay untouched. Browsers that accept AVIF or WebP get a converted copy, the others get the image in its original format, and if a conversion fails the edge serves the original. Your HTML keeps the same image URLs.
What happens if my origin server goes down?
Anything already cached at the edge keeps being served to visitors during the TTL window, so a brief origin outage does not necessarily take your static content offline. Requests for uncached or expired objects will still need the origin, which is another reason to keep TTLs generous on stable assets.
Do I have to move my files to use the CDN?
Not with the Pull model. You keep your existing origin server and only change DNS so the edge sits in front of it, pulling and caching content on demand. Push storage is optional and useful when you want the edge to serve media without any origin at all.