Cómo crear una web corporativa: notas de nuestro propio sitio

El sitio web de una empresa de software es el primer software que escribe esa empresa. Quien lo abre no ve el código, pero ve el resultado. Si la página tarda en cargar, si en otro idioma se ha quedado una frase en turco, si el formulario de contacto deja de funcionar sin avisar, lo atribuye al trabajo de la empresa.

Por eso no construimos el sitio como un folleto, sino como un pequeño producto. A continuación explico qué decisiones tomamos, por qué y en qué nos equivocamos.

Generación estática

El sitio está escrito con Next.js. En la primera versión, las páginas se volvían a generar en el servidor con cada petición. La causa era una línea inocente: el layout raíz leía la cabecera de la petición para averiguar el idioma. Next considera dinámica cualquier página en la que ve esto.

El resultado fue que Cloudflare no podía guardar ninguna página en caché. Cada visita llegaba hasta el servidor de Hetzner. Al medirlo en local, el tiempo hasta el primer byte era de unos pocos milisegundos. Es decir, el código no era lento. El problema aparecería con la escala.

La solución fue deducir el idioma de la dirección y no de la petición. Cada idioma tiene su propio layout raíz, y el idioma se sabe por la carpeta en la que está la página. Hoy las casi trescientas páginas se generan todas una sola vez durante la compilación.

Siete idiomas y coherencia

El sitio se publica en turco, inglés, francés, portugués, alemán, español y árabe. La traducción en sí es la parte fácil. Lo difícil es que, cuando cambia un texto, cambie en siete sitios a la vez.

La mayoría de los errores que encontramos en las primeras revisiones salían del mismo patrón. Una larga cadena de condiciones que elegía el texto según el idioma caía en silencio en la última rama cuando se olvidaba de un idioma. Y la última rama solía ser la turca. Así aparecía una frase en turco en mitad de una página en francés.

Lo resolvimos con una función auxiliar. Cada lugar que elige un texto está obligado a dar los siete idiomas a la vez. Si falta un idioma, el código no compila. El error se detecta antes de publicarse.

El título académico era un problema parecido. En una traducción, el título «Doç. Dr.» se había convertido en profesor. Ahora el título no se traduce en ningún idioma. Se toma del registro en turco, y una prueba lo comprueba en cada push.

Pruebas

No montamos un marco de pruebas pesado. Escribimos nueve pruebas con el módulo de pruebas propio de Node. Cada una detecta un error que ya nos ocurrió de verdad.

Entre ellas están que el título sea el mismo en todos los idiomas, que ningún texto contenga una raya, que el nombre de la marca no se traduzca, que cada artículo en turco tenga su equivalente en los otros seis idiomas y que los textos legales no se resuman al traducirlos. La última prueba es tosca, pero funciona: si la página legal en un idioma tiene menos del sesenta por ciento de la extensión de la turca, lo más probable es que se haya resumido.

En cada push a GitHub se ejecutan la comprobación de tipos, el lint, estas pruebas y la compilación de producción. Si una falla, la versión no se publica.

Seguridad

La política de seguridad de contenidos es estricta. No se pueden cargar scripts, fuentes ni imágenes desde un dominio externo. Las fuentes vienen de nuestro propio servidor, así que el navegador del visitante no envía peticiones a terceros al abrir la página. Google Analytics solo se carga si el visitante da su consentimiento.

La pantalla del protocolo de trabajo de la página de inicio envía a un modelo de lenguaje el texto que escribe el visitante. Es el punto del sitio más fácil de usar de forma abusiva. Alguien que quiera usar gratis un modelo de pago podría llamar directamente al endpoint. Lo impedimos con varias capas: la comprobación de que la petición viene de nuestra página, un ticket firmado de corta duración y de un solo uso, un límite por hora y por día para cada dirección, un techo diario para todo el sitio y un límite al número de peticiones que pueden ir al modelo a la vez.

Despliegue

El código está en GitHub. En el servidor de Hetzner funciona Coolify, que con cada push a la rama principal vuelve a compilar el sitio como imagen de Docker y lo publica. Un despliegue tarda unos dos minutos y medio.

Delante está Cloudflare. Al pasar a la generación estática, también el HTML se pudo guardar en caché, y las páginas se mantienen allí hasta una hora.

En qué nos equivocamos

La caché fue tanto la fuente de la velocidad como la de un malentendido. Publicamos una nueva versión, Coolify dijo que todo había ido bien, pero la página de inicio seguía saliendo como antes. La causa era sencilla. Cloudflare no pedía la nueva copia hasta que caducaba la que tenía.

La solución correcta es vaciar la caché automáticamente al final de cada despliegue. El proceso de publicación no termina cuando termina en el servidor, sino cuando termina donde lo ve el visitante.

También está la accesibilidad. El análisis automático no encontraba errores en las páginas. Pero las pequeñas etiquetas de la página de inicio estaban sobre una fotografía semitransparente, y la herramienta de análisis no puede medir el contraste sobre una fotografía. Medimos aparte los píxeles que había detrás de las etiquetas, y la relación rondaba 3:1. Al aclarar un poco la fotografía y oscurecer un tono las etiquetas, superó 5:1. Hay que mirar incluso cuando la herramienta dice «sin errores».

Por qué lo contamos

Decirle a un cliente «entregamos software que funciona» es fácil. Al explicar con claridad lo que hicimos en este sitio, también resulta fácil ver en qué se apoya esa frase.