Construyendo un sitio de lanzamiento de libro que realmente respeta a sus usuarios

Dorian Des Lauriers está escribiendo un libro sobre su viaje desde la vida corporativa hasta el despertar espiritual en la selva costarricense. Cuando me pidió construir el sitio de lanzamiento, tuve un requisito: necesitaba funcionar perfectamente para todos. No “suficientemente bien para la mayoría”. Todos.

Eso significaba usuarios de teclado, usuarios de lectores de pantalla, personas con conexiones lentas, hablantes de español y cualquiera que prefiera el modo oscuro. Sin compromisos.

Terminamos con puntuaciones de 99/100/100/100 en Lighthouse—99 en Rendimiento, 100s perfectos en Accesibilidad, Mejores prácticas y SEO. Esto es lo que eso realmente significa.

Por qué este proyecto importaba

Esta no es solo otra página de aterrizaje. El libro de Dorian trata sobre transformación espiritual: sobre sanar traumas, encontrar propósito y despertar a la vida. El sitio web no podía solo verse bien. Necesitaba encarnar esos mismos valores: inclusivo, accesible, acogedor.

Si alguien no puede usar tu sitio porque navega con un teclado, o porque está usando un lector de pantalla, o porque no te molestaste en traducirlo a su idioma—no estás siendo inclusivo. Simplemente estás dejando gente afuera.

El diseño: Claro, oscuro y todo lo que está en medio

El sitio necesitaba sentirse fundamentado y espiritual sin ser cursi. Colores cálidos. Tipografía limpia. Y un fondo animado del que estoy genuinamente orgulloso.

Construí “rayos de luz” animados que se mueven lentamente por la página—como la luz del sol atravesando los árboles. Dos capas a diferentes velocidades, suficientemente sutiles que podrías no notarlas conscientemente, pero crean esta sensación de movimiento y calma.

El desafío fue hacer que funcionara tanto en modo claro como oscuro sin sentirse discordante. En modo claro, beiges cálidos y dorados. En modo oscuro, marrones profundos y tonos apagados. Misma animación, paleta diferente.

Accesibilidad: De bueno a perfecto

Mi construcción inicial obtuvo 96/100 en Accesibilidad de Lighthouse. Eso es bueno según la mayoría de los estándares. Pero 96 no es 100, y quería saber por qué.

La cosa de la navegación por teclado

Cada elemento del sitio es accesible por teclado. Navega con Tab por todo. Escape cierra modales. Enter activa botones. Cuando abres un modal, el foco salta al primer campo de entrada. Cuando lo cierras, el foco regresa a donde estabas.

Esto no es magia—es solo respetar cómo la gente realmente usa la web.

También hay un enlace de “Saltar al contenido” que aparece cuando presionas Tab. Está oculto por defecto, pero si estás navegando con un teclado, te permite saltar toda la navegación e ir directamente al contenido. Requerido para puntuaciones perfectas de accesibilidad. Esencial para usuarios que realmente lo necesitan.

El error de la etiqueta ARIA

Aquí está lo que me tropezó inicialmente: estaba añadiendo atributos aria-label a botones que ya tenían texto visible.

Lighthouse me reprobó en dos auditorías:

• “Los enlaces no tienen un nombre distinguible”
• “Los elementos con texto visible no coinciden con los nombres accesibles”

¿La solución? Dejar de pensarlo demasiado. Si un botón dice “Notifícame al lanzamiento”, ese ya es el nombre accesible. Agregar un aria-label que dice algo diferente solo confunde a los lectores de pantalla.

Texto visible = nombre accesible. Eso es todo.

Campos de formulario bien hechos

Cada campo de formulario obtuvo etiquetas apropiadas, atributos de autocompletado y etiquetas aria-required. Cuando alguien comete un error, los mensajes de error son claros y en su idioma (inglés o español).

Pequeños detalles que se acumulan en una gran experiencia.

Bilingüe: Ambos idiomas, no solo la interfaz

He escrito antes sobre por qué la traducción adecuada importa. Este proyecto reforzó todo eso.

