El lado oscuro de los sitios estáticos

Read in English

Durante casi 8 años he usado un generador de sitios estáticos para mi blog, en concreto Jekyll. Sin embargo, cuando decidí rediseñar mi sitio, tenía muy claro que iba a migrar todo el contenido y lógica a una solución dinámica. Llevaba demasiado tiempo limitado por la naturaleza estática como para repetir el mismo error. Después de un cambio largo pero satisfactorio, ahora puedo decir que no me arrepiento de haber dado el paso.

Antes de empezar, un apunte de transparencia: soy el autor de Django LiveView, el framework que uso ahora para servir este blog. Así que tómate lo que leas con esa parte interesada en mente.

Quiero compartir las razones que me llevaron a este movimiento, y de paso, hablar sobre el lado oscuro de los sitios estáticos que no muchos se atreven a decir en voz alta. Y antes de ser acusado de herejía, quiero dejar claro que no estoy en contra de los sitios estáticos. De hecho, sigo pensando que es una buena opción para muchos casos de uso y una buena puerta de entrada para iniciarse en el mundo del blogging.

Argumentos a favor de un sitio estático

Cuando empezamos un blog, todos nos sentimos seducidos de forma instintiva por la idea de un sitio estático. Y no es para menos:

  • Escribir con tu editor favorito: Creas o editas tus artículos en texto plano con tu editor favorito.
  • Despliegue sencillo: Solo necesitas un servidor web o usar cualquier hosting gratuito.
  • Mínimo mantenimiento: No hay preocupaciones de seguridad ni parches de emergencia.
  • Buen rendimiento: No hay que preocuparse de la carga del servidor.
  • SEO friendly: Los motores de búsqueda amarán tu sitio.

Y para qué lo vamos a negar: un sentimiento de superioridad moral frente a los grandes CMS que requieren un servidor y una base de datos. Te sientes más independiente, hacker y alineado con la filosofía IndieWeb. Win-win.

Si eres el perfil que no le pide más a su blog que: los artículos se lean correctamente, sea navegable y tenga un feed RSS; un sitio estático es perfecto para ti. No necesitas más. Sin embargo, todo proyecto grande empezó siendo uno pequeño. En cuanto quieres dar un paso más allá empiezan los costes de oportunidad. Cada concesión implica un sacrificio.

Coste de oportunidad de un sitio estático

Que un contenido sea estático no implica que no pueda tener elementos dinámicos. Por ejemplo, para personalizar la apariencia (modo oscuro, tamaño de letra, etc.). Sin embargo, no todo se puede arreglar con un poco de JavaScript o una extensión de tu generador de sitios estáticos. En cuanto necesitas una comunicación entre tu lector y tú, más allá del email, ya estamos metiendo el pie en terrenos ásperos. Como puede ser un formulario (comentarios, contacto, buscador, etc.). Pero también puede ser que quieres una mejor experiencia de usuario (paginador infinito, previsualización de contenido, etc.). Un sitio estático se queda sin recursos.

Como administrador del sitio, debes hackearlo:

  • Crear un script que genere el contenido de forma periódica.
  • Usar JavaScript para manipular el contenido.
  • Integrar un widget de servicio externo.
  • Implementar un backend (o APIs o Serverless).

Dependes del exterior y los dolores de cabeza: ¿Quiero que mi contenido sea mío o de terceros? Por ejemplo, si usas Disqus para los comentarios, o un servicio similar, el contenido de los comentarios se estará almacenando en un servidor y base de datos que no es tuyo. Si cierran tu cuenta, todo desaparecerá. Además, tu sitio indie está guardando datos de tus lectores en un servidor que no es tuyo. Nótese la contradicción.

En definitiva, cada vez que ganas una característica dinámica en un sitio estático, aumenta la complejidad y el coste de mantenimiento. O peor aún, aumenta la dependencia de terceros.

Qué aporta un sitio dinámico

Hablemos de lo que tengo ahora, que antes o no podía o era muy complicado de implementar.

  • Publicación programada: Puedo escribir un artículo y programar su publicación para un momento concreto.
  • Formulario de contacto: Puedo recibir mensajes de mis lectores y responderles, sin exponer una dirección de correo electrónico.
  • Comentarios: Puedo recibir comentarios de mis lectores, renderizarlos junto al artículo, y moderarlos desde cualquier dispositivo.
  • Buscador: Siendo los resultados instantáneos y navegables.
  • Newsletter: Pueden suscribirse o darse de baja. Toda su información se almacena en mi servidor y no en un tercero.
  • Integración con protocolos: Puedo recibir y enviar Webmentions, o interactuar parcialmente con ActivityPub.
  • Panel administrativo: Puedo realizar cambios rápidos y sutiles desde el navegador o smartphone.
  • Contenido multimedia: Puedo subir imágenes y vídeos, y el sistema se encarga de optimizar, redimensionar y convertir entre formatos.

