Recons­truindo a dsti.school: dezoito meses na estrada, três semanas no teclado

Esta é a versão longa de como reconstruímos dsti.school — e por que uma escola de engenharia pequena e seletiva na Riviera Francesa acabou escrevendo sua própria cadeia de construção de site estático, seu próprio validador do schema.org e seu próprio mecanismo de geolocalização na borda. A versão curta cabe em uma frase: a maior parte do que parece marketing é, na verdade, engenharia, e a maior parte da engenharia só faz sentido quando você sabe para o que ela serve. Por isso, esta postagem faz as duas coisas — os sistemas, na íntegra, e as razões por trás deles.

Dois esforços correm em paralelo ao longo da história. Um é dezoito meses construindo uma rede global de parceiros, na estrada, uma instituição por vez. O outro é três semanas reconstruindo o site do zero. Parecem não ter relação. São o mesmo projeto: uma tentativa persistente de conquistar a confiança de uma família por uma escola da qual ela muitas vezes nunca ouviu falar, em um país que raramente é seu primeiro instinto. O site é a parte desse esforço que roda enquanto todos dormem, então é bom que seja excelente.

01A razão pela qual existe: uma rede, não um mercado de origem

Antes de qualquer código: o site foi reconstruído por causa de onde os nossos alunos realmente vêm. Nos últimos dezoito meses, a rede de parceiros-conselheiros da DSTI cresceu de algumas dezenas de relacionamentos para 92 parceiros aprovados em 78 países e territórios. Esse crescimento aconteceu pessoalmente — feiras, visitas ao campus, longas conversas — e mudou o que o site precisa fazer. Ele já não é uma brochura para quem já nos conhece. É, cada vez mais, o primeiro encontro sério que um futuro aluno em Lagos, La Paz, Hanói ou Bogotá tem com a escola, em um celular, em uma conexão instável, em um idioma que pode não ser o primeiro dele.

Esse único fato estabelece quase todas as restrições técnicas que se seguem: tem que ser rápido no celular, legível para máquinas tanto quanto para pessoas, disponível em mais de um idioma como cidadão de primeira classe e impossível de publicar quebrado, porque raramente há alguém acordado para detectá-lo. Nenhuma dessas é uma escolha estética. São consequências de quem está do outro lado.

02A aposta: o ofício como único nivelador

Somos pequenos. Não temos um nome famoso nem um orçamento enorme, e não vamos adquirir nenhum dos dois neste trimestre. O que uma equipe pequena pode controlar é a qualidade daquilo que ela realmente publica. Portanto, a aposta por trás da reconstrução foi deliberadamente à moda antiga: resolver o problema com mais engenharia. Tornar o site mais rápido, mais limpo, mais correto e mais legível por máquina do que escolas cem vezes maiores que nós, porque essa é uma competição decidida pelo cuidado e pela disciplina, não pelos gastos.

É também por isso que a reconstrução criou um volante de inércia em vez de uma reformulação única. Toda propriedade de qualidade que queríamos — velocidade, validade, legibilidade por máquina — foi transformada em algo que a construção pode verificar a cada lançamento, de modo que o padrão se mantém sem que ninguém precise se lembrar de mantê-lo.

03Velocidade, porque milissegundos recrutam

Um futuro aluno em uma conexão instável e em altitude não espera por uma página lenta; ele vai embora. Por isso nos medimos no celular, onde isso realmente importa, contra as escolas de engenharia mais famosas do mundo — não para afirmar que ensinamos melhor, mas para estabelecer uma ordem de grandeza técnica.

Um único instantâneo rápido é sorte; um site rápido é engenharia. Os três números que o Core Web Vitals do Google realmente usa — a rapidez com que o conteúdo principal aparece, a rapidez com que a página responde a um toque e o quanto ela se desloca visualmente durante o carregamento — ficam todos dentro da faixa “boa”, e a construção mantém essa linha a cada lançamento. HTML pré-renderizado no S3 atrás de um CDN significa que não há nenhuma renderização por requisição; sobre isso somam-se imagens AVIF, dicas de pré-carregamento direcionadas, um caminho crítico deliberadamente leve e uma otimização que vale a pena destacar porque parece trivial e não é.

O acompanhamento do V308: remover o trabalho evitável antes de alterar a arquitetura

