Cómo pasamos la web de Fogón Criollo a rendimiento real

Fogón Criollo llegó sin nada. Sin marca, sin web, sin una sola reseña en Google. Seis meses después factura en seis cifras y acumula más de 200 reseñas a 4,9 estrellas. Esa parte de la historia ya la contamos en el caso completo del proyecto.

Lo que no contamos ahí es lo que pasa por debajo. Porque una web bonita que tarda cinco segundos en cargar no vende. Vende una que responde antes de que el cliente termine de decidir si tiene hambre.

El problema no era el diseño

Cuando un restaurante empieza a moverse rápido, la web recibe una presión distinta a la de un portafolio o una landing estática. Gente entrando desde Instagram con el móvil en 4G, mirando la carta a las nueve de la noche con hambre real, esperando que las fotos carguen antes de decidir si van o piden a domicilio. No hay tiempo de espera aceptable cuando lo que compite contigo es Glovo abierto en la pestaña de al lado.

Ya hablamos de lo que cuesta cada segundo de espera en una web lenta. Con Fogón Criollo no era teoría de blog. Era la diferencia entre una mesa reservada y alguien que cierra la pestaña y abre la del competidor de enfrente. Un restaurante nuevo, sin historial, sin boca a boca todavía acumulado, no se puede permitir perder a nadie por un problema que no tiene nada que ver con la comida.

Y hay un matiz que se olvida fácil: la mayoría de ese tráfico no llega con wifi de fibra en casa. Llega desde la calle, con datos móviles, muchas veces con cobertura mediocre porque el restaurante está en una zona con más gente que antenas. Diseñar pensando en “mi conexión de la oficina” es diseñar para un escenario que casi ningún cliente real va a vivir. Hay que asumir el peor caso — 4G lento, un móvil de gama media, una sola mano libre porque con la otra sostiene una bolsa de la compra — porque ese es el cliente real, no el que prueba la web desde el ordenador de la agencia con fibra simétrica.

No era solo la web — era todo el sistema alrededor

Una carta que carga rápido no sirve de mucho si detrás hay un proceso lento gestionando lo que llega. Fogón Criollo no solo necesitaba una web veloz — necesitaba que el pedido llegara a cocina sin fricción, que el inventario se actualizara sin depender de que alguien lo revisara a mano, que las fotos del menú se pudieran cambiar sin abrir un ticket con un desarrollador cada vez que cambia un plato. Parte de por qué el rendimiento se pudo mantener en el tiempo es que el sistema completo — no solo el frontend — se construyó para que un equipo sin conocimientos técnicos pudiera operarlo el día a día sin romper nada.

Lo que cambió

Nada de plugins acumulados ni constructores visuales cargando scripts que nadie usa. La web se construyó con Next.js y Payload CMS, pensada para el móvil primero — no como un “también funciona en móvil” añadido al final, sino como el punto de partida real, porque ahí es donde vive el tráfico de un restaurante.

Las imágenes van en WebP en vez del JPG de siempre — el mismo criterio que aplicamos en cualquier proyecto que pasa por Reveled, no una excepción para este cliente. Cuando el menú tiene cuarenta fotos de platos y cada una pesa la mitad, la diferencia se nota antes de que el usuario piense en ello: simplemente la carta ya está ahí cuando va a mirarla.

La carta y el checkout — porque Fogón Criollo también vende a domicilio y tienda propia, con Stripe integrado — se sirven como páginas estáticas donde se puede, generadas de antemano en vez de calculadas en cada visita. Eso significa que cuando alguien entra a las nueve de la noche desde el móvil, no hay un servidor procesando nada mientras el cliente espera: el HTML ya está listo, se muestra, y solo entonces se activa lo que necesita interacción real (el carrito, el formulario de pago). Es la misma lógica que usamos en Astro para proyectos editoriales, aplicada aquí con las herramientas que un ecommerce real necesita.

También importa el orden en el que carga cada cosa, no solo el peso total. La foto del primer plato que ve el usuario al entrar se carga con prioridad; las cuarenta fotos del resto de la carta esperan su turno hasta que el usuario baja hasta ahí (lazy loading). Es una diferencia sutil que no se nota en una auditoría rápida, pero sí se nota en el móvil real de alguien con cobertura mediocre un viernes por la noche: lo primero que necesita ver aparece primero, no compite por ancho de banda con veinte fotos que todavía no está mirando.

Google documentó con datos de 37 marcas y más de 30 millones de sesiones que una mejora de solo 0,1 segundos en velocidad móvil puede traducirse en hasta un 10% más de conversiones en sectores como retail y viajes. No es una cifra decorativa ni un caso aislado: Rakuten 24 midió un 53% más de ingresos por visitante después de mejorar su LCP (el tiempo que tarda en aparecer el contenido principal de la página), y Vodafone Italia consiguió un 8% más de ventas mejorando esa misma métrica en un 31%. La velocidad no es un detalle técnico que se arregla al final. Es una palanca de negocio que se decide al principio.

Por qué esto importa más en un restaurante que en casi cualquier otro negocio

Una tienda de ropa online puede permitirse que alguien vuelva mañana a comprar el mismo jersey. Un restaurante no. El hambre no espera al día siguiente, y la decisión de “¿dónde pido esta noche?” se toma en minutos, muchas veces en la misma pantalla donde antes estaba mirando Instagram. Si la carta tarda en cargar, esa persona no piensa “vuelvo luego” — piensa en la otra opción que ya tiene abierta en otra pestaña.

Esto se nota especialmente en Core Web Vitals, las tres métricas que Google usa para medir experiencia real de usuario: LCP (qué tan rápido aparece lo principal de la página), INP (qué tan rápido responde cuando tocas algo) y CLS (si los elementos saltan mientras cargan, como ese botón de “Añadir al carrito” que se mueve justo cuando ibas a pulsarlo). Un restaurante que vende también a domicilio depende de que esas tres métricas estén bien no por presumir en una auditoría, sino porque cada una de ellas es un punto exacto donde un cliente real puede decidir irse.

Construirlo bien no es el final — hay que vigilarlo

Una web rápida el día del lanzamiento no se queda rápida sola. Se añaden páginas, se suben más fotos, se integran más herramientas, y cada cosa nueva le resta algo a la velocidad si nadie está mirando. La mayoría de las agencias entregan la web y se van; el rendimiento se revisa de nuevo solo cuando el cliente ya nota que algo va mal.

En Reveled preferimos enterarnos antes que el cliente. Por eso monitorizamos el rendimiento real de los proyectos que llevamos — no una auditoría puntual el día de la entrega, sino un seguimiento continuo de cómo se comporta la web con tráfico real, con avisos automáticos si algo empieza a degradarse. Fogón Criollo es uno de los proyectos donde ya aplicamos esto. No es una promesa de marketing — es la misma lógica de “constrúyelo pensando en el peor escenario” aplicada también a lo que pasa después del lanzamiento.

El resultado no se mide en Lighthouse

Se mide en mesas ocupadas y en pedidos que llegan completos. Fogón Criollo no necesitaba un 100 en PageSpeed para presumir en una reunión de agencia. Necesitaba que un cliente con hambre y poca paciencia no se fuera antes de ver el menú, y que el que decidiera pedir a domicilio pudiera terminar el proceso sin que la web se lo pusiera difícil.

Como decimos en Venezuela, “el que no arriesga no gana” — pero aquí no hubo que arriesgar nada raro. Solo construir la web como se construye un negocio que va a crecer rápido: pensando en el peor escenario de tráfico desde el primer día, no arreglándolo después de que ya duela. Cuando un negocio pasa de cero a seis cifras en 6 meses, no hay margen para descubrir en pleno crecimiento que la base técnica no aguanta el ritmo.

Si tu web tarda más de lo que tarda un cliente en decidir si tiene hambre, probablemente ya lo sabes, aunque nadie te lo haya dicho con estos números delante. No hace falta un diagnóstico de dos horas para intuirlo — basta con abrirla en el móvil, en la calle, con datos, y contar cuánto tarda en aparecer el primer plato.

Miramos los números contigo y te decimos qué parte se puede arreglar sin rehacer nada, y qué parte necesita una base distinta desde el principio. A veces la respuesta es un ajuste de una tarde. A veces es admitir que la base sobre la que se construyó ya no da más de sí, y que seguir parcheándola cuesta más a medio plazo que empezar de nuevo con los cimientos correctos.