Además, ahora puedo ofrecer una navegación por tipos de visitantes.

  • IAs: Leen el contenido en Markdown.
  • Indexadores: Leen el contenido en HTML, de forma estática, sin ejecutar JavaScript. También para lectores humanos con JavaScript desactivado.
  • Lectores humanos: Leen el contenido en HTML sobre WebSockets (SPA) y con contenido dinámico.

Mismo contenido en 3 formatos distintos, adaptado a cada forma de consumo. Desarrollo todo esto en más profundidad en Escribe en Markdown, sírvelo dinámico.

Añadiría a la lista los lectores de pantalla, ya que es la parte que menos brilla pero a su vez he invertido un tiempo considerable y no quiero que pase desapercibida. Sin embargo, no es una característica exclusiva de un sitio dinámico.

Algunas de las funcionalidades son salvables si tenemos nuestro backend/script corriendo en un servidor, con alguna API que nos permita interactuar con JavaScript. Pero aquí entramos en un terreno que no es trivial: ¿sigue siendo un sitio estático? ¿híbrido, donde el contenido es estático, pero la interacción con el usuario es dinámica?

No perdemos las ventajas de un sitio estático

Las 4 ventajas que mencioné al principio de los sitios estáticos siguen siendo válidas, aunque con matices:

  • Escribir con tu editor favorito: Tal vez la parte a la que más importancia le damos es justamente la edición de contenido en texto plano. Cada uno de mis artículos es un Markdown que dinámicamente se renderiza a HTML. Incluso puedo previsualizar el resultado en tiempo real, sin necesidad de compilar nada. Mi copia de seguridad es un repositorio Git.
  • Despliegue sencillo: No podemos ocultar la complejidad detrás de un sitio dinámico en su despliegue, pero una vez tienes construido tu pipeline, es tan sencillo como un sitio estático. En mi caso solo debo ejecutar un git push y el resto se encarga de mi pipeline de CI/CD.
  • Mínimo mantenimiento: No todos los días, pero cada cierto tiempo hay que revisar actualizaciones de seguridad, tanto en mi framework como en mi Debian. Aun así, considero que el trabajo es muy bajo: unos pocos comandos cada cierto tiempo para actualizar dependencias y sistema, que reviso yo antes de aplicar.
  • Buen rendimiento: Con CDNs y cacheo de contenido, el rendimiento es equiparable al de un sitio estático.
  • SEO friendly: Todo sigue siendo indexable y accesible para los bots, incluso mejor ya que puedo personalizar el contenido para cada tipo de robot o lector humano.

Stack

Antes de cerrar sería un buen ejercicio de transparencia mostrar mi stack tecnológico actual. No considero que tenga nada exótico.

  • Servidor web: Nginx
  • Base de datos: PostgreSQL
  • Backend: Django + Channels + Django LiveView
  • Tareas en segundo plano: Huey + Redis
  • Frontend: No uso, lo gestiona todo Django LiveView.
  • Sistema operativo: Debian
  • Contenedores: Docker + Docker Compose
  • CI/CD: Gitea + Script

El contenido vive en archivos Markdown y los archivos multimedia se optimizan al vuelo con Imagor, el cual uso para varios propósitos.

Conclusión

Considero que es más rápido y satisfactorio empezar con un sitio estático. Aunque si eres ambicioso, acabará siendo un lastre. El coste de oportunidad demasiado alto y la dependencia de terceros demasiado grande.

Por otro lado, los CMS modernos son muy buenos y fáciles de instalar con contenedores. Además es relativamente sencillo llegar a todos mis puntos por medio de extensiones o con un poco de código si eres desarrollador. También hay híbridos como Astro, con arquitectura de Islas, que permiten tener lo mejor de ambos mundos. Pero si quieres un control total sobre tu contenido y la experiencia de tus lectores, un sitio dinámico es la mejor opción.

Un sitio estático es una buena opción para un blog personal sin muchas pretensiones o que se despreocupa de la información de sus visitantes. Pero si quieres ir un paso más allá, o te profesionalizas, los sitios dinámicos rompen cualquier limitación incluso llegando a superar las ventajas de un sitio estático. Por supuesto, todo depende de tus necesidades y tus habilidades técnicas. No olvidemos que para la gran mayoría de los casos, un sitio estático es más que suficiente. Pero te dejo una última reflexión: ¿es suficiente para tus lectores?

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

Will you buy me a coffee?

This is how I keep writing without ads or paywalls.

Comments

There are no comments yet.

You may also like

Visitors in real time

You are alone: