> ## Documentation Index
> Fetch the complete documentation index at: https://gcore.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Improve video delivery speed for low-traffic accounts
If your video buffers like this, the most likely cause is that the CDN is not serving content from cache — every segment is being fetched from your origin server on demand. This guide explains why that happens and how to fix it.
## Why CDN performance depends on traffic volume
Gcore CDN delivers content by caching files at edge servers close to your viewers. The first time a viewer requests a video segment, the CDN edge server does not have it in cache yet — it must pull the file from your origin server and cache it locally. This first request is called a **cache miss**.
Every subsequent request for the same file from the same edge location is served directly from the edge cache (**cache hit**) — much faster, because it never touches the origin.
```
Cache MISS: Viewer → CDN Edge → Origin
Cache HIT : Viewer → CDN Edge (cache)
```
### Example: how the cache changes over time
To see how this works in practice, imagine three viewers watching the same video at different times:
* **Viewer 1 — the first request.** No edge server has the video yet, so the CDN fetches it from your origin and stores a copy at the edge. This first view is a little slower while the copy is being retrieved.
* **Viewer 2 — a few minutes later.** The video is still warm in the edge cache, so it's delivered straight from the CDN — fast, with no trip back to your origin.
* **Viewer 3 — several days later.** If no one watched the video in the meantime, the edge may have already removed it to make room for more frequently requested content. The CDN then fetches it from your origin again, just like the very first time.
This is completely normal: a cached copy stays at the edge only as long as the content is requested often enough to keep it warm.
```
Day 0, 10:00 Viewer 1 ─► CDN edge (empty) ─► Origin ─► copy cached at edge [MISS · slower]
Day 0, 10:05 Viewer 2 ─► CDN edge (cached) ─► delivered to viewer [HIT · fast]
│
│ 3–7 days pass with no requests
│ → edge evicts the video to free space
▼
Day 5, 14:00 Viewer 3 ─► CDN edge (empty again) ─► Origin ─► re-cached [MISS · slower]
```
**Scenario: few viewers, rare requests (cold cache)**
Edge servers do not hold files in cache indefinitely. Cached content has a limited lifetime — once it expires or is displaced by other content, it is removed. If your video library has many titles but each title is only watched occasionally, segments expire between views and must be fetched from origin again on the next request. In practice, nearly every playback session starts with a cache miss, and viewers experience the same slow start every time — regardless of how long the CDN resource has been active.
**Scenario: many viewers, frequent requests (hot cache)**
When a large number of viewers watch the same content in a short window, segments are requested repeatedly before they expire. The CDN keeps them in cache continuously, so viewers after the first consistently get a cache hit — fast delivery, low latency, no origin involved.
**A high time-to-first-byte (TTFB) on video segments is normal when cache is cold.** TTFB values of 1000+ ms for small segments are expected when the CDN has not yet cached the content for a given edge location. This is not a CDN malfunction — it is how CDN caching works.
For a CDN to consistently serve content fast, your content must be requested often enough to stay warm in the edge cache. If your viewer traffic is low or unevenly distributed, edge caches evict rarely-requested segments and the CDN reverts to pulling from origin on every request.
## How to check your cache hit ratio
There are two ways to check whether your content is being served from cache.
### Check in the browser for a specific request
You can inspect the cache status of any individual video segment directly in your browser:
1. Open the page where your video is embedded.
2. Open browser DevTools: press **F12** (Windows/Linux) or **Cmd+Option+I** (macOS).
3. Go to the **Network** tab.
4. Play the video and look for requests to your CDN domain (files ending in `.ts`, `.m4s`, `.mp4`, or `.m3u8`).
5. Click on any segment request and open the **Headers** tab.
6. In the **Response Headers** section, find the `Cache` header:
* `Cache: HIT` — the segment was served from the CDN edge cache. Fast delivery expected.
* `Cache: MISS` — the segment was fetched from origin. This is the cause of high TTFB.
If you consistently see `Cache: MISS` across multiple segments and multiple page loads, the cache is cold and the steps below will help.
### Check in the Gcore Customer Portal
1. Open the [CDN Statistics](https://portal.gcore.com/cdn/reports/statistics) section in the Gcore Customer Portal.
2. Select your CDN resource and review the **Cache hit ratio** metric.
The chart above shows two examples. The orange line stays at 100% — every viewer request is served from cache, meaning fast delivery at all times. The purple line drops repeatedly to 0% — the cache empties between bursts of traffic, so many requests go back to the origin server and viewers experience slow playback until the cache fills again.
### What cache hit ratio to expect
The figures below are **average, typical values** — not guarantees or thresholds Gcore sets for you. Your actual ratio depends on your content, audience size, TTLs, and configuration. Use them to gauge where you stand and to decide which actions to take. **Improving the ratio is driven by your own decisions** — choosing TTLs, enabling features, and sizing your setup. Gcore provides the tools (origin shielding, cache lifetime controls, and larger shield cache for enterprise customers on a committed plan); which ones you apply is up to you.
VOD and live streaming behave differently, so judge them against different baselines.
**VOD (video on demand)**
Static content should cache well, so VOD ratios are high on average.
| Typical ratio | What it usually means | Actions you can take |
| ------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **90–100%** | Hot content is served from edge cache mainly | If you plan to increase traffic, consider additional optimization |
| **70–90%** | Warm content is served from cache and origin, some requests are forwarded to origin | Analyze which content is being served from origin, and if it is possible to increase TTLs and use CDN shield cache |
| **50–70%** | Cold content with the occasional appearance of frequent requests | Your content is rarely requested, or is requested from different locations across the region/world. If you're confident you have a large number of users, then connecting to a Shield will help. If you have a small number of users, then this is normal behavior for cold content. |
| **Below 50%** | A sign of low number of requests | See the section below for how to optimize hit-ratio |
**Live streaming**
Live runs with lower hit ratio by design: playlists and manifests (`.m3u8`, `.mpd`) carry a very short TTL and are re-requested every few seconds, so they almost always MISS.
Manifests will always show a low or near-zero hit ratio. That is expected and not something to fix — don't include them when assessing live cache performance.
So, evaluate the **segment** hit ratio only, not the overall figure.
| Typical ratio of segments | What it usually means | Actions you can take |
| ------------------------- | ------------------------------------------------ | ------------------------------------------------------ |
| **70–99% (segments)** | Normal for live streaming | No action needed — this is expected behavior for live. |
| **Below 70% (segments)** | Segments are being re-fetched more than expected | See the section below for how to optimize hit-ratio |
## How to improve delivery speed
### 1. Check what files are frequently requested from the origin
If you see a high number of cache misses, the first step is to understand which files are being re-fetched from the origin. You can find this information in the CDN statistics and logs.
First, check the Response statistics. If you see a large number of non-200 responses, clients may be requesting non-existent content or the origin can't find the requested content. Check why the origin can't find the content.
Then check what content is being requested and check the advanced analytics.
And if you need more detail or a breakdown down to each request, check the logs page. You can filter by status codes (200, 404, etc.) and by caching status for MISS.
### 2. Allow the cache to warm up naturally
After a CDN resource is created or new content is uploaded, it takes time for edge servers to populate their caches as real viewers request files. In most cases, wait for steady viewer traffic before evaluating delivery performance.
If your viewer traffic is consistently low (fewer than a few hundred requests per day per title), natural cache warmup may never produce a meaningfully high cache hit ratio — use the options below instead.
### 3. Pre-load popular content with Prefetch
If you have a set of video files that you expect to receive significant traffic, you can push them into the CDN cache before viewers request them using the Prefetch feature. This eliminates cold-start latency for those specific files.
Prefetch is recommended for MP4 files. HLS and MPEG-DASH streams consist of a manifest file (`.m3u8` or `.mpd`) plus hundreds of individual segments (`.ts`, `.mp4`, `.m4s`, `.m4v`, `.m4a`, etc.). To fully pre-load a single title you would need to prefetch the manifest and every segment file separately — for a large video library this quickly becomes impractical. For HLS/DASH content, natural warmup or origin shielding are better alternatives.
See [Load content to CDN before users request it](/cdn/load-the-content-to-cdn-before-users-request-it) for instructions.
### 4. Verify cache TTL settings
If your CDN resource is configured with very short or zero cache TTLs, segments are evicted quickly and the cache never stays warm. Check that your cache settings allow segments to be stored for a reasonable duration:
TTL is the **maximum** time a file can stay in cache. In practice, content may be removed earlier — for example, when an edge server evicts less-requested files to make room for new ones, or when a cache purge is triggered. Setting a high TTL improves the chance of a cache hit but does not guarantee content will always be cached.
To review and configure cache TTLs, see [Specify cache lifetime on a CDN resource for video VOD and/or Live](/cdn/getting-started/create-a-cdn-resource/create-a-cdn-resource-for-video-streaming#step-4-configure-caching-rules).
### 5. Verify CDN resource settings
Check that the CDN resource is properly configured for video delivery.
Apply these [recommended settings](/cdn/getting-started/create-a-cdn-resource/create-a-cdn-resource-for-video-streaming#step-4-configure-caching-rules) for better performance and delivery.
### 6. Enable origin shielding
Origin shielding is the most effective way to improve cache hit ratio for low-traffic content. It inserts a dedicated **shield (precache) server** between your origin and all CDN edge servers.
Instead of every edge location independently pulling the same segment from your origin, all edge servers pull from the shield — which itself caches the content. Once a segment is cached on the shield, any edge server worldwide can retrieve it from the shield rather than from origin, dramatically increasing effective cache reuse.
Origin shielding is a paid option. Contact [Gcore support](mailto:support@gcore.com) or your account manager to enable it.
To configure shielding after it is enabled on your account, see [Enable and configure origin shielding](/cdn/cdn-resource-options/general/enable-and-configure-origin-shielding).
**Recommended shield location**: choose the location geographically closest to your origin server.
### 7. Slice very large single-file videos
If you deliver video as **large single MP4 files** (progressive download, not split into segments), enable [Large File Delivery Optimization](/cdn/cdn-resource-options/optimize-large-file-delivery). The CDN then fetches the file from origin in 10 MB chunks and caches each chunk independently, so viewers can start playback and seek without waiting for the whole file to be pulled.
This applies only to **large single-file MP4** delivery. **HLS and MPEG-DASH don't need slicing** — those formats are already split into small segments that the CDN caches individually. For how chunked origin fetching works, see [Example of large file slicing](/cdn/cdn-resource-options/optimize-large-file-delivery#example-of-large-file-slicing).
### 8. More help
See [Cache hit ratio is low](/cdn/troubleshooting/cache-percentage-is-low-how-to-solve-the-issue) for more information.
## How to improve 404 (Not Found) errors
### 1. Check origin mapping for 404s
When the CDN forwards a segment request to the origin and the origin returns `404 Not Found`, check origin access logs and error logs for the exact URL path shown in CDN logs. If the segment is expected to exist, fix the origin mapping before tuning cache settings.
| Origin type | Checks |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S3-compatible object storage | Confirm that the object key matches the request path exactly, including bucket prefix, capitalization, file extension, and URL encoding. Check that the CDN uses the correct bucket endpoint and Host header, and that the origin has read access to the objects. |
| Web server origin, including NGINX | Confirm that `root`, `alias`, and rewrite rules map the CDN path to the real file path. Check file permissions for the web server process and confirm that `access_log` and `error_log` entries show the same `404` path. |
| Media server origin, including Wowza, Flussonic, or Nimble Streamer | Confirm that the VOD content directory, storage location, application name, and playback URL format match the requested stream. For live streams, confirm that the encoder is publishing the exact stream name and all expected renditions before the CDN requests the HLS or DASH segments. |
For HLS and MPEG-DASH, also compare the manifest with the missing segment URL. If the manifest advertises a segment that the origin can't serve, the issue is in the packager, storage path, stream name, or file generation workflow rather than CDN caching.
### 2. Check live players for 404s
Live streams can generate many origin `404` responses when the player asks for a segment outside the live window. This often happens with low-latency settings, especially for MPEG-DASH, when the player calculates the live edge too aggressively and requests the nearest future segment before the origin has generated it.
Open your player page in a browser, keep DevTools on the **Network** tab, and let playback run for several hours for long live events or 24/7 broadcasts. Filter by `404` and segment extensions (`.ts`, `.m4s`, `.mp4`) to see whether failed requests repeat over time, affect one rendition, or happen only near the live edge.
Use the failed segment URLs to identify the pattern:
| Pattern | Likely cause | Checks |
| -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The player requests segment numbers or timestamps slightly ahead of the manifest | Live delay or target latency is too low, or the player clock is ahead of the packager clock | Increase the player live delay, review low-latency mode settings, and verify DASH timing values including `suggestedPresentationDelay`, `availabilityStartTime`, and `timeShiftBufferDepth`. |
| The player requests old segments after the tab has been open for a long time | The player fell behind the sliding live window, or the browser/CDN cached an outdated manifest | Keep manifest TTL short, confirm that the player reloads the manifest, and configure the player to return to the live edge when it falls outside the live window. |
| Only one bitrate, audio track, or subtitle track returns 404 | The encoder or packager stopped producing one rendition, or the manifest references a file that was never written | Check encoder and packager logs for the affected rendition, then compare the manifest entries with files available on the origin. |
If 404s appear only from one custom player, test the same stream in a reference player. If the reference player stays stable while the custom player keeps requesting future or expired segments, adjust the player rather than CDN cache settings.
## Check CDN-to-origin connectivity
When you see a high number of cache misses, the speed of the connection between CDN edge servers and your origin becomes critical. On every miss, the edge pulls the file directly from your origin — so if your origin is slow, distant, or under load, viewers feel that latency on every uncached request.
**Your origin server must be fast and reliable.** It should respond in well under a second, be hosted close to your primary CDN shield location, and have no firewall rules blocking CDN server IPs. For a full checklist of origin-side issues, see [5xx error: how to solve server issues](/cdn/troubleshooting/5xx-error-how-to-solve-server-issues).
**Alternatively, use Gcore's own infrastructure as your origin.** Gcore's storage and streaming services are co-located with the CDN network, meaning the CDN-to-origin path is internal and optimized for low latency — eliminating the origin bottleneck entirely:
* **[Object Storage](/storage/create-an-s3-or-sftp-storage)** — S3-compatible storage for VOD files (MP4, HLS segments, images). Use it as a CDN origin for fast, reliable pulls with no external hops. See [Use storage as the origin for your CDN resource](/storage/use-storage-as-the-origin-for-your-cdn-resource).
* **[Video Streaming for VOD](/streaming/video-hosting/upload-a-video-and-embed-it-to-your-app)** — upload video files and let Gcore handle transcoding, storage, and CDN delivery as a single integrated service.
* **[Video Streaming for live streams](/streaming/live-streaming/create-a-live-stream)** — ingest live streams via RTMP, SRT, or WebRTC and deliver them globally through Gcore CDN with no external origin required.
## Check response codes and origin response time
Cache hit ratio tells you whether content is served from cache, but it won't tell you whether errors are coming from your origin. Two metrics in the Customer Portal help separate a delivery problem from an origin problem.
Go to **Customer Portal → Reports → Statistics** and select your CDN resource:
* **Response classes** — counts of `2xx`/`3xx`/`4xx`/`5xx` responses the CDN returned to viewers. A rise in `5xx` indicates delivery errors. Note that if your origin returns a `504`, it is counted here as a `5xx` — this view does **not** distinguish whether the error came from the origin or was generated by the CDN itself.
* **Upstream response time** — the average time, in seconds, the CDN waited for a response from your origin. A high or rising value means the origin is slow or struggling, which is a common cause of buffering and `5xx` errors during traffic peaks such as live events.
Use the values below as operational guidelines, not as an SLA. Investigate sustained values above the threshold, especially when they happen together with low cache hit ratio, rising `5xx`, or viewer buffering.
| Request type | Expected origin response time on cache MISS | Investigate when |
| --------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Large single MP4 files or byte-range requests | Less than 1 s for TTFB; total transfer can be longer because the file is large | TTFB is above 2 s, download speed is low, or viewers wait before playback starts. Enable Large File Delivery Optimization for large single-file MP4 delivery. |
| VOD manifests (`.m3u8`, `.mpd`) from object storage or a media server | 100–500 ms | Average response time is above 500 ms, because manifests are small and should be returned quickly. |
| VOD segments (`.ts`, `.m4s`) from object storage or a media server | 200–1000 ms | Average response time is above 1 s, or segment misses show high TTFB in browser DevTools. |
| Live manifests (`.m3u8`, `.mpd`) from a media server | 100–500 ms | Average response time is above 1 s, or manifests are slow during traffic peaks. |
| Live regular segments (`.ts`, `.m4s`) from a media server | 100–500 ms | Average response time is above 1 s, or slow responses appear with `404`/`5xx` errors. |
| Low-latency live manifests and segments (`.m3u8`, `.mpd`, `.m4s`) | 500–5000+ ms | Response time can be close to the video segment duration, because in low-latency manifests and segments are produced and pulled in realtime by arrays of bytes continuously. |
If `5xx` errors climb during a live event **and** upstream response time rises at the same time, the bottleneck is almost certainly your origin, not the CDN. Protect it with [origin shielding](/cdn/video-cdn/origin-shielding-for-video) and verify origin capacity. For a full origin-side checklist, see [5xx error: how to solve server issues](/cdn/troubleshooting/5xx-error-how-to-solve-server-issues).
## When to contact support
If you have applied the steps above and delivery is still slow, contact [Support](mailto:support@gcore.com) and include:
1. Show us the affected "bad" video URL (CDN segment URL, not the player page).
2. Show us your cache hit ratio from the Statistics section (screenshot or value).
3. Show us response headers and timing for the slow segment.
Get URL of your "bad" file, change url in command below to your url. Run this command from **the viewer's machine** where video is bad: (script works on macOS, Linux, and Windows 10+):
```sh theme={null}
curl -v -o /dev/null -s -w "\nspeed: %{speed_download} bytes/s\ntime_total: %{time_total}s\ntime_starttransfer: %{time_starttransfer}s\n" https:///path/to/segment.ts
```
The `-v` flag prints the full HTTP response code and all response headers (including `Cache`, `X-ID`, `X-Cache`, and `Server`), which help support identify which edge server handled the request and whether it was a cache hit or miss.
4. Your CDN debug snapshot. Open `https://gcore.com/.well-known/cdn-debug/json` in your browser and copy the full JSON output into your ticket. This snapshot shows:
* **Your public IP and geographic location** — confirms which region the request came from
* **Edge server IP and location** (`server_headers`) — shows which CDN PoP served you; if this is far from your actual location, it indicates a routing issue
Example output:
```json theme={null}
{
"request_info": { "your ip": "203.0.113.10", "host": "gcore.com", ... },
"client_headers": { "city": "Singapore", "country": "{'code': 'SG'}", ... },
"server_headers": { "server": "sin-hw-edge-gc05", "country": "{'code': 'SG'}", ... },
"other_headers": { "traceparent": "00-25717f...-01", ... }
}
```
5. (Optional) A [HAR file](https://toolbox.googleapps.com/apps/har_analyzer/) recorded during playback.
## Next steps
Protect your origin and improve cache reuse with a precache server
Diagnose and fix a low cache hit ratio
Pre-load popular content into CDN cache before viewers request it
Configure how long CDN edge servers keep your content cached
Serve large single-file MP4 videos in 10 MB chunks for faster start and seek