Tech SEO Summit Hamburg - Caching as a Competitive Advantage

My deck from the Tech SEO Summit in Hamburg 23/04/2026.

Caching is no longer just an engineering detail. In modern web architectures, it directly affects rendering, performance, crawl efficiency, SEO, infrastructure cost, and business outcomes. This talk breaks down core caching strategies, including build-time caching, TTLs, stale-while-revalidate, and on-demand invalidation, and shows how SEOs can audit cache behaviour, identify rendering issues, and make a stronger business case for caching work. 

Transcript

1. Caching as a Competitive Advantage Rendering, Performance & SEO in Modern Web Architectures Will Kennard SEO Consultant linkedin.com/in/willkennard @willkennard
2. 1: Modern Web Architecture willkennard.com 2: Core Caching Strategies 4: Making the Business Case for Caching 3: Measuring Impact & Identifying SEO Issues Coming Up
3. Modern Web Architecture & Caching willkennard.com 1
4. What is caching? willkennard.com
5. The process of storing a temporary copy of frequently used data so that future requests can be served instantly. willkennard.com
6. Caching means storing content generated during the request-response cycle and reusing it when responding to similar requests.
7. Caching means storing content generated during the request-response cycle and reusing it when responding to similar requests.
8. Caching matters because it changes outcomes. willkennard.com
9. 1: Faster experiences willkennard.com 2: Lower server load 3: Better crawl efficiency 5: Stronger business performance 4: More stable rendering
10. Modern sites & LLMs are changing the caching conversation. willkennard.com
11. “ We want you to think about caching at every possible layer. - Tim Neutkens, Next.js
13. • Layout files • Server components • Client components • Embedded junk • Its own cache
14. The amount of applications out there is growing. Technical SEOs are going to need to fix them. willkennard.com
15. Generally, it ’ s probably a good idea to build first, then add caching later - optimising as you build. willkennard.com
16. “ The results consistently show that none of the major AI crawlers currently render JavaScript. willkennard.com
17. 1: TTFB and perceived speed willkennard.com 2: Crawl budget / crawl efficiency 3: Indexation consistency 5: UX and conversion 4: Freshness vs stability Why should SEO ’ s care?
18. Rendering: Quick Recap willkennard.com
19. Rendering choices influence what can be cached, where, and for how long. willkennard.com
20. And composable architecture makes that even more useful annoying complex. willkennard.com
21. willkennard.com 􀪬 􀈼 􀁿 􀱗 Routing Data Fetching Rendering 􀦊 􀟛 Displaying
22. willkennard.com 􀪬 􀈼 􀁿 􀱗 Routing Data Fetching Rendering 􀦊 􀟛 Displaying CDN
23. willkennard.com 􀪬 􀈼 􀁿 􀱗 Routing Data Fetching Rendering 􀦊 􀟛 􀈼 􀁿 􀱗 Client Routing Async Fetching Rendering Displaying ?
24. Server Rendered Content Components statically rendered willkennard.com Server/ Application Client/ Browser Network
25. Edge caching built into host willkennard.com Server/ Application Client/ Browser Network
26. User requests trigger data revalidation willkennard.com Server/ Application Client/ Browser Network
27. willkennard.com
28. willkennard.com Model
29. 1. Where is the content generated? willkennard.com 2. Where can it be cached? 3. When should it be refreshed? What SEO ’ s Decide
30. SEOs generally are concerned only with HTTP caching. willkennard.com
31. Core Caching Strategies & Applying Them willkennard.com 2
32. 1. Build time caching willkennard.com 2. Time-based revalidation 3. Stale-while-revalidate The Big Four 4. On-demand invalidation
33. “ There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton
34. 1. Build time caching willkennard.com 2. Time-based revalidation 3. Stale-while-revalidate The Most Difficult 4. On-demand invalidation
35. Where do caches live? willkennard.com
36. Server/ Application Client/ Browser Network willkennard.com Application layer CDN/Edge Browser Cache
37. Server/ Application Network willkennard.com Application layer CDN/Edge Browser Cache Most of this Client/ Browser
38. Server/ Application Network willkennard.com Application layer CDN/Edge Browser Cache Is controlled here Client/ Browser
39. Server/ Backend Network willkennard.com Next.js Rails WordPress Akamai Cloudflare HTTP Requests Local cache Client/ Browser
40. Strategies & Their Use Cases. willkennard.com
41. willkennard.com Strategy Strength Risk Build-time Fast, stable Can go stale Time-based Simple Freshness lag Stale-While-Revalidate Fast + resilient Temporary staleness On-demand invalidation Accurate freshness Operational complexity
42. Build Time Caching. willkennard.com
43. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event.
44. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event. • Very fast response times • Minimal origin work on each request • Stable HTML for users and crawlers
45. Build time caching is essentially baked in to modern frameworks. Providing they are used correctly!
46. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event. • Good fit for: • Marketing pages • Evergreen editorial content • Documentation • Layouts
47. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event. • Watch out for: • Content can go stale between builds • Large sites may have long build times • Small changes may require full or partial regeneration
48. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event.
49. Build Time Caching Content is rendered ahead of time and reused until the next build or publish event.
50. Expiry Based Caching (TTL). willkennard.com
51. TTL / expiry based Content is cached for a fixed period, then refreshed when that period ends.
52. TTL / expiry based Content is cached for a fixed period, then refreshed when that period ends. • Easy to understand and configure • Reduces repeated processing for busy pages • Gives predictable freshness windows • Works well when exact real-time freshness is not required
53. TTL / expiry based Content is cached for a fixed period, then refreshed when that period ends. • Good fit for: • Category pages • Blog indexes • Product listing pages
54. TTL / expiry based Content is cached for a fixed period, then refreshed when that period ends. • Watch out for: • Short TTLs can reduce cache efficiency • Long TTLs can leave SEO-critical content stale
55. Cloudflare Edge Cache TTL Platform-level control over how long Cloudflare keeps a response at the edge.
56. “If you see a lot of revalidated content, it ’ s a good sign you should increase your Edge Cache TTLs through a page rule or max-age origin directive.
57. WP Rocket ‘Cache Lifespan ’ It’s TTL based. It’s in a plugin dashboard.
58. Stale-while- revalidate. willkennard.com
59. Stale-while-revalidate Serve cached content immediately, then refresh it in the background.
60. SWR is the most widely used modern caching pattern because it gives a practical compromise: keep things fast & update freshness in the background. willkennard.com
61. Stale-while-revalidate Serve cached content immediately, then refresh it in the background. • Keeps response times fast • Avoids blocking users on regeneration • Helps absorb traffic spikes • Often a practical balance between speed and freshness
62. Stale-while-revalidate Serve cached content immediately, then refresh it in the background. • SWR is likely the one you might be focused on the most
63. Stale-while-revalidate Serve cached content immediately, then refresh it in the background.
64. Stale-while-revalidate Serve cached content immediately, then refresh it in the background. • Good fit for: • Articles with frequent visits • High-traffic pages where performance matters more than second-by-second freshness
65. You can still have a static output with components that revalidate.
66. <div id="app"> willkennard.com
67. <LayoutHeader/> <StaticComponent/> <DynamicComponent/> <LayoutFooter/> willkennard.com
68. Partial Prerendering can serve a static shell immediately while dynamic portions are rendered and streamed later.
69. <LayoutHeader/> <StaticComponent/> <DynamicComponent/> <LayoutFooter/> willkennard.com
70. <LayoutHeader/> <StaticComponent/> <Suspense fallback={loading}> <DynamicComponent/> </Suspense> <LayoutFooter/> willkennard.com
71. <Header/> <ProductDetails/> <Suspense fallback={loading}> <StockInfo/> </Suspense> <Footer/> willkennard.com
72. <Header/> ← build time static <ProductDetails/> ← SWR <Suspense fallback={loading}> <StockInfo/> ← Client </Suspense> <Footer/> ← build time static willkennard.com
73. <Header/> ← build time static 86400s <ProductDetails/> ← SWR 3600s <Suspense fallback={loading}> <StockInfo/> ← Client </Suspense> <Footer/> ← build time static willkennard.com
74. Stale-while-revalidate Serve cached content immediately, then refresh it in the background. • Watch out for: • Users and bots may briefly see older content • Teams need to be comfortable with a short stale window
75. Event-driven / on-demand invalidation. willkennard.com
76. Event-driven / on-demand invalidation Cached content is refreshed or purged when a specific change happens.
77. Event-driven / on-demand invalidation Cached content is refreshed or purged when a specific change happens. • Better freshness control • Faster updates for important content
78. Event-driven / on-demand invalidation Cached content is refreshed or purged when a specific change happens. • Avoids waiting for TTL windows • Good for sites where some content changes unpredictably
79. Event-driven / on-demand invalidation Cached content is refreshed or purged when a specific change happens. • Good fit for: • Publishing workflows • Faceted/category pages affected by product changes
80. Event-driven / on-demand invalidation Cached content is refreshed or purged when a specific change happens. • Watch-out for: • Invalidation rules can become complex • Dependencies are easy to miss • Usually the hardest strategy to design well
81. • Imagine a change is the same as flushing a certain route ’ s cache using a CMS
82. 1. Public and changes occasionally willkennard.com 2. Dynamic & user-specific per request Think about two content types:
83. willkennard.com If your traffic is low and your content doesn ’ t change very often, leave long invalidation periods on 🤷
84. willkennard.com If your traffic is low and your content doesn ’ t change very often, leave long invalidation periods on 🤷 And vice versa!
85. Measuring Impact & Identifying SEO Issues willkennard.com 3
86. 1. Performance: TTFB, CWV, perceived load willkennard.com 2. SEO: crawl behaviour, indexation consistency 3. Business: engagement, conversion, infrastructure Layers of measurement
87. 1. Templates by content volatility willkennard.com 2. Expensive uncached responses 3. Invalidation logic What do we audit? 4. Bot-facing vs user-facing output 5. Prioritising high-impact templates
88. 1. Over-caching important content willkennard.com 2. Under-caching expensive templates 3. Broken invalidation What goes wrong 4. Inconsistent signals - for bots & users
89. 1. Get hold of observability stats from your platforms willkennard.com How do we audit? 2. Check response headers and work with devs
90. Platform Observability Stats Hosting platforms like Vercel offer this.
91. Be sure to audit compute vs edge requests You can do this on a route level too. Edge = 2ms Compute = 798ms
92. Cloudflare offer a cache insights dashboard You can sort by content type.
93. Check build logs How much of your site is being rendered at build time? Nuxt
94. Response headers. willkennard.com
95. curl: quickest response check! Obviously you’ll want to use observability tools at scale. But there’s nothing like doing a few curls on the key templates to give you an instant idea of what is going on.
96. Response headers: cache result. willkennard.com
97. Cache Result Headers These don ’ t direct caches to do stuff These help you understand what actually happened in the cache for a specific request.
98. x-cache: HIT / MISS One of the easiest ways to confirm a cache is working.
99. cf-cache-status / x-vercel-cache CDN specific responses.
100. x-cache: BYPASS The cache was skipped entirely. Often indicates cookies, auth or configuration prevented caching.
101. Diagnosis, not control Cache result headers are mostly for humans to debug, and are available as standard on most CDNs.
102. Response headers: freshness. willkennard.com
103. Cache-Control Directives These actually direct caches to do stuff These tell caches how long a response can be reused, when it becomes stale, and how old the cached copy already is.
104. cache-control: public The response may be stored by shared caches such as CDNs. This is usually what you want for public HTML, CSS, JS, images, and other non-personalised resources.
105. cache-control: private The response is intended for one user and should not be stored by shared caches. Important for logged-in or personalised pages.
106. cache-control: no-cache The response may be stored, but it must be revalidated before reuse. It does not mean do not cache. It means “check before using the cached copy”.
107. cache-control: no-store The response should not be stored in cache at all. Useful for sensitive data, but bad for performance if applied to content that could safely be cached.
108. cache-control: max-age This is the basic TTL rule. It tells you how long a cached version can be reused before it becomes stale.
109. cache-control: s-maxage Very important for SEO, because bots often hit pages through shared cache layers. This can be different from the browser cache lifetime.
110. cache-control: immutable The response is not expected to change during its freshness lifetime. Commonly used for versioned static assets like JS or CSS files. Usually good for performance, but dangerous if applied to something that can change unexpectedly.
111. cache-control: stale-if-error If the origin fails, the cache may keep serving the stale response. Useful for resilience. It can keep important pages available during outages, though it also means stale content may persist longer.
112. cache-control: stale-while-revalidate After becoming stale, the response may still be served while a fresh version is fetched in the background. Great for speed and resilience. Also important to understand when explaining why a page can still be briefly stale after expiry.
113. Response headers: validation. willkennard.com
114. Validation Headers These help caches & crawlers check whether their stored copy is still valid, instead of downloading the whole response again.
115. ETag A unique identifier for this version of the response. When the content changes, the ETag changes too. Checks for changes instead of fetching the full page again.
116. If None Match Sent by the client/cache to ask whether its stored ETag still matches the current version. Server can return 304 Not Modified instead of sending the whole response again.
117. Server/ Application Client/ Google Cache Google happy Stores resource with etag Renders page, generates etag Checks with if-none-match Returns 304 not modified Requests resource & stores etag Etag same as stored
118. Next.js / Nuxt Automatically cache every static route to use as an ETag Cloudflare / Cloudfront Uses ‘weak’ ETags - Google accepts these Nginx & Apache Automatically generate ETag from last modified + file size App Servers (Node/Express) No Etag by default - needs middleware configuring
119. ETag & If None Match Caches use them, many by default. From a page statically rendered at build time
120. ETag & If None Match Caches use them, many by default. From a page explicitly told to remain dynamically rendered
121. Last Modified The date/time the response was last changed. Useful for understanding when content last changed, and whether a cached copy may still be reusable.
122. Response headers: vary. willkennard.com
123. Vary headers When cached versions must differ. Tell caches which request headers affect the response, so they know when they must store or serve a different version.
124. vary: Accept-Encoding The cache should keep separate versions for gzip, brotli. Normal and expected: helps explain why the “same” page may exist in multiple cached forms.
125. vary: User-Agent Different cached versions depending on the browser or bot making the request. Can affect bot vs user delivery, mobile vs desktop behaviour, and can create debugging headaches if Googlebot gets a different cached response.
126. vary: Accept-Language Different cached versions based on language preference. Relevant for international sites: helps ensure the right language version is cached and served.
127. vary: Cookie Different cached versions depending on cookies sent with the request. Often a big cache killer. It can reduce cache efficiency and create inconsistent delivery if personalised and non-personalised users share templates.
128. Crawl the same URLs with different request conditions, then compare the responses.
129. Config > User-Agent Googlebot Smartphone, Googlebot Desktop, Desktop Chrome, Mobile Chrome
130. Config > Spider > HTTP extraction Test the top 5 or so ‘templates ’ on your site
131. I ’ m also working on a tool
132. I ’ m also working on a tool It ’ s not quite ready yet! I ’ m looking for someone to work on it with me to make it as useful as possible - if that ’ s you please give me a shout :)
133. Check your CDN rules vs application logic.
134. E.g. Cloudflare does not cache the resource when: • The Cache-Control header is set to private, no-store, no-cache, or max-age=0 • Set-Cookie header exists • HTTP request method is not GET.
136. If enterprise, check for reverse proxy. willkennard.com
137. Server/ Backend Network willkennard.com Next.js Rails WordPress Akamai Cloudflare HTTP Requests Local cache Client/ Browser Reverse Proxy
138. Apply the same problem solving logic to reverse proxies as CDN/Edge. willkennard.com
139. A caching checklist for SEOs willkennard.com
140. Application Network Is there a CMS with caching options? Which CDN is set up? Do a curl: which headers return? Client What triggers revalidation? Which content should be cached? Is CDN/proxy changing cache behaviour? Is the CDN configured individually from CMS? Check site performance/CWV Who is using the caching options? How is the CDN currently performing? % edge vs compute. Are there different responses for bots, mobile, cookies? Static, semi- dynamic, user specific?
141. Making the Business Case willkennard.com 4
142. It ’ s difficult to get SEOs to care about caching… willkennard.com
143. …so it ’ s naturally difficult to get businesses to care about it. willkennard.com
144. So how do we get folks to care? willkennard.com
145. Talk about AI willkennard.com
146. willkennard.com
147. willkennard.com Model
148. Caching is a part of technical strategy. willkennard.com
149. Performance metrics are not vanity metrics - we ’ ve known this for a long time. 100ms slower = up to 7% lower conversion
150. One reason Core Web Vitals mattered so much is that they turned performance into something teams could prioritise together. Same when making the case for caching work.
151. Strawberry ’ s legacy setup was an F5 BIG- IP solution, built on physical hardware managed by an IT partner which also handled platform configuration – including proxy and traffic-routing rules.
152. “Our entire application is based on JavaScript, so we can cache nearly everything. “Approximately 70% of the traffic to RightBlogger is currently cached via Cloudflare.
153. “Allow us to cache, pretty please.
154. “10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%
155. “If the site responds quickly for a while, the limit goes up.
156. “While not required, consider also setting the max-age field of the Cache-Control header to help crawlers determine when to recrawl the specific URL.
157. Following the principles of composable architecture & cache thinking - INP improves naturally.
158. If you fix or add invalidation it immediately has an impact. willkennard.com
159. 1. Fast = better for users & Google willkennard.com 2. Serve from cache = cheaper compute costs 3. Robust = cache helps mitigate unexpected traffic spikes Why is caching good?
160. Will Kennard Web & App Consultant linkedin.com/in/willkennard @willkennard Articles and other bits used in the slides: