Store API Caching: Fast Headless Shops 2026

Headless shops are fast in 2026 - as long as the Store API keeps up. This is exactly where Shopware steps in from version 6.7: selected, non-mutating Store API endpoints are now cacheable and return real Cache-Control headers. This shifts a large share of the load away from the origin onto reverse proxy, CDN and the frontend. The lever is substantial: a mere 0.1 second faster response increased retail conversions by 8.4% and average order value by 9.2% (Deloitte) - and good Core Web Vitals lift conversion by 15 to 30% (web.dev). This guide shows how to avoid N+1 problems in Nuxt and composable frontends, set client caching correctly and use stale-while-revalidate in production - purely on the Store API caching layer, distinct from the architecture question.

Why Store API caching is the 2026 performance lever

In a headless setup the frontend - for example Nuxt or a composable UI - renders the interface and fetches data through the Store API. Unlike the classic storefront, which brings its own HTTP cache and ESI, Store API responses long ran uncached straight from the origin. Every page view, every category, every product block triggered a fresh PHP request including a database hit. As traffic grows, this becomes the bottleneck.

The numbers make the pressure clear: 53% of mobile users leave a page that takes longer than 3 seconds to load (Google/SOASTA), and conversion drops by around 7% for every additional second of load time (Conductor). Just 100 ms of extra time can cost around 1% of revenue (Amazon via Conductor). Making the Store API cacheable addresses exactly this latency - not in the frontend code, but at the most expensive point: server response time.

What changes concretely from Shopware 6.7

With the reworked caching system (introduced via the CACHE_REWORK feature flag and rolled out in production since the 6.7.5/6.7.6 releases), Shopware marks selected Store API routes as cacheable. A route is cacheable when it carries the route attribute '_httpCache' => true - meaning non-mutating endpoints that return no sensitive, customer-specific data (Shopware Docs).

Cacheable routes return the following Cache-Control header by default (Shopware Docs):

Cache-Control: public, max-age=0, s-maxage=1800,
               stale-while-revalidate=86400, stale-if-error=7200

# Non-cacheable route:
Cache-Control: no-cache, private

So that separate languages, currencies and contexts do not share the same cache entry, Shopware uses three dedicated headers instead of cookies, carried in the Vary header: sw-currency-id, sw-language-id and sw-context-hash (Shopware Docs). This way a DE/EUR visitor does not accidentally receive the EN/USD response from the cache.

GET instead of POST: the prerequisite for caching

HTTP caches usually store only GET responses. Many Store API calls previously used POST to pass complex filter and search criteria in the body. To make these requests cacheable, criteria can now be passed as a compressed, encoded string in the GET parameter _criteria - internally encoded as JSON -> gzip -> base64url (Shopware Docs).

// Cacheable GET request with encoded criteria
const criteria = {
  limit: 24,
  associations: { cover: {}, manufacturer: {} },
  filter: [{ type: 'equals', field: 'active', value: true }]
}

const encoded = encodeCriteria(criteria) // JSON -> gzip -> base64url
const res = await $fetch(
  `/store-api/product?_criteria=${encoded}`,
  { headers: { 'sw-access-key': key } }
)
// the response now carries a public Cache-Control header

Avoiding N+1 problems in Nuxt and composable frontends

The most common performance leak in headless frontends is not the missing cache but the N+1 pattern: a list component renders 40 products and fires its own detail call per product. One request becomes 41 - and even with caching that stays inefficient, because every call brings its own latency, connection and revalidation.

The solution lies in the Store API itself: instead of reloading per product, you request related data via associations and includes in a single call. This reduces not only the number of requests but also the transferred data volume - includes trims the response to the fields you actually need.

// Instead of 40 single calls: one batched, lean request
const { data } = await useAsyncData('listing', () =>
  storeApi('/store-api/product-listing/' + categoryId, {
    method: 'GET',
    query: { _criteria: encodeCriteria({
      associations: { cover: {}, options: {} },
      includes: {
        product: ['id', 'name', 'calculatedPrice', 'cover'],
        product_media: ['url']
      }
    }) }
  })
)
// useAsyncData deduplicates parallel calls automatically

• Batch instead of reload: Fetch related entities via associations in one call, not per product.
• Keep the payload lean: Use includes to request only the fields the UI actually renders - fewer bytes, faster parsing.
• Request deduplication:useAsyncData/useFetch in Nuxt bundle identical parallel calls into one request with a shared key.
• Pagination before prefetch: Load the visible page first, prefetch following pages only on demand or when idle.

Setting client caching correctly in the frontend

Server caching addresses response time, client caching addresses navigation. A composable frontend can keep already loaded Store API responses in memory and render them instantly from the normalized cache on repeat access - while revalidating in the background. Page changes feel instant. Studies quantify the effect: React Server Components and lean hydration reduce the JavaScript bundle by 40 to 60% (digitalapplied), directly improving INP and LCP.

The key is alignment with the server headers. Because max-age=0 is set, the browser revalidates - but a conditional request with ETag or If-None-Match ends in a lean 304 Not Modified instead of a full response when data is unchanged. That saves bandwidth without sacrificing freshness.

Using stale-while-revalidate in production

Stale-while-revalidate (SWR) is the most effective lever for perceived speed. The principle: once s-maxage expires, the cache still serves the stale response instantly and triggers a refresh in the background. Nobody waits for the origin - the next visitor already gets the fresh version. In practice, SWR headers cut origin hits by around 65% (digitalapplied).

Stale-while-revalidate decouples perceived speed from actual origin response time: the user sees content immediately, while the refresh happens invisibly in the background.

XICTRON development team

The Shopware defaults are deliberately generous: stale-while-revalidate=86400 (24 hours) and stale-if-error=7200 (2 hours) ensure that content is still served even with rare traffic or a brief origin outage. For fast-moving content - such as availability or promotional prices - tighter values can be configured per route via named caching policies that form Cache-Control per area (storefront, store_api) and route.

# A dedicated backend-for-frontend layer that bundles
# multiple Store API sources can set tighter values:
Cache-Control: public, s-maxage=60, stale-while-revalidate=600

Cache invalidation: fresh, without a bottleneck

A cache is only as good as its invalidation. When a price or stock level changes, the affected entry must expire selectively - not the entire cache. Shopware works here with cache tags that synchronize the object cache, the HTTP cache and - configured cleanly - the edge layer too. This keeps the hit rate high without stale data hanging around.

1. Invalidate by tag: On a product change, clear only the related cache tags, do not flush globally.
2. SWR as a buffer: Even right after expiry the cache serves instantly and fetches fresh data in the background - no load spike on the origin.
3. Monitor the hit rate: A falling hit rate is often the first signal of fragmented cache keys or overly tight TTLs - monitor performance regularly.
4. Check context headers: Incorrectly set Vary headers fragment the cache and reduce the hit rate drastically.

Measure what matters: headless performance audit

Caching only works when it is measured. A headless performance audit checks which Store API routes are actually cacheable, how high the real hit rate is, whether N+1 patterns lurk in the frontend and whether the Vary headers are set cleanly. The effect is measurable: edge and API caching typically reduce origin requests by 85 to 95% (digitalapplied) and TTFB by 60 to 80% (Cloudflare).

At the same time: a poorly planned headless rebuild can cost 20 to 40% of organic traffic (digitalapplied) when rendering, caching and SEO do not align. That is exactly why the caching layer and Core Web Vitals optimization belong in the same analysis. XICTRON examines both levels together and derives concrete, prioritized measures.

• Cacheable Store API routes identified and _httpCache set correctly
• GET with _criteria instead of POST for cacheable queries
• N+1 patterns in the Nuxt/composable frontend replaced by batching
• Vary headers (sw-currency-id, sw-language-id, sw-context-hash) correct
• Personalized endpoints strictly separated from public cache
• Tag-based invalidation and hit-rate monitoring established

Backend-for-frontend: bundling multiple sources cleanly

Many headless pages combine several Store API responses into one view: a product list, plus the navigation menu, cross-selling and a CMS block. If these calls are fired directly from the browser, latencies and connections add up. A backend-for-frontend (BFF) bundles them server-side into a single, prepared response - and can set its own tighter Cache-Control values, because it knows the freshness of the mixture itself.

The effect is twofold: first, the client avoids the waterfall of individual requests; second, the aggregated response itself becomes cacheable. A BFF with public, s-maxage=60, stale-while-revalidate=600 serves the composition fresh for 60 seconds and then as a stale response for up to ten minutes, while it is recomposed in the background. It is important that the BFF passes through the context headers (sw-language-id, sw-currency-id, sw-context-hash) and carries them in Vary, so the aggregation is not confused across language and currency boundaries.

In practice the BFF pays off especially for entry and category pages with a large static catalog share. Product detail pages benefit too, as long as availability and price do not need to be accurate to the second. Where they do, you combine a cacheable base state with a small, uncached live request for the volatile part.

Common caching mistakes and how to avoid them

Caching only works when it is thought through consistently. In headless projects we repeatedly encounter the same patterns that depress the hit rate or - worse - serve incorrect data. The good news: they can be avoided with clear rules.

There is also an organizational point: caching is not a one-time setup but an ongoing process. Assortments, prices and promotions change, the frontend evolves, new routes are added. That is why the hit rate belongs in monitoring and the caching strategy in every larger release plan. This way the performance gain is sustained instead of fading again after a few weeks.

Roll out step by step: activate caching without risk

Store API caching can be activated safely and step by step, because the reworked caching system sits behind a feature flag and the defaults are conservatively chosen. In practice a staged rollout is advisable: measure on a staging environment first, then start with well-cacheable catalog routes and observe the hit rate before further routes follow. This way you see the effect before it takes hold in production, and you can adjust the TTL values to your assortment.

The order is especially important: first eliminate the N+1 patterns in the frontend, then activate server caching. Anyone who caches first without untangling the frontend merely caches many small, inefficient responses - the gain stays below what is possible. Only the combination of batched, lean requests and cacheable responses unfolds the full effect. This order is also reflected in a headless performance audit that goes from the frontend code all the way to the cache configuration.

Finally, caching pays off on operating costs: fewer origin requests mean less CPU load, smaller servers and calmer load spikes during promotions. What starts as a pure performance measure thus also relieves the hosting - an effect that becomes clearer as traffic grows and justifies the investment in a clean caching layer beyond pure speed.