What is EdgeStart

When a website is served, it is typically a mixture of cacheable and uncacheable resources. Resources like images and css are often static, cacheable resources, whereas a personalized homepage or search result, might not be. The advantage of caching resources is that the time to first byte (TTFB) is very quick as a result of the resources being cached on the Akamai Edge, close to the end user. A non-cacheable page often has to do a round trip to an origin server, prolonging the TTFB but is more dynamic in nature than a static asset. EdgeStart provides the best of both worlds.

In the case of non-cacheable pages, Edgestart essentially allows us to immediately stream the cached part of the document, and then streams the dynamic portion of the response from origin. This methodology provides the TTFB one would expect for a cached page, allowing the browser to start processing the first part of the response, even while the request is still going on to the server.


EdgeStart Legend
EdgeStart Legend


EdgeStart UnOptimized
EdgeStart UnOptimized

An unoptimized page with a 1.4s time to first byte. Resources referenced in the HTML page begin loading after 1.4s

Optimized with EdgeStart

EdgeStart Optimized
EdgeStart Optimized

An optimized page with a 0.4s time to first byte. Resources referenced in the EdgeStart content begin loading at approx 0.5s. Content received from the response from origin begin loading after 1.4s.

In this waterfall for Edgestart, we see that the unoptimized page has a long TTFB. With Edgestart, the cached portion of the response is served immediately and files referenced in the cached component start downloading right away. When the content is returned from origin, those files can begin loading.

How Does It Work

The FEO analyzer will analyze a response and split it in two. The first part is cached, and the second part is discarded. When a user makes a request, the cached component is served immediately, and the request is forwarded to the origin. When the response is returned from origin, the edge splits it, similar to the first step, and serves the second part of the response. Note that when the initial cached component is served to the client, FEO framework scripts are also injected.

There are three key stages to EdgeStart: Scoping, Configuration, Automated Analysis and delivery.


The first step for scoping is to determine applicability. If the page is fully cacheable in some circumstances, you should consider caching or dynamic page caching If the page is non-cacheable, consider using EdgeStart.

The second step is to determine how much of the HTML document to cache. The system default is to determined this by the X-UA-Compatible or Content-Type tag, however you have the option to perform your own analysis and determine how much of the response to cache.

Developers often have intimate knowledge of what is and is not transient between requests. To gain even greater performance improvement, it is suggested to examine the full HTTP response and determine how deep into the HTML response you believe can be cached and served for the various pages within the page type. Once this is determined, you can specify a custom barrier to change what tag is matched in the source.


In the FEO configuration, EdgeStart must be enabled in one of the FEO policies. This is simply a checkbox in the FEO Configuration. If you wish to use a custom barrier , such as a comment tag like

<!-- FEO BARRIER -->;

please discuss with your Akamai account team on how to add the custom barrier to the configuration. This will allow you to move the barrier as needed in your source code, without needing Akamai intervention.

Automated Analysis

Once enabled, the analyzer will analyze a page, splitting the response at a predefined barrier that can be the system default or custom.

Typically the FEO analyzer looks for the X-UA-Compatible or Content-Type metatags, grabbing all content up to the detected tag. If scripts or CSS tags are above these tags, they will be included.

Note that if the title, metatags or scripts aren’t the same on every page, it’s recommended to place them below the barrier or to move the barrier itself by using a custom barrier definition.


When the edge receives a request, the response headers and cached content are sent to the client and the request is forwarded to the origin. When the edge receives a response from the origin, it splits the content, and serves the remainder of the response. If the origin responds with unexpected content, a clientside directive redirects with to the same page with FEO disabled via query string.


Are there any concerns about what tag to use for the barrier?

  • The response is merged immediately after the barrier, so it must be a complete tag, ending with >, and, in general, should be after an end tag, or self terminating tag. For example, using the <head> is fine, but not recommended for <script name="ads"> since injected content would likely break the script.

Testing considerations

Generally you will notice the time to first byte (TTFB) drop significantly, content in the cached component may start downloading immediately, and then the remainder of the requests will begin when the origin content is received by the client.

How to debug

Compare with FEO on and off, using the akamai-feo=off querystring. On the Akamai staging network, a comment similar to <!-- EdgeStart Barrier--> is added at the insertion point.