| Gargalo | Sintoma no PageSpeed | Correção prioritária |
|---|---|---|
| CSS por widget | Render-blocking de 200 a 500 ms | Improved CSS Loading nas Experiments |
| Imagens hero sem dimensão | CLS acima de 0,1 | Definir width/height fixos no widget |
| Widgets fora da dobra | LCP acima de 4 s no mobile | Lazy-load nativo e diferir scripts |
| HTML repintado a cada visita | TTFB acima de 600 ms | Cache de página via WP Rocket |
Legenda: o PageSpeed separa o que é peso do tema do que é peso do builder, e mostra onde atacar primeiro.
--- ## Otimizar a velocidade do Elementor pelas experiments nativas Para otimizar a velocidade do Elementor sem gastar nada, comece pelas Experiments: em painéis montados acima de 6 seções, ligar Improved CSS Loading e Optimized DOM Output costuma derrubar o tamanho do HTML em 20 a 40 KB e remover folhas de estilo não usadas. É o maior ganho gratuito antes de qualquer plugin pago. O caminho é Elementor > Configurações > Recursos (Experiments). Segundo a [documentação do Elementor](https://elementor.com/help/), o Improved CSS Loading carrega o CSS de um widget só quando ele aparece na página, em vez de um arquivo global gigante. Ative também o Inline Font Icons, que troca o pacote `eicons` por SVG embutido e elimina uma requisição de fonte. Faça um teste por vez no PageSpeed Insights: se algum widget antigo quebrar o layout, é só desligar a flag específica. Quem usa muitos widgets de terceiros deve conferir antes nas [ferramentas que deixam o Elementor mais rápido](https://full.services/ferramentas-que-deixam-o-elementor-mais-rapido-e-funcional/). --- ## Reduza o CSS e o JavaScript que o builder injeta Cortar o CSS e o JavaScript extra é o passo que mais move o ponteiro para otimizar a velocidade do Elementor depois das Experiments: o Elementor PRO injeta scripts de animação, sticky e motion effects mesmo em páginas que não os usam. Em média, isso adiciona de 80 a 150 KB de JavaScript bloqueante por página, que o navegador precisa baixar antes de pintar. A correção tem duas camadas. A primeira é desativar o que não se usa: em Elementor > Configurações, desligue o Google Fonts quando o tema já carrega a tipografia, e evite empilhar motion effects em cada seção. A segunda camada é diferir a execução com um plugin de performance. O [WP Rocket](https://wp-rocket.me/) oferece Delay JavaScript Execution, que segura os scripts até a primeira interação do usuário. Aplique com cuidado: scripts de animação da primeira dobra precisam de exclusão, ou a página pinta sem efeito por um segundo. Para minificação, o glossário da [minificação](https://full.services/glossario/minificacao/) explica o trade-off entre tamanho e risco de quebra. --- ## Diferir imagens e widgets fora da primeira dobra Diferir o que está fora da tela inicial reduz o LCP em 1 a 2 segundos no mobile, porque o navegador para de baixar mídia que o usuário ainda não vê. O Elementor já traz [lazy-load nativo](https://full.services/lazy-load-wordpress/) para imagens, ativável em Elementor > Configurações > Recursos, sem custo de plugin. O ponto crítico é a exceção: a imagem hero da primeira dobra NÃO pode ter lazy-load, porque ela É o elemento de LCP. Adiar o carregamento dela piora a métrica em vez de melhorar. Defina `fetchpriority="high"` na imagem principal e lazy-load em todo o resto. Para vídeos de fundo e iframes do YouTube, troque o embed direto por um placeholder com clique, o que economiza de 500 KB a 1 MB no carregamento inicial. Galerias e carrosséis abaixo da dobra também ganham com lazy-load. Esse cuidado com a ordem de carregamento é o mesmo que sustenta um bom [preloader no Elementor](https://full.services/criar-preloader-no-elementor/), que esconde o repintar enquanto os assets chegam. --- ## Carregue fontes sem travar a renderização Controlar o carregamento de fontes ajuda a otimizar a velocidade do Elementor ao evitar o flash de texto invisível, que pode segurar a pintura do texto por 300 a 800 ms. O Elementor, por padrão, busca fontes do Google em servidores externos, o que adiciona uma conexão DNS extra e atrasa o First Contentful Paint. A correção tem três frentes. Primeiro, hospede as fontes localmente: o Perfmatters tem a opção Local Google Fonts, que baixa os arquivos para o seu servidor e remove a chamada externa. Segundo, aplique `font-display: swap` para o navegador mostrar uma fonte de sistema enquanto a definitiva carrega. Terceiro, faça preload só dos dois pesos realmente usados na primeira dobra, porque preload de fonte demais compete com a imagem hero pelo mesmo budget de rede. Em sites com muitas variações de peso, limitar a tipografia a um ou dois pesos por página já corta de 100 a 250 KB de download. --- ## Ative o cache de página para otimizar a velocidade do Elementor O cache de página é o que transforma o ganho em estável: sem ele, o WordPress remonta todo o HTML do Elementor a cada visita, o que mantém o TTFB acima de 600 ms mesmo numa hospedagem boa. Um plugin de [cache de página](https://full.services/cache-wordpress-plugin/) guarda a versão pronta e serve em poucos milissegundos. O WP Rocket ativa cache, minificação e lazy-load num só painel; o Perfmatters foca em remover o que não se usa, e os dois rodam bem juntos quando você não duplica a mesma função. O comparativo entre [Perfmatters e WP Rocket](https://full.services/perfmatters-vs-wp-rocket/) ajuda a decidir o papel de cada um. Regra de ouro: ative o cache por último, depois de limpar CSS e JavaScript, para não cachear uma página ainda inchada. Combine com o glossário de [cache de página](https://full.services/glossario/cache-de-pagina/) para entender o que fica em disco. --- ## Acelere o Elementor com o bundle da FULL Acelerar o Elementor de forma definitiva costuma exigir mais de um plugin pago, e é aí que o custo avulso pesa: licença do Elementor PRO, do WP Rocket e do Perfmatters somadas passam de R$1.000 por ano por site. No plano PRO da FULL, por R$849 você ativa esses três e mais 14 plugins premium em um clique, o que dá cerca de R$85 por site quando você gerencia 10 projetos. A gente vê no suporte que a maioria dos sites Elementor lentos não precisa de nova hospedagem, e sim dessa combinação de cache, otimização de assets e fontes locais já configurada. Para quem gerencia carteira, é a forma mais barata de otimizar a velocidade do Elementor em escala. Quem cuida de vários sites para de pagar licença avulsa por projeto. Veja os [planos da FULL](https://full.services/planos) e compare com o custo somado das licenças individuais. --- ## Próximos passos para manter o Elementor rápido Manter a velocidade exige reteste a cada mudança grande de layout, porque um único widget de Posts ou Carousel novo na primeira dobra reabre o problema de LCP que você acabou de resolver. Depois de aplicar os seis passos para otimizar a velocidade do Elementor, rode o PageSpeed Insights em mobile e compare com a linha de base: o alvo é LCP abaixo de 2,5 s e CLS abaixo de 0,1. Se a página ainda travar mesmo com tudo configurado, o gargalo provavelmente saiu do builder e foi para a hospedagem: vale revisar o diagnóstico de [por que o Elementor fica lento](https://full.services/elementor-lento/). Para aprofundar cada lever de performance, o FULL Academy reúne os tutoriais e guias num só lugar. ## Perguntas frequentes sobre otimizar a velocidade do ElementorO Elementor injeta CSS por widget, scripts de animação e fontes externas que o navegador precisa baixar antes de pintar a tela, somando de 8 a 15 requisições por página. Hospedagem boa reduz o TTFB, mas não remove esses arquivos. Por isso o ganho real vem de cortar assets e diferir o que está fora da primeira dobra, não de trocar de servidor.
Sim, e na maioria dos casos a troca de tema é desnecessária. As Experiments nativas (Improved CSS Loading, Optimized DOM Output) mais cache de página e lazy-load resolvem a maior parte dos casos de LCP alto. A gente vê no suporte da FULL que poucos sites lentos no Elementor precisam de tema novo; quase sempre o problema é excesso de widgets pesados na dobra inicial e ausência de cache.
A ordem que rende mais para otimizar a velocidade do Elementor é: primeiro ligar as Experiments do Elementor, depois cortar CSS e JavaScript extra e hospedar fontes localmente, em seguida diferir imagens e widgets fora da dobra, e só por último ativar o cache de página. Ativar o cache antes de limpar os assets congela uma página ainda inchada, e você perde a chance de medir o efeito de cada lever isolado.
O cache de página derruba o TTFB de mais de 600 ms para poucos milissegundos ao servir HTML pronto, e o lazy-load corta de 1 a 2 segundos do LCP no mobile ao adiar mídia fora da tela. Juntos, costumam levar um LCP de 4 s para a faixa abaixo de 2,5 s, que o web.dev define como bom. O ganho exato varia conforme o número de widgets pesados na primeira dobra.
As Experiments do Elementor entregam Improved CSS Loading, que carrega o estilo de um widget só quando ele aparece, Optimized DOM Output, que reduz o HTML gerado, e Inline Font Icons, que troca o pacote eicons por SVG embutido. Esses três recursos são gratuitos e removem CSS não usado e uma requisição de fonte antes de qualquer plugin pago. É sempre o ponto de partida recomendado.
| Gargalo | Sintoma no PageSpeed | Correção prioritária |
|---|---|---|
| CSS por widget | Render-blocking de 200 a 500 ms | Improved CSS Loading nas Experiments |
| Imagens hero sem dimensão | CLS acima de 0,1 | Definir width/height fixos no widget |
| Widgets fora da dobra | LCP" }, { "@type": "HowToStep", "position": 2, "name": "Otimizar a velocidade do Elementor pelas experiments nativas", "text": "Para otimizar a velocidade do Elementor sem gastar nada, comece pelas Experiments: em painéis montados acima de 6 seções, ligar Improved CSS Loading e Optimized DOM Output costuma derrubar o tamanho do HTML em 20 a 40 KB e remover folhas de estilo não usadas. É o maior ganho gratuito antes de qualquer plugin pago. O caminho é Elementor > Configurações > Recursos (Experiments). Segundo a documentação do Elementor, o Improved CSS Loading carrega o CSS de um widget só quando ele aparece na página, em vez de um arquivo global gigante. Ative também o Inline Font Icons, que troca o pacote `eicons` por SVG embutido e elimina uma requisição de fonte. Faça um teste por vez no PageSpeed Insights: se algum widget antigo quebrar o layout, é só desligar a flag específica. Quem usa muitos widgets de terceiros deve conferir antes nas ferramentas que deixam o Elementor mais rápido. ---" }, { "@type": "HowToStep", "position": 3, "name": "Reduza o CSS e o JavaScript que o builder injeta", "text": "Cortar o CSS e o JavaScript extra é o passo que mais move o ponteiro para otimizar a velocidade do Elementor depois das Experiments: o Elementor PRO injeta scripts de animação, sticky e motion effects mesmo em páginas que não os usam. Em média, isso adiciona de 80 a 150 KB de JavaScript bloqueante por página, que o navegador precisa baixar antes de pintar. A correção tem duas camadas. A primeira é desativar o que não se usa: em Elementor > Configurações, desligue o Google Fonts quando o tema já carrega a tipografia, e evite empilhar motion effects em cada seção. A segunda camada é diferir a execução com um plugin de performance. O WP Rocket oferece Delay JavaScript Execution, que segura os scripts até a primeira interação do usuário. Aplique com cuidado: scripts de animação da primeira dobra precisam de exclusão, ou a página pinta sem efeito por um segundo. Para minificação, o glossário da minificação explica o trade-off entre tamanho e risco de quebra. ---" }, { "@type": "HowToStep", "position": 4, "name": "Diferir imagens e widgets fora da primeira dobra", "text": "Diferir o que está fora da tela inicial reduz o LCP em 1 a 2 segundos no mobile, porque o navegador para de baixar mídia que o usuário ainda não vê. O Elementor já traz lazy-load nativo para imagens, ativável em Elementor > Configurações > Recursos, sem custo de plugin. O ponto crítico é a exceção: a imagem hero da primeira dobra NÃO pode ter lazy-load, porque ela É o elemento de LCP. Adiar o carregamento dela piora a métrica em vez de melhorar. Defina `fetchpriority="high"` na imagem principal e lazy-load em todo o resto. Para vídeos de fundo e iframes do YouTube, troque o embed direto por um placeholder com clique, o que economiza de 500 KB a 1 MB no carregamento inicial. Galerias e carrosséis abaixo da dobra também ganham com lazy-load. Esse cuidado com a ordem de carregamento é o mesmo que sustenta um bom preloader no Elementor, que esconde o repintar enquanto os assets chegam. ---" }, { "@type": "HowToStep", "position": 5, "name": "Carregue fontes sem travar a renderização", "text": "Controlar o carregamento de fontes ajuda a otimizar a velocidade do Elementor ao evitar o flash de texto invisível, que pode segurar a pintura do texto por 300 a 800 ms. O Elementor, por padrão, busca fontes do Google em servidores externos, o que adiciona uma conexão DNS extra e atrasa o First Contentful Paint. A correção tem três frentes. Primeiro, hospede as fontes localmente: o Perfmatters tem a opção Local Google Fonts, que baixa os arquivos para o seu servidor e remove a chamada externa. Segundo, aplique `font-display: swap` para o navegador mostrar uma fonte de sistema enquanto a definitiva carrega. Terceiro, faça preload só dos dois pesos realmente usados na primeira dobra, porque preload de fonte demais compete com a imagem hero pelo mesmo budget de rede. Em sites com muitas variações de peso, limitar a tipografia a um ou dois pesos por página já corta de 100 a 250 KB de download. ---" }, { "@type": "HowToStep", "position": 6, "name": "Ative o cache de página para otimizar a velocidade do Elementor", "text": "O cache de página é o que transforma o ganho em estável: sem ele, o WordPress remonta todo o HTML do Elementor a cada visita, o que mantém o TTFB acima de 600 ms mesmo numa hospedagem boa. Um plugin de cache de página guarda a versão pronta e serve em poucos milissegundos. O WP Rocket ativa cache, minificação e lazy-load num só painel; o Perfmatters foca em remover o que não se usa, e os dois rodam bem juntos quando você não duplica a mesma função. O comparativo entre Perfmatters e WP Rocket ajuda a decidir o papel de cada um. Regra de ouro: ative o cache por último, depois de limpar CSS e JavaScript, para não cachear uma página ainda inchada. Combine com o glossário de cache de página para entender o que fica em disco. |