Site performance is often a combination of architecture decisions rather than isolated optimisations. In the case of Spendesk’s marketing site, the platform relies heavily on static generation and CDN delivery through Netlify to ensure consistent performance and reliability.

Below is a breakdown of how the current setup works and what we observed when analysing response times and caching behaviour.

Response Times Across the Site

We analysed response times across the entire site using crawling tools & the results were very strong overall, with 99.3% of URLs responding in under one second, and an average response time of less than 400ms across 1,700+ URLs.

For a site of such varying content types, this level of performance is excellent. Quick response times mean:

• Crawlers can efficiently process the site
• Users receive content quickly
• The infrastructure can handle spikes without performance degradation

Understanding the Current Caching Headers

Two key response headers appear consistently across the site.

Cache-Control

cache-control: public, max-age=0, must-revalidate

This configuration means:

• public The response can be cached by shared caches such as CDNs.
• max-age=0 The cached version is immediately considered stale.
• must-revalidate The cache must check with the origin before serving the page again.

Here we are ensuring browsers do not serve outdated HTML pages without verifying that the content is still current. This is a common setup for dynamic or frequently updated content, which means publishing on our popular blog and resources sections, or changes to service pages is always fresh for the user.

Importantly, this behaviour applies mainly to HTML documents. Static assets such as JavaScript and CSS are typically cached much more aggressively.

Cache Status

cache-status: "Netlify Edge"; fwd=hit

This header shows how Netlify’s CDN served the request.

• Netlify Edge indicates the request was handled by Netlify’s global edge network - distributed to hundreds of servers globally for maximum performance.
• fwd=hit means the edge node already had a cached copy of the page and was able to serve it directly.

When a request is served from the edge cache, the response does not need to travel back to the origin server. This significantly reduces response time and helps ensure consistent performance for users and crawlers around the world.

Because the content is delivered from the CDN layer rather than the origin, pages can be served extremely quickly even under high traffic. This is one of the key benefits of combining static site generation with edge caching.

The Benefits of Static Site Builds

The Spendesk marketing site is fully statically generated using Netlify. This architecture provides several operational advantages.

Entire Site Is Built at Build Time

We made the choice to have all pages rendered during the build process, rather than dynamically at request time.

This means pages can be delivered extremely quickly as they are rendered as static HTML - with no runtime dependency on application servers. This also means we take advantage of automatic rollbacks.

Automatic Rollbacks Provide Reliability

A huge advantage of using Netlify is that it automatically versions builds.

In fact, if a deployment fails, it is blocked before reaching production. Netlify waits for the full build to finish successfully before deploying it to production.

However, the rollback functionality can be very useful when a build succeeds but introduces bugs or issues, as it allows you to revert the deployment with a single click.

Rebuilds Are Triggered Automatically

Another benefit of this setup in combination with a headless CMS (Storyblok) means updates will trigger a full rebuild of the site, with Netlify then deploying the new version across the CDN.

While this means the entire site rebuilds when content changes, it also simplifies infrastructure and removes the complexity of partial rebuild logic, reducing the risk of any issues with the site breaking.

Because every build is deployed as a complete static version of the site, there is strong confidence that:

• Broken runtime dependencies are unlikely and near impossible
• Infrastructure issues are minimal
• Deployments are predictable and maintainable

Locale Consolidation Improvements

A recent improvement was merging three separate English locales into a single unified structure.

This change simplified the site architecture and improved consistency across the English-language experience.

Reducing duplicated structures also helps:

• Simplify crawl paths
• Consolidate signals
• Reduce operational overhead.

Limitations of Edge Caching Configuration

Architecture usually involves some trade-offs, and one of those is that Netlify’s edge layer can act somewhat like a black box.

While Netlify provides global caching, it may not always expose fine-grained control over:

• Which edge locations cache which resources
• How specific HTML pages are cached
• Custom regional caching policies

Even when using Netlify Edge functionality, caching behaviour is often handled automatically rather than configured manually. In our opinion, this is actually ideal for most development teams as it removes the added maintence of the edge layer.

We are always improving though, and working with the Netlify platform to produce more granular control over edge caching locations is on our radar.

Static Assets vs HTML Caching

It is also important to distinguish between HTML pages and static resources.

In the current setup:

HTML pages use conservative caching rules to prevent stale content.

HTML page caching occurs at the CDN (or edge network) level due to the cache-control: public, max-age=0, must-revalidate rule. In contrast, JS, CSS, and images are cached both at the CDN and in the browser. This means that when a visitor returns to our website, these assets remain in its browser cache and don’t need to be requested again.

This allows the site to maintain freshness for page content while still benefiting from strong performance for static assets.

Summary

Spendesk’s architecture prioritises reliability and simplicity by using static site generation on Netlify combined with global CDN delivery.

The result is:

• Speedy response times for the vast majority of pages
• Strong deployment safety through versioned builds and rollbacks
• Simplified infrastructure through full static builds
• Globally distributed content delivery through Netlify Edge

While edge caching configuration is somewhat abstracted away, the overall architecture provides excellent performance and operational stability.