El sitio no está simplemente “disponible en español”. Está construido en español. Cada cadena, cada etiqueta de botón, cada mensaje de error, cada atributo de accesibilidad—completamente traducible desde el primer día.

La versión en español obtuvo 100/100 en SEO, igual que en inglés. Eso no sucede por accidente.

Móvil: No una ocurrencia tardía

La experiencia móvil recibió tanta atención como el escritorio. La navegación se colapsa en un cajón inferior (más fácil de alcanzar con tu pulgar). El cambio de tema está justo ahí. Todo escala apropiadamente.

El flujo de registro funciona perfectamente en un teléfono. ¿La celebración de confeti cuando alguien se une? Igual de dramática en móvil que en escritorio. ¿Por qué no?

La celebración del registro

Cuando alguien se registra, no solo están enviando un formulario—se están uniendo a un viaje. La experiencia necesitaba reflejar eso.

¿Una notificación toast estándar en la esquina superior derecha? Aburrido.

Lo que construí: Un mensaje de éxito grande y centrado con 100 piezas de confeti cayendo desde arriba. Cuatro segundos de celebración. Porque unirse a un viaje de despertar espiritual debería sentirse significativo.

Es extra. Probablemente exagerado. Pero hace que la gente sonría, y eso importa.

El panel de administración que nadie ve (pero debería conocer)

Mientras celebramos registros en el frontend, Dorian necesita rastrear realmente quién se está registrando. Así que construí un panel de administración limpio.

Lo que hace:

• Estadísticas en tiempo real: registros totales, registros de esta semana, registros de hoy
• Lista completa de registros con nombres, correos electrónicos y marcas de tiempo
• Exportación CSV con un solo clic (descarga como signups-YYYY-MM-DD.csv)
• Eliminación individual de registros si es necesario
• Se actualiza automáticamente cada 30 segundos
• Autenticación basada en sesiones

Los datos viven en una base de datos SQLite con índices apropiados para rendimiento. Simple, rápido y mantenible.

No es público, pero está construido con el mismo cuidado que todo lo demás. Porque las herramientas que usas todos los días deberían funcionar bien.

SEO: 100/100 en ambos idiomas

Las puntuaciones perfectas de SEO requirieron ser intencional sobre todo:

Meta títulos que incluyen palabras clave que la gente realmente busca:
“Awaken to Life in the Meat Suit | Memoria de despertar espiritual por Dorian Des Lauriers”

Meta descripciones de menos de 160 caracteres que realmente impulsan clics, no solo relleno de palabras clave.

Datos estructurados (JSON-LD) diciéndole a Google exactamente de qué trata este sitio—un libro, por este autor, con esta descripción.

Etiquetas hreflang diciéndole a Google sobre las versiones de idioma para que aparezcan correctamente en los resultados de búsqueda.

Texto alternativo en cada imagen que es descriptivo, no decorativo.

¿Todo esto junto? 100/100 en SEO tanto para inglés como para español.

La corrección de seguridad que casi pierdo

Inicialmente intenté establecer encabezados de seguridad a través de meta tags:

<meta http-equiv="X-Frame-Options" content="DENY" />

La consola del navegador literalmente me dijo: “Esto no funciona aquí.”

X-Frame-Options solo puede establecerse a través de encabezados HTTP, no meta tags. Así que escribí middleware para establecer encabezados de seguridad apropiados en cada respuesta. Sin advertencias de consola. Limpio.

Pequeño detalle, pero importa.

Rendimiento: Acercándose a lo perfecto

El sitio carga rápido. Las imágenes están optimizadas a WebP/AVIF, todo debajo del pliegue carga perezosamente, el CSS está minificado y hay cero cambio de diseño.

Puntuación de producción actual: 99/100. Lo suficientemente rápido que se siente instantáneo.

¿Qué lo llevaría a 100?

Lighthouse me mostró exactamente lo que queda:

• Preconectar a fonts.gstatic.com (ahorra ~90ms en LCP)
• Agregar fetchpriority="high" a la imagen hero
• Aumentar la compresión de imagen ligeramente (podría ahorrar ~36KB)
• Incluir CSS crítico en línea en lugar de enlazarlo

Todas optimizaciones que importan más para benchmarks que para la experiencia del usuario. El sitio ya es rápido. ¿Pero para la próxima iteración? Alcanzaremos ese 100 perfecto.

El stack (para quienes les importe)

Construido con Astro.js, Tailwind CSS 4, TypeScript y Bun. Base de datos SQLite para registros. Desplegado vía Docker a Coolify.

Elegí Astro porque envía cero JavaScript por defecto a menos que lo necesites. Perfecto para un sitio de contenido que necesita cargar instantáneamente.

El enfoque CSS-first de Tailwind 4 hizo que el sistema de temas fuera limpio. Cada color definido una vez, usado en todas partes, cambia perfectamente entre claro y oscuro.

Los números

Puntuaciones de Lighthouse en producción:

• Rendimiento: 99/100 ⚡
• Accesibilidad: 100/100 ✅
• Mejores prácticas: 100/100 ✅
• SEO: 100/100 ✅

Casi perfecto en todos los aspectos. 99 en rendimiento con optimizaciones claras identificadas para alcanzar ese punto final.

Tanto las versiones en inglés como en español obtienen estas puntuaciones consistentemente. El rendimiento es lo suficientemente rápido que los usuarios no notan ninguna diferencia—y sabemos exactamente qué ajustar para llegar a ese 100 perfecto en la próxima iteración.

Lo que aprendí (otra vez)

La accesibilidad es una restricción de diseño, no una característica

No puedes “agregar accesibilidad después”. Tiene que estar incorporada en cada decisión desde el principio. ¿Cómo funcionan los modales? ¿Qué sucede cuando alguien presiona Escape? ¿A dónde va el foco?

Estos no son casos extremos. Son cómo millones de personas usan la web.

El modo oscuro es un sistema de diseño

No puedes simplemente invertir colores y enviarlo. Cada elemento—texto, fondos, sombras, animaciones—necesita consideración en ambos temas. No es el doble de trabajo, pero definitivamente es más que “establecer un fondo oscuro.”

Bilingüe desde el día uno es más fácil

Construir la traducción desde el principio es mucho más fácil que adaptarla después. Cada componente que escribí asumió múltiples idiomas. Nunca código duro de texto. Limpio, mantenible, escalable.

Lighthouse te humillará

96/100 se siente genial hasta que te das cuenta de que no es 100/100. ¿Esos últimos 4 puntos? Me enseñaron más que los primeros 96.

Los detalles se acumulan

Atributos apropiados de autocompletado. Retorno de foco después del cierre del modal. Manejadores de tecla Escape. Transiciones suaves de tema. Confeti celebratorio.

Ninguno de estos era “requerido.” Todos ellos importan.

Reflexiones finales

Este proyecto me recordó por qué me importa este trabajo. No se trata solo de hacer que las cosas se vean bien (aunque eso ayuda). Se trata de crear experiencias que funcionen para todos—usuarios de teclado, usuarios de lectores de pantalla, hablantes de español, personas con conexiones lentas.

El libro de Dorian trata sobre despertar a la vida. El sitio también necesitaba estar despierto—accesible, inclusivo, acogedor y técnicamente sólido.

Las puntuaciones perfectas de accesibilidad y SEO no son solo números. Son un compromiso de respetar a todos los que visitan tu sitio.

Un proyecto vivo

Este no es un sitio web de “configúralo y olvídalo”. A medida que Dorian se acerque al lanzamiento del libro, continuaremos refinando tanto el sitio principal como la tienda. Se agregarán nuevas características. El contenido evolucionará. El diseño se adaptará a lo que la audiencia necesite.

La fundación es sólida, pero el proyecto está muy vivo y creciendo junto al viaje de Dorian.

---

Míralo en vivo:
awakentolifeinthemeatsuit.com

¿Quieres algo similar?
Ponte en contacto

---

Escrito mientras escuchaba música ambiental y bebía demasiado café costarricense. Del bueno.