# Reconstruir dsti.school: dieciocho meses en el camino, tres semanas frente al teclado HTML canónico: https://dsti.school/es/techblog/reconstruccion-dsti-school-primavera-2026 Esta versión Markdown se genera con el mismo build del sitio estático de DSTI que la página HTML canónica. Está pensada para facilitar la lectura automática y la consulta concisa. [DSTI TechBlog](https://dsti.school/es/techblog)  /  Team DSTI Team DSTI Sistemas · instituciones · entrega Un análisis técnico completo de la reconstrucción integral de un sitio web, junto con las razones concretas por las que una escuela pequeña, selectiva y concebida para el mundo necesitaba cada una de sus piezas. ![Sébastien Corniglion](https://media.dsti.school/wp-content/uploads/2026/05/25131106/Sebastien-Corniglion-DSTI-School-of-Engineering.avif) Sébastien Corniglion Director General, Decano, cofundador y docente de sistemas de información, DSTI 22 de junio de 2026 43 min de lectura actualizado hasta V308 sitio-estatico aws-cloudfront controles-ci schema.org llms.txt css-por-pagina xml-xsd ia-portable Ingeniería desde dentro de DSTI ## De la realidad organizacional a una versión que puede demostrar su validez 01 Observar Dieciocho meses de conversaciones, viajes y evidencia de reclutamiento internacional. 02 Modelar Convertir necesidades, restricciones, actores y riesgos en un sistema de información explícito. 03 Construir Convertir el modelo en fuente, herramientas, contenido y entrega en el edge de forma determinista. 04 Demostrar Rechazar la publicación hasta que se hayan superado todos los controles bloqueantes. 18 meses aprendizaje de campo 3 sem. reconstrucción integral V308 versión descrita aquí Esta es la versión larga de cómo reconstruimos [dsti.school](https://dsti.school/) y de por qué una pequeña escuela de ingeniería selectiva, ubicada en la [Riviera Francesa](https://dsti.school/es/vida-riviera-francesa), terminó escribiendo su propia cadena de build de un sitio estático, su propio validador de schema.org y su propio motor de geolocalización en el edge. La versión corta cabe en una frase: gran parte de lo que parece marketing es en realidad ingeniería, y gran parte de la ingeniería solo cobra sentido cuando se entiende para qué sirve . Por eso este artículo presenta ambas cosas: los sistemas, completos, y las razones que los sustentan. Dos esfuerzos avanzan en paralelo a lo largo de esta historia. Uno corresponde a dieciocho meses de construcción de una red mundial de socios, viajando y trabajando con una institución a la vez. El otro son tres semanas de reconstrucción completa del sitio web. Parecen no tener relación. Sin embargo, forman parte del mismo proyecto: un esfuerzo sostenido por ganar la confianza de una familia en una escuela de la que muchas veces nunca ha oído hablar, en un país que rara vez figura entre sus primeras opciones. El sitio web continúa ese esfuerzo mientras todos duermen, así que tiene que estar a la altura. La perspectiva docente detrás del build ## Analizar antes de implementar Este es un relato de Team DSTI, pero también refleja la disciplina de sistemas de información que se enseña dentro de la escuela: comprender la organización antes de decidir qué construir. El análisis formaliza el «qué» de un sistema; el diseño transforma ese «qué» en un «cómo» coherente. Sébastien imparte actualmente Analysis & Design of Information Systems en el [MSc in Data Analytics with AI](https://dsti.school/es/msc-data-analytics-ai) y el [MSc in Data Engineering for AI](https://dsti.school/es/msc-data-engineering-ai). Su premisa práctica es directamente pertinente aquí: los proyectos suelen fracasar no porque nadie sepa programar, sino porque las actividades, los datos, las partes interesadas, los eventos, las restricciones y las responsabilidades no se comprendieron con suficiente precisión antes de iniciar la implementación. [MSc Data Analytics with AI](https://dsti.school/es/msc-data-analytics-ai) [MSc Data Engineering for AI](https://dsti.school/es/msc-data-engineering-ai) [Executive MSc](https://dsti.school/es/executive-msc-inteligencia-artificial-transformacion-digital) [BSc Computer Science & Engineering](https://dsti.school/es/bsc-informatica-ingenieria) [AI Awareness](https://awareness.dsti.school/) Fundamentos de sistemas Creación e impartición de Computer Architecture, Networking, Data Management y AI Awareness en el DSTI Warm Up; de Data Wrangling with SQL, también en el Executive MSc; y de Software Engineering Parts 1 & 2 en los MSc centrados en datos. Datos empresariales y colaboración Creación e impartición de CRM Data Management para públicos de MSc Data Engineering, MSc Data Analytics y Executive MSc, además de Relational Database Management Systems y Systems and Applications for Enterprise Collaboration en el BSc. Arquitectura, del hardware a la nube Creación e impartición de Computer Architecture and Operating Systems e Introduction to Computer Networks en el BSc; también impartición del programa oficial AWS Solution Architect en los programas de DSTI como instructor certificado de Amazon AWS. ## 01 Por qué existe: una red, no un mercado nacional Antes de escribir una sola línea de código: el sitio web se reconstruyó debido al origen real de nuestros estudiantes. Durante los últimos dieciocho meses, la red de socios consejeros de estudios en el extranjero de DSTI pasó de unas cuantas decenas de relaciones a 92 socios aprobados en 78 países y territorios . Ese crecimiento ocurrió en persona —ferias, visitas a campus, conversaciones largas— y cambió lo que el sitio web debe hacer. Ya no es un folleto para personas que ya nos conocen. Cada vez más, es el primer encuentro serio que un futuro estudiante de Lagos, La Paz, Hanói o Bogotá tiene con la escuela, desde un teléfono, con una conexión irregular y en un idioma que quizá no sea el suyo. Ese solo hecho determina casi todas las restricciones técnicas que siguen: el sitio debe ser rápido en dispositivos móviles , legible para las máquinas tanto como para las personas , estar disponible en más de un idioma, cada uno tratado como un idioma de pleno derecho y ser imposible de publicar si está roto , porque rara vez habrá alguien despierto para detectarlo. Ninguna de estas decisiones es estética. Son consecuencias de quién está al otro lado. ## 02 La apuesta: el oficio como única forma de competir en igualdad Somos una institución pequeña. No tenemos un nombre famoso ni un presupuesto enorme, y no vamos a adquirir ninguno de los dos este trimestre. Lo que un equipo pequeño sí puede controlar es la calidad de lo que realmente publica. Por eso, la apuesta de la reconstrucción fue deliberadamente clásica: resolver el problema con mejor ingeniería. Hacer que el sitio sea más rápido, más limpio, más preciso y más legible para las máquinas que los de escuelas cien veces más grandes, porque esta competencia se decide por el cuidado y la disciplina, no por el gasto. También por eso la reconstrucción creó un ciclo de mejora acumulativa en lugar de un rediseño aislado. Cada propiedad de calidad que buscábamos —velocidad, validez, legibilidad automática— se convirtió en algo que el build puede comprobar en cada versión , para mantener el estándar sin depender de que alguien recuerde hacerlo. Figura — el ciclo acumulativo de calidad **Figure:** Un ciclo acumulativo: oficio y velocidad mejoran la visibilidad, atraen a las personas adecuadas, fortalecen la reputación y permiten reinvertir en más calidad > **Figure caption:** Ninguna mejora es decisiva por sí sola; juntas se refuerzan y mantienen el movimiento. Esa acumulación es toda la estrategia, y es exactamente lo que alimenta la red del capítulo 1. ## 03 Velocidad, porque los milisegundos cuentan en el reclutamiento Un futuro estudiante con una conexión inestable en una zona de gran altitud no espera a que cargue una página lenta: se va. Por eso nos medimos en dispositivos móviles, donde realmente importa, frente a las escuelas de ingeniería más famosas del mundo; no para afirmar que enseñamos mejor, sino para establecer un orden de magnitud técnico. Figura — la carrera de velocidad móvil (Lighthouse, 19 de junio de 2026) **Figure:** Puntuaciones de rendimiento móvil: DSTI encabeza con 96, seguido de Edinburgh 75, Imperial 70, Stanford 68, Cambridge 63, CentraleSupélec 58, MIT 57, Harvard 55, Polytechnique 50 y ETH Zürich 39 > **Figure caption:** Mediciones de laboratorio, no una clasificación permanente: las páginas, redes, herramientas de consentimiento y cachés son distintas, y esto no dice nada sobre la calidad de estas excelentes instituciones. La figura contextualiza un orden de magnitud técnico: en un teléfono, nuestra página de inicio es la más rápida del grupo. Una captura rápida puede ser cuestión de suerte; un sitio rápido de forma constante es ingeniería. Las tres métricas que realmente utilizan los Core Web Vitals de Google —la rapidez con que aparece el contenido principal, la velocidad de respuesta de la página a una interacción y cuánto se desplaza visualmente durante la carga— se encuentran dentro de la categoría «buena», y el build mantiene ese nivel en cada versión. El HTML pregenerado en S3 detrás de un CDN elimina por completo el renderizado por solicitud; además, utilizamos imágenes AVIF, indicaciones de precarga específicas, una ruta crítica deliberadamente ligera y una optimización que merece destacarse porque parece trivial, pero no lo es. ### La continuación en V308: eliminar trabajo evitable antes de cambiar la arquitectura La primera versión posterior a la reconstrucción aún mostraba una advertencia intermitente de Lighthouse en nuestro propio runtime: un controlador de desplazamiento podía escribir la barra de progreso de lectura y después pedir al navegador una geometría actualizada de las secciones durante el mismo ciclo. V308 reorganizó ese flujo alrededor de un solo `requestAnimationFrame`: la altura del encabezado sticky y las posiciones de las secciones se almacenan en caché, la geometría se lee una sola vez y las clases de progreso o estado activo se escriben después. La misma versión colocó las hojas de estilo enlazadas antes de los bloques JSON-LD extensos en las páginas mantenidas, las páginas generadas y los flujos de build de los materiales, preservando el orden de las hojas de estilo. Fue deliberadamente la opción conservadora: sin separar el CSS crítico, sin trucos de carga asíncrona de hojas de estilo y sin una nueva cascada que demostrar. La primera ejecución móvil de laboratorio después del despliegue reflejó el cambio sin fingir que una sola prueba equivale a datos de campo: First Contentful Paint se mantuvo en 0.9 s ; Largest Contentful Paint pasó de 2.9 s a 2.7 s ; Total Blocking Time bajó de 190 ms a 30 ms ; Speed Index pasó de 1.1 s a 0.9 s ; y Cumulative Layout Shift se mantuvo en 0 . La ruta crítica máxima medida se redujo de 159 ms a 98 ms . Lighthouse todavía reporta correctamente una solicitud que bloquea el renderizado —la hoja de estilo reducida de 19.5 KiB de la página— porque preferimos un primer renderizado predecible a eliminar una advertencia a cualquier costo. ### Una hoja de estilo por página y por qué es difícil La forma habitual de construir un sitio es utilizar una gran hoja de estilo compartida, lo que hace que cada página descargue, analice y aplique miles de reglas que nunca usará. Nosotros hacemos lo contrario: cada página entrega una hoja de estilo reducida a las reglas que realmente necesita. Menos datos que enviar y menos trabajo para el navegador antes de poder mostrar el contenido. El problema es que no se puede depurar únicamente a partir de lo que aparece en el HTML de la página. La versión ingenua —«elimina cualquier regla cuyo selector nunca aparezca en esta página»— rompe el sitio de forma silenciosa, porque las clases más importantes ni siquiera están en el HTML guardado. JavaScript las añade en tiempo de ejecución: un menú se vuelve `open` al tocarlo, un encabezado se vuelve `sticky` y `scrolled` al desplazarse, un cuadro de diálogo pasa a `active`, el banner de cookies alterna `consent` y un elemento se vuelve `selected` o `loading`. Si se eliminan esas reglas «no utilizadas», todas las interacciones pierden su estilo. Por eso el optimizador conserva una lista permitida deliberadamente conservadora de estos marcadores de estado dinámico y nunca los elimina. Hay otras tres dificultades: los selectores no se leen de izquierda a derecha (`:is()`, `:where()` y `:has()` anidan otros selectores, por lo que la coincidencia es recursiva); las reglas precedidas por @ se dividen en dos tipos (`@media`/`@container` envuelven reglas y deben recorrerse, mientras que `@font-face`/`@keyframes` se referencian por nombre y se mantienen opacas); y parte del CSS moderno que realmente utilizamos —consultas de contenedor con `container-type` y unidades `cqi`— es tan reciente que el propio validador HTML/CSS lo reporta como una propiedad que «no existe». El pipeline conserva estos casos como falsos positivos conocidos y revisados. Como eliminar CSS es riesgoso, cada página con CSS reducido se vuelve a comparar con la original mediante un verificador independiente antes de publicarse. ## 04 Alcance: tres idiomas con la misma prioridad El sitio nació bilingüe: inglés y francés. El español (`es-MX`) es la incorporación más reciente, y conviene explicar la lógica porque se trata de una decisión de negocio, no de un ejercicio de traducción. El español es el idioma que abre un continente entero: una sola edición da acceso a toda América Latina, excepto Brasil, mientras que cada uno de los muchos idiomas de Asia abriría solo una parte. Por eso el español merece su lugar no por ser, en abstracto, el «segundo idioma de los negocios», sino por el alcance excepcional que ofrece una sola versión lingüística. Figura — una fuente, tres idiomas con la misma prioridad **Figure:** Tres idiomas, en-GB, fr y es-MX, enlazados recíprocamente con hreflang y cada uno con gemelos legibles para máquinas > **Figure caption:** Cada idioma es un destino real con enlaces hreflang recíprocos para que los motores de búsqueda entreguen la versión correcta; las URLs nunca se traducen automáticamente. El siguiente capítulo explica con más detalle los gemelos legibles para máquinas. Lo esencial es que los idiomas no se organizan como un sitio principal al que se le añadieron traducciones. Cada uno es un destino de pleno derecho producido a partir de una sola fuente, con reciprocidad `hreflang` correcta, un `x-default` y una lista estricta de elementos que no deben traducirse: nombres de programas, marcas, nombres de certificadores y campus, y nombres de modalidades de estudio; todo lo que debe permanecer idéntico en cada idioma para seguir siendo fácil de encontrar y correcto. ### La gobernanza de traducción se convirtió en parte de la memoria del build La traducción al francés del relato largo de Team DSTI hizo visible una distinción importante: una buena guía de traducción necesita tanto reglas normativas como la evidencia que las produjo. Desde V308, el paquete de continuidad incluye una autoridad de traducción mantenida, junto con archivos de procedencia separados para francés y español mexicano. La autoridad establece lo que debe preservarse —identificadores, URLs, nombres oficiales de programas y modalidades de estudio, atribución de la primera persona, marcado y significado legible para máquinas—. Los archivos de procedencia registran cómo se expresa de forma natural el contenido público en cada idioma: francés internacional neutro con vous ; español mexicano profesional con tú ; convenciones numéricas distintas; terminología recurrente; controles de falsos amigos y variantes propias de España. Esos archivos no son notas sueltas. Son elementos obligatorios del paquete curado para el siguiente modelo y forman parte de su orden de lectura, sumas de verificación, manifiestos y reporte de estructura. Así, un futuro traductor —humano o modelo— recibe no solo la regla, sino también su procedencia y el vocabulario de QA necesario para comprobar el resultado. La localización se convierte en otra superficie de ingeniería reproducible, en lugar de depender de la memoria de quien haya traducido la última página. ## 05 Legible para las personas y para las máquinas Por primera vez en la historia de la web importan dos tipos de lectores: las personas y los sistemas de IA que cada vez responden más a sus preguntas. Una escuela que desea ser descubierta debe ser legible para ambos, así que cada página contiene más de lo que se ve. Figura — una página, cuatro representaciones, dos públicos **Figure:** Una página se despliega en HTML, JSON-LD, un gemelo Markdown y llms.txt para alimentar motores de búsqueda y asistentes de IA > **Figure caption:** El HTML visible está destinado a las personas y los rastreadores; el JSON-LD indica con precisión a las máquinas qué es un programa, una colegiatura o una fecha; el gemelo Markdown y llms.txt entregan a los sistemas de IA una copia clara y sin ambigüedades. No estamos adivinando cómo ser citados: lo exponemos de forma explícita. El HTML visible está destinado a las personas y a los rastreadores; schema.org JSON-LD indica con precisión a las máquinas qué es un programa, una colegiatura o una fecha; un gemelo Markdown fiel de cada página y un índice llms.txt entregan a los sistemas de IA una copia clara y sin ambigüedades. Cuando un futuro estudiante pregunta a un asistente «¿dónde puedo estudiar data engineering en Francia, en inglés?», los sistemas que responden leen datos estructurados y texto limpio, no intentan interpretar una página bonita. La mayoría de las instituciones no ha publicado versiones de sí mismas legibles para máquinas. Nosotros sí. ### El control de schema.org es nuestro y no hace trampa Conviene precisar dos aspectos. Primero, ese validador de schema.org es desarrollado internamente . El vocabulario es público y existe un verificador interactivo en la web, pero no hay una herramienta que pueda ejecutarse sin supervisión dentro de un build como ocurre con el validador HTML. Por eso escribimos un verificador específico que obtiene el vocabulario oficial de schema.org y reproduce, página por página y sin intervención humana, lo que mostraría el Schema Markup Validator en línea. Segundo, y más importante: nunca buscamos un resultado superficial de «cero errores, cero advertencias» eliminando marcado. schema.org es deliberadamente un vocabulario abierto , así que una propiedad que no declara formalmente genera una advertencia , no un error. La forma fácil de silenciar esas advertencias es eliminar los campos correspondientes, lo que también elimina significado. En cambio, los errores bloquean la versión por completo, mientras que las advertencias se revisan y se conservan cuando el marcado es realmente correcto y útil. Validamos la estructura sin amputarla. Una primera señal externa de que la apuesta empieza a dar resultado. Mientras terminábamos este trabajo, Lighthouse de Google —el motor detrás de PageSpeed Insights— añadió discretamente una categoría experimental de «Agentic browsing» que evalúa qué tan preparada está una página para agentes de IA, en lugar de para personas. Tres de sus comprobaciones predeterminadas son un árbol de accesibilidad bien formado, cero desplazamiento de diseño y un `llms.txt` válido. La página de inicio de DSTI supera las tres: un resultado claro de 3/3 . Google todavía indica que no utiliza `llms.txt` para Search, y la categoría está abiertamente «en desarrollo», por lo que no es un trofeo de clasificación; es la señal más clara hasta ahora de que las plataformas avanzan hacia páginas preparadas para lectores automáticos antes de que sea obligatorio. No predijimos esa auditoría. Simplemente ya la superábamos. ## 06 Construido para no romperse Estático no significa frágil; cuando se hace correctamente, significa lo contrario. Todo el sitio es HTML prerenderizado en almacenamiento de objetos, bloqueado para que solo pueda servirse mediante el CDN, con un firewall de aplicaciones web, protección DDoS administrada en el edge y DNS al frente. No existe un servidor de aplicaciones que pueda fallar a las 2 a. m., porque no hay servidor de aplicaciones. Figura — la ruta anterior de una solicitud frente a la nueva **Figure:** La ruta anterior de WordPress ensambla una página por solicitud a partir de PHP, una base de datos y plugins; la nueva entrega un archivo preconstruido desde un CDN detrás de un firewall > **Figure caption:** Arriba, la falla de una sola pieza hace fallar la página. Abajo, la página ya está construida: la persona visitante simplemente la recibe, a través de un firewall, desde una red diseñada para mantenerse disponible. La única migración realmente delicada fue el comportamiento de las URLs. La configuración anterior dependía de la lógica `try_files` de un servidor web para asociar URLs limpias, sin extensión, con archivos; el nuevo edge tuvo que reproducirla mediante una pequeña función de CDN y manejar la particularidad de que un origen bloqueado devuelve un estado distinto del esperado cuando falta un objeto. Conseguir que esa lógica de reescritura fuera exacta —para que todos los enlaces antiguos resolvieran correctamente y nada produjera un 404 por accidente— ocupó la mayor parte del trabajo verdaderamente minucioso de esas tres semanas, junto con un mapa de redirecciones desde los sitemaps del sitio anterior hacia la nueva estructura. ## 07 Validez demostrable: nueve controles y la negativa a publicar Esta es la parte que más sorprende. El sistema se niega a publicar una versión que no supera sus propias comprobaciones. No se trata de una recomendación de «ten cuidado al desplegar», sino de una máquina que no permite que una página rota o sin validar llegue al entorno público. En esencia, la publicación es una máquina de estados finitos. Figura — la publicación como máquina de estados finitos **Figure:** Estados: edición, candidato, preparación, controles de validación, listo y publicado, con un ciclo de falla hacia un candidato conservado y una transición de reversión > **Figure caption:** Nunca se publica algo parcial: una falla devuelve el sistema a un candidato conservado, y una versión puede revertirse a una versión anterior etiquetada. Determinista y reentrante. Nunca se publica algo parcial: cuando falla un control de validación, el sistema vuelve a un candidato conservado, y una versión puede revertirse a una versión anterior etiquetada. Los controles bloqueantes, en orden, son: build (esbuild analiza y minifica cada archivo externo `.js` y `.css`, mientras el minificador HTML se ejecuta con la minificación de JavaScript inline expresamente desactivada para que ningún script sea reescrito) → VNU HTML y CSS (la salida debe estar vacía) → validez del JavaScript inline (cada `