Data Types

Permanent Cache

The Bytescale CDN's permanent cache eliminates file re-processing costs and latency.


The Bytescale CDN's permanent cache:

Eliminates file reprocessing on edge cache misses.

Reduces download latency.

Reduces processing costs.

How it works

Bytescale's permanent cache is a configurable cache that permanently stores processed files for fast subsequent responses.

By default, files that take longer than 500 milliseconds to process will be permanently cached.

When permanent caching is enabled:


Processed files will be automatically saved to Bytescale's permanent cache after generation.


Processed files will be served from the permanent cache or edge cache on all subsequent requests to the same URL.


Processed files will remain in the permanent cache until you reset your cache.

You are not billed for processing time when a file is served from the permanent cache: you will only be billed for bandwidth usage.

The download performance of a perma-cached file is identical to that of downloading a static asset (i.e. very fast).

Please note:

  • Permanent caching adds ~100ms of latency to the initial response.

  • This occurs once per URL: when both the permanent cache and edge cache are missed.


Example download performance of a 4000×2667 JPEG with image processing applied:

Bytescale (TTFB)Alternative Solution (TTFB)Edge CachePermanent Cache











































The Bytescale CDN further reduces latency by routing edge cache misses to a master edge cache node. This additional optimization reduces edge cache misses by keeping traffic within the edge network where possible: requests are only forwarded to the central permanent cache when both the regional edge cache nodes and the master edge cache node don't have a copy of the requested file.

Using these techniques, Bytescale is able to ensure there is only one file processing request per URL.

Without permanent caching or edge cache rerouting, alternative solutions will perform file reprocessing on regional edge cache misses. Depending on the structure of the CDN, this could result in thousands of file processing requests per URL.

Measuring performance

Time to First Byte (TTFB) is a key metric for measuring the performance of a file processing solution.

TTFB measures the end-to-end latency of a request, and includes DNS resolution, TLS handshakes, and file processing.

We recommend using a TTFB tool like SpeedVitals TTFB when evaluating file processing solutions.

Asia Pacific & Africa: get a performance boost for these regions by using Bytescale's Extended Coverage option.

Measuring cache hits

The Bytescale CDN includes the following HTTP response headers to help users identify cache hits and misses:

HTTP/2 200
x-cache: Hit
x-cache-perma: Miss
x-cpu-on-cache-miss: 971
  • x-cache: header values containing Hit indicate the response was served from the edge cache, else:

  • x-cache-perma: header values containing Hit indicate the response was served from the permanent cache, else:

  • The cache was missed (aka a "full cache miss").

If both headers contain Miss then the response is considered a "full cache miss", else it's considered a "cache hit".

File processing only occurs on a "full cache miss":

  • The x-cpu-on-cache-miss header is present on all "full cache miss" responses and on some "cache hit" responses. The header indicates the processing time (in milliseconds) that was spent on the last "full cache miss". When this header is returned for "cache hit" responses, it should be ignored by clients, as no file processing will have occurred; the header is an echo from the last "full cache miss".

  • The x-cpu-on-cache-miss-adjusted may also be present, and indicates the amount of CPU time that was consumed from your monthly CPU quota on the full cache miss. This value may be different from the x-cpu-on-cache-miss header value (which indicates the wall clock processing time). This header will only be present on certain transformation types, like video and audio transformations. If this header is not present, then the x-cpu-on-cache-miss header indicates the amount of time that was consumed from your monthly CPU quota. Similarly to x-cpu-on-cache-miss (above) this header should be ignored by clients for "cache hit" responses.

Cache resets

To reset your edge cache and permanent cache, click "Reset Cache" on the cache settings page in the Bytescale Dashboard.

Cache configuration

Bytescale's permanent cache can be configured via the URL and also via your account's settings (to control default cache behavior).

Account settings

Your account's default cache behavior is configured via the Bytescale Dashboard and determines:

  • Edge cache TTL duration.

    • The maximum amount of time a file will stay in a regional edge cache node.

    • Default: 1 year.

  • Permanent cache behavior.

    • The strategy used to determine when to permanently cache a processed file.
    • Default: permanently cache files that take > 500 milliseconds to process.

Querystring parameters

You can override your account's default cache behavior via the URL for each request:

  • ?v=123

    • Forces an edge cache miss and permanent cache miss each time 123 is changed to a unique value.

  • ?cache=false

    • Forces an edge cache miss and permanent cache miss on each request.

  • ?cache_ttl=31536000

    • Specifies the maximum time to store the file in the edge cache.

  • ?cache_perm=auto|false|true

    • Specifies whether to permanently cache the processed file.

    • Permanent caching adds ~100ms of latency to the initial request. This latency is incurred once per URL: when both the permanent cache and edge cache are missed (i.e. when the URL is first requested).

    • If auto is used, the file will be permanently cached if it takes > 500 milliseconds to process.

Your account's default cache behavior is used for cache_ttl and cache_perm when they are omitted from the querystring.

Was this section helpful? Yes No

You are using an outdated browser.

This website requires a modern web browser -- the latest versions of these browsers are supported: