Performance and Usability Explained

Speed and usability are not cosmetic; they affect trust, conversion, and operational cost.

English Svenska Español

Audience: Site owner / marketing / operations

Back to docs

What matters for non-technical teams

Slow pages lose user attention and confidence. Unstable pages increase support load and checkout dropoff.

A predictable user journey usually increases completed purchases and reduces manual support requests.

What this project already does

Measures and stores runtime and web-vitals context from connected sites.

Surfaces recommendations tied to concrete impact and action language.

What teams can action weekly

Review failing checks, pick top two actions, re-run heartbeat, and compare trend on tenant/peer pages.

Track non-200 incidents and fallback paths to reduce hidden reliability regressions.

Default cache times and rules (as of March 30, 2026)

GraphQL edge cache defaults to 60s fresh + 120s stale-while-revalidate (GRAPHQL_EDGE_CACHE_TTL_SECONDS, GRAPHQL_EDGE_CACHE_STALE_SECONDS).

Menu snapshot cache is 5 minutes, menu URI existence cache is 5 minutes, and sitemap path cache is 10 minutes (MENU_SNAPSHOT_TTL_MS, MENU_URI_CHECK_TTL_MS, MENU_SITEMAP_TTL_MS).

Storefront GraphQL capability probe runs every 15 minutes (STOREFRONT_GRAPHQL_PROBE_TTL_MS). /shop uses ISR with revalidate 300 seconds, while many content GraphQL calls use 1800 seconds revalidation.

Refresh cache after schema/menu/taxonomy changes, after deployment of routing logic, or when non-200/fallback rates spike.

Impact of refresh now vs waiting for TTL

Refresh now: users see corrected content and routes immediately, and diagnostics align faster after a change.

Refresh now also has a cost: temporary higher origin pressure because more cache misses hit WordPress/GraphQL at once.

Wait for TTL: lower immediate backend pressure, but users can keep seeing stale menus, stale content, or mixed old/new behavior until timers expire.

Practical rule: refresh immediately after structural changes; let TTL pass naturally for small text-only edits.

Use cache controls and purge actions after content model changes.
Validate menus/routes before publishing to avoid dead-end navigation.
Keep diagnostics visible in planning so quality work is not postponed.
Use Server-Timing response headers (app_ms, wp_ms, menu_ms) to locate latency before changing settings.

Cache refresh command (WP-CLI)

wp cache flush && wp transient delete --all

Run on the WordPress host after content-model, menu, or schema changes.

Mermaid diagram

flowchart LR U[User request] --> SF[StoreFront worker] SF --> MC[Menu snapshot cache 5m] SF --> GC[GraphQL edge cache 60s + SWR 120s] GC --> WP[WordPress GraphQL] U --> WV[Browser web vitals beacon] WV --> HB[Heartbeat and diagnostics payload] HB --> RP[RAGBAZ tenant and peer reports] RP --> ACT[Choose fix and cache refresh action] ACT --> NX[Next requests validate improved metrics]