Overview of Web Application Acceleration

Learn about the Web Application Acceleration service and how to manage its components.

Web Application Acceleration is a service that can speed up traffic on your layer 7 HTTP load balancers by applying a combination of caching and compression. This combination of speed enhancements is configured as a web application acceleration policy. The policy includes the caching or caching and compression. After the web application acceleration policy is created, you assign the policy to a load balancer as an acceleration resource of the policy.

The Web Application Acceleration service is available to regular Oracle Cloud Infrastructure customers for free. It is not available for Free Tier users.

Each acceleration is a binding of the policy to a specific load balancer. If you wanted to apply the same web application acceleration policy to multiple load balancers, you could create a separate acceleration resource for each load balancer.

Web Application Acceleration can compress the following response types:

  • application/atom+xml

  • application/geo+json

  • application/javascript

  • application/x-javascript

  • application/json

  • application/ld+json

  • application/manifest+json

  • application/rdf+xml

  • application/rss+xml

  • application/xhtml+xml

  • application/xml

  • font/eot

  • font/otf

  • font/ttf

  • image/svg+xml

  • text/css

  • text/html

  • text/javascript

  • text/plain

  • text/xml


  • The request must have the Accept-Encoding header to get a compressed response.

  • The Cache-Control response header values private and no-store turn off Web Application Acceleration caching.

See Overview of Load Balancer for more information on load balancers.

The remainder of this document describes the two resources associated with this functionality:

Manage these resources through the OCI Console, the command line interface (CLI), or the API.


Lists and describes concepts associated with the Web Application Acceleration service.

Accelerations are what bind web application acceleration policies to load balancers. When you attach an acceleration to a web application acceleration policy, you are assigning a load balancer to that policy, and the provisions of the policy are applied to the load balancer's operations

Enables caching at the load balancer to reduce latency and avoid increased load on the backend servers.

Cache purge

The caches of one or more load balancers comprising the acceleration are purged of data.


Cache purging is an irreversible action.


Compression is an option when selecting caching. Compressions compresses backend server responses before returning them to the web application user to reduce the amount of required bandwidth. This compression speeds the server responses' transit over the network. Currently only the GZIP compression algorithm is supported.

Load balancers
Load balancers determine the traffic routing. You can enhance the performance of load balancers by assign web application acceleration policies to them through accelerations.
Web application acceleration policy
Web application acceleration policies set the parameters for applying accelerations to web traffic using caching and compression.

Caching and Compression Limitations

Web Application Acceleration is a service that can speed up traffic on your load balancers by applying a combination of caching and compression.

Caching and compression occur for any 200 response to a GET or HEAD request lower than the maximum cache size. Caching and compression do not occur when the following headers are present:

  • Cache-Control: no-cache

  • Cache-Control: private

Caching and compression can significantly speed up traffic on your load balancers. However, using these features has the following constraints:

  • Caching

    • Only HEAD and GET requests are cached.

    • Only responses that return HTTP status code 200 are cached.

    • Cached content might not stay current with content on the backed servers until the cache expires or is purged.

    • Content is cached until it expires or is purged even if the file is removed from the backend server.

    • Backend servers can get a drastic increase in traffic when any of the following events occurs:

      • Multiple cache items expire at the same time.

      • The cache is purged.

      • The Web Application Acceleration service is disabled.
    • The maximum size of the cache is 100 MB. After this maximum size is reached, the Web Application Acceleration service removes those resources that have been accessed the fewest times until the maximum size is no longer exceeded.

      You cannot cache files over 100 MB.


      You can request to increase your Web Application Acceleration service's cache size. See Requesting a Service Limit Increase for more information.

    • Responses that return the Set-Cookie header are not cached.

    • Oracle recommends you do not cache dynamic pages because they can leak information.

  • Compression:

    • If you disable compression when it was previously enabled, users of your web applications might experience increased request latency as their data downloads increase.

By default, the response is cached for 10 minutes. You can configure the cache time by setting one of the cache time response headers in response returned by the backend server.

The following cache time headers are supported:

  • Cache-Control: Select the max-age or s-maxage directives to set the cache time. Both directives indicate how long in seconds the response is stored in the cache. For example, Cache-Control: max-age=300 caches the response for 300 seconds. If both the max-age and s-maxage directives are present, the s-maxage takes precedence.

  • Expires: Specify the date/time after which the response is considered expired. Only use the HTTP-date format (RFC2616) to specify the date/time. For example, Expires: Mon, 20 Feb 2023 12:45:26 GMT caches the response until this date.

  • X-Accel-Expires: Specify the caching time of a response in seconds. The zero (0) value disables caching for a response. If the value starts with the @ prefix, it sets an absolute time in seconds since Epoch. The response time is cached up to this time. For example, X-Accel-Expires: 300 caches the response for 300 seconds. X-Accel-Expires: @1676901818 caches the response until Monday, Feb 20 2023 14:03:38 GMT.

Configure the cache time based on the expected lifetime of a cached response. If the content that is static (immutable), configure the cache for an extended period of time. If the content changes often, configure the cache for a shorter period of time. For best results, cache the expiration time to match the content update time.

Tagging Resources

Apply tags to your resources to help organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.

If you are not sure whether to apply tags, ask your administrator for guidance.