Caché de contenido

Qué hace

Cachea respuestas estáticas (CSS, JS, imágenes, tipografías, etc.) en el borde, según patrones definidos por ruta. La primera solicitud va al servidor de origen; las siguientes se sirven directamente desde Tero Services con latencia mínima y menos carga sobre tu backend.

Cuándo usarlo

Sitios con archivos estáticos que cambian poco (versionados por hash en la URL, publicaciones periódicas).
WordPress / Laravel / Symfony con /wp-content/uploads/*, /build/*, /storage/*.
API cuyas respuestas son cacheables por tiempo de vida corto.

Cómo se configura

Se le indica al equipo:

Patrones a cachear. Ejemplos: *.css, *.js, *.png, *.jpg, *.woff2, /static/*, /build/*.
Tiempo de vida deseado (si difiere del valor por defecto).

El proxy respeta los encabezados Cache-Control / Expires que devuelva el servidor de origen. Si el servidor marca no-store o private, el proxy no cachea esa respuesta aunque el patrón coincida.

Cómo invalidar

Versionado por hash en la URL (recomendado): app.abc123.js → cuando cambia el contenido, cambia la URL y la entrada vieja queda huérfana hasta expirar.
Tiempo de vida corto para contenido que cambia seguido.
Limpieza manual: solicitá al equipo el vaciado de una entrada o de todo el dominio.

Limitaciones

La caché vive en el borde del servicio; no es una red de distribución global con presencia en múltiples regiones.
Solo cachea respuestas 200 OK. Códigos como 301, 404, 5xx no se cachean.
Tamaño máximo por entrada y total por dominio: definidos por plan.
No hay interfaz pública de limpieza aún.

Preguntas frecuentes

¿Cómo verifico que mi respuesta vino de la caché? Buscá el encabezado X-Tero-Cache: HIT / MISS en la respuesta (si lo expone tu plan).
¿Cachea respuestas dinámicas (HTML de WordPress)? Por defecto no; los HTML suelen tener Cache-Control: no-cache. Si querés cachear HTML de páginas estáticas, hay que coordinarlo y enviar encabezados explícitos desde el servidor de origen.