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 Ehundu (abre en ventana nueva), que he escrito yo mismo, 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.

Lo escribí en mayo, cuando el blog todavía salía de Lume, y lo he reescrito en octubre, ahora que sale de Ehundu. El cuarto de máquinas ha cambiado bastante. La filosofía que hay debajo, no.

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.

Ehundu, el generador

El corazón técnico del sitio es Ehundu, un generador de sitios estáticos escrito en PHP. Si has trabajado con herramientas de este tipo conocerás nombres más populares: Hugo, Jekyll, Eleventy, Astro. Ehundu no es ninguno de ellos, ni lo será pronto: no lo conoce nadie salvo yo, y por ahora eso es más un problema que un atractivo.

Cuento su porqué, lo que hace y todo lo que le falta en otro artículo. Aquí basta con lo esencial. Le das una carpeta con el contenido en Markdown, los datos en YAML y las plantillas en Twig, y te devuelve el sitio en HTML. Es software libre, va por la versión 0.6 y para compilar necesita PHP y nada más: ni Node, ni Deno, ni carpetas de dependencias creciendo como hongos. Las carpetas de este blog se llaman contenido, plantillas y publico, y los campos de cada entrada titulo, fecha o etiquetas. Todo está en español, a propósito.

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.

Hasta ahora el blog salía de Lume (abre en ventana nueva), un generador que desarrolla Óscar Otero (abre en ventana nueva), un programador gallego, y que corre sobre Deno. Me sirvió durante años y se lo agradezco. Si buscas un generador de sitios estáticos que no sea de los de siempre, sigue siendo una elección excelente. No lo dejé porque me fallara, sino porque quería que este blog fuera también el banco de pruebas de mi propio motor, y migrarlo era la prueba más exigente que se me ocurría: 253 entradas, once relatos, veinte juegos y herramientas, y 282 páginas que tenían que salir con las mismas direcciones de siempre. Comparé el HTML de las dos versiones página a página, y cada diferencia quedó explicada.

Casi todas eran cuestión de sintaxis. Las que no, eran fallos que llevaban tiempo en el blog sin que nadie, yo el primero, los hubiera visto: una entrada con unas comillas sin escapar en la descripción, que rompían el HTML de su cabecera; un campo mal escrito, image-alt con guion, que dejaba la descripción de la imagen que se comparte en redes con la de otra foto; y un feed que apuntaba a unas imágenes en una dirección que no existe. Comparar con una máquina que no se cansa tiene esas cosas.

Hoy el sitio entero se compila en unos dos segundos, y en la vista previa se rehace solo lo que cambia con cada modificación, en décimas de segundo.

Los proveedores, y por qué europeos

El código del blog es una carpeta de ficheros con su historial de Git. Lo escribo en mi ordenador y, cuando quiero publicar, Ehundu sube por SFTP solo los ficheros que han cambiado a Alwaysdata (abre en ventana nueva), una empresa francesa de hosting que además sirve el sitio ya construido, sin pasar por ningún servicio intermedio. El servidor no compila ni ejecuta nada: solo sirve ficheros. Las imágenes, los PDFs y algún otro fichero pesado están en Scaleway (abre en ventana nueva), otra empresa francesa que ofrece entre otras cosas almacenamiento de objetos compatible con S3 pero con infraestructura en Europa, detrás de un dominio propio, media.paigar.eu.

Hay una excepción a lo de los proveedores europeos y prefiero contarla yo. La copia de seguridad del proyecto está en GitHub, en un repositorio privado. No es europeo y no es lo que predico. Para publicar no lo necesito, porque se publica desde mi ordenador, pero de ahí lee también la tarea programada que recompila el sitio cada madrugada, de la que hablo más abajo. Si un día desaparece, lo sustituyo por otro Git y poco más: con Git, mudarse es cambiar una dirección.

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. Ehundu no procesa imágenes, es una de las cosas que he dejado fuera a propósito: las variantes ya están hechas y esperando en el almacenamiento, y la plantilla se limita a escribir el <picture> que las usa.

La segunda es lo que en inglés se llama LQIP, siglas de Low Quality Image Placeholders (cuento cómo lo hacía con Lume en otro artículo). 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. Ehundu no tiene pasos previos a la compilación, otra decisión deliberada, así que un script aparte, que ejecuto al añadir una imagen, descarga la miniatura y la guarda en un fichero de datos que la compilación se limita a leer. Mientras una imagen no esté ahí, la plantilla usa directamente la miniatura del almacenamiento: viaja por la red en lugar de ir dentro del HTML, pero el efecto es el mismo.

La tercera es que los estilos CSS están incrustados directamente en el HTML. Ehundu los toma tal como están escritos y los inyecta en el <head> de cada página, solo los de las hojas que esa página necesita, 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. Con Lume, el CSS y el HTML pasaban además por un minificador; con Ehundu no, porque el motor no los toca, y por eso cada página pesa ahora unos tres kilobytes más una vez comprimida. Es una diferencia pequeña a cambio de un proceso con un paso menos, y si algún día quiero recuperarlos, será un paso aparte.

La cuarta es que puedo escribir con meses de adelanto. Cada entrada tiene su fecha, y con publicarEnSuFecha en la carpeta de entradas una fecha futura retiene la página: no sale en ningún listado, ni en el sitemap, ni en el feed, hasta que llega su día. Para que salga sola, una tarea programada recompila el sitio cada madrugada, en un servidor europeo, y sube lo que haya cambiado. No hay que acordarse de nada, y a las cuatro de la mañana no hay nadie mirando.

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.