Qué importa para equipos no técnicos
Páginas lentas pierden atención y confianza. Páginas inestables suben carga de soporte y abandono de checkout.
Un recorrido de usuario predecible suele aumentar compras completadas y reducir soporte manual.
Rendimiento y Usabilidad Explicados
Velocidad y usabilidad no son cosmética; afectan confianza, conversión y costo operativo.
Audiencia: Propietario / marketing / operaciones
Qué hace este proyecto hoy
Mide y guarda contexto de runtime y web-vitals de sitios conectados.
Muestra recomendaciones unidas a impacto concreto y acciones claras.
Qué puede ejecutar el equipo cada semana
Revisar checks fallidos, elegir dos acciones principales, reenviar heartbeat y comparar tendencia en páginas tenant/peer.
Seguir incidentes non-200 y rutas fallback para reducir regresiones ocultas de fiabilidad.
Tiempos y reglas de caché por defecto (30 de marzo de 2026)
La caché edge de GraphQL usa 60s en fresco + 120s stale-while-revalidate por defecto (GRAPHQL_EDGE_CACHE_TTL_SECONDS, GRAPHQL_EDGE_CACHE_STALE_SECONDS).
La caché snapshot de menú es 5 minutos, la verificación de existencia de URI de menú es 5 minutos y la caché de sitemap paths es 10 minutos (MENU_SNAPSHOT_TTL_MS, MENU_URI_CHECK_TTL_MS, MENU_SITEMAP_TTL_MS).
El probe de capacidad GraphQL storefront se ejecuta cada 15 minutos (STOREFRONT_GRAPHQL_PROBE_TTL_MS). /shop usa ISR con revalidate 300 segundos y muchas consultas de contenido usan 1800 segundos.
Refresca caché tras cambios de schema/menú/taxonomía, tras despliegues de lógica de rutas, o cuando suben non-200/fallbacks.
Impacto de refrescar ahora vs esperar el TTL
Refrescar ahora: usuarios ven contenido y rutas corregidas de inmediato, y los diagnósticos se alinean más rápido tras un cambio.
También tiene costo: presión temporal mayor en origen porque más misses de caché golpean WordPress/GraphQL al mismo tiempo.
Esperar TTL: menor presión inmediata en backend, pero usuarios pueden seguir viendo menús stale, contenido stale o comportamiento mixto viejo/nuevo hasta que expiren los tiempos.
Regla práctica: refrescar inmediatamente después de cambios estructurales; dejar pasar TTL para ajustes menores de texto.
- Usa controles de caché y purge tras cambios del modelo de contenido.
- Valida menús/rutas antes de publicar para evitar navegación sin salida.
- Mantener diagnósticos visibles en planificación evita postergar calidad.
- Usa Server-Timing (app_ms, wp_ms, menu_ms) para ubicar la latencia antes de cambiar configuración.
Comando de refresco de caché (WP-CLI)
wp cache flush && wp transient delete --allEjecuta en el host WordPress tras cambios en modelo de contenido, menú o schema.
Diagrama Mermaid
flowchart LR
U[Request del usuario] --> SF[StoreFront worker]
SF --> MC[Cache snapshot de menu 5m]
SF --> GC[Cache edge GraphQL 60s + SWR 120s]
GC --> WP[WordPress GraphQL]
U --> WV[Beacon web vitals en navegador]
WV --> HB[Heartbeat y payload de diagnostico]
HB --> RP[Reportes tenant y peer en RAGBAZ]
RP --> ACT[Elegir mejora y accion de refresco de cache]
ACT --> NX[Siguientes requests validan mejora]