Arquitecturas web
Landings de Nicho y Alta Concurrencia
Construimos sitios para sectores donde el tráfico llega de golpe: una apertura de reservas, un anuncio, una jornada electoral. Salida estática servida desde el borde de la red, que cuesta lo mismo con mil visitas que con un millón.
EstáticoSin servidor que mantener · Centro Ocular Dr. Rincón
Si esto te suena
- Tu sitio se cayó justo el día del lanzamiento, que era el único día que importaba.
- Pagas un servidor dimensionado para el pico y ocioso el resto del año.
- La campaña dura tres semanas y montar la web tarda seis.
- Cada pico de tráfico obliga a que alguien vigile el servidor en directo.
¿Por qué el pico es un problema distinto del volumen?
Un sitio que recibe cien mil visitas repartidas en el mes no tiene ningún problema técnico. Ese mismo sitio, con las mismas cien mil visitas concentradas en la hora siguiente a un anuncio, se cae. La diferencia no es el total, es la forma de la curva.
En hotelería es la apertura de una temporada. En eventos, el minuto en que salen las entradas. En una campaña, la noche de la jornada. Son sectores donde el día que el sitio importa es exactamente el día que más carga soporta.
¿Qué se hace distinto?
La página se genera una sola vez, durante el build, y se sirve como HTML desde el nodo de red más cercano a cada visitante. No hay servidor de aplicación que dimensionar, ni base de datos que se bloquee, ni autoescalado que llegue tarde. Lo dinámico —un formulario, una consulta de disponibilidad— se aísla en una función propia, para que su fallo no arrastre al resto.
Y antes de lanzar se prueba: una prueba de carga contra el pico previsto, con el resultado por escrito. Preferimos entregar una cifra medida a una promesa.
Este mismo sitio es la demostración
Einscube.com está construido exactamente así. Puedes abrir las herramientas de desarrollo, mirar la pestaña de red y comprobar cuánto pesa y cuánto tarda. Es más útil que cualquier párrafo que podamos escribir aquí.
¿Qué entregamos?
- Sitio en Astro con salida estática y cero JavaScript por defecto.
- Servido desde el borde de Cloudflare, sin servidor de aplicación que saturar.
- Prueba de carga documentada antes del lanzamiento, con la cifra que aguanta por escrito.
- Sistema de componentes con Tailwind, para publicar variantes de campaña en horas.
- SEO técnico completo de serie - metadatos por página, datos estructurados y sitemap.
- Presupuestos de rendimiento en integración continua que rompen el build si el sitio se degrada.
¿Cómo trabajamos?
- 01
Descubrimiento
1 semanaObjetivo de la campaña, pico esperado, contenido y línea base medida. Participan quien decide y quien mantiene el contenido.
- 02
Diseño y construcción
3 a 5 semanasDirección visual y plantillas revisadas en navegador, no sobre imágenes estáticas. Control de calidad de rendimiento y accesibilidad en paralelo.
- 03
Prueba de carga y lanzamiento
1 semanaPrueba de carga contra el pico previsto, redirecciones, analítica y monitoreo durante la ventana crítica.
Inversión
Presupuesto a medida
Propuesta con cifra cerrada en 3–5 días hábiles
El alcance define el precio. Cuéntanos el proyecto: en menos de 24 horas hábiles te decimos si encaja, y la propuesta —qué entra, qué no y cuánto cuesta— llega en tres a cinco días hábiles.
El rango depende del número de plantillas, del volumen de contenido y de si hay CMS. La cifra sale de la reunión de alcance, no de un catálogo.
Prueba
Preguntas frecuentes
¿Qué significa aquí alta concurrencia?
Que el tráfico no llega repartido sino concentrado: una apertura de reservas, un anuncio en televisión, una jornada electoral. El problema no es el volumen mensual, es que la mitad de ese volumen puede entrar en diez minutos.
¿Por qué un sitio estático aguanta mejor un pico?
Porque no hay nada que calcular cuando alguien entra. La página ya está construida y se sirve desde el nodo de Cloudflare más cercano al visitante. No hay base de datos que bloquear ni servidor de aplicación que saturar, así que el coste de la visita número un millón es prácticamente el mismo que el de la primera.
¿Y si necesito un formulario o una reserva?
Eso sí es dinámico, y va aparte: una función en el borde que atiende solo esa petición. El resto del sitio sigue siendo estático, de modo que un fallo en el formulario nunca tumba la página.
¿Mi equipo podrá publicar cambios durante la campaña?
Sí. Con CMS headless si lo incluimos, o desde archivos Markdown en el repositorio con una interfaz web. En los dos casos el sitio se reconstruye y publica solo.
¿Cuánto tarda un proyecto típico?
Entre cinco y siete semanas. La ruta crítica casi nunca es el código - es la aprobación del contenido. Si el copy está listo, el proyecto va más rápido.