Core Web Vitals resgate para sites WordPress feitos com IA

#Core Web Vitals resgate para sites WordPress feitos com IA: o problema depois da construção

Um assistente de IA consegue colocar um site WordPress online numa tarde. Não consegue avisar que o quarto plugin de “velocidade” que recomendou está a lutar contra a segunda camada de cache que recomendou dois prompts antes. Os donos costumam descobrir isto através de uma captura de ecrã do PageSpeed Insights com números vermelhos, ou de um stakeholder a perguntar porque é que um site com bom aspeto carrega como em 2015. Este é um resgate feito exatamente para este padrão de falha: Core Web Vitals avariados especificamente porque a construção foi montada por prompt, não porque o negócio escolheu deliberadamente um tema pesado.

Este é um serviço mais restrito do que a otimização de velocidade geral. Uma auditoria de performance padrão assume escolhas arquitetónicas deliberadas, ainda que imperfeitas, feitas ao longo do tempo. Este resgate assume o contrário: um assistente que respondeu a dez pedidos separados com dez instalações de plugins separadas numa única sessão de construção, e um page builder que envia markup, CSS e JavaScript de cada bloco independentemente do que realmente aparece acima da linha de visão.

#Porque é que as construções com IA destroem os Core Web Vitals

Três mecanismos aparecem em praticamente todas as construções com IA que abrimos, normalmente juntos.

Excesso de plugins. Os grandes modelos de linguagem não têm um inventário em tempo real do que já está instalado. O primeiro prompt recebe um plugin de formulários. O prompt quinze recebe um segundo plugin de formulários, porque o modelo não se lembra do primeiro prompt. Cada instalação é individualmente defensável; o peso acumulado não é. Documentámos os números anonimizados por detrás deste padrão em excesso de plugins depois de uma construção com IA: 38 plugins ativos é um ponto de partida rotineiro para uma construção com IA de três semanas, não uma excepção.

Otimizadores duplicados. A resposta instintiva a uma página lenta é “instala um plugin de cache”. Quando o TTFB continua alto uma semana depois, o próximo prompt é “instala um plugin de cache mais rápido”, muitas vezes sem desativar o primeiro. Encontramos regularmente duas caches de página completa, dois minificadores e dois plugins de otimização de imagens a lutar entre si no mesmo site, por vezes produzindo JavaScript intermitentemente avariado porque dois minificadores reescrevem os mesmos ativos de forma diferente.

Output de builder que bloqueia o render. Os page builders geram markup genérico e reutilizável para que cada bloco funcione em qualquer layout. Esse carácter genérico significa que cada bloco envia o seu próprio CSS e JS, carregado independentemente da posição no viewport. Uma secção de hero construída com um builder de arrastar-e-soltar mais um pacote de addons envia rotineiramente mais CSS que bloqueia o render do que a página inteira realmente precisa, exatamente o que arrasta o LCP e o INP para vermelho em mobile.

Vimos isto numa loja online que usava MB WAY como método de pagamento: o bloco de checkout do page builder carregava um pacote de addons próprio só para o botão de pagamento, e o widget MB WAY corria o seu próprio conjunto de scripts em cima de duas caches concorrentes. O INP na página de pagamento estava acima de 650ms antes de removermos o pacote de addons redundante e deixarmos o builder entregar apenas o widget MB WAY diretamente; depois disso o INP caiu para 190ms sem mudar de hosting.

#Prova da prática: 38 plugins para 21, TTFB 1,47s para 0,68s

A prova mais clara é o caso anonimizado documentado na íntegra em excesso de plugins depois de uma construção com IA. Um site de serviços profissionais B2B, construído em cerca de três semanas com ferramentas assistidas por IA, chegou com:

O hosting e o tema não mudaram. O ganho veio de remover plugins duplicados de SEO, cache e analytics, fundir três builders de formulários num só, e auditar três mu-plugins personalizados que o assistente tinha gerado, dos quais dois foram apagados depois de uma revisão de segurança. É assim que se parece um resgate de Core Web Vitals num site feito com IA: sobretudo desinstalações e fusões, não infraestrutura nova.

#Tabela de triagem: sintoma, causa, ação

Corra isto antes de se comprometer a um contrato completo. Diz-lhe se uma passagem rápida chega ou se a construção precisa de uma desmontagem em fases.

Se a maioria das linhas apontar para duplicação isolada de plugins, uma desmontagem focada costuma bastar. Se código personalizado de IA, excesso de plugins e fluxos partidos aparecerem juntos, planeie o resgate mais completo em vez de corrigir a performance isoladamente.

#Ordem de desmontagem em fases

O trabalho de performance segue uma ordem fixa para que uma correção não seja anulada pelo lote seguinte, e para que falhas de segurança em código personalizado não sejam expostas ao remover os plugins que as contornavam silenciosamente.

1. Congelar novas instalações. Nenhuma resposta com plugins até existir o registo da auditoria.
2. Remover primeiro os plugins de cache e otimização duplicados. Duas caches de página completa a lutarem entre si são a causa mais comum de resultados inconsistentes no PageSpeed; corrigir isto antes de tocar em qualquer outra coisa.
3. Auditar o código personalizado de IA antes de apagar os plugins comerciais à volta. Se um mu-plugin gerado depende silenciosamente de um plugin que se está a remover, apagar o plugin primeiro avaria o site.
4. Fundir ferramentas sobrepostas em lotes de cinco a oito, testando checkout e formulários depois de cada lote, medindo TTFB e número de queries.
5. Corrigir problemas do caminho de render nos templates que carregam tráfego: atrasar JS não crítico, adicionar dimensões explícitas de imagens e fontes, reduzir o uso de addons do builder no hero.
6. Medir novamente e fixar um orçamento de plugins para que a próxima alteração assistida por IA não reabra os mesmos buracos.

#Checklist de medição: LCP, INP, CLS e TTFB

Acompanhe os quatro juntos. Uma pontuação do PageSpeed sozinha esconde qual métrica concreta está realmente a impulsionar o impacto no negócio.

• LCP (Largest Contentful Paint) - objetivo abaixo de 2,5s. Medir no template de hero real, não numa página de teste leve.
• INP (Interaction to Next Paint) - objetivo abaixo de 200ms. Testar numa página com formulário ou filtro, onde os utilizadores realmente interagem.
• CLS (Cumulative Layout Shift) - objetivo abaixo de 0,1. Testar com o banner de cookies e imagens com lazy loading presentes, já que são fontes comuns de CLS em sites feitos com IA.
• TTFB (Time to First Byte) - objetivo abaixo de ~800ms sem cache numa página padrão. Medir com curl ou WebPageTest em cinco execuções e usar a mediana, não uma amostra única.
• Queries à base de dados por vista - acompanhar com o Query Monitor; assinalar tudo acima de cerca de 120 numa página de conteúdo.

Meça na página inicial, na landing page mais pesada e no checkout ou contacto. Um site que parece rápido na página inicial e lento no checkout é um padrão comum em construções com IA, porque os templates pesados de builder raramente são os que alguém testou por último.

#O que não fazer

• Não instalar mais um plugin de otimização para corrigir um site lento causado por demasiados plugins. É assim que os sites chegam a 40 plugins em primeiro lugar.
• Não correr duas caches de página completa “por segurança”. Escolher uma e configurá-la corretamente.
• Não apagar mu-plugins personalizados gerados por IA antes de auditar de que dependem. Alguns corrigem silenciosamente uma falha que outro plugin deixou aberta.
• Não perseguir uma pontuação sintética de 100 no PageSpeed à custa de LCP/INP/CLS reais nos templates que geram receita.
• Não deixar de medir as páginas de checkout e contacto porque “a página inicial está bem”. Templates secundários pesados de builder costumam ser onde vivem os piores números.

#Como corre o contrato

Passo 1 - base. Medimos LCP, INP, CLS e TTFB sem cache em templates representativos, mais um inventário completo de plugins e base de dados.

Passo 2 - auditoria. Cada plugin é mapeado à sua função real; duplicados e output do builder que bloqueia o render são assinalados.

Passo 3 - desmontagem em fases. Lotes de cinco a oito plugins, desativados, testados, medidos, depois apagados. Sem eliminações em massa em produção.

Passo 4 - correções do caminho de render. Adiar scripts não críticos, corrigir carregamento de imagens e fontes, consolidar numa única camada de cache.

Passo 5 - nova medição e fixação do orçamento. Mesmos templates, mesmas ferramentas, antes/depois documentado, mais uma regra de que nenhum plugin novo entra sem retirar ou fundir um existente.

#Serviços relacionados e leituras aprofundadas

Este resgate anda ao lado do trabalho de saneamento mais amplo que fazemos em sites gerados:

Leitura de blog aprofundada: Excesso de plugins: quando uma construção com IA o deixa 40 plugins abaixo - o caso anonimizado completo por detrás dos números usados acima.

O orçamento é individual e definido depois da auditoria base. Contacte-nos com o site e uma nota curta sobre como foi construído.