Última verificação: 30 de setembro de 2026
Reconstruí o kevinyoung.net como um site estático com SvelteKit e SveltePress em vez de WordPress, a ferramenta que uso na maior parte do trabalho para clientes. Eu queria menos peças móveis, controle sobre cada linha que o navegador recebe e um placar público para me cobrar. Diante de uma lista de qualidade web de 172 tópicos, o site marca 92 por cento na sua própria auditoria, falhas incluídas. O WordPress continua sendo a ferramenta certa para a maioria dos sites de negócios, e a RdyToGo continua construindo esses sites. Este é um projeto pessoal: o que escolhi, o que dizem as fontes e onde começa a minha opinião.
Como um web designer acaba com um site desatualizado?
Do mesmo jeito que um mecânico acaba com um carro barulhento. Construí sites para clientes durante anos enquanto o meu ficava congelado em 2023, com uma página Sobre que descrevia um negócio que já não era mais assim.
Isso me incomodava mais do que eu admitia. Meu primeiro site foi o que um colega e eu construímos no ensino médio, por volta de 1997. Aprendemos HTML sozinhos no Bloco de Notas, e nosso professor de informática transformou esse novo passatempo em um projeto de aula: a turma inteira construiu o primeiro site da escola. Cada página era um arquivo simples em um servidor. Nada para atualizar, nada para corrigir. Simplesmente carregava.
Vinte e nove anos depois, a coisa mais moderna que consegui construir para mim acabou sendo, de novo, arquivos simples. Com muito mais cuidado por dentro.
Com qual lista eu medi?
Usei o specification.website, uma lista gratuita e aberta do que um bom site faz. Ela cobre 172 tópicos em dez categorias: Fundamentos (20), SEO (14), Acessibilidade (30), Segurança (20), URIs conhecidas (13), Preparação para agentes (21), Desempenho (26), Privacidade (7), Resiliência (8) e Internacionalização (13). Cada tópico leva ao padrão por trás dele, do W3C às WCAG, e o site diz que a especificação vale se você usa WordPress, Next.js ou HTML simples.
Uma pequena ironia me fez sorrir. A lista foi escrita por Joost de Valk, fundador do Yoast SEO, um dos plugins de WordPress mais conhecidos. Ou seja, a régua que usei para medir meu site sem WordPress veio de alguém do próprio mundo WordPress. Bons padrões não ligam para o que você usa para construir.
Pedi ao Claude que auditasse o site no ar contra cada item, e publiquei os resultados, erros incluídos. No momento em que escrevo: 92,0 por cento, 268,5 de 292 pontos aplicáveis. SEO marcou 27 de 27. Acessibilidade marcou 60 de 63. Segurança é a categoria mais fraca, com 80 por cento. A pontuação era menor quando comecei a escrever este texto, porque eu continuei corrigindo coisas.
Isso é uma autoavaliação feita por uma IA, não uma certificação, e não revisei cada linha à mão. A página da auditoria diz isso logo no início.
Por que não construir simplesmente em WordPress?
Porque o WordPress é a ferramenta certa para outro tipo de trabalho. Segundo a W3Techs, ele roda em cerca de 40 por cento de todos os sites e em quase 60 por cento dos sites com CMS conhecido. É de código aberto, o diretório de plugins cobre quase tudo e pessoas sem conhecimento técnico conseguem editá-lo. Sou coorganizador do Myrtle Beach WordPress Meetup, e a RdyToGo constrói sites em WordPress toda semana. Este não é um texto de despedida.
O WordPress, sim, vem com um trabalho de manutenção. Em setembro de 2026, a versão 7.1.1 saiu no dia 17 com um lote de correções de segurança. A versão 7.1.2 veio no dia 22 para fechar uma falha crítica, avaliada em 9,2 de 10, que podia permitir que um invasor sem login executasse código em alguns servidores. Ambas vieram com o mesmo conselho: atualize imediatamente.
As atualizações de segurança do núcleo costumam se instalar sozinhas. Nos temas e plugins, ainda é preciso clicar, testar e, às vezes, arrumar o que uma atualização quebrou. Isso não é um escândalo. É o custo de ser o software em que 40 por cento da web funciona, porque os invasores miram onde está a multidão. Passei anos nessa esteira para meus clientes, e por isso criei a Firebolt, que transforma um site WordPress em uma cópia estática já pronta.
Eu poderia ter atingido a lista com WordPress? Provavelmente, com plugins suficientes ou código personalizado suficiente trabalhando contra as premissas da plataforma. Para o meu próprio site, eu queria menos peças móveis.
Com o que eu construí?
Sete ferramentas, cada uma escolhida para uma tarefa, servidas pela Netlify e pela Cloudflare. Não digitei cada linha sozinho. Construí o site conversando com o Claude e o Claude Code, as ferramentas de programação com IA da Anthropic. Eu decidi o que construir, olhei os resultados e pedi mudanças até ficar certo. Minha página de política de IA explica quem fez o quê.
Node é o motor em que tudo roda. É mais uma coisa para manter atualizada, mas uma coisa silenciosa.
pnpm instala as peças com que o site é construído. Em vez de copiar cada pacote para cada projeto como o npm faz, ele guarda uma só cópia no disco e cria links para ela. Também não executa os scripts de instalação de um pacote novo até eu aprovar, o que bloqueia um truque favorito dos ataques à cadeia de suprimentos. A página de testes do próprio pnpm mostra que ele vence o npm nos seis cenários; uma instalação limpa do projeto de teste "alotta-files" levou 4,42 segundos contra 48,4 do npm. É o laboratório do pnpm, em uma única máquina. Fique com a direção, não com as casas decimais.
TypeScript é o corretor ortográfico do código. Ele aponta erros enquanto eu digito, antes de qualquer coisa rodar. O custo é uma curva de aprendizado e uma compilação mais rígida, e ele só pega os tipos de erro que um sistema de tipos consegue descrever.
Svelte constrói o que as pessoas veem e clicam. Ele faz o trabalho quando o site é compilado, transformando componentes em arquivos JavaScript pequenos, enquanto o React faz mais do trabalho no navegador do visitante. Mais sobre velocidade abaixo.
SvelteKit é o framework em volta do Svelte, e eu o escolhi pela seriedade com que trata sites estáticos. Por padrão, o adaptador estático faz a compilação falhar se alguma página não foi pré-renderizada, então não consigo publicar um site pela metade estático por acidente. Uma só configuração pré-comprime todos os arquivos com Brotli e gzip. A documentação chega a avisar que o modo de aplicação de página única prejudica o desempenho e o SEO.
SveltePress transforma Markdown em páginas. De fábrica ele oferece busca e um arquivo llms.txt para ferramentas de IA, mas eu dispensei os temas dele e construí um próprio, para que cada página tenha a aparência e o comportamento que eu queria. A contrapartida é a comunidade. O WordPress tem um meetup na minha cidade; eu ajudo a organizá-lo. O SveltePress tem um repositório no GitHub. Quando algo quebra às 11 da noite, essa diferença pesa.
UnoCSS escreve os estilos. Ele gera apenas os estilos que eu realmente uso e me deixa definir minhas próprias regras de design em vez de adotar as de outra pessoa. Não afirmo que gere arquivos menores que o Tailwind. Afirmo que combina melhor com o meu jeito de trabalhar.
Netlify e Cloudflare servem o site. HTTPS, cabeçalhos de segurança e proteções de DNS ficam lá, não no framework. Um site estático deixa boa parte da sua segurança nas mãos da hospedagem, então escolha bem.
O Svelte é mesmo mais rápido que o React?
No único teste público em que confio, sim. Na execução com Chrome 152 do js-framework-benchmark, o Svelte 5 marcou 1,17 e o React 19 (hooks) marcou 1,58 na média de CPU com chaves, onde menos é melhor. Pela minha aritmética, o número do React é cerca de 35 por cento maior.
Esse teste mede componentes atualizando uma tabela grande em uma única máquina. Ele não diz nada sobre sites inteiros, nem sobre SvelteKit contra Next.js. E, sendo honesto, em um site pessoal feito principalmente de texto, os visitantes nunca vão sentir essa diferença. O que eles sentem é quanto a página envia, e uma página pré-renderizada envia muito pouco.
E o Next.js?
Não encontrei nenhum teste público comparando SvelteKit com Next.js, então não afirmo que um seja mais rápido. Os dois podem construir um site totalmente estático.
O Next.js lista o que sua exportação estática deixa de fazer: reescritas, redirecionamentos, cabeçalhos personalizados, regeneração incremental, otimização de imagens padrão, modo rascunho e mais. Para ser justo, a saída estática do SvelteKit também não faz essas coisas sozinha. Meus redirecionamentos e cabeçalhos ficam na Netlify e na Cloudflare. A diferença que me importa são os padrões: o SvelteKit se recusa a publicar um site pela metade estático, a menos que eu diga que pode. Isso é uma preferência minha, não uma medição.
Quais projetos ainda devem usar WordPress?
A maioria. Em 1999, dei uma aula de informática para adultos pelo departamento de Parques e Recreação do meu município. Minha aluna mais velha, uma confeiteira de 82 anos, levantou o mouse da mesa na primeira noite e o apontou para a tela. Alguns meses depois, ela tocava o negócio dela pelo computador. A história dela está aqui. Pessoas como ela merecem um painel, um botão de pré-visualização e um botão grande de Publicar. Isso é WordPress.
Se a sua equipe edita conteúdo, se um time publica em conjunto ou se você precisa de comércio eletrônico, reservas ou assinaturas, use WordPress. O mesmo vale se você quer contratar ajuda com facilidade em qualquer cidade.
A pilha estática serve a outro tipo de projeto: um site pessoal, um site de marketing, documentação ou um blog em que um desenvolvedor publica e o controle de qualidade é o ponto. A maioria dos clientes da RdyToGo pertence ao primeiro grupo, e tudo bem. O segundo grupo agora tem uma opção que antes não estava no nosso cardápio. Escolher a ferramenta certa para cada projeto é o trabalho todo.
O que eu errei pelo caminho?
Bastante, e a página da auditoria guarda os recibos.
- Minha primeira tentativa de favicon vetorial pesava 827 KB, traçado a partir de uma foto com 1.481 caminhos. Um traçado mais simples e uma limpeza o levaram a 27 KB.
- Um teste só com teclado descobriu que o painel de ajustes de exibição abria, mas deixava o foco para trás, então apertar Tab passava direto por ele. Corrigido.
- Desligar o JavaScript revelou uma fileira de botões mortos: menu, busca, troca de tema. Agora eles ficam ocultos até os scripts rodarem, e uma fileira simples de links substitui o menu.
- Em um celular lento simulado, a imagem principal ainda leva 4,6 segundos para aparecer. A linha de "bom" do Google é 2,5 segundos. Esse ainda está em aberto.
- As páginas em espanhol e português começaram como traduções automáticas. Amigos que falam esses idiomas nativamente estão revisando.
Prefiro mostrar essa lista a mostrar uma pontuação perfeita.
Qual é a evidência por trás dessas afirmações?
Esta seção é para leitores que querem conferir meu trabalho. Abri cada fonte abaixo em 30 de setembro de 2026.
Svelte contra React. js-framework-benchmark, resultados oficiais com Chrome 152. Implementações com chaves, CPU, média geométrica ponderada da lentidão em relação à implementação mais rápida. O Svelte 5.42.1 marcou 1,17; o React Hooks 19.2.0 marcou 1,58. O "cerca de 35 por cento" é minha aritmética: (1,58 − 1,17) ÷ 1,17. A página não mostra data de execução, então cito pela versão do Chrome. Ela mede frameworks de interface, não SvelteKit contra Next.js.
pnpm. Página de testes do pnpm, projeto alotta-files, npm 12.1.0 contra pnpm 12.7.0, a mais rápida de três execuções, em uma conexão emulada de 50 ms e 200 Mbps. Instalação limpa: 48,4 s contra 4,42 s. Sem mudanças: 1,24 s contra 18 ms. Os testes são rodados pelo próprio fornecedor em uma única máquina, três de nove cenários ficam de fora e a página é reconstruída com números novos a cada implantação.
WordPress. Uso: W3Techs, 21 de setembro de 2026. Versões: WordPress 7.1.1 (17 de setembro) e 7.1.2 (22 de setembro), que corrigiu a CVE-2026-87902.
A auditoria. kevinyoung.net/website-audit: 268,5 de 292 pontos aplicáveis, ponderados pelo nível de cada item (3 pontos para Obrigatório, 2 para Recomendado, 1 para Opcional). Auditado pelo Claude, sem certificação independente.
Também conferi: a lista do specification.website, a documentação do adapter-static do SvelteKit, a documentação de exportações estáticas do Next.js e o README do SveltePress.
Perguntas frequentes
Devo mudar meu site WordPress para o SveltePress?
Provavelmente não. Se a sua equipe edita conteúdo, um time publica em conjunto ou plugins cuidam da sua loja, reservas ou assinaturas, o WordPress é a melhor escolha. Mudar significa reconstruir como as suas pessoas publicam, não só as páginas. Uma pilha estática serve a sites em que um desenvolvedor publica e o controle de qualidade importa mais. A RdyToGo constrói os dois e vai dizer qual deles o seu projeto precisa.
Minha equipe consegue editar um site SveltePress sem um desenvolvedor?
Não do jeito que editam o WordPress. O conteúdo fica em arquivos Markdown e as mudanças vão ao ar por uma etapa de compilação. Não há painel, nem botão de pré-visualização, nem plugin para instalar um recurso novo. Quem se sente à vontade com um editor de texto aprende em uma tarde. Se a sua equipe edita todo dia e prefere não ver código, escolha o WordPress.
O Svelte é mais rápido que o React?
Na execução com Chrome 152 do js-framework-benchmark, sim: o Svelte 5 marcou 1,17 e o React 19 marcou 1,58, onde menos é melhor. Isso dá cerca de 35 por cento de diferença pela minha aritmética. O teste mede a rapidez com que componentes se atualizam em uma máquina, não a rapidez com que sites inteiros carregam, e não compara o SvelteKit com o Next.js.
Essa pilha custa menos para manter?
Ela tem menos coisas que podem quebrar. Não há esteira de atualização de plugins, nem banco de dados para corrigir, e o resultado são arquivos simples. Mas menos desenvolvedores conhecem Svelte do que WordPress ou React, então encontrar ajuda é mais difícil. A manutenção fica mais barata e a contratação fica mais difícil. Planeje o orçamento para as duas coisas com os olhos abertos.
O que significa a pontuação de auditoria de 92 por cento?
Significa que o site conquistou 268,5 de 292 pontos possíveis na lista do specification.website, com mais peso para itens obrigatórios do que para opcionais. O Claude fez a auditoria, não um auditor independente, e publiquei todos os resultados, inclusive as falhas. Ela cobre SEO, acessibilidade, segurança, desempenho, privacidade e mais. O número muda conforme eu corrijo as coisas.
A RdyToGo vai abandonar o WordPress?
Não. A RdyToGo continua construindo sites em WordPress e vai continuar, porque o WordPress é a ferramenta certa para sites que os clientes editam sozinhos. A pilha estática é uma segunda opção para projetos que querem o controle e o nível de qualidade de um site ajustado à mão. Duas ferramentas, escolhidas por projeto.
Quer um site construído neste padrão?
Se você quer um site com o mesmo nível de exigência do meu, em WordPress ou nesta pilha estática, fale com a RdyToGo. Você vai falar diretamente comigo.