Dynamic site acceleration

An edge device, either an ADC or a CDN, is capable of TCP multiplexing which can be placed between web servers and clients to offload origin servers and accelerate content delivery.

Usually, each connection between client and server requires a dedicated process that lives on the origin for the duration of the connection. When clients have a slow connection, this occupies part of the origin server because the process has to stay alive while the server is waiting for a complete request. With TCP multiplexing, the situation is different. The device obtains a complete and valid request from the client before sending this to the origin when the request has fully arrived. This offloads application and database servers, which are slower and more expensive to use compared to ADCs or CDNs.[2]

HTTP has a built-in system for cache control, using headers such as ETag, "expires" and "last modified". Many CDNs and ADCs that claim to have DSA, have replaced this with their system, calling it dynamic caching or dynamic cache control. It gives them more options to invalidate and bypass the cache over the standard HTTP cache control.[3]

The purpose of dynamic cache control is to increase the cache-hit ratio of a website, which is the rate between requests served by the cache and those served by the normal server.[4]

Due to the dynamic nature of web 2.0 websites, it is difficult to use static web caching. The reason is that dynamic sites, per definition, have personalized content for different users and regions. For example, mobile users may see different content from what desktop users may see, and registered users may need to see different content from what anonymous users see. Even among registered users, content may vary widely, often example being social media websites.

Static caching of dynamic user-specific pages introduces a potential risk of serving irrelevant content or 3rd party's content to the wrong users, if the identifier allowing the caching system to differentiate content, the URL/GET-request, isn't correctly varied by appending user-specific tokens/keys to it.

Dynamic cache control has more options to configure caching, such as cookie-based cache control, that allows serving content from cache based on the presence or lack of specific cookies. A cookie stores the unique identifier-key of a logged-in user on their device and it's already implemented for authenticating users upon execution of any page that opens a session, in a dynamic caching system, the caches are referred to by URL as well as the cookie keys, allowing to simply enable serving of default caches to anonymous users and personalized caches to logged-in users (without forcing you to modify the code, to make it append additional user identifiers to the URL, like in a static caching system).

If personalized content cannot be cached, it might be queued on an edge device. This means that the system will store a list of possible responses that might needed in the future, allowing them to be readily served. This differs from caching as prefetched responses are only served once, being especially useful for accelerating responses of third-party APIs, such as advertisements.[5]

Route optimization, also known as "latency-based routing", optimizes the route of traffic between clients and the different origin servers in order to minimize latency. Route optimization can be done by a DNS provider[6] or by a CDN.[7]

Route optimization comes down to measuring multiple paths between the client and origin server, and then recording the fastest path between them. This path is then used to serve content when a client in a specific geographical zone makes a request.[8]