fix(vtex): cache bounded legacy map= PLP shapes, keep deep facet crawl uncached

Draft
PE
3d ago
+91-5

Why

#1570 made the legacy PLP cacheKey return null for any URL containing map=. deco treats a null key as no-store, so every legacy ?map= page bypasses the CDN, including the clean ones like brand links (/<brand>?map=b) and category+brand pages (/a/b?map=c,b).

The reason for #1570 (thanks @guitavano) was that bots crawl endless filter combinations. Each one is a one-off URL, and caching them pushed hot entries out of the loader cache. This PR keeps that protection and only re-enables caching for shapes with bounded cardinality.

Data (miess, Cloudflare, last 24h, GET ?map= pages)

ShapeRequestsUnique URIsReuse
≥3 map parts, spec filters, priceFrom, ft, or map not matching the path44,38542,824~1.0
≤2 parts, only c/b, matching the path3,1401,477~2.1
any shape with q/ft search param2,3622,307~1.0

So caching the deep combinations buys nothing and only churns the cache. The bounded shapes repeat.

Change

  • map= URLs get a key only when the map has ≤2 parts, every part is c or b, and the part count matches the path segment count. Everything else still returns null, same as today.
  • Adds fmap and PS to the key, only when present. The loader reads both from the URL: fmap drives the facets query and PS the page size. Keys for URLs without them are byte-identical to before.
  • Search terms not in cachedSearchTerms still return null.

Tests

productListingPage_test.ts:

  • /brand?map=b and /cat/brand?map=c,b get keys, and different maps get different keys
  • deep (c,c,c), specificationFilter_*, priceFrom, ft, and mismatched map/path stay null
  • fmap/PS vary the key
  • keys for URLs without map/fmap/PS exactly match the current output
  • uncached search terms stay null

deno fmt --check, deno lint and deno check vtex/mod.ts are clean.

Not done yet

Draft until it's validated on a miess-01 preview pinned to this commit, compared against production on the same URLs.

The deep facet crawl (44k req/day, ~1.9 GB) stays uncached. Reducing that is a robots.txt / bot-rule decision, not a cache one.