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 with WebP
Images are usually the heaviest part of a page, and shipping full-size JPEG or PNG files to every visitor wastes bandwidth and slows rendering. cdn.com.tr can transparently convert eligible images to WebP at the edge and serve the lighter version to browsers that advertise support, while browsers that do not get the original untouched. You do not re-export your media library or change your HTML; the optimization happens in the delivery path, and the savings show up directly in page weight and load time.
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 automatic WebP conversion so JPEG and PNG images are re-encoded and served in a lighter format to browsers that accept it, with the original kept as a fallback. This typically cuts image bytes substantially without touching your source files.
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 worldwide.
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 conversion change my original image files?
No. The conversion happens in the delivery path. Your stored originals are untouched; the edge generates and serves a WebP variant to browsers that support it and falls back to the original format for those that do not.
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.