SvelteKit con adapter-static, mi flujo para webs sin backend

Uno de los primeros prejuicios que tuve con SvelteKit fue pensar que, por ser un framework “con servidor” por defecto, me obligaba a mantener uno en producción incluso para proyectos que no lo necesitan para nada. No es así, y @sveltejs/adapter-static es la pieza que lo demuestra.

Qué hace exactamente

En vez de desplegar un servidor Node que renderiza cada página bajo petición, adapter-static genera todo el HTML, CSS y JS en el momento del build — cada ruta se convierte en un archivo .html real, listo para servir desde cualquier hosting de archivos estáticos, sin infraestructura de servidor de ningún tipo. Para un blog, un portfolio o la web de un cliente que no necesita lógica de servidor propia, es exactamente lo que hace falta: toda la ventaja de desarrollar con un framework moderno, sin arrastrar el coste de mantener un servidor corriendo veinticuatro horas.

Las rutas dinámicas son la parte que hay que entender bien

Lo que más confunde al principio es cómo prerenderizar rutas dinámicas como /blog/[slug]. adapter-static no puede adivinar qué slugs existen — hay que decírselo explícitamente con una función entries() en el +page.ts de esa ruta, que le devuelve la lista completa de slugs a generar. La primera vez que se me olvidó añadirla, el build fallaba con un error bastante claro, así que tampoco es un fallo silencioso — pero hay que saber que existe.

El truco que más veces se me olvida a mí mismo

Durante el prerender, cualquier cosa que dependa del dominio real de la web (page.url.origin, por ejemplo) devuelve un host inventado como http://sveltekit-prerender, porque en ese momento no hay ninguna petición real todavía. Si usas ese valor para construir una URL absoluta — la canonical, el og:image, el sitemap — ese host falso se queda publicado tal cual en el HTML final. La solución es tener una única función que centralice el dominio real desde la configuración del sitio, y usarla siempre en vez de fiarse de la URL de la petición.

Por qué sigo eligiendo esto

Cero servidor que actualizar, cero base de datos que hacer copia de seguridad, cero superficie de ataque más allá de un hosting de archivos. Para el tipo de proyectos que hago — donde el contenido vive en el propio repositorio, no en una base de datos — es la combinación con menos cosas que puedan romperse mientras yo duermo.