Caso Merida Casa de Campo: el escaparate que gestiona el dueño
Merida Casa de Campo
El punto de partida
Merida Casa de Campo es la tienda y taller oficial de Merida en Madrid, en la calle Sepúlveda, junto a la Casa de Campo. La lleva Pepe, que vende bicicletas y las repara —el taller está además certificado por Shimano— y que hasta hace nada tenía una web hecha en WordPress que no contaba ninguna de las dos cosas.
La primera fase la resolvimos con una landing de una página: presentable, rápida y con un formulario que funcionaba. Sirvió para salir del WordPress viejo y dejar de pagar un servidor que ya no hacía falta.
El problema
El negocio no es una landing. Pepe tiene bicicletas concretas, con su precio, su talla y su oferta, y las va rotando: entran unas, se venden otras. Y tres problemas de fondo:
El stock cambia cada semana. Cualquier solución que dependiera de llamarme para cambiar un precio estaba muerta antes de empezar.
Las fichas de las bicis llegan como llegan. Un Excel de Merida con una hoja por bici, en formatos distintos según el año del modelo, y las fotos igual: unas oficiales de estudio, otras hechas con el móvil en la tienda.
Y nadie busca «Merida Casa de Campo». Buscan «bicicletas de gravel Madrid». Si eso no es una página propia, no existe.
Qué hicimos
Una web estática con un panel detrás. Astro genera el sitio entero como HTML plano —no hay base de datos que consultar cuando alguien entra— y Payload le da a Pepe un panel para gestionar el escaparate. Al pulsar «Publicar cambios», la web se vuelve a generar en un minuto.
El escaparate lo lleva él, no yo
En el panel hay tres cosas y nada más: las bicis, el horario y un cartel de avisos. Ni una opción de sobra. Da de alta una bici en dos minutos, y cuando se vende la marca como vendida.
Una bici vendida no se borra. Desaparece del listado, pero su página se queda publicada: lleva tiempo en Google, sigue trayendo visitas, y quien llega ve un aviso claro y, justo debajo, el resto de bicis de esa categoría. Una unidad vendida sigue trabajando.
Un importador para el Excel que ya tenía
Las 29 bicis del catálogo no se metieron a mano. Escribí un importador que lee el Excel de Merida tal cual llega —una hoja por bici, con las fichas en tres formatos distintos y los precios en celdas que no siempre están en el mismo sitio— y las da de alta con sus fotos.
Lo interesante no es que lea el Excel, es lo que hace cuando el Excel no cuadra:
No pierde una bici en silencio. Dos hojas del mismo modelo no son un duplicado: hay dos Big Nine 200 en las que solo cambia el color. Si dos hojas acaban resolviendo a la misma bici, no importa ninguna de las dos y dice cuáles son. Sobrescribir a ciegas significa 29 hojas de entrada y 28 bicis de salida, y ese hueco no se ve hasta que un cliente pregunta por la que falta.
Lo que no entiende no lo adivina. Los rótulos de categoría venían de ocho formas distintas («Bici de montaña», «Montaña Doble Suspensión», «Carretera»…). Se normalizan las que se conocen; una desconocida deja la hoja fuera y lo dice en pantalla, en vez de colocarla en cualquier sitio.
Y se puede repetir. Reimportar actualiza precios y fichas sin duplicar nada, y sin pisar lo que Pepe haya escrito de su puño en el panel.
Las fotos se arreglan solas
Pepe sube la foto que tenga, del móvil o del catálogo, sin prepararla. El servidor la recorta, le quita el fondo que le sobra, la deja del mismo tamaño y con el mismo aire que todas las demás y genera las versiones ligeras.
Es lo que hace que veintinueve fotos de origen distinto se vean como un escaparate y no como un tablón de anuncios. Y le quita de encima la única tarea que habría hecho que dejara de actualizar la web a las dos semanas.
Cada categoría es una página de verdad
Las seis categorías no son un filtro de JavaScript: son direcciones propias —/bicicletas/gravel, /bicicletas/electricas— con su título y su texto escritos para quien busca eso en Madrid. Se pueden enlazar, mandar por WhatsApp y posicionar.
Y una categoría sin ninguna bici no existe: no se genera, no sale en el filtro y no entra en el sitemap. Hoy no hay urbanas ni infantiles, así que esas dos secciones no están. El día que entre la primera, aparecen solas. Nada de páginas vacías esperando contenido.
Sin cookies, sin banner
No hay Google Fonts, ni vídeos incrustados, ni scripts de terceros que dejen rastro. La tipografía va servida desde el propio dominio. Resultado: la web no necesita banner de cookies, porque no pone ninguna que haya que consentir.
El formulario está protegido con Turnstile de Cloudflare, que no usa cookies, y está montado para fallar cerrado: sin verificación válida no se guarda nada.
El detalle que más cuesta y nadie ve
De las 29 fotos del catálogo, 28 venían sobre blanco puro y una sobre un gris casi imperceptible. Diez puntos de diferencia sobre 255.
Recortando el fondo de esa foto como las demás, la bici quedaba dentro de un rectángulo gris al que después se le añadía el margen blanco del resto. En la rejilla se veía como un recuadro sucio alrededor de una sola bici, y ninguna de las 29 fotos era la culpable de nada: el fallo estaba en dar por hecho que el blanco es blanco.
Ahora el fondo se mide en las cuatro esquinas antes de tocar nada. Si es claro se recorta y, si no era blanco puro, se lleva a blanco corrigiendo cada canal por separado. Y si las esquinas no son claras, no se toca: la foto hecha en la tienda con el móvil conserva su fondo.
Las 29 acaban ocupando exactamente el mismo porcentaje del ancho de su hueco. Nadie lo va a notar, y esa es justo la idea.
La segunda parte: de 75 a 99 en móvil
Cuando el escaparate estuvo publicado, la web sacaba 99 en escritorio y 75 en móvil. El 75 tenía una causa aparentemente clara: la portada abría con una animación que revelaba la foto poco a poco, heredada de cuando la web era una sola página. La foto se descargaba en 7 milisegundos y tardaba 5,2 segundos en pintarse.
La parte interesante es que el primer arreglo, el obvio, no funcionó. Y por qué no funcionó es lo que hace que este trabajo valga la pena contarlo.
Un fundido desde transparente no arregla nada: lo esconde
Cambiar la animación lenta por un fundido corto parece la solución evidente. Se hizo, se midió, y la puntuación pasó de 75 a 76.
El motivo es una regla de Chrome que no es evidente: un elemento cuya primera pintura ocurre con opacidad cero no se registra como candidato a Largest Contentful Paint, y el navegador no lo reevalúa cuando después se vuelve visible.
Es decir: la animación original, que oscurecía la foto pero la mantenía opaca, sí la contaba, y la contaba tarde. El fundido desde transparente hizo que la foto desapareciera del recuento entero, y la métrica pasó a fijarse en un párrafo de 15 píxeles que había más abajo. El síntoma cambió de sitio; el problema seguía.
La única forma de arreglar esa métrica es que el elemento se pinte antes. Si estorba una animación de entrada, se quita. No se cambia por otra más corta.
Un tercero en el camino crítico se difiere, no se optimiza
Con la foto arreglada apareció lo que estaba detrás: Turnstile descargaba 605 kilobytes, el 70 % del peso de la portada, en cada visita, la usara alguien o no. Y el mapa incrustado traía otros 293 kilobytes de JavaScript.
Ninguno de los dos se optimizó: los dos se aplazaron. Turnstile se carga cuando el formulario entra en pantalla o cuando alguien toca el primer campo. El mapa se sustituyó por una imagen estática con el marcador, generada durante la compilación, y el mapa interactivo solo aparece si alguien lo pide.
Y aquí hay un beneficio que no es de velocidad. Antes, todo el que entraba contactaba con los servidores de Cloudflare y de OpenStreetMap sin haberlo pedido. Ahora solo lo hace quien va a escribir o quien quiere ver el mapa. Es más rápido, sí, pero sobre todo es coherente con lo que la web dice de sí misma unos párrafos más arriba: que no necesita banner de consentimiento.
Resultado en cifras
PageSpeed escritorio : 100 rendimiento · 100 accesibilidad · 100 buenas prácticas · 100 SEO
PageSpeed móvil: 99 rendimiento · 100 accesibilidad · 100 buenas prácticas · 100 SEO
Al publicar el escaparate: 75 rendimiento móvil · 96 accesibilidad
Tiempo de desarrollo: Cinco días: cuatro de construcción, uno de rendimiento
Páginas publicadas: 42
Catálogo: 29 bicicletas cargadas desde el Excel del proveedor con un comando
Terceros diferidos: 605 KB fuera de la carga inicial
Privacidad: Cero cookies, cero banners
Y lo que no se mide en cifras: Pepe cambia un precio, marca una bici como vendida o enciende el cartel de vacaciones sin llamar a nadie. Que es lo que decide si una web sigue viva dentro de un año.
Una nota sobre agentes de IA
PageSpeed añade una categoría nueva, navegación agéntica, que comprueba si un agente de IA puede recorrer el sitio. La web la pasa entera, en móvil y en escritorio.
No se hizo nada para conseguirlo, y ahí está lo interesante: se pasa por las mismas decisiones que ya están contadas más arriba. El sitio es HTML estático, así que no hay contenido que dependa de ejecutar JavaScript. Las categorías son direcciones reales y no un filtro. Los encabezados van en orden. Y una sección sin contenido no se publica, así que no hay enlaces que no lleven a ninguna parte.
Es una categoría en desarrollo y el propio validador avisa de que puede cambiar; por eso no va en la tabla junto a las otras cuatro. Pero el patrón de fondo se sostiene: lo que hace una web legible para un buscador y para un lector de pantalla la hace legible también para un agente. No son tres trabajos distintos.
Servicio relacionado
Desarrollo a medida con IA — Tu web o herramienta interna, hecha a medida, rápida desde el primer día y tuya de verdad.
Me he quedado sin palabras. Después de tantos años sin nada y el fiasco que fue la primera vez que lo intentamos, verlo así me parece mentira. Es justo lo que necesitábamos.