Spoiler: quando é ruim, os sinais aparecem rápido

Projetos WordPress mal feitos não falham em silêncio. Eles deixam rastros.
O problema é que muita gente não sabe onde olhar.

Em 10 minutos, você consegue ter uma boa noção se está diante de:

• Um projeto profissional ou uma bomba-relógio disfarçada de site bonito

Abra o site no celular (primeiro minuto)

Antes de qualquer ferramenta, abra no mobile.

Sinais clássicos de problema:

• Site lento para carregar
• Layout “pulando”
• Texto pequeno ou mal espaçado
• Elementos quebrados

Se o site já sofre no mobile, o problema geralmente é estrutural — não é “só ajuste fino”.

Inspecione o HTML (2 minutos)

Clique com o botão direito → Inspecionar.

Se você vê:

• Camadas infinitas de <div>
• Classes genéricas e repetidas
• Estrutura semântica inexistente
• Conteúdo principal perdido no meio do código

Isso indica HTML inflado, típico de projetos feitos no arrastar e soltar.

HTML ruim é sinal de:

• SEO fraco
• Performance ruim
• Manutenção difícil

Veja quantos arquivos CSS e JS são carregados (1 minuto)

Abra a aba Network do navegador.

Red flags claras:

• 15, 20, 30 arquivos CSS
• JS sendo carregado em todas as páginas, sem necessidade
• Scripts de plugins que nem aparecem na tela

Quanto mais dependência global, pior a saúde do projeto.

Cheque a hierarquia de títulos (H1, H2, H3) (1 minuto)

Use qualquer extensão simples ou até o próprio inspector.

Problemas comuns:

• Mais de um H1
• H1 usado como elemento visual
• Pulando de H2 para H4
• Headings usados só para “aumentar fonte”

Isso é um tiro no pé para SEO e acessibilidade.

Abra o painel administrativo (2 minutos)

Se você tem acesso ao admin, a verdade aparece rápido.

Sinais de alerta:

• 15, 30, 50 plugins ativos
• Plugins com funções sobrepostas
• Plugins abandonados ou sem atualização
• Tudo resolvido com plugin, nada com código

Projeto bom usa plugin como ferramenta, não como muleta.

Dê uma olhada no banco de dados (1 minuto)

Mesmo sem aprofundar, alguns sinais gritam:

• Tabelas demais para um site simples
• Prefixos estranhos
• Plugins que criaram dezenas de tabelas
• Lixo acumulado de plugins removidos

Quando um site institucional tem mais de 200 tabelas, algo está muito errado. (História real)

Veja como o cache está sendo tratado (1 minuto)

Perguntas simples:

• Tem cache?
• Cache é de página, objeto, CDN?
• Limpa cache a cada acesso?

Cache mal configurado é quase tão ruim quanto não ter cache nenhum.

Observe como o site reage a pequenas mudanças

Esse é um teste indireto, mas poderoso.

Pergunte:

• Atualizar um plugin quebra layout?
• Trocar tema é inviável?
• Qualquer ajuste exige “rezar”?

Se sim, o projeto não foi pensado para evoluir.

O padrão por trás de tudo isso

Projetos WordPress mal feitos geralmente compartilham a mesma origem:

• Pressa
• Preço baixo
• Soluções visuais
• Falta de base técnica

O site até funciona, mas vive no limite.

Importante: WordPress não é o problema

WordPress bem utilizado:

• É rápido
• Escala
• É estável
• Aguenta tráfego
• É fácil de manter

O problema nunca foi o CMS.
O problema é como ele é usado.

Identificar um projeto WordPress mal feito cedo:

• Evita retrabalho
• Evita prejuízo
• Evita desgaste com cliente
• Evita promessas que não podem ser cumpridas

E a melhor parte:
você não precisa de ferramenta cara, só de olhar técnico.

The post Como identificar um projeto WordPress mal feito em 10 minutos appeared first on Leonardo Nascimento | Engenheiro de Software.

Vamos começar com o óbvio que ninguém gosta de dizer

WordPress move uma fatia gigantesca da internet. Portais de notícias, sites institucionais, e-commerces, projetos governamentais e empresas milionárias usam WordPress em produção, com alto tráfego e performance.

Se o WordPress fosse o problema, esses sites simplesmente não existiriam.

O que existe, na prática, é outra coisa:
WordPress virou terra sem lei técnica.

O mito: “WordPress é lento”

Não.
Lento é o jeito que ele é montado.

WordPress, por padrão:

