El cuarto de máquinas de este blog

De vez en cuando alguien me pregunta con qué está hecho este blog. La respuesta corta es que con un generador de sitios estáticos llamado Lume (abre en ventana nueva) y un puñado de decisiones tomadas con más intención de la que parece a primera vista. La respuesta larga es este artículo.

No voy a escribir un tutorial. Lo que me interesa contar no es cómo se configura nada sino por qué está montado así y qué hay detrás de cada elección. Hay una filosofía debajo, aunque dicho así suene un poco pretencioso para lo que al fin y al cabo es un blog personal.

Lume, el generador

El corazón técnico del sitio es Lume, un generador de sitios estáticos construido sobre Deno. Si has trabajado con herramientas de este tipo conocerás nombres más populares: Hugo, Jekyll, Eleventy, Astro. Lume no es ninguno de ellos, es menos conocido fuera de ciertos círculos, y eso forma parte de su atractivo para mí.

Lo desarrolla Óscar Otero (abre en ventana nueva), un programador gallego, y corre sobre Deno en lugar de Node.js. Eso ya lo hace diferente desde la base: Deno es el entorno de ejecución que escribió el creador original de Node.js después de replantear lo que haría distinto si empezara de cero. Es más moderno, más seguro por defecto, y en la práctica resulta mucho más limpio de usar. No hay carpetas de dependencias creciendo como hongos en cada proyecto. Las dependencias se resuelven por URL. El TypeScript funciona directamente sin pasos de compilación previos.

Lume genera HTML estático a partir de Markdown y de plantillas escritas en Vento, un lenguaje de plantillas también creado por Óscar Otero. El resultado es un directorio de ficheros que se puede alojar en cualquier servidor web, sin bases de datos, sin procesos en segundo plano, sin nada que mantener encendido. Los sitios estáticos tienen una resistencia estructural que el software dinámico nunca puede igualar: no hay superficie de ataque, no hay actualizaciones de seguridad urgentes, no hay caídas por carga. Están ahí y punto.

Los proveedores, y por qué europeos

El código del blog vive en Codeberg (abre en ventana nueva), que es básicamente lo que sería GitHub si estuviera gestionado por una organización sin ánimo de lucro alemana en lugar de por Microsoft. Las imágenes, los PDFs y algún otro fichero pesado están en Scaleway (abre en ventana nueva), una empresa francesa que ofrece entre otras cosas almacenamiento de objetos compatible con S3 pero con infraestructura en Europa. Y el sitio en sí está alojado en statichost (abre en ventana nueva), un servicio especializado en sitios estáticos, también europeo.

La decisión de usar proveedores europeos no es solo una cuestión de rendimiento o de preferencia técnica. Tiene que ver con dónde quiero que vivan los datos y bajo qué legislación. El RGPD no es perfecto ni mucho menos, pero es infinitamente mejor que no tener nada, y alojar cosas en Europa significa al menos que las normas aplicables son las europeas. En un momento en que la relación entre datos personales e infraestructura americana se está volviendo cada vez más complicada, me parece una decisión sensata aunque nadie la note desde fuera.

La galería y las tres mil fotos de Instagram

Hay una sección de este sitio que requiere más explicación que el resto. La llamo «momentos aleatorios» y es una galería de algo más de tres mil fotografías que en su día publiqué en Instagram. Cuando decidí dejar de depender de esa plataforma para mis fotos, no quería perder lo publicado. Así que lo rescaté, lo organicé y lo monté aquí.

Para mostrar esa cantidad de imágenes de manera funcional y razonablemente bonita uso pig.js (abre en ventana nueva) de Dan Schlosser, una librería JavaScript que construye cuadrículas responsivas con carga progresiva. Las imágenes no se cargan todas de golpe, sino a medida que el usuario va bajando por la página, y la cuadrícula se reorganiza sola según el ancho de la pantalla. He modificado algunas cosas respecto al original para adaptarlo a cómo están almacenadas las imágenes y a cómo funciona el resto del sitio. Si te interesa el detalle técnico de cómo funciona la galería por dentro, hay un artículo específico sobre ello.

Las fotos en sí viven en el almacenamiento de Scaleway y se sirven desde ahí directamente. El blog solo guarda un fichero JSON con los metadatos: nombres de fichero, pies de foto, dimensiones. Es un patrón bastante elegante: separar el contenido del catálogo.

Los detalles que nadie ve pero que importan

Hay algunas cosas técnicas que me parecen suficientemente interesantes como para mencionar, aunque no se noten a simple vista.

La primera es el sistema de imágenes responsivas. Cada imagen del blog se sirve en múltiples tamaños y en formatos modernos: AVIF primero, WebP como alternativa, JPEG como último recurso. El navegador elige automáticamente el más adecuado según sus capacidades y el tamaño de la pantalla. Esto se hace con el elemento <picture> de HTML y sus atributos srcset y sizes, que están disponibles desde hace años pero que todavía mucha gente no usa.

La segunda es lo que en inglés se llama LQIP, siglas de Low Quality Image Placeholders. Antes de que cargue la imagen real, el navegador muestra una versión en miniatura de dieciséis píxeles codificada directamente en el HTML. El resultado es ese efecto de desenfoque que va resolviéndose en imagen nítida mientras la página carga. Lo genera un script que corre antes del proceso de construcción del sitio y cachea los resultados para no tener que regenerarlos en cada publicación.

La tercera es que los estilos CSS están inlineados directamente en el HTML. Lume los procesa y minifica, y luego los inyecta en el <head> de cada página en lugar de servirlos como ficheros separados. Eso elimina una petición de red por página y evita el destello de contenido sin estilo que aparece cuando los estilos llegan tarde.

Para qué sirve contar todo esto

Una de las cosas que más me gusta del mundo de los blogs personales y de la IndieWeb es que la gente comparte cómo hace las cosas. No para presumir ni para vender un curso, sino porque hay algo genuinamente interesante en ver las decisiones que toma otra persona cuando construye algo para uso propio. Este sitio acumula años de trabajo en decisiones pequeñas, correcciones, pruebas y descubrimientos. Contarlo me parece más honesto que fingir que el resultado final apareció de la nada.

Si tienes alguna pregunta sobre algo concreto, puedes escribirme a través de la página de contacto.