Skip to content
P2Lab Cache

First cache hit

After installation and basic configuration, you should see your storefront responses being served from cache on the second hit. Here is how to verify it end-to-end.

Step 1 — Enable debug mode

Section titled “Step 1 — Enable debug mode”
  1. Open Settings → Speed Boost → Core → Settings.
  2. Toggle Debug Mode on.
  3. Save.

Debug mode adds two response headers to every storefront request handled by P2Lab Cache:

  • X-P2Lab-Cache-Status — HIT (served from cache), MISS (just generated and stored), or absent (route not cacheable / cache disabled)
  • X-P2Lab-Cache-Generation-Time — fractional seconds the request spent in the framework (low for HIT, full render time for MISS)

Step 2 — Make a fresh request

Section titled “Step 2 — Make a fresh request”

Pick any product detail URL on your storefront. Open it in a private/incognito window so no session cookies interfere, or hit it from curl:

Terminal window
curl -sI https://www.example.com/product-foo | grep -i p2lab

The first request should return:

X-P2Lab-Cache-Status: MISS
X-P2Lab-Cache-Generation-Time: 0.4123

Step 3 — Make a second request

Section titled “Step 3 — Make a second request”

Repeat the same URL within the configured TTL. You should now see:

X-P2Lab-Cache-Status: HIT
X-P2Lab-Cache-Generation-Time: 0.0021

A well-warmed HIT typically returns in low-millisecond territory regardless of how heavy the original page is.

Step 4 — Confirm the dashboard updates

Section titled “Step 4 — Confirm the dashboard updates”

Go to Settings → Speed Boost → Dashboard:

  • Total cached entries should be at least 1 and split across the types (Products, Categories, CMS, Listings, Buybox).
  • Total cached size shows what’s stored in your backend.
  • Average HIT time and Average generation time populate after a few requests.
  • Total space saved shows the gain from compression (zero if compression is disabled).

If you switch sales channels via the top header switcher, statistics filter to that channel.

Things that prevent a HIT

Section titled “Things that prevent a HIT”

A response is not cached when any of the following are true:

  • A customer session cookie indicates a logged-in user
  • A non-empty cart cookie is present
  • The route is disabled in Dashboard → Cacheable Routes
  • The response contains Cache-Control: no-store or private
  • Cookies the response itself sets disqualify it
  • A query parameter that is not in the Ignored Query Parameters list is present (every distinct value would create a distinct cache entry, so by default the request is bypassed)

If a route you expected to cache is always MISSing, see Troubleshooting for the full checklist.

Next: explore features

Section titled “Next: explore features”

Now that the cache is live, learn about the moving parts: