Este sitio no manda JavaScript
Treinta páginas en tres idiomas, menos de 30 KB cada una, con accesibilidad y SEO trabados en el CI. Las decisiones detrás del sitio y lo que costaron.
La página que estás leyendo no manda JavaScript a tu navegador. Ningún framework, ningún script de hidratación, ningún píxel de analytics. La página entera pesa menos de 30 KB y las fuentes son lo más pesado que tiene.
Para un sitio personal con blog es una decisión defendible. También es muestra de trabajo: vendo servicios de rendimiento y accesibilidad, quedaría raro venderlos desde una página que tarda tres segundos en volverse útil.
Estático, porque el contenido es estático
El sitio es Astro: markdown en un repositorio git que se convierte en HTML en el build. Treinta páginas quedan listas en medio segundo. No hay servidor que parchear, base de datos que respaldar ni panel de administración que proteger, y escribir un post es abrir el editor, que es donde ya estoy.
Pasé tres años en ConsumerAffairs, un sitio con siete millones de visitas por mes, donde la velocidad de página se seguía como métrica de negocio porque se comportaba como una. La lección de esa época es aburrida y sigue valiendo: la petición más rápida es la que no ocurre.
La única excepción es el formulario de contacto, que arma un correo en tu propio cliente de mail. Doce líneas de script. Todo el resto del sitio funciona con JavaScript apagado.
Tres idiomas, desiguales a propósito
El inglés vive en la raíz, el portugués lo refleja entero, el español cubre las páginas principales. Las URLs también están traducidas, así que la página sobre mí en español es /es/sobre-mi y no /es/about.
La desigualdad es la forma honesta de quien lee. Los pedidos de consultoría llegan en inglés. La mentoría, que ayuda a devs de Argentina y Brasil a llegar a clientes de afuera, ocurre en español y portugués. Traducir cada post a tres idiomas triplicaría el mantenimiento por una fracción del retorno.
Hay dos páginas en portugués que existen solo para búsqueda: una sobre consultoría en Brasilia, otra sobre Goiânia. No están en el menú. Están ahí porque alguien en Goiânia que escribe “consultoria de tecnologia” merece encontrar una página escrita para él y no una genérica.
Lo que más trabajo dio
El color, aunque no lo parezca. El diseño usaba un naranja cálido para los acentos, y reprobaba el contraste de WCAG en tamaño chico: 3,31:1 contra el fondo de la tarjeta, cuando el mínimo es 4,5:1. La corrección fue un segundo naranja, más cerrado, para cualquier texto por debajo de 24px, y costó una pasada por todas las pantallas. El gris secundario tenía el mismo problema, en 4,44:1.
Ninguno de los dos lo habría cazado a ojo. Los dos aparecieron midiendo.
El menú del celular es un checkbox y un label, sin JavaScript. En el primer intento escondí el checkbox de los lectores de pantalla y lo saqué del orden de tabulación al mismo tiempo, lo que dejó todo el menú inalcanzable con teclado por debajo de 768px. El test automático decía que la página estaba limpia. Apretar Tab tres veces decía lo contrario.
Lo que exige el build
Cada push corre cuatro controles. Una revisión de contenido tira el build abajo si un título pasa de 60 caracteres, si hay metadatos duplicados, falta un canonical, hay más de un h1 o aparece una raya en el texto, porque no la quiero en mi escritura y una regla que depende de mi memoria es una regla que voy a olvidar. Un escaneo de axe cubre diez páginas en dos anchos y reprueba ante cualquier violación de WCAG 2.2 AA. Lighthouse tiene que quedar en 100 en las cuatro categorías, con límites de LCP, CLS y tiempo de bloqueo. Y knip borra código y dependencias que nadie importa.
Números de hoy: LCP 0,4s, CLS 0, bloqueo 0ms.
El CLS estaba en 0,04 hasta que precargué las dos fuentes que aparecen arriba de todo. Es el tipo de detalle que nadie nota cuando está bien y todos sienten cuando está mal.
Si valió la pena
Un armador de sitios resolvía esto en una tarde. Este camino llevó más tiempo, y la diferencia no se ve en una captura de pantalla.
Se ve cuando un reclutador abre el sitio con el wifi de un hotel, cuando alguien recorre el formulario con lector de pantalla, y cuando Google renderiza las páginas en portugués y encuentra la palabra clave en la URL. Para esos tres casos lo construí.