A primeira versão após a reconstrução ainda expôs um aviso intermitente do Lighthouse em nosso próprio tempo de execução: um manipulador de rolagem poderia escrever a barra de progresso de leitura e, em seguida, solicitar ao navegador uma nova geometria de seção no mesmo turno. O V308 reorganizou esse caminho em torno de um requestAnimationFrame: a altura do cabeçalho fixo e as posições da seção são armazenadas em cache, a geometria é lida uma vez e as classes de progresso ou estado ativo são gravadas somente depois. A mesma versão moveu folhas de estilo vinculadas à frente de blocos JSON-LD substanciais nas páginas mantidas, páginas geradas e caminhos de construção colaterais, preservando a ordem das folhas de estilo. Foi deliberadamente a opção conservadora — nenhuma divisão crítica do CSS, nenhum truque de folha de estilo assíncrona e nenhuma nova cascata a provar.

A primeira execução de laboratório no celular após a implantação refletiu a mudança sem fingir que uma única execução equivale a dados de campo: o First Contentful Paint manteve-se em 0.9 s; o Largest Contentful Paint passou de 2.9 s to 2.7 s; o Total Blocking Time caiu de 190 ms to 30 ms; o Speed Index passou de 1.1 s to 0.9 s; e o Cumulative Layout Shift permaneceu em 0. O caminho crítico máximo medido encurtou de 159 ms to 98 ms. O Lighthouse ainda relata corretamente uma requisição de bloqueio de renderização — a folha de estilo de 19.5 KiB reduzida da página — porque preferimos uma primeira renderização previsível a remover um aviso a qualquer custo.

Uma folha de estilo por página — e por que isso é difícil

A maneira usual de construir um site é uma grande folha de estilo compartilhada, o que significa que cada página baixa, analisa e aplica milhares de regras que nunca usará. Fazemos o oposto: cada página entrega uma folha de estilo reduzida às regras de que aquela página realmente precisa. Menos para enviar, menos para o navegador processar antes de conseguir pintar. O problema é que você não pode podar com base no que está no HTML da página.

A versão ingênua — “remover qualquer regra cujo seletor nunca apareça nesta página” — quebra o site silenciosamente, porque as classes que mais importam não estão no HTML salvo. O JavaScript as adiciona em tempo de execução: um menu fica open ao ser tocado, um cabeçalho fica sticky e scrolled conforme você rola, uma caixa de diálogo fica active, o banner de cookies alterna consent, um item fica selected ou loading. Remova essas regras “não utilizadas” e cada interação perde seu estilo. Por isso o otimizador mantém uma lista de permissões deliberadamente conservadora desses marcadores de estado dinâmico e nunca os remove. Outras três coisas tornam isso delicado: os seletores não são lidos da esquerda para a direita (:is(), :where(), :has() aninham outros seletores, então a correspondência é recursiva); as at-rules se dividem de duas formas (@media/@container envolvem regras e precisam ser percorridas, enquanto @font-face/@keyframes são referenciadas pelo nome e mantidas opacas); e alguns CSS modernos que realmente usamos — consultas de contêiner, com container-type e unidades cqi — são novos o suficiente para que o próprio validador de HTML/CSS os relate como uma propriedade que “não existe”, então o pipeline os carrega como falsos positivos conhecidos e revisados. Como excluir CSS é perigoso, cada página podada é então reverificada em relação à original por um verificador separado antes de poder ser publicada.

04Alcance: três idiomas de primeira classe

O site nasceu bilíngue — inglês e francês. O espanhol (es-MX) é a adição mais recente, e vale a pena expor o raciocínio, porque é uma decisão de negócio, não um exercício de tradução. O espanhol é a única língua que abre um continente inteiro: uma edição abre a América Latina (menos o Brasil) de uma só vez, ao passo que as muitas línguas da Ásia abririam, cada uma, apenas uma fração. Assim, o espanhol conquista seu lugar não por ser a “segunda língua de negócios” em abstrato, mas por seu alcance incomum por edição.

Fundamentalmente, as localidades não são um site principal com traduções acopladas. Cada uma é um cidadão de primeira classe produzido a partir de uma única fonte, com a devida reciprocidade de hreflang e um x-default, e uma lista estrita de itens que não se traduzem: nomes de programas, marcas registradas, nomes de certificadores e de campus, e nomes de modos de estudo — as coisas que precisam permanecer idênticas em todos os idiomas para continuarem localizáveis e corretas.

A governança da tradução passou a fazer parte da memória da construção

