ESI Demo System

This example uses various functionalities of Edge to perform cache-efficient ESI inclusion of fragments. That is, we have a number of clients who have required the following functionality:

"Products" exist at /products/<long-url-here>
Each product consists of a standard design and the page looks exactly the same, except for the content about the specific product.
This product-specific information is either returned from a third-party system based on query string, or built up using a REST asset in Matrix.
This usually involves a webserver-level rewrite for /products/(.*) to /_product?query=$1 or similar, which means Matrix can then use the query string to build the content.

There are a number of downsides to doing in in the origin webserver directly, and most of these are the significant effect on cache-ability since each path is seen as a separate cache key.

Using ESI, Edge Rewrites and Cache Key modification it is possible to perform this in Edge fully, in the most cache-efficient way:

hostnames:
 - esi-demo.staging.squiz.co.uk
framework_config:
    force_html_revalidation: true
    ignore_bot_cache_headers: true
    ignore_max_age_zero: true
    esi: true

    upstream: staging
    rewrites:
      # Rewrite all product pages to ESI loader
      -   from: /products(/.+)$
          to:   /cache-compression/dynamic-esi-fragment?path=$1?

    locations:
        # Remove args from cache_key_spec for products. This compresses the cache key for all products into a single entry
        -   id: 0675822D-1867-48D3-A700-4C6A4084CB2C
            pattern: ^/cache-compression/dynamic-esi-fragment$
            conf:
                cache_key_ignore_args: true

You can test this out by browsing to the following URL with any path on the end: http://esi-demo.staging.squiz.co.uk/products/foo/bar

Imagine a traditional Matrix site, a cache miss requires generating everything on the page from scratch. Headers, footers, menus, everything. These can be very slow.

Lets assume generating all of that takes 4 seconds. Lets also assume that the nested content that generates the product information (the actual unique content per product) takes 1 second to process.
On your traditional site it takes 5 seconds to generate a product page with a cold cache, every hit after that is essentially instant.

You request another product, the page is a cache miss and you have to go generate the full thing.
5 Seconds.

No Compression

Now lets switch to ESI fragments with cache compression.

On a totally cold cache we still have to go to Matrix and generate the 'frame' of the page, headers, menus etc. This takes 4 seconds.
The product content is then ESI'd in, processing ESI is essentially instant, cache is cold so we go to Matrix and generate that fragment, 1 second.
Total time is still 5 seconds

The next request for the same product gets a hit on the 'frame' page, runs ESI and gets a hit for the fragment too. Total time near zero.
No real difference so far, here's where we start to see some wins.

You request a totally different product, get a hit on the frame page, run ESI and have to go to Matrix for the fragment.
Total time is only 1 second.

With Compression

Cache Compression