Fastly Server-Timing

RUMvision can collect Fastly timing data when your website exposes it through the Server-Timing response header.

This helps you understand whether slow server response times are caused by Fastly delivery, edge compute, the origin server, or cache behavior.

If your site is not exposing these headers yet, you can add them in Fastly with VCL or from your Fastly Compute application.

Add Server-Timing via Fastly

Below are the recommended fields to expose. Once these fields are exposed and Fastly is selected as the CDN in your tech stack settings and enabled the Fastly checkbox, we will automatically collect them.

ValueType/SourceMeaning
processingMetric
time.elapsed.msec		Time spent in the Fastly Delivery layer for this request.
Shows the time since the request started in milliseconds.
cdn_cacheFilter
X-Cache		Shows whether the response was served from cache.
For example HIT or MISS.
cdn_coloFilter
server.pop		An identifier representing one of Fastly's POP locations.
This is the POP where the VCL code is currently running.
cdn_regionFilter
server.region		A code representing the general region of the world in which the POP location resides.
For example SA-East for Eastern South America or APAC for Australia and New Zealand

Where to implement

In Fastly, go to:

  • Fastly
  • Select service
  • Edit configuration
  • Clone active version
  • VCL snippets

Add the Server-Timing logic in vcl_deliver.

Rule to implement

Create a VCL snippet and apply it to all HTML document requests. These are the main page requests RUMvision uses to understand document TTFB and backend-related delays.

This usually means the main document request of your pages, not images, scripts, stylesheets, or API calls.

If needed, you can also expose these timings on other request types, but HTML document requests are the recommended starting point.

Add the following VCL snippet (code from Fastly blog)

sub vcl_deliver {
  if ( fastly.ff.visits_this_service == 0 ) { 
    # Any Server-Timing header is cached and old, so overwrite  
    if ( resp.http.X-Cache ~ "HIT") { 
      set resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec
        + ", cdn-cache;desc=HIT"
        + ", cdn-pop;desc=" + server.pop
        + ", cdn-region;desc=" + server.region;
    } else { 
      # Communicated with origin, so append if present
      if ( resp.http.Server-Timing ) { 
        add resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec; 
      } else { 
        set resp.http.Server-Timing = "processing;dur=" + time.elapsed.msec; 
      } 
      
      add resp.http.Server-Timing = "cdn-cache;desc=MISS";
      add resp.http.Server-Timing = "cdn-pop;desc=" + server.pop;
      add resp.http.Server-Timing = "cdn-region;desc=" + server.region;
    } 
  } 
}

If your origin or Fastly Compute application already emits origin or compute timings, this VCL keeps those values on cache misses and adds the Fastly delivery timing.

Testing the outcome

Next step is testing the outcome. You could either wait for data to arrive in your RUMvision dashboard, or proactively test the outcome using the DevTools of your preferred browser.

Expected outcome

For a cache miss where the origin also exposes timing data, your HTML document may return a header similar to this:

Server-Timing: delivery;dur=1, fastlyCache;desc=HIT, fastlyPop;desc=AMS;fastlyRegion;desc=EU-West

For a cached response, the header may look like this:

Server-Timing: origin;dur=248, delivery;dur=25, fastlyCache;desc=MISS, fastlyPop;desc=AMS;desc=EU-West

Check the response headers

To verify the setup:

  1. Open your website in Chrome or Edge.
  2. Open DevTools.
  3. Go to the Network tab.
  4. Reload the page.
  5. Click the main HTML document request.
  6. Check the Response Headers section.
  7. Look for server-timing.

Test in DevTools Console

As the browser exposes Server-Timing values through the PerformanceServerTiming interface, you can also test it in the browser console by running the following JavaScript:

const navEntries = window.performance.getEntriesByType('navigation');
console.table( navEntries[0].serverTiming );

Important

In general, be sure to:

  • Always test on staging environment before deploying these steps to a production environment.
  • Avoid exposing sensitive internal details. Server-Timing data is visible in the browser, so only expose metrics that are safe to share with visitors and third-party scripts.

Fastly notes

If your origin already sends a Server-Timing header, make sure your Fastly VCL preserves it on cache misses. Otherwise, useful origin or application metrics may be removed.

On cache hits, origin timings from a previously cached response may be stale. That is why this example overwrites Server-Timing on cache hits and only exposes Fastly delivery and cache status.

Published by:

On , updated

Table of Contents