A tradução francesa da história mais longa da Team DSTI tornou visível uma distinção importante: um bom livro de regras de tradução precisa tanto de regras normativas quanto das evidências que as produziram. Por isso, no V308, a transferência trazia uma autoridade de tradução mantida, além de sidecars de proveniência separados para o francês e o espanhol mexicano. A autoridade diz o que deve ser preservado — identificadores, URLs, nomes oficiais de programas e de modos de estudo, agência em primeira pessoa, marcação e significado legível por máquina. Os sidecars registram como realmente é a linguagem pública natural em cada localidade: francês internacional neutro com vous; espanhol mexicano profissional com tú; diferentes convenções numéricas; terminologia recorrente; verificações de falsos amigos e de variantes da Espanha.

Esses arquivos não são notas soltas. Eles são membros obrigatórios do pacote curado para o próximo modelo, incluídos em sua ordem de leitura, somas de verificação, manifestos e relatório de estrutura. Isso significa que um futuro tradutor — humano ou modelo — recebe não apenas a regra, mas também sua proveniência e o vocabulário de controle de qualidade necessário para testar o resultado. A localização tornou-se mais uma superfície de engenharia reproduzível, em vez de um conhecimento retido por quem traduziu a última página.

05Legível para humanos e para máquinas

Pela primeira vez na história da web, dois tipos de leitores são importantes: as pessoas e os sistemas de IA que respondem cada vez mais às suas perguntas. Uma escola que quer ser descoberta agora tem que ser legível para ambos, para que cada página carregue mais do que aquilo que você vê.

O HTML visível é para pessoas e rastreadores; o schema.org JSON-LD diz às máquinas exatamente o que um programa, uma taxa ou uma data é; um fiel gêmeo Markdown de cada página e um índice llms.txt entregam aos sistemas de IA uma cópia limpa e inequívoca. Quando um futuro aluno pergunta a um assistente “onde posso estudar engenharia de dados na França, em inglês?”, os sistemas que respondem estão lendo dados estruturados e texto limpo, e não olhando de soslaio para uma página bonita. A maioria das instituições não publicou versões de si mesmas legíveis por máquina. Nós, sim.

O gate do schema.org é nosso e não trapaceia

Dois detalhes merecem ser explicitados. Primeiro, esse validador do schema.org é interno. O vocabulário é publicado e há um verificador interativo na web, mas nada que se possa executar de forma autônoma em uma construção da maneira que se faz com o validador de HTML — então escrevemos um verificador feito sob medida que busca o vocabulário oficial do schema.org e reproduz, página por página, o que o Schema Markup Validator on-line mostraria, sem nenhum humano no circuito. Em segundo lugar, e mais importante: nunca perseguimos a vaidade de “zero erros, zero avisos” apagando marcação. O schema.org é um vocabulário deliberadamente aberto, então uma propriedade que ele não declara formalmente é um aviso, não um erro — e a forma preguiçosa de silenciá-los é retirar os campos incômodos, o que joga fora o significado. Em vez disso, os erros bloqueiam o lançamento por completo, enquanto os avisos são revisados e mantidos sempre que a marcação é genuinamente correta e útil. Validamos a estrutura sem amputá-la.

06Construído para não quebrar

Estático não significa frágil; feito corretamente, significa o oposto. Todo o site é HTML pré-renderizado em armazenamento de objetos, bloqueado para que só possa ser servido por meio do CDN, com firewall de aplicação web e proteção DDoS gerenciada na borda e DNS na frente. Não há servidor de aplicativos para cair às 2 da manhã, porque não há servidor de aplicativos.

A única migração realmente complicada foi o comportamento das URLs. A configuração anterior dependia da lógica try_files de um servidor web para mapear URLs limpas e sem extensão para arquivos; a nova borda precisava replicar isso com uma pequena função de CDN e lidar com a peculiaridade de uma origem bloqueada retornar, para um objeto ausente, um status diferente do que as pessoas esperam. Acertar exatamente essa lógica de reescrita — para que todo link antigo resolva e nada retorne 404 por acidente — foi a maior parte do trabalho genuinamente minucioso das três semanas, ao lado de um mapa de redirecionamento dos sitemaps do site antigo para a nova estrutura.

07Compro­vadamente correto: nove gates e a recusa de publicar

Aqui está a parte que mais surpreende as pessoas. O sistema se recusa a publicar um lançamento que falha em suas próprias verificações. Não “tenha cuidado ao implantar” — uma máquina que não deixa uma página quebrada ou não validada entrar no ar. No fundo, a publicação é uma máquina de estados finitos.

Nada parcial é enviado: um gate com falha retorna o sistema a um candidato retido, e um lançamento pode ser revertido para uma versão anterior marcada. Os gates de bloqueio, em sequência, são: construir (o esbuild analisa e minifica todo .js e .css externo, enquanto o minificador de HTML roda com a minificação de JavaScript inline forçada como desativada, de modo que os scripts nunca são reescritos) → VNU HTML e CSS (a saída deve estar vazia) → validade do JavaScript inline (todo <script> executável, manipulador on* e URL javascript: deve ser analisável) → preservação exata de bytes do JavaScript inline ao longo da minificação → otimização conservadora de CSS por página (somente reescritas na lista de permissões, cada página comprovadamente equivalente) → validade de JSON-LD / schema.org → prova de reconstrução byte a byte idêntica → autoridade de versão entre fontes (cinco documentos devem concordar sobre a versão ativa) → publicar, com um marcador do-not-deploy e marcação de versão para reversão.

# publish() — simplified; every step is a hard gate
def publish(candidate):
    stage(candidate)                  # into a verified temp tree
    for gate in [
            build,                # esbuild parses/minifies every .js and .css; inline JS untouched
            vnu_html, vnu_css,    # W3C/VNU must print nothing — HTML and CSS alike
            inline_js_valid,      # every inline script, on-handler, javascript: URL must parse
            inline_js_preserve,   # inline JS byte-identical, before vs after minification
            css_allowlist,        # per-page CSS pruned; only allow-listed rewrites, proven equivalent
            schemaorg,            # JSON-LD validates against the live vocabulary
            byte_identical,       # published == validated source, to the byte
            version_authority]:   # five documents agree on the active version
        if not gate(candidate).ok:
            mark("DO_NOT_DEPLOY"); keep(candidate)   # retained for retry; nothing ships
            return Blocked
    aws_publish(candidate); tag_version(candidate)   # transactional; rollback enabled
    return Published

Um gate que você executa a cada lançamento precisa ser rápido, por isso aceleramos drasticamente a validação de HTML e CSS — e, o que é crucial, provamos que o caminho rápido retorna exatamente os mesmos veredictos que o confiável, mesmo em fixtures deliberadamente quebradas e em caminhos Unicode complicados. Velocidade sem essa prova seria trapaça; velocidade com ela é apenas boa engenharia.

08A máquina inteira, de ponta a ponta

Antes do “como”, aqui está tudo em uma página — todas as linguagens e ferramentas da cadeia que transforma uma linha de planilha em uma página na borda. É deliberadamente poliglota e vendorizado: o núcleo em Python tem zero dependências de terceiros, e as ferramentas mais pesadas viajam dentro do projeto, fixadas, tanto para Windows quanto para macOS, de modo que qualquer máquina possa reproduzir uma compilação sem instalações globais.

Um condutor Python sem dependências de terceiros aciona o conjunto de ferramentas — uma ferramenta de inventário de conteúdo em .NET 8, um verificador interno de schema.org em Python, o Nu Html Checker baseado em Java (que valida HTML e CSS), um minificador em Node ladeado, no mesmo estágio de construção, por um validador de JavaScript inline e um otimizador conservador de CSS por página, e um mecanismo de geolocalização em XML/XSD. A saída é um site estático com impressão digital — cada byte contabilizado por somas de verificação e um manifesto por arquivo — servido a partir do armazenamento de objetos por meio do CDN. As duas peças legadas ainda em migração são uma instalação do WordPress que contribui com imagens em tempo de construção (não em tempo de execução) e um único formulário de inscrição com estado.

Um mecanismo de conteúdo para todos, não apenas para engenheiros

O objetivo de toda essa disciplina é que pessoas que não são engenheiras possam contribuir com segurança. A superfície de edição é uma planilha; uma ferramenta de inventário de conteúdo a lê; o orquestrador Python conduz cada etapa; e os gates acima significam que um colega que edita uma taxa ou uma data não consegue publicar por acidente algo inválido. O ciclo é fechado e se autoverifica.

09Dinâmico onde é importante

Um site estático não precisa ser inerte. Onde ajuda genuinamente o visitante, a página se adapta — mas por meio de um mecanismo de regras pequeno e validado, em vez de scripts ad hoc. O roteamento com reconhecimento de região (por exemplo, enviar um visitante do Sul da Ásia ao representante regional correto) é expresso como um conjunto de regras XML validado contra seu próprio XSD antes de ter permissão para rodar. O mesmo reflexo aparece em todos os lugares da construção: os próprios parâmetros de implantação são validados contra um esquema antes que qualquer comando possa agir sobre eles, de modo que um alvo de implantação malformado é capturado em repouso, e não no meio da implantação. Verifique e prossiga — tanto na borda quanto no pipeline.

10Construído com IA — e deliberadamente portátil

Muito disso foi construído com assistência de IA, mas não do jeito descartável de colar respostas de um chatbot. O princípio é simples: a memória do projeto reside no projeto, não em qualquer conversa ou modelo. Cada decisão importante é gravada em arquivos de continuidade versionados que viajam com o repositório — um para conteúdo (versão de referência, regras de tradução, invariantes de UI/UX, URLs, mídia, decisões de não regressão), um para ferramentas (validações, procedimentos AWS, incidentes conhecidos). Um novo colaborador, humano ou modelo, parte desses arquivos e do pacote autoverificável, e não do histórico de conversa de alguém.

Isto não é teórico: a transferência foi exercida em diferentes modelos, com um segundo modelo reconstruindo de forma independente a versão ativa e verificando cada soma de verificação antes de propor uma alteração. No V308, a transferência compacta era uma lista de permissões rigorosamente curada, e não um despejo de pasta conveniente: fonte e saída mantidas, ContentInventory ativo, autoridade de tradução e evidências de localidade, código-fonte das ferramentas, estrutura do pacote gerado, manifesto por arquivo e uma linha de base de somas de verificação verificada de forma independente. Vincular o site de uma escola à memória de um fornecedor de IA seria apenas uma nova forma de dependência tecnológica e um novo ponto único de falha — por isso eliminamos essa dependência do projeto. E adotá-lo não deve custar a um colega uma semana de configuração: um único comando verifica as ferramentas de que a construção precisa, instala as peças vendorizadas e se recusa a se considerar “pronto” até que os parâmetros do projeto sejam validados contra o seu esquema.

11Por que o mundo, e não o mercado interno

É justo perguntar por que uma escola francesa investe tanto no mundo e comparativamente pouco no mercado à sua porta. A resposta honesta está na natureza do que construímos. A DSTI é uma instituição projetada, desde o primeiro dia, para o mercado internacional: um corpo docente deliberadamente misto de mais de 50 acadêmicos e profissionais; uma Direção de Estudos que é, na verdade, uma função de controle de operações e qualidade de um tipo que a França mal reconhece como disciplina, muito menos valoriza; modos de estudo hiperflexíveis; bolsas de estudo por mérito; programas e avaliações exigentes; certificações profissionais; e instrução inteiramente em inglês. Nada disso foi moldado para uma captação local.

E por razões estruturais — e não uma questão de qualidade — os mercados franceses de graduação e pós-graduação são, em grande parte, insensíveis exatamente a essas coisas. Então fazemos a coisa mais francesa que se possa imaginar: exportamos. A França é uma das grandes economias exportadoras do mundo; nós também. Levamos ao mundo o melhor que a França e a DSTI têm a oferecer, e trazemos bons estudantes para tirar o máximo proveito disso.

12Uma palavra honesta: investir durante um ano difícil

Franqueza, porque é devida. O mercado do ensino superior está difícil agora, para todos. Estamos resistindo melhor do que a maioria, mas seria desonesto maquiar a situação: o número de alunos se manteve estável, em vez de crescer, desde 2024. Nesse cenário, segurar a linha é mais do que muitas instituições podem dizer — mas não é crescimento, e tudo nesta reconstrução é uma aposta de que o crescimento volta.

A atitude fácil em um ano difícil é cortar e esperar. Fizemos o oposto — investindo em programas, em pessoas, no corpo docente e em exposição internacional: a rede de parceiros, o site, os materiais de apoio. Isso foi possível graças ao apoio paciente do nosso Presidente e dos acionistas (todos pessoas físicas, todos engenheiros e cientistas) — apoio que não consideramos garantido.

13Para que serve tudo isso

A rede em 78 países, as páginas rápidas, a marcação limpa, os lançamentos comprováveis, os três idiomas — nada disso é o ponto por si só. A questão é o para quê: que um jovem, em algum lugar onde ainda não estivemos, com talento e nada mais, tenha uma chance real de uma educação séria, de uma boa profissão e de uma carreira duradoura. Somos pequenos e jovens, sem nome famoso nem orçamento vasto. O que temos é a decisão de fazer o melhor trabalho possível, na mais alta qualidade que conseguimos alcançar — e, cada vez mais, a engenharia para provar que o fizemos.

As figuras são produzidas a partir da construção real; alguns detalhes técnicos são simplificados para o público geral de engenharia. Os valores de desempenho são medições laboratoriais das execuções declaradas e não substituem os dados de campo.