Event cards can multiply API demand quickly. A homepage, city page, performer profile, venue directory and sidebar widget may all request related SeatGeek data, while traffic spikes can cause many visitors to arrive at once. PI Events for SeatGeek treats caching as an operational feature rather than a simple on/off checkbox.
Review the plugin’s SeatGeek API caching for WordPress and licence options.
Safe caching is active for every licence
Standard, Business and Developer all cache supported SeatGeek data and rendered imported listings using safe fixed defaults. Live listings and event details default to one hour, entity event collections to a shorter interval, and relatively stable taxonomy data to a longer interval. The exact policy is grouped by content type so unrelated requests do not overwrite one another.
Storage uses WordPress transients and can benefit from a persistent object cache such as Redis or Memcached when the hosting environment provides one.
Stampede protection reduces duplicate refreshes
A cache expiry during a popular event announcement can otherwise trigger many simultaneous upstream requests. Query-specific refresh locks allow one request to refresh the data while other visitors avoid duplicating the same work. This protects both the WordPress server and the SeatGeek API allowance.
Stale fallback improves resilience
If SeatGeek times out or returns a temporary error, stale-on-error delivery can use the last successful cached response instead of replacing a useful event section with an error. Short negative caching also prevents a failed lookup from being retried continuously. Together, these behaviors reduce load and make temporary upstream problems less visible to visitors.
Business cache controls
Business and Developer can set custom lifetimes for live listings, event details, directories, profiles, entity events, taxonomies, imported listing HTML and REST responses. This supports a practical balance: short lifetimes for rapidly changing inventory, longer lifetimes for stable profiles, and policies adapted to the site’s traffic pattern.
Selected landing pages can be pre-warmed on a schedule so their data is already cached before the next visitor arrives. The plugin supports warming up to 20 selected pages every 15 minutes. A metrics dashboard reports hits and misses, while grouped flush controls clear a specific content family or the entire plugin cache.
Developer observability and hooks
Developer adds pisg_cache_policy and pisg_cache_flushed hooks for custom integration logic. REST responses expose an X-Cache header, making it easier to confirm whether an application request was served from cache. API-key authentication and per-client rate limiting complement caching when event data is consumed outside the WordPress frontend.
A sensible caching strategy
- Start with the safe defaults and measure before shortening lifetimes.
- Warm only important landing pages instead of every URL.
- Use a persistent object cache for high-traffic installations when available.
- Keep stale fallback enabled so a temporary API issue does not empty the frontend.
- Flush a content group only when its data truly needs immediate refresh.
Understand the different cache groups
Live listing queries can vary by city, performer, venue, category, date and pagination, so their keys must reflect the full request. Event details are cached separately from collections. Performer and venue profiles are distinct from their upcoming-event feeds because the profile may change slowly while the event schedule changes more often. Taxonomy data is comparatively stable and can usually tolerate a longer lifetime.
Imported event cards do not require SeatGeek on every render, but caching their generated HTML still reduces repeated WordPress queries and template work. Developer REST responses form another group so an application request does not collide with a frontend fragment that happens to use similar filters.
How landing-page warming works
Business can select up to 20 important pages for scheduled warming every 15 minutes. Warming requests the page before a visitor does, allowing its event data and output to enter cache proactively. Candidates might include the homepage, a major city calendar, the most popular venue and a seasonal events page.
Do not warm every possible archive. Prioritize pages that receive regular traffic or must respond quickly during promotions. A narrow warming list reduces unnecessary background work and keeps the cache focused on real visitor demand.
Reading cache metrics
A high hit ratio generally means visitors are reusing cached work, but the number should be interpreted alongside freshness requirements. A low ratio may indicate highly varied queries, very short lifetimes, frequent manual flushing or a cache that is too small for the site’s request diversity. Metrics are a diagnostic starting point, not a target to maximize at any cost.
When testing, open the same listing more than once, review hits and misses, and confirm that a forced cache clear produces the expected refresh. Developer integrations can inspect X-Cache on REST responses to make the same behavior visible outside the admin dashboard.
Caching does not replace upstream discipline
Keep page filters purposeful, avoid embedding many near-duplicate feeds on one URL and do not set every lifetime to the shortest permitted value. Caching works best when the site architecture avoids unnecessary request diversity. Rate limiting on Developer endpoints adds another layer for external clients, while API-key authentication identifies approved consumers.
After changing display settings, imports or entity data, clear only the affected group when possible. A full flush removes useful cached responses and can create an avoidable burst of regeneration.
Standard receives the essential protection. Business is the right fit when the site needs tuning, warming and metrics. Developer is intended for teams that also need cache-aware APIs and extensibility. Each licence covers one verified domain.
Build a faster, more resilient SeatGeek event site →
