Qué mostraron los logs
El 6 de octubre auditamos el sitio para buscadores. En 54 horas de logs del balanceador, 40 peticiones de página tardaron más de 5 segundos, y el 1% más lento tardó 9.96 segundos o más. No estaban repartidas: cada una era la primera página después de unos minutos sin visitas, y las siguientes respondían en milisegundos.
Ese patrón tiene nombre: arranque en frío. Cloud Run, donde corre el sitio, puede bajar un servicio a cero instancias cuando nadie lo usa, y levanta una de nuevo con la siguiente petición. Mientras duerme no se cobra nada. Paga el primer visitante, con su tiempo.
Por qué no lo vimos
Cada vez que abríamos el sitio era porque acabábamos de desplegarlo o estábamos trabajando en él, así que ya había una instancia corriendo. Solo los logs veían lo que veía un visitante que llegaba después de un rato sin visitas.
Por qué tardaba tanto
Un contenedor en frío no lo explicaba todo. El contenedor del servidor web estaba listo en 1.6 segundos y sus primeras respuestas tardaban de 6 a 7. La espera más larga estaba detrás:
- La API también bajaba a cero, y su lectura pública del catálogo tardaba de 11 a 21 segundos mientras despertaba.
- Cada página pública espera esa lectura para decidir si enlaza nuestra página de trabajo, que solo aparece cuando hay un producto publicado.
- Así que el primer visitante despertaba dos servicios, uno detrás del otro, y esperaba a los dos.
Una lectura pequeña en cada página había hecho que el servicio más lento marcara la velocidad de todo el sitio.
Qué cambiamos
- 01Una instancia mínima para la web y otra para la API (
minScale: "1"en cada servicio de Cloud Run). Ninguno vuelve a bajar a cero. - 02Un límite de 2 segundos para la lectura del catálogo. Si la API está lenta, la página sale sin el enlace a trabajo, el fallo se guarda unos segundos y la siguiente petición vuelve a intentarlo.
El segundo cambio importa aunque esté el primero. Una página no debería ser tan lenta como lo más lento que lee, y casi nada en las nuestras depende de esa lectura, así que ya no la espera más de 2 segundos.
Cuánto cuesta
Cloud Run cobra la instancia mínima a su tarifa en reposo: USD 0.0000025 por vCPU-segundo y por GiB-segundo en las regiones Tier 1, según la página de precios de Google consultada el 6 de octubre de 2026. Con 1 vCPU y 512 MiB son unos USD 9.70 al mes por servicio en un mes de 30 días, antes de la capa gratuita. Los dos servicios, unos USD 20.
Del otro lado: el primer visitante después de un rato sin visitas puede ser alguien que acaba de hacer clic en uno de nuestros artículos. Para el sitio de un estudio, USD 20 al mes para no hacer esperar a esa persona es una decisión fácil.
Qué cambió después
Durante el día siguiente (7 de octubre, de 00:43 a 23:58 UTC), los logs registraron 445 peticiones de página. La mediana tardó 0.12 segundos, el 1% más lento 1.36 segundos y la más lenta de todas 4.67. Ninguna pasó de 5.
Es un día de tráfico de un sitio nuevo, así que seguiremos mirando. Pero la primera página de 25 segundos ya no existe.
Lo que le diríamos a cualquiera en Cloud Run
- Bajar a cero sirve para herramientas internas y tareas en segundo plano. En un sitio público, o en una API que una página espera, le pasa el costo a tu primer visitante.
- Mide con los logs del balanceador, no con tu navegador: casi nunca eres el visitante que llega en frío.
- Ponle un tiempo máximo a cada lectura que una página espera, y decide qué muestra la página sin ella.
- Haz las cuentas antes de decidir. Aquí el arreglo costó unos USD 20 al mes.
Si un producto tuyo tiene el mismo síntoma, envíanos un brief. Una persona lo lee y te responde con preguntas o un primer plan.