Site de conferência com Astro 5 e Tailwind 4: IA-First 2026

Acabei de publicar um artigo nos bastidores sobre como estamos a construir o site CMS Conf 2026, e é muito mais do que “apenas uma landing page”.

No artigo, eu passo por:

• por que escolhemos Astro 5 + Tailwind CSS 4 para desempenho e manutenibilidade,
• como usamos um CMS headless nativo do Git (Pages CMS) em vez de um backend tradicional,
• o que fizemos em torno de SEO, Schema.org e dados estruturados específicos de eventos,
• e como estamos a preparar o site para o futuro da pesquisa orientado para a IA com coisas como llms.txt, llms.json e atualizações automatizadas durante o processo de build.

É uma história prática sobre design, arquitetura frontend, fluxos de trabalho de conteúdo e otimização para tanto mecanismos de busca quanto LLMs, construído por uma equipa pequena e focada.

Se tem interesse em sites de conferência modernos, arquiteturas estáticas, ou SEO pronto para IA, pode achar útil.

#Astro #TailwindCSS #SEO #LLMO #AISEO #HeadlessCMS #StaticSites #CMSConf

#Como criar um site de conferência com Astro 5 e Tailwind 4

Mariusz Szatkowski Developer {WordPress | WooCommerce | AI | GEO | AEO | LLMO}

18 de dezembro de 2025

Quando começamos a planejar a presença digital para CMS Conf 2026, sabíamos que a rota padrão “tema WordPress + plugins” não ia funcionar. Queríamos algo diferente. Precisávamos de um site que não fosse apenas um folheto, mas uma plataforma de conteúdo de alto desempenho, rápida, maintenível e explicitamente projetada para a era da IA.

Aqui está a história de como a eu de site, Agnieszka Palmowska, Maciek Palmowski e eu, construo os fundamentos para CMS Conf 2026 usando um stack moderno que é o ponto doce para desenvolvimento web agora.

#Desempenho com Astro 5 e Tailwind CSS 4

Escolhemos Astro 5 por uma razão simples: desempenho é um recurso.

Por padrão, Astro envia zero JavaScript para o cliente. Isto significa que nossas páginas carregam instantáneamente, o que é crítico para utilizadores móveis verificando o cronograma ou palestrantes em wifi de conferência instável. Nós combinamos isso com Tailwind CSS 4 (usando o novo plugin Vite), que foi uma revelação.

Medimos a implementação em muitas ferramentas, uma delas foi Google PageSpeed Insights é aqui estão os resultados:

Resultado 100 alcançado

Mas deixe-me explicar o que isso realmente significa na prática. Quando falamos de “zero JavaScript”, não estamos a falar apenas de tamanhos de pacote menores. Estamos a falar sobre uma mudança fundamental em como abordamos o desenvolvimento web. SPAs tradicionais (Single Page Applications) frequentemente enviam centenas de quilobytes de JavaScript apenas para renderizar o que poderia ser conteúdo estático simples. Astro vira esse modelo de cabeça para baixo.

Aqui está como funciona: Astro renderiza o seu site inteiro para HTML estático no tempo de build. Ele apenas “hidrata” componentes interativos quando necessário, e mesmo assim, ele faz isso de forma inteligente. Se tem um componente que precisa ser interativo (como um menu de navegação ou um formulário), Astro pode isolar apenas esse componente e carregar o JavaScript para ele independentemente, deixando o resto da página como HTML leve.

Essa abordagem nos dá o melhor dos dois mundos: o desempenho de sites estáticos com a interatividade de aplicações web modernas quando precisamos dela.

Dica técnica: Se está a migrar para Tailwind 4, use o plugin @tailwindcss/vite. Compila o seu CSS em milissegundos, tornando a experiência de desenvolvimento incrivelmente rápida. Também implementámos LightningCSS (baseado em Rust) para minificação e construo um plugin Vite personalizado para pré-carregar CSS crítico, eliminando aquele “flash of unstyled content” (FOUC, o instante em que a página aparece sem estilos) perturbador.

Vejamos mais de perto a nossa configuração do Tailwind CSS 4. A nova versão traz um motor reescrito de raiz. A análise dos ficheiros à procura de nomes de classe mantém-se no tempo de build, mas o Tailwind 4 deteta as fontes sozinho, dispensando o array content da versão 3, e a configuração passa do JavaScript para o CSS, através da diretiva @theme. Isto significa:

1. Reconstruções mais rápidas: os builds incrementais que não precisam de compilar CSS novo saltam o passo mais caro, pelo que uma classe alterada aparece de imediato
2. Pacotes menores: apenas as classes que constam mesmo dos ficheiros de origem entram no resultado

Também implemento um sistema personalizado de tokens de design usando o recurso de variáveis CSS do Tailwind. Isso nos permite manter consistência em todo o site enquanto ainda temos flexibilidade para substituir valores quando necessário. Para CMS Conf, definimos nossa paleta de cores, escala de tipografia e sistema de espaçamento como variáveis CSS, então referenciamos elas em a nossa configuração Tailwind.

Nossas otimizações de desempenho não pararam por aí. Implemento:

• CSS crítico inline para conteúdo acima da dobra
• Lazy loading para imagens e iframes
• Dicas de recursos (preconnect, prefetch, preload) para recursos externos
• Service worker para funcionalidade offline
• Otimização CDN com otimização automática de imagem

#Que versão do Astro usa o site da CMS Conf em 2026

Este artigo descreve o build tal como estava em dezembro de 2025, com o Astro 5. O Astro 5.0 saiu a 3 de dezembro de 2024 (notas de lançamento do Astro 5.0). As novidades principais foram a Content Layer, as server islands, o pré-renderizado simplificado (o antigo modo de saída hybrid foi fundido com static), as variáveis de ambiente tipadas através de astro:env e o Vite 6. Num site de conteúdo, o que mais conta é a Content Layer: a equipa do Astro indica que as coleções compilam até 5 vezes mais depressa em páginas Markdown de sites com muito conteúdo e até 2 vezes mais depressa em MDX, com uma redução de 25 a 50% no uso de memória.

Desde então saíram duas versões principais. O Astro 6.0, lançado a 10 de março de 2026, exige Node 22 ou posterior, passa para o Vite 7 e o Zod 4, e acrescenta uma Fonts API integrada, uma API de Content Security Policy e coleções de conteúdo em tempo real (notas de lançamento do Astro 6.0). O Astro 7.0 chegou a 22 de junho de 2026 com o compilador de .astro reescrito em Rust, um pipeline em Rust para Markdown e MDX, e o Vite 8; a equipa do Astro mediu builds entre 15 e 61% mais rápidos nos seus próprios testes (notas de lançamento do Astro 7.0). As datas de publicação no registo do npm coincidem com estas publicações. A 15 de outubro de 2026, a meta tag generator de cmsconf.com indicava Astro v7.1.1, por isso o site em produção já passou a versão que está no título deste artigo. Para um projeto existente, as notas de ambas as versões indicam o mesmo comando: npx @astrojs/upgrade.

#Como instalar o Tailwind CSS 4 num projeto Astro

O Tailwind CSS 4.0 foi anunciado a 22 de janeiro de 2025 (anúncio do Tailwind CSS v4.0). O anúncio refere builds completos até 5 vezes mais rápidos e builds incrementais mais de 100 vezes mais rápidos, medidos em microssegundos, e aponta entre as mudanças principais a deteção automática de ficheiros de conteúdo, um plugin oficial para o Vite e a configuração CSS-first. A linha 4.x atual no npm é a 4.3.

O guia oficial (Install Tailwind CSS with Astro) tem quatro passos depois de criado o projeto Astro:

1. Instalar os pacotes com npm install tailwindcss @tailwindcss/vite.
2. Acrescentar tailwindcss() de @tailwindcss/vite a vite.plugins em astro.config.mjs.
3. Criar src/styles/global.css com @import "tailwindcss";.
4. Importar esse ficheiro num layout ou numa página e começar a usar as classes utilitárias.

Nesta configuração não existe tailwind.config.js. Os valores do tema ficam num bloco @theme no mesmo ficheiro CSS. Antes de escolher a versão 4, verifique os browsers do seu público: a página de compatibilidade indica que o núcleo do framework depende do Chrome 111, do Safari 16.4 e do Firefox 128, e o guia de atualização recomenda ficar na v3.4 se precisar de suportar browsers mais antigos.

#Pages CMS como CMS headless baseado em Git

Um gargalo comum em projetos de site estático é gestão de conteúdo. Programadores amam Markdown; equipas de marketing… não tanto.

Maciek resolveu isso integrando Pages CMS (https://pagescms.org). É um CMS headless brilhante que funciona diretamente com seu repositório GitHub. Dá à a eu de conteúdo uma UI amigável para gerir posts de blog e perfis de autor, mas por baixo dos panos, é apenas fazer commit de mudanças em nosso repo.

Por que isso funciona:

• Zero Infraestrutura: Nenhum banco de dados para manter, nenhum servidor para patchear.
• Git-Nativo: Cada mudança de conteúdo aciona nossa pipeline CI/CD, garantindo que nada quebre.
• Custo: É gratuito e de código aberto, com licença MIT.

Mas deixe-me explicar como realmente implemento isso na prática. A abordagem CMS tradicional muitas vezes envolve um banco de dados separado, sistema de autenticação e camada API. Isso adiciona complexidade, custo e potenciais vulnerabilidades de segurança. Pages CMS toma uma abordagem completamente diferente.

Aqui está a nossa configuração: Crio um diretório content dedicado em nosso repositório com estruturas de pasta claras para diferentes tipos de conteúdo:

content/
├── blog/
│   ├── post-1.md
│   └── post-2.md
├── speakers/
│   ├── speaker-1.md
│   └── speaker-2.md
└── schedule/
    ├── day-1.md
    └── day-2.md

Cada ficheiro Markdown inclui uma secção frontmatter com metadados estruturados:

---
title: "Construindo Sites de Conferência Modernos"
author: "Mariusz Szatkowski"
date: "2025-12-18"
tags: ["astro", "tailwind", "cms"]
status: "published"
featured: true
---

Pages CMS lê estes ficheiros e apresenta-os em uma interface simples. Eu de conteúdo pode:

1. Criar novo conteúdo através de um editor baseado na web com visualização ao vivo
2. Editar conteúdo existente com um editor rich text que outputs Markdown limpo
3. Gerir media fazendo upload de imagens que ficam guardadas no nosso repositório
4. Revisar mudanças através de um sistema de workflow embutido com estados draft/published

O Pages CMS guarda cada edição como um commit no ramo que está aberto no editor, por isso o histórico do conteúdo fica no Git ao lado do código. Quando a equipa edita num ramo diferente do main, as alterações chegam à produção através de um pull request. Isto significa:

• Todas as mudanças passam por nosso processo normal de code review
• Podemos executar testes automatizados em mudanças de conteúdo
• Temos um rastreamento completo de cada modificação
• Podemos reverter mudanças se necessário
• Podemos implantar atualizações de conteúdo independentemente de mudanças de código

Também implemento regras de válidação personalizadas para garantir a qualidade do conteúdo. Por exemplo, exigimos que todos os posts de blog tenham:

• Contagem mínima de palavras de 500
• Pelo menos uma imagem em destaque
• Metadados SEO adequados
• Sem links internos quebrados

Essas válidações executam automaticamente quando o conteúdo é salvo, fornecendo feedback imediato para a eu de conteúdo.

A integração com nosso processo de build é perfeita. Quando as mudanças de conteúdo são mescladas para main, nossa pipeline CI/CD automaticamente:

1. Constrói o site com o novo conteúdo
2. Executa testes de acessibilidade e desempenho
3. Implanta para produção
4. Invalida o cache do CDN
5. Envia notificações para membros relevantes da equipa

Esta abordagem baseada em Git transformou como lidamos com conteúdo. Eu de marketing agora pode fazer atualizações sem intervenção de desenvolvedor, enquanto mantemos controle completo sobre a implementação técnica.

#Como se configura o Pages CMS num repositório

Toda a configuração do Pages CMS está num único ficheiro, .pages.yml, na raiz do repositório (configuração do Pages CMS). O Pages CMS lê-o por repositório e por ramo, por isso um ramo de desenvolvimento pode trazer um modelo de conteúdo alterado sem mexer na produção. As chaves de primeiro nível são media (onde ficam os uploads e que URL são escritos no conteúdo), content (as coleções e ficheiros editáveis), components (definições de campos partilhadas), settings e actions.

Há duas definições que convém conhecer antes de a equipa começar a editar. settings.content.merge vale false por defeito, o que reescreve o ficheiro apenas a partir do esquema configurado e remove tudo o que fique fora do que o editor envia; com true, o Pages CMS funde os campos enviados com o ficheiro existente e mantém as chaves que o esquema não define (definições do Pages CMS). Num site em que os scripts de build acrescentam chaves próprias ao frontmatter, o valor por defeito apagava-as na edição seguinte. settings.commit.templates define as mensagens de commit, com valores por defeito como “Update {path} (via Pages CMS)”, o que torna fácil filtrar os commits de conteúdo no git log. A chave actions acrescenta botões que lançam workflows do GitHub Actions a partir de .github/workflows/, por exemplo um deploy ou um build de pré-visualização. O Pages CMS só funciona com o GitHub e é gratuito e com licença MIT, quer use a versão alojada, quer o instale na Vercel ou no seu próprio servidor (pagescms.org).

#Schema.org para eventos e organizações

Ranking em 2026 requer mais do que apenas palavras-chave. Precisa de estrutura.

Fomos fundo na implementação Schema.org. Construo um componente SchemaOrg.astro personalizado que gera dinamicamente dados estruturados JSON-LD para cada página.

O que implemento:

• Schema de Organização: Identificando Openweb S.C. como entidade legal.
• Schema de Evento: Fornecendo ao Google datas precisas, localização (PPNT Gdynia) e informações de bilhetes.
• Linking @id: Crucialmente, usamos referências @id para “conectar os pontos” entre a organização é o evento no Knowledge Graph do Google.

Dica Pro: Não confie em plugins SEO padrão para fazer tudo. Personalizar o Schema para ligar as suas entidades (ex: ligar o evento à sua organização via IDs) é um sinal poderoso para mecanismos de busca sobre quem é e o que faz.

#Que propriedades de Event a Google exige para resultados enriquecidos de eventos

A documentação da Google sobre eventos (dados estruturados de Event) indica três propriedades obrigatórias: name, startDate em formato ISO 8601 com hora, e location como Place com name e uma PostalAddress completa. Indicar só o nome da cidade como morada está marcado como não recomendado. As propriedades recomendadas são description, endDate, eventStatus, image (a Google recomenda 1920 px de largura, com um mínimo de 720 px), offers, organizer e performer. Em offers, price é o preço mais baixo disponível do bilhete com taxas incluídas, e 0 assinala um evento gratuito.

Numa conferência, a correspondência é direta. Em organizer referencia-se o @id da Organization dos parágrafos anteriores em vez de a repetir, offers.url aponta para a página de bilhetes e performer pode listar os oradores como entradas Person. Se o evento mudar de data, a Google documenta previousStartDate para a data antiga; tem de ser usado em conjunto com eventStatus definido como EventRescheduled, e startDate passa a ter só a nova data.

#O que é o ficheiro llms.txt para modelos de IA

Esta é minha parte favorita. A busca está a mudar. Pessoas estão a perguntar ao ChatGPT e Perplexity sobre eventos com tanta frequência quanto usam Google. Para garantir que esses sistemas de IA deem respostas precisas sobre CMS Conf, otimizamos o site para eles.

Implemento um ficheiro llms.txt na raiz do nosso site.

Pense nele como robots.txt, mas para LLMs. Fornece um resumo estruturado, rico em contexto de toda a conferência, palestrantes, datas, stack tecnológico, explicitamente formatado para ingestão de IA. Até escrevemos um script Node.js personalizado (scripts/update-llm-txt.js) que corre durante o build para analisar nossos metadados e manter este ficheiro sempre atualizado.

O resultado? Quando uma IA rastreia nosso site, ela não precisa adivinhar. Nós dizemos a ela exatamente o que é CMS Conf.

#O que deve conter um ficheiro llms.txt

A convenção por trás deste ficheiro é a proposta llms.txt de Jeremy Howard, publicada a 3 de setembro de 2024 e revista como v2 em agosto de 2026 (llmstxt.org). A proposta chama ao ficheiro llms.txt, com “s”, e é esse o caminho que cmsconf.com serve: /llms.txt devolve texto simples e /llms.json devolve JSON, enquanto /llm.txt devolve uma página HTML. O formato é Markdown numa ordem fixa:

1. Um H1 com o nome do projeto ou do site, o único elemento obrigatório.
2. Uma citação (blockquote) com um resumo curto.
3. Parágrafos ou listas opcionais com mais detalhe, sem títulos.
4. Secções sob títulos H2, cada uma com uma lista de links na forma [nome](url) e notas opcionais.

Uma secção com o título “Optional” marca os links que um agente pode saltar quando precisa de um contexto mais curto. O ficheiro da CMS Conf segue esta forma: o H1 é “CMS Conf 2026”, a citação descreve a conferência e uma secção “Project Information” lista a agenda, a página de bilhetes, o call for papers e as páginas legais. A proposta descreve o llms.txt como um ficheiro que convive com o robots.txt e os sitemaps, e nada nela obriga um modelo ou um motor de pesquisa a lê-lo.

#Como verificar links partidos no Astro antes do build

Finalmente, automatizamos as coisas chatas. Configuramos verificações pré-build com astro-link-validator para garantir que nunca enviamos um link quebrado. Validamos nossos redirecionamentos em astro.config.mjs para lidar gracefulmente com URLs legadas.

#Conclusão

Construir o site CMS Conf não foi apenas sobre código; foi sobre criar um sistema que serve nossos utilizadores (velocidade), a eu (manutenibilidade) e as máquinas que ajudam pessoas a nos encontrar (SEO & IA).

Se está a construir um site rico em conteúdo em 2026, recomendo altamente olhar para esta arquitetura Astro + Tailwind + baseada em Git CMS. É enxuta, é rápida e escala lindamente.

Veja em: https://cmsconf.com/

Estamos apenas começando. Vemo-nos em Gdynia em novembro!

#WebDevelopment #AstroJS #TailwindCSS #SEO #AI #CMSConf2026 #TechStack

Veja os meus serviços de SEO e GEO.

Um site de conferência em Astro continua a precisar de integração de IA no WordPress quando o CMS por trás da agenda começa a responder a assistentes.