Every remote catalog request crosses a network boundary. Without caching, repeated page views can ask the source store for the same filtered products again and again. PI Remote WooCommerce Product Display WordPress Plugin uses WordPress transients on both publishing and display workflows to reduce avoidable requests.
Two layers of response caching
The publishing store can cache product-feed responses generated by WooCommerce. The display website can separately cache the remote response it receives.
Publisher caching reduces repeated WooCommerce queries for identical API parameters. Display caching reduces network traffic and helps the partner page render consistently even when many visitors request the same catalog.
Cache keys vary with request parameters. A category page, sale-only grid and search-based list create different cached responses because they do not represent the same product query.
Choose a sensible cache lifetime
The cache lifetime, or TTL, is entered in seconds. The plugin accepts values from 60 seconds to 86,400 seconds.
Useful starting points include:
- 300 seconds for frequently changing inventory or active promotions.
- 900 seconds for typical partner catalogs.
- 3,600 seconds for relatively stable collections.
- 86,400 seconds only when product data changes infrequently and delayed updates are acceptable.
The correct value depends on price volatility, stock movement, source-server capacity and how quickly a partner page must reflect a change. Caching is a freshness tradeoff, not simply a speed switch.
Configure publisher caching
On a Publish or Publish + Display site, open Publish Products. Enable response caching and set the publisher TTL. This screen also controls the maximum number of products returned per request, up to 100.
Shorter responses are generally faster to generate and transfer. Use pagination instead of requesting an unnecessarily large catalog on every page load.
Configure display caching
On a Display or combined site, open Settings. Enable local response caching and choose the display TTL. This local cache is what the front-end catalog reads before making another remote request.
If the publisher and display layers use different TTLs, the effective freshness can be influenced by both. For a time-sensitive sale, use appropriately short lifetimes on both sites and clear existing entries when the campaign begins.
Use the Caching tab
The dedicated Caching tab lists plugin-owned transient requests. Its summary separates:
- Total cached requests.
- Publish API entries.
- Display request entries.
Each row shows the cache type, transient key, expiry and active or expired status. Administrators can delete a single request, clear all display cache, clear all publish cache or clear every plugin cache entry.
Targeted deletion is useful when only one filtered catalog needs refreshing. Group clearing is appropriate after a broad product import, pricing update or connection change.
When to clear the cache
Clear relevant entries after:
- Regenerating or replacing a source API key.
- Correcting a remote Source API URL.
- A major price or stock import.
- Changing an important campaign filter.
- Testing whether an old response is hiding a resolved connection issue.
Routine clearing is not necessary. Expired WordPress transients naturally stop being used, and excessive clearing removes the performance benefit.
Troubleshoot with a controlled sequence
If products appear outdated, first identify whether the source store itself shows the new value. Then clear publisher cache, followed by display cache. Test the remote source and reload the landing page.
If the request fails completely, caching may preserve an older successful result until expiry. Use the Caching tab during diagnosis, but also verify the domain-bound key, endpoint, allowed hostname, HTTPS and licence connection allowance.
Performance beyond caching
Choose a reasonable per_page value, optimize product images at the source, avoid displaying metadata that the design does not use and keep WordPress hosting healthy on both sites. Caching works best as part of a disciplined catalog setup.
For the complete remote product workflow—including cache inspection and selective deletion—visit the PI Remote WooCommerce Product Display product page.
