LCP acima de 2,5s sangrando conversão
Hero lento, font blocking, JavaScript que trava o main thread. Audit com Lighthouse, WebPageTest e RUM real, depois cirurgia por prioridade.
Eixo 01
Front-end development e performance
Front-end development de quem entende que código bom é código rápido. HTML semântico, CSS vanilla com custom properties, JavaScript sem framework, temas e plugins WordPress custom, Core Web Vitals no verde e design systems que ainda vão rodar daqui a 5 anos sem quebrar em cada update de Node.
A maioria dos sites lentos não é lenta por falta de hosting. É lenta porque o código acumula peso, framework sobre framework, plugin sobre plugin, build step que ninguém audita. O meu trabalho é o oposto: vanilla primeiro, framework só quando o problema realmente pede, performance como default e não como tarefa de fim de sprint.
Cada linha tem custo mensurável em LCP, INP, CLS e conta bancária de hosting. Trato front-end como disciplina de engenharia, tipagem forte onde possível, testes que importam, documentação que não apodrece.
Problemas que resolvo
Tipicamente, este eixo sozinho
Tema WordPress legado quebrando a cada mudança
Código spaghetti, CSS global, jQuery em tudo. Refactor incremental pra classic PHP theme custom com componentes reutilizáveis, sem virar um novo monstro.
INP ruim em forms e interações complexas
Event handlers pesados, re-render desnecessário, long tasks acima de 50ms. Trabalho com profiler real do Chrome, não com número de Lighthouse.
CLS tropeçando em fontes, imagens e ads
Font-display, dimensões reservadas, content-visibility. Estabiliza layout sem sacrificar flexibilidade visual.
Acessibilidade descoberta no teste de mercado
WCAG AA+ retroativa ou built-in: contrast, keyboard nav, ARIA landmarks, reduced motion. Axe + NVDA como parte do processo, não como revisão final.
Build step cada vez mais complexo
Vanilla, zero build. Ou Vite minimalista quando faz sentido. Sem webpack config de 500 linhas que ninguém mais entende.
Mobile morrendo em 3G/4G brasileiro
Budget real de 250KB por página, imagens responsivas com WebP, lazy loading cirúrgico. Performance em conexão ruim é a baseline, não bônus.
Combinando eixos
Quando este eixo cruza com os outros
Problema real raramente mora num eixo só. A maioria dos clientes que me procuram precisa de pelo menos dois, e o ganho é composto, não aditivo.
Junto com
SEO técnico e AEO
Front-end e SEO técnico são a mesma disciplina hoje, Core Web Vitals entra como fator de ranking, HTML semântico entra como sinal pra AI Overviews. Refatorar tema sem pensar em SEO é desperdiçar a janela; auditar SEO sem tocar o front-end é tratar sintoma. Junto, o ROI é composto: template performático + schema correto + arquitetura de conteúdo = autoridade tópica real.
Junto com
Automação e integrações com LLM
Pipeline de IA gera 500 artigos novos por mês. Se o template do WordPress não aguenta renderizar isso sem inflar TTFB, o ganho de produção vira dívida de performance. Front-end performático é pré-requisito pra content velocity de verdade, template enxuto, componentes parametrizáveis e cache HTTP correto.
Entregáveis
O que chega na sua mão
- Implementação from scratch ou refactor incremental
- Tema/plugin WordPress custom (classic PHP, sem FSE)
- Componentes reutilizáveis + design tokens
- Otimização de Core Web Vitals (LCP, INP, CLS)
- Acessibilidade WCAG AA+ retroativa ou built-in
- Performance budget + monitoring contínuo
- Design system documentado e versionado
Stack deste eixo
HTML semânticoCSS custom propertiesJavaScript vanillaWeb ComponentsWordPress (temas e plugins)PHP 8.2+GatsbyShopify themingVite (quando faz sentido)Lighthouse CIWebPageTest
Projetos deste eixo
Exemplos reais que passaram pelo meu teclado
Refactor de calculadoras com Design System
Suite de calculadoras médicas refatorada como Web Components nativos, 100% aderentes ao design system, com a11y AA+ e zero dependências JS.
2025Ler case
Plugin WordPress com fix de timezone (UTC)
Plugin com datas deslocadas 3h em cenários de cron. Regra única: UTC como fonte da verdade, conversão só no display. Zero tickets pós-deploy.
2025Ler case
FAQ
Perguntas frequentes
Você só trabalha com WordPress ou aceita outros stacks?
WordPress é minha especialidade mais profunda, mas trabalho com qualquer stack onde HTML/CSS/JS vanilla resolvem. Tenho cases em Shopify, Gatsby e apps estáticos. Evito frameworks de UI pesados (React/Vue/Svelte) a menos que o problema realmente peça, na maioria dos portfolios e sites de conteúdo, vanilla + Web Components é mais rápido, mais leve e mais durável.
Como você mede performance real? Só Lighthouse?
Lighthouse é ponto de partida, não destino. Uso WebPageTest pra capturar real-user metrics com throttling de rede, Chrome DevTools Performance pra profiling de main thread, e quando o cliente tem RUM (CrUX, Vercel Analytics, SpeedCurve), trabalho com esses dados também. Número sintético só importa se refletir user experience.
Preciso refazer o site inteiro ou dá pra refatorar por partes?
Refactor incremental quase sempre vale mais que rewrite. Começo pela página de maior tráfego ou maior conversão, otimizo, meço, repito. Rewrite completo só faz sentido quando o código atual não tem como ser consertado sem custo maior que recomeçar.
Vamos trabalhar juntos
Precisa de front-end e performance?
Conta o contexto em 3 linhas. Respondo em 48h com proposta ou com "não sou eu que você precisa", o que for verdade.