• Renderiza HTML no servidor
• Funciona muito bem com cache
• Escala com Cloudflare, CDN e NGINX
• Aguenta alto volume quando bem configurado

O que deixa o site lento não é o core. É o ecossistema mal utilizado.

O verdadeiro vilão: o “arrastar e soltar”

Construtores visuais como Elementor, WPBakery e similares não são ferramentas neutras. Eles impõem um modelo de desenvolvimento que cobra um preço alto — e quase sempre invisível para o cliente final.

O que realmente acontece por baixo do capô

Um site feito com drag and drop geralmente entrega:

• HTML inflado, sem semântica
• CSS duplicado, inline, desorganizado
• JavaScript carregado em excesso
• Dependência de dezenas de scripts globais
• Layouts quebradiços fora do editor

Tudo isso para resolver algo simples: posicionar bloco na tela.

O problema não é o plugin. É o conceito.

Construtores visuais vendem a ideia de “qualquer um pode criar um site”.
Tecnicamente, isso é verdade.
Profissionalmente, é um desastre.

Criar um site não é:

• Arrastar caixa
• Escolher fonte
• Mudar cor

Criar um site é:

• Pensar estrutura
• Performance
• SEO
• Manutenção
• Evolução futura

E nisso, drag and drop falha e falha muito.

SEO sofre (e muito)

Sites feitos com construtores visuais costumam ter:

• Hierarquia de headings quebrada
• Conteúdo diluído em divs sem sentido
• HTML difícil de interpretar para crawlers
• Tempo de carregamento alto no mobile

Depois, o cliente culpa:

• O Google
• O WordPress
• O servidor
• O SEO

Quando, na verdade, o problema nasceu no layout.

Manutenção vira um inferno silencioso

Todo site precisa evoluir.
E é aqui que o arrastar e soltar cobra a conta.

• Atualização quebra layout
• Plugin vira dependência crítica
• Migrar tema vira pesadelo
• Refatorar é praticamente impossível

O site funciona… até o dia que não funciona mais.

E quando dá problema, ninguém quer mexer.

“Mas é mais rápido desenvolver”

É mais rápido entregar.
Não é mais rápido manter.

Construtores visuais economizam horas no início e custam meses no futuro.
É dívida técnica disfarçada de produtividade.

A culpa também acaba sendo do cliente, que pretende lançar seu negócio em 1 semana e acha um ‘programador wordpress’ que entrega o projeto em 3 dias por menos de R$ 500 (História real)

Cansei de refazer sites em WordPress que foram utilizados ‘arrastar e soltar’, quando falo para o cliente que não da para aproveitar nada, ele ainda fica bravo comigo.

Na verdade não deveria estar fazendo essa crítica, poque é muito bom refazer esses sites, você refaz o tema, olha o banco de dados e tem lá mais de 245 tabelas para um portal de notícias regional ou até mesmo institucional (Mais uma história real), com certeza não saiu por R$ 500

WordPress bem feito é outra história

Quando WordPress é usado como deve ser:

• Tema enxuto
• PHP bem estruturado
• HTML semântico
• CSS organizado
• JS apenas quando necessário
• Cache correto
• Integração com CDN

O resultado é:

• Site rápido
• SEO limpo
• Fácil de manter
• Fácil de evoluir
• Profissional

Isso não aparece em tutorial de “site em 30 minutos”.

O mercado criou o problema — e culpa a ferramenta

O que estragou a reputação do WordPress não foi o WordPress.

Foi:

• Freelancer sem base técnica
• Agência vendendo atalho
• Cliente buscando preço, não solução
• Cultura do “funciona, então tá bom”

O arrastar e soltar só acelerou esse processo.

WordPress não é amador — o uso dele que é

WordPress é uma ferramenta poderosa.
Mas ferramenta boa na mão errada vira problema.

Se você quer:

• Performance
• SEO
• Escalabilidade
• Longevidade

Então pare de tratar WordPress como brinquedo visual.

Porque no fim, não é o CMS que define a qualidade do site.
É quem está por trás das decisões técnicas.

The post WordPress não é amador. Amador é o uso que fazem dele. appeared first on Leonardo Nascimento | Engenheiro de Software.

Antes de decidir usar ou abandonar AMP, é preciso entender o problema que ele tentou resolver, quem o criou e o que mudou desde então.

O que é AMP

AMP (Accelerated Mobile Pages) é um framework criado para entregar páginas extremamente rápidas no mobile, com um conjunto restrito de HTML, CSS e JavaScript. A ideia central é reduzir ao máximo tudo que pode atrasar o carregamento.

Na prática, páginas AMP:

• carregam com menos recursos
• têm layout mais previsível
• priorizam conteúdo acima de scripts

O foco sempre foi experiência, não estética ou flexibilidade.

Quem criou o AMP e por quê

O AMP foi criado pelo Google, em parceria com outros players, por volta de 2015. Naquele período, a web mobile era lenta, pesada e inconsistente. Sites abusavam de scripts, anúncios e trackers, e a experiência no celular era ruim.

O AMP surgiu como uma resposta direta a isso: impor limites para forçar desempenho.

Para que o AMP realmente serve

O AMP serve para garantir carregamento rápido e previsível, especialmente em:

• notícias
• artigos
• conteúdos informativos
• páginas públicas e abertas

Ele nunca foi pensado para:

• aplicações complexas
• áreas autenticadas
• e-commerces completos
• experiências altamente interativas

Quando usado fora do escopo, costuma frustrar.

O auge do AMP e a associação com SEO

Durante um período, o AMP foi fortemente associado a vantagens de visibilidade, especialmente em carrosséis de notícias no mobile. Isso criou a percepção de que “usar AMP ajuda no ranking”.

Com o tempo, o Google deixou claro que não é o AMP em si que melhora SEO, mas sim os sinais de experiência (velocidade, estabilidade, interatividade). A partir daí, o AMP deixou de ser requisito e passou a ser apenas uma opção.

O que mudou nos últimos anos

Hoje, tecnologias modernas permitem alcançar desempenho semelhante ao AMP sem suas limitações:

• frameworks mais leves
• melhor uso de cache
• CDN em borda
• Core Web Vitals como métrica oficial

Além disso, o próprio Google passou a priorizar experiência medida, não tecnologia usada.

Resultado: AMP deixou de ser obrigatório e virou decisão estratégica, não padrão.

As principais vantagens do AMP

Quando bem aplicado, o AMP ainda entrega benefícios reais:

• carregamento quase instantâneo no mobile
• layout estável (baixo CLS)
• menor consumo de dados
• previsibilidade de performance

Para sites focados em leitura rápida, isso pode ser relevante.

As limitações (e por que muita gente abandonou)

O AMP impõe restrições que incomodam em projetos mais maduros:

• menos controle sobre JavaScript
• personalização limitada
• integrações mais complexas
• dependência maior de cache externo

Além disso, manter duas versões (AMP e não-AMP) aumenta custo de manutenção.

AMP vale a pena hoje?

Depende do tipo de site.

Pode fazer sentido se:

• o foco é conteúdo informativo
• o público é majoritariamente mobile
• a equipe é pequena
• performance ainda é um problema sério

Provavelmente não vale se:

• o site já tem bom desempenho mobile
• há muita interatividade
• o projeto depende de lógica complexa
• o time consegue otimizar sem AMP

AMP não é solução universal. É ferramenta específica.

Como medir engajamento em páginas AMP

Aqui está um ponto crítico: muita gente mede errado.

Métricas que fazem sentido

• tempo médio na página
• scroll depth
• taxa de retorno
• cliques em links internos
• eventos de leitura (ex.: 50%, 75%, 100%)

Essas métricas mostram se o usuário consumiu o conteúdo, não apenas se carregou rápido.

Atenção à fragmentação de dados

AMP pode gerar URLs diferentes e cache intermediário. Isso exige cuidado para:

• consolidar métricas corretamente
• evitar duplicação de sessões
• manter rastreamento consistente

Sem isso, o engajamento parece pior (ou melhor) do que realmente é.

AMP não substitui estratégia de performance

Um erro comum é usar AMP como atalho para não otimizar o site principal. Isso cria uma falsa sensação de qualidade.

AMP deve ser:

• complemento
• experimento
• ou solução pontual

Nunca muleta permanente.

Conclusão

O AMP nasceu para resolver um problema real da web mobile e cumpriu bem esse papel. Com a evolução das tecnologias e das métricas de experiência, ele deixou de ser obrigatório, mas não se tornou inútil.

Hoje, usar AMP é uma decisão consciente, não uma regra. Vale para alguns contextos, é desnecessário para outros. O que realmente importa é entregar uma experiência rápida, estável e previsível — com ou sem AMP.

The post AMP: o que é, para que serve, ainda vale a pena usar? appeared first on Leonardo Nascimento | Engenheiro de Software.

Mais do que uma nota colorida, o Lighthouse é uma ferramenta de diagnóstico. Saber usá-lo corretamente evita decisões erradas e otimizações inúteis.

O que é o Lighthouse

O Lighthouse é uma ferramenta automatizada de auditoria de páginas web. Ele analisa uma URL e gera um relatório com métricas e recomendações em cinco áreas principais:

• Performance
• Acessibilidade
• Boas práticas
• SEO
• Progressive Web App (PWA)

O objetivo não é apenas pontuar o site, mas mostrar onde estão os gargalos reais.

Onde o Lighthouse está disponível

Você pode usar o Lighthouse de várias formas:

• Chrome DevTools (nativo do navegador)
• Linha de comando (CLI)
• CI/CD (auditorias automatizadas)
• Ferramentas online baseadas no Lighthouse

Para a maioria dos casos, o DevTools já resolve bem.

Como rodar o Lighthouse pelo Chrome

1. Abra o site no Chrome
2. Pressione F12 ou Ctrl + Shift + I
3. Vá até a aba Lighthouse
4. Escolha o tipo de dispositivo (Mobile ou Desktop)
5. Clique em Generate report

Em poucos segundos, o relatório é gerado.

As métricas mais importantes (e o que elas significam)

Performance

Avalia tempo de carregamento e resposta da página. Algumas métricas-chave:

• LCP (Largest Contentful Paint)
  Mede quando o maior elemento visível aparece. Impacta diretamente a percepção de velocidade.
• INP (Interaction to Next Paint)
  Avalia a resposta do site às interações do usuário.
• CLS (Cumulative Layout Shift)
  Mede instabilidade visual (elementos “pulando” na tela).

Essas métricas fazem parte do Core Web Vitals, usados pelo Google como sinal de experiência.

Acessibilidade

Verifica se o site pode ser usado por pessoas com limitações visuais, motoras ou cognitivas. Exemplos de checagem:

• contraste de cores
• textos alternativos em imagens
• labels em formulários
• estrutura semântica do HTML

Mesmo que não seja um requisito legal em todos os casos, acessibilidade melhora usabilidade para todos.

Boas práticas

Aqui entram problemas mais técnicos, como:

• uso de APIs inseguras
• imagens com proporções erradas
• erros de console
• bibliotecas desatualizadas

É uma área que ajuda a manter o site saudável ao longo do tempo.

SEO

O Lighthouse não substitui ferramentas avançadas de SEO, mas valida o básico:

• meta tags essenciais
• indexabilidade
• uso correto de links
• estrutura mínima de conteúdo

Se o site falha aqui, dificilmente terá bom desempenho orgânico.

O erro mais comum: otimizar só para a nota

Muita gente usa o Lighthouse como competição de pontuação. Isso é um erro.

Um site pode ter nota 100 e ainda assim:

• carregar dados desnecessários
• ter arquitetura ruim
• sofrer em cenários reais de tráfego

O relatório deve ser lido como ferramenta de diagnóstico, não como objetivo final.

Mobile vs Desktop: sempre priorize mobile

O Google avalia sites com mobile-first indexing. Isso significa que:

• o relatório mobile é mais relevante
• problemas no mobile impactam mais SEO
• otimizações devem começar pelo mobile

Um site rápido no desktop e lento no celular está em desvantagem.

Lighthouse em produção e CI/CD

Em projetos mais maduros, o Lighthouse pode rodar automaticamente:

• antes de deploy
• após mudanças críticas
• em pipelines de CI/CD

Isso ajuda a evitar regressões de performance e garante que melhorias não sejam perdidas com o tempo.

Limitações do Lighthouse

Apesar de poderoso, o Lighthouse tem limites:

• roda em ambiente controlado
• não reflete todos os cenários reais
• não substitui métricas de usuários reais (RUM)

O ideal é combiná-lo com dados reais de uso, como relatórios de experiência de campo.

Quando o Lighthouse faz mais diferença

Ele é especialmente útil para:

• identificar gargalos iniciais de performance
• validar mudanças estruturais
• educar times sobre impacto técnico
• criar baseline de qualidade

Não é uma bala de prata, mas é um excelente ponto de partida.

O Lighthouse não serve para “tirar nota alta”, mas para entender como o site se comporta do ponto de vista do usuário. Quando usado com critério, ele direciona otimizações que realmente fazem diferença.

Ignorá-lo pode custar performance, experiência e visibilidade. Usá-lo mal pode custar tempo. O valor está em interpretar os dados, não apenas executá-los.

The post O que é Lighthouse e como usar para melhorar seu site appeared first on Leonardo Nascimento | Engenheiro de Software.