--- title: "Matando performance acelerar WordPress: 5 causas e a correção essencial" description: "Quando um site WordPress fica lento, o instinto é instalar mais um plugin. Quase sempre isso piora o quadro. O que está matando a performance e." url: https://full.services/matando-performance-acelerar-wordpress/ date: 2026-06-27 author: "Clayton Margiotti" --- # Matando performance acelerar WordPress: 5 causas e a correção essencial **Matando performance acelerar WordPress** exige primeiro descobrir a causa real: hospedagem, plugins, imagens ou falta de cache. Segundo a [web.dev](https://web.dev/articles/lcp) (2026), um LCP bom fica em 2,5 s ou menos no 75º percentil. Cada correção entrega ganho diferente, de 200 ms a vários segundos. Diagnostique antes de instalar qualquer plugin. Quando um site WordPress fica lento, o instinto é instalar mais um plugin. Quase sempre isso piora o quadro. O que está matando a performance e travando a velocidade do seu site WordPress costuma ser uma de cinco causas concretas: hospedagem fraca, plugins mal calibrados, imagens pesadas, ausência de cache ou um TTFB alto no servidor. Cada uma tem um sintoma diferente e uma correção diferente. Antes de qualquer ajuste, você precisa de um número de base, medido com a mesma ferramenta, para saber se a mudança ajudou ou só mascarou o problema. Este guia mostra como diagnosticar, na ordem certa, e como acelerar sem quebrar nada. --- ## As 5 causas que estão matando a performance do WordPress São cinco as causas mais comuns por trás de matar a performance e acelerar WordPress: hospedagem compartilhada saturada, plugins lentos, imagens sem compressão, ausência de cache de página e TTFB alto. Em tickets de suporte da FULL, a hospedagem responde pela maior parte dos casos de site travado, mesmo quando o dono jurava que o gargalo era o tema. A tabela abaixo cruza cada uma dessas 5 causas com o sintoma típico e o ganho esperado quando você corrige a fonte certa, em vez de empilhar otimizações no lugar errado e nunca medir o efeito real de cada ajuste isoladamente.
Matando performance no WordPress: causa, sintoma e ganho da correção
Causa raiz Sintoma típico Ganho esperado ao corrigir
Hospedagem saturada TTFB acima de 800 ms mesmo com site otimizado De 500 ms a 2 s no tempo até o primeiro byte
Plugins lentos Admin travado e queries longas no banco Até 1,5 s removendo 2 ou 3 plugins pesados
Imagens pesadas LCP acima de 4 s no mobile De 1 a 3 s com WebP e lazy-loading
Sem cache de página Cada visita reprocessa PHP do zero Reduz o TTFB pela metade na maioria dos casos
TTFB alto Página em branco por 1 a 2 s antes de carregar Servidor responde em menos de 200 ms
Comece pela linha de cima. Não adianta comprimir imagem se o servidor leva 2 segundos para responder. A ordem de diagnóstico é o que mais economiza tempo e dinheiro de quem cuida da performance do site, e é o ponto que veremos a seguir. --- ## Por que o WordPress fica lento mesmo após otimizar Um WordPress otimizado e ainda lento quase sempre tem o gargalo no servidor, não no front-end. Em hospedagem compartilhada com PHP 7.4 e dezenas de sites no mesmo disco, o TTFB sobe acima de 800 ms antes de uma única imagem carregar, e nenhuma compressão de tela resolve isso. Nesse cenário, a relação causal é direta: hospedagem barata mais plugins acumulados mais ausência de cache de página resulta em site travado mesmo depois de você comprimir tudo. A FULL conecta mais de 150 mil sites e o padrão se repete: o dono otimiza o que vê na tela e ignora o tempo de resposta do servidor, que é invisível sem ferramenta. Atualizar para PHP 8.2 e ativar [cache de página](https://full.services/glossario/cache-de-pagina/) tende a cortar boa parte desse atraso na maioria dos cenários testados, porque o servidor passa a entregar HTML pronto em vez de reprocessar o PHP a cada visita. --- ## Passo a passo: Como acelerar o WordPress em 5 etapas Acelerar o WordPress de forma confiável segue 5 etapas em ordem fixa: medir, corrigir o servidor, limpar plugins, otimizar imagens e ativar cache. Pular a medição inicial é o erro número um, porque sem uma base de comparação em milissegundos você não sabe se a mudança ajudou ou só mascarou o sintoma. Use o [PageSpeed Insights](https://pagespeed.web.dev) e o Query Monitor para isolar cada causa antes de mexer. As etapas abaixo são passos H3 dentro deste procedimento único e devem ser executadas na sequência, validando o número a cada passo antes de avançar para o próximo ajuste. ### Passo 1: Meça a base com PageSpeed insights Rode o teste de performance três vezes no mobile e anote o LCP e o TTFB médios. Esse é o número que valida cada correção depois. ### Passo 2: Verifique o TTFB e a hospedagem Se o TTFB passa de 800 ms com o site em repouso, o gargalo é o servidor. Veja [como reduzir o TTFB no WordPress](https://full.services/como-reduzir-ttfb-no-wordpress/) antes de tocar no resto. ### Passo 3: Identifique os plugins lentos Ative o Query Monitor e ordene as queries por tempo. Para um mapa completo, use o guia de [como encontrar plugins lentos no WordPress](https://full.services/encontrar-plugins-lentos-wordpress/). ### Passo 4: Otimize e converta as imagens Converta para WebP e ative lazy-loading nas imagens abaixo da dobra. O passo a passo está em [como otimizar imagens no WordPress](https://full.services/como-otimizar-imagens-no-wordpress/). ### Passo 5: Ative o cache de página Instale um [plugin de cache do WordPress](https://full.services/cache-wordpress-plugin/) e ative o cache de página. Meça de novo no PageSpeed e compare com a base do Passo 1. --- ## O servidor e o TTFB: Onde a velocidade nasce ou morre O TTFB define o teto da velocidade: nenhum truque de front-end compensa um servidor que demora 1,5 s para responder. O [TTFB](https://full.services/glossario/ttfb/) ideal fica abaixo de 200 ms, e quando ele passa de 800 ms o problema está na hospedagem, no PHP desatualizado ou na ausência de cache no nível do servidor. Subir de PHP 7.4 para PHP 8.2 já reduz o tempo de processamento de páginas pesadas em uma faixa de 20% a 30%, porque o interpretador ficou mais rápido entre essas versões. A FULL vê no suporte que migrar de hospedagem compartilhada saturada para um plano com recursos dedicados costuma derrubar o TTFB de mais de 1 s para menos de 300 ms, sem mudar uma linha do tema. O ganho aqui é estrutural: corrige a base sobre a qual todas as outras otimizações vão se apoiar depois. --- ## Plugins e banco de dados: O peso invisível Cada plugin ativo adiciona queries ao banco, e 3 ou 4 plugins mal escritos derrubam a performance mais que cem imagens pesadas juntas. O Query Monitor mostra que um único plugin de page builder mal configurado pode disparar mais de 200 queries por carregamento, contra as 30 a 50 de um site enxuto. A relação causal aparece todo dia no suporte: plugins acumulados mais banco de dados sem limpeza mais revisões de post infinitas resulta em admin travado e front-end lento mesmo com cache ativo. Desativar o que não se usa e otimizar a tabela wp_options costuma recuperar de 0,5 a 1,5 s na maioria dos casos testados. O [Perfmatters](https://full.services/perfmatters) ajuda a desligar scripts por página, um controle que o WordPress não oferece nativamente e que evita carregar código de checkout em uma página de blog. --- ## Imagens e Core Web Vitals: O front-end que o usuário sente Imagens mal otimizadas são a causa mais visível de LCP ruim: uma foto de 2 MB sem compressão pode sozinha empurrar o LCP para além de 4 s no mobile. Os [Core Web Vitals](https://full.services/glossario/core-web-vitals/) medem exatamente isso, e o [LCP](https://full.services/glossario/lcp/) é o que mais pesa para WordPress com muita mídia. Converter para WebP reduz o peso do arquivo em torno de 25% a 35% sem perda visível, e ativar [lazy-loading](https://full.services/glossario/lazy-loading/) impede que imagens fora da tela bloqueiem o carregamento inicial. Em sites de blog e portfólio que chegam ao suporte da FULL, só a otimização de imagem já tira o LCP da faixa vermelha em boa parte dos casos. Para o quadro completo das três métricas, veja o guia de [Core Web Vitals no WordPress](https://full.services/core-web-vitals-wordpress/), que conecta cada métrica a uma causa técnica concreta. --- ## Cache e CDN: Servindo a página antes de processá-la O cache de página é o ajuste de maior retorno por esforço: ele entrega HTML pronto e elimina o reprocessamento do PHP a cada visita, cortando o TTFB pela metade na maioria dos cenários testados no suporte da FULL. É o primeiro plugin a instalar depois de resolver o servidor. Um [plugin de cache](https://full.services/cache-wordpress-plugin/) bem configurado, como o WP Rocket, ativa cache de página, [minificação](https://full.services/glossario/minificacao/) de CSS e JavaScript e pré-carregamento em poucos cliques. Uma [CDN](https://full.services/glossario/cdn/) como a Cloudflare distribui os arquivos estáticos em servidores próximos do visitante, reduzindo a latência de quem acessa de outra região. A relação causal a vigiar: cache de página ativo sem exclusão do carrinho mais WooCommerce resulta em cliente vendo o carrinho de outro usuário, um bug silencioso. Para a estratégia de borda, o guia de [CDN para WordPress](https://full.services/cdn-para-wordpress/) detalha quando a rede de distribuição compensa. --- ## Acelere o WordPress com a infraestrutura certa Boa parte do que está matando a performance vem de hospedagem e plugins desalinhados, e resolver isso peça por peça custa caro: a soma das licenças premium avulsas passa fácil dos R$1.000 por ano. O plano PRO da FULL, por R$849, reúne os principais plugins de performance já licenciados e ativáveis em um clique. Esse bundle inclui WP Rocket e Perfmatters, entre outros premium. Dividido pelos sites que você gerencia, isso sai por cerca de R$85 por site. A gente vê no suporte que quem centraliza os plugins de otimização num pacote único para de perder tempo com renovações soltas e configurações conflitantes. Compare os planos em [FULL.services/planos](https://full.services/planos) e veja qual faixa cobre o seu volume de sites. --- ## Perguntas frequentes sobre acelerar o WordPress
Por que meu WordPress continua lento mesmo depois de instalar um plugin de cache?

Porque o cache trata o sintoma, não a causa, quando o gargalo está na hospedagem. Se o TTFB do servidor passa de 800 ms em repouso, o plugin de cache reduz o reprocessamento do PHP, mas o site ainda espera o servidor responder. Verifique o TTFB no PageSpeed Insights antes: se ele continua alto com o cache ativo, o problema é o plano de hospedagem ou a versão do PHP, e nenhum plugin resolve isso sozinho.

É possível acelerar o WordPress sem trocar de hospedagem?

Sim, em muitos casos. Se o seu TTFB já fica abaixo de 400 ms, o ganho está no front-end: otimizar imagens para WebP, ativar lazy-loading, ativar cache de página e usar uma CDN como a Cloudflare. Essas medidas reduzem o LCP em 1 a 3 s sem tocar no servidor. Trocar de hospedagem só vira obrigatório quando o TTFB passa de 800 ms em repouso, sinal de que o servidor está saturado e nenhum ajuste de página compensa.

Qual é o primeiro item a diagnosticar quando o site está matando a performance?

O TTFB, sempre. Ele mede o tempo até o servidor enviar o primeiro byte e define o teto de velocidade de tudo o que vem depois. Rode o PageSpeed Insights e olhe esse número antes de qualquer outra coisa: abaixo de 200 ms é bom, acima de 800 ms indica problema de hospedagem ou PHP. Começar pelas imagens ou pelo cache sem checar o TTFB é o erro mais caro, porque você otimiza a camada errada.

Quanto tempo de carregamento o Google considera aceitável para WordPress?

O Google usa o LCP como referência principal, e a meta é 2,5 s ou menos no 75º percentil dos carregamentos, segundo a web.dev. Acima de 4 s o LCP entra na faixa vermelha e prejudica a experiência e o ranqueamento. Para um WordPress com muitas imagens, atingir 2,5 s exige cache de página ativo, imagens em WebP e um TTFB abaixo de 200 ms. Meça no mobile, que é onde o Google avalia e onde o site costuma ser mais lento.

O que mais derruba a performance de um site WordPress no mobile?

Imagens sem compressão e JavaScript de terceiros pesado. No mobile, a conexão e o processador são mais limitados, então uma foto de 2 MB que passa despercebida no desktop empurra o LCP para além de 4 s no celular. Converter para WebP corta de 25% a 35% do peso, e adiar scripts não essenciais com um plugin como o Perfmatters libera a renderização inicial. O cache de página completa o trio que mais melhora a nota mobile na prática.

--- ## Próximos passos para um WordPress rápido de verdade Matando a performance e querendo acelerar o WordPress, o caminho é sempre o mesmo: medir, corrigir a causa raiz na ordem certa e validar cada mudança com o mesmo teste. Comece pelo TTFB e pela hospedagem, porque é ali que a velocidade nasce ou morre. Só depois passe para plugins, imagens e cache, sempre comparando com a base que você mediu no primeiro passo. Essa disciplina evita o ciclo de instalar plugins no escuro e nunca saber o que realmente funcionou. Para continuar aprendendo, o guia de [como acelerar o WordPress](https://full.services/guias/acelere-o-wordpress) reúne todos os tutoriais de performance em um só lugar, e a categoria de [conteúdos de performance WordPress](https://full.services/performance-wordpress/) traz os artigos mais aprofundados de cada causa. Performance não é sorte: é diagnóstico na ordem certa.

Legenda: o relatório do PageSpeed Insights é a base de comparação que valida cada correção de performance.

--- ## Metadados Estruturados (Schema.org) ```json-ld { "@context": "https://schema.org", "@graph": [ { "@type": "TechArticle", "@id": "https://full.services/matando-performance-acelerar-wordpress/#article", "headline": "Matando performance acelerar WordPress: 5 causas e a correção essencial", "description": "Quando um site WordPress fica lento, o instinto é instalar mais um plugin.", "url": "https://full.services/matando-performance-acelerar-wordpress/", "datePublished": "2026-06-27T09:00:00-03:00", "dateModified": "2026-06-27T09:00:00-03:00", "inLanguage": "pt-BR", "articleSection": "Performance WordPress", "keywords": [ "matando performance acelerar wordpress", "WordPress Performance", "Core Web Vitals", "Web Optimization" ], "author": { "@id": "https://full.services/#person-clayton" }, "publisher": { "@id": "https://full.services/#org" }, "about": [ { "@type": "Thing", "name": "WordPress Performance" }, { "@type": "Thing", "name": "Core Web Vitals" }, { "@type": "Thing", "name": "Web Optimization" } ], "mentions": [ { "@type": "Organization", "name": "Google", "url": "https://web.dev/", "@id": "https://www.wikidata.org/wiki/Q95", "sameAs": "https://www.wikidata.org/wiki/Q95" }, { "@type": "Organization", "name": "WordPress", "url": "https://wordpress.org/", "@id": "https://www.wikidata.org/wiki/Q13166", "sameAs": "https://www.wikidata.org/wiki/Q13166" } ], "mainEntityOfPage": { "@type": "WebPage", "@id": "https://full.services/matando-performance-acelerar-wordpress/" }, "wordCount": 2465, "citation": [ { "@type": "CreativeWork", "name": "web.dev", "url": "https://web.dev/articles/lcp", "publisher": { "@type": "Organization", "name": "web.dev" } }, { "@type": "CreativeWork", "name": "PageSpeed Insights", "url": "https://pagespeed.web.dev", "publisher": { "@type": "Organization", "name": "PageSpeed Insights" } } ] }, { "@type": "FAQPage", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq", "isPartOf": { "@id": "https://full.services/matando-performance-acelerar-wordpress/#article" }, "mainEntity": [ { "@type": "Question", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq-q1", "name": "Por que meu WordPress continua lento mesmo depois de instalar um plugin de cache?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Porque o cache trata o sintoma, não a causa, quando o gargalo está na hospedagem. Se o TTFB do servidor passa de 800 ms em repouso, o plugin de cache reduz o reprocessamento do PHP, mas o site ainda espera o servidor responder. Verifique o TTFB no PageSpeed Insights antes: se ele continua alto com o cache ativo, o problema é o plano de hospedagem ou a versão do PHP, e nenhum plugin resolve isso sozinho.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq-q2", "name": "É possível acelerar o WordPress sem trocar de hospedagem?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Sim, em muitos casos. Se o seu TTFB já fica abaixo de 400 ms, o ganho está no front-end: otimizar imagens para WebP, ativar lazy-loading, ativar cache de página e usar uma CDN como a Cloudflare. Essas medidas reduzem o LCP em 1 a 3 s sem tocar no servidor. Trocar de hospedagem só vira obrigatório quando o TTFB passa de 800 ms em repouso, sinal de que o servidor está saturado e nenhum ajuste de página compensa.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq-q3", "name": "Qual é o primeiro item a diagnosticar quando o site está matando a performance?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "O TTFB, sempre. Ele mede o tempo até o servidor enviar o primeiro byte e define o teto de velocidade de tudo o que vem depois. Rode o PageSpeed Insights e olhe esse número antes de qualquer outra coisa: abaixo de 200 ms é bom, acima de 800 ms indica problema de hospedagem ou PHP. Começar pelas imagens ou pelo cache sem checar o TTFB é o erro mais caro, porque você otimiza a camada errada.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq-q4", "name": "Quanto tempo de carregamento o Google considera aceitável para WordPress?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "O Google usa o LCP como referência principal, e a meta é 2,5 s ou menos no 75º percentil dos carregamentos, segundo a web.dev. Acima de 4 s o LCP entra na faixa vermelha e prejudica a experiência e o ranqueamento. Para um WordPress com muitas imagens, atingir 2,5 s exige cache de página ativo, imagens em WebP e um TTFB abaixo de 200 ms. Meça no mobile, que é onde o Google avalia e onde o site costuma ser mais lento.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/matando-performance-acelerar-wordpress/#faq-q5", "name": "O que mais derruba a performance de um site WordPress no mobile?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Imagens sem compressão e JavaScript de terceiros pesado. No mobile, a conexão e o processador são mais limitados, então uma foto de 2 MB que passa despercebida no desktop empurra o LCP para além de 4 s no celular. Converter para WebP corta de 25% a 35% do peso, e adiar scripts não essenciais com um plugin como o Perfmatters libera a renderização inicial. O cache de página completa o trio que mais melhora a nota mobile na prática.", "author": { "@id": "https://full.services/#org" } } } ] }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://full.services/" }, { "@type": "ListItem", "position": 2, "name": "Performance WordPress", "item": "https://full.services/performance-wordpress/" }, { "@type": "ListItem", "position": 3, "name": "Matando performance acelerar WordPress: 5 causas e a correção essencial", "item": "https://full.services/matando-performance-acelerar-wordpress/" } ] }, { "@type": "Organization", "@id": "https://full.services/#org", "name": "FULL Services", "url": "https://full.services", "logo": { "@type": "ImageObject", "url": "https://full.services/wp-content/uploads/full-services-logo.png", "width": 200, "height": 60 }, "sameAs": [ "https://www.instagram.com/fullservicesbr", "https://www.facebook.com/fullservices.br", "https://www.linkedin.com/company/fullservicesbr/" ], "knowsAbout": [ "WordPress", "WordPress Hosting", "Web Development", "Performance Optimization", "WordPress Security", "SEO para WordPress" ], "award": [ "Gold Medal - The WP Weekly Awards 2023 (https://thewpweekly.com/awards-2023/)", "Gold Medal - The WP Weekly Awards 2024 (https://thewpweekly.com/awards-2024/)" ], "hasCredential": { "@type": "EducationalOccupationalCredential", "credentialCategory": "certification", "name": "CVE Numbering Authority (CNA)", "description": "Autoridade de numeração de vulnerabilidades (CVE) para o ecossistema WordPress, autorizada a atribuir IDs CVE. Certificação válida desde 2022-05-03, com abrangência global.", "url": "https://www.cve.org/PartnerInformation/ListofPartners/partner/FULL", "recognizedBy": { "@type": "Organization", "name": "CISA — Cybersecurity and Infrastructure Security Agency", "url": "https://www.cisa.gov/", "sameAs": "https://www.cisa.gov/" } } }, { "@type": "Person", "@id": "https://full.services/#person-clayton", "name": "Clayton Margiotti", "givenName": "Clayton", "familyName": "Margiotti", "jobTitle": "Fundador e CEO da FULL Services", "description": "Fundador e CEO da FULL Services, plataforma WordPress SaaS com 50 mil clientes e 150 mil sites conectados, e anchor do ecossistema Elevor Global. Em 2024 conduziu a FULL a se tornar a primeira e unica empresa brasileira aprovada como CVE Numbering Authority sob a CISA (DHS/EUA). Mais de 20 anos construindo empresas digitais, com 13+ reconhecimentos internacionais (Facebook, GPTW, ONU, RD Summit).", "url": "https://full.services/sobre-nos/", "image": "https://full.services/wp-content/uploads/2026/05/clayton-margiotti.jpg", "sameAs": [ "https://www.linkedin.com/in/cmargiotti/" ], "knowsAbout": [ "Artificial Intelligence", "Cybersecurity", "CVE Program", "WordPress Enterprise", "SaaS Platforms", "Digital Infrastructure", "Technology Entrepreneurship", "Company Building", "Business Leadership", "Digital Growth" ], "hasOccupation": { "@type": "Occupation", "name": "Fundador e CEO", "occupationalCategory": "11-1011.00" }, "knowsLanguage": [ { "@type": "Language", "name": "Portuguese", "alternateName": "pt-BR" }, { "@type": "Language", "name": "English", "alternateName": "en" } ], "memberOf": { "@type": "Organization", "name": "CVE Numbering Authorities", "url": "https://www.cve.org/", "sameAs": "https://www.cve.org/" }, "alumniOf": [ { "@type": "EducationalOrganization", "name": "Global Scaling Academy (Blitzscaling Program)", "url": "https://www.blitzscalingacademy.com" }, { "@type": "EducationalOrganization", "name": "Esade", "url": "https://www.esade.edu" }, { "@type": "EducationalOrganization", "name": "Business School Sao Paulo (BSP)", "url": "https://bsp.edu.br/" }, { "@type": "EducationalOrganization", "name": "Tera", "url": "https://somostera.com" }, { "@type": "EducationalOrganization", "name": "Le Wagon", "url": "https://www.lewagon.com" }, { "@type": "EducationalOrganization", "name": "FIAP", "url": "https://www.fiap.com.br" }, { "@type": "EducationalOrganization", "name": "PUCRS", "url": "https://online.pucrs.br/" } ], "award": [ "Digital Disruptor – Engaging Experiences Master (Globant, 2021)", "Maior ROI do e-commerce brasileiro – Letrissimas (Facebook, 2019)", "1º lugar – Melhores Empresas para Trabalhar no Brasil – Eleva Digital (Great Place to Work, 2018)", "Case global de educacao no Facebook – Metodo SUPERA (Facebook, 2017)", "Maquina de Geracao de Leads, Agencia do Ano (RD Summit / RD Station, 2015)", "Monthly Recurring Revenue, top performance (RD Summit / RD Station, 2015)", "Quality/Efficiency – Entrepreneurship Training (UNCTAD / PNUD-ONU, 2010)" ], "subjectOf": [ { "@type": "NewsArticle", "url": "https://www.globant.com/news/globant-reveals-inaugural-digital-disruptors-award-winners", "publisher": { "@type": "Organization", "name": "Globant" } }, { "@type": "NewsArticle", "url": "https://www.prnewswire.com/news-releases/letrissimas-com-e-destaque-do-e-commerce-brasileiro-com-maior-roi-de-2018-877517801.html", "publisher": { "@type": "Organization", "name": "PR Newswire" } }, { "@type": "NewsArticle", "url": "https://www.segs.com.br/seguros/102599-gestao-de-pessoas-garante-mais-lucro-as-empresas", "publisher": { "@type": "Organization", "name": "Segs" } }, { "@type": "NewsArticle", "url": "https://franquiaeducacional.com/negocios-inovadores-facebook-elege-supera-case-mundial-de-educacao", "publisher": { "@type": "Organization", "name": "Franquia Educacional" } }, { "@type": "NewsArticle", "url": "https://acontecendoaqui.com.br/marketing/resultados-digitais-divulga-vencedores-do-premio-agencias-de-resultados-2015-durante-o-rd", "publisher": { "@type": "Organization", "name": "Acontecendo Aqui" } } ], "worksFor": { "@type": "Organization", "@id": "https://full.services/#org" } }, { "@type": "HowTo", "@id": "https://full.services/matando-performance-acelerar-wordpress/#howto", "isPartOf": { "@id": "https://full.services/matando-performance-acelerar-wordpress/#article" }, "name": "Passo a passo: matando performance acelerar wordpress", "description": "Guia passo a passo sobre matando performance acelerar wordpress para WordPress.", "url": "https://full.services/matando-performance-acelerar-wordpress/", "totalTime": "PT30M", "author": { "@type": "Organization", "@id": "https://full.services/#org" }, "step": [ { "@type": "HowToStep", "position": 1, "name": "Passo 1: Meça a base com PageSpeed insights", "text": "Rode o teste de performance três vezes no mobile e anote o LCP e o TTFB médios. Esse é o número que valida cada correção depois." }, { "@type": "HowToStep", "position": 2, "name": "Passo 2: Verifique o TTFB e a hospedagem", "text": "Se o TTFB passa de 800 ms com o site em repouso, o gargalo é o servidor. Veja como reduzir o TTFB no WordPress antes de tocar no resto." }, { "@type": "HowToStep", "position": 3, "name": "Passo 3: Identifique os plugins lentos", "text": "Ative o Query Monitor e ordene as queries por tempo. Para um mapa completo, use o guia de como encontrar plugins lentos no WordPress." }, { "@type": "HowToStep", "position": 4, "name": "Passo 4: Otimize e converta as imagens", "text": "Converta para WebP e ative lazy-loading nas imagens abaixo da dobra. O passo a passo está em como otimizar imagens no WordPress." }, { "@type": "HowToStep", "position": 5, "name": "Passo 5: Ative o cache de página", "text": "Instale um plugin de cache do WordPress e ative o cache de página. Meça de novo no PageSpeed e compare com a base do Passo 1. --- O TTFB define o teto da velocidade: nenhum truque de front-end compensa um servidor que demora 1,5 s para responder. O TTFB ideal fica abaixo de 200 ms, e quando ele passa de 800 ms o problema está na hospedagem, no PHP desatualizado ou na ausência de cache no nível do servidor. Subir de PHP 7.4 para PHP 8.2 já reduz o tempo de processamento de páginas pesadas em uma faixa de 20% a 30%, porque o interpretador ficou mais rápido entre essas versões. A FULL vê no suporte que migrar de hospedagem compartilhada saturada para um plano com recursos dedicados costuma derrubar o TTFB de mais de 1 s para menos de 300 ms, sem mudar uma linha do tema. O ganho aqui é estrutural: corrige a base sobre a qual todas as outras otimizações vão se apoiar depois. --- Cada plugin ativo adiciona queries ao banco, e 3 ou 4 plugins mal escritos derrubam a performance mais que cem imagens pesadas juntas. O Query Monitor mostra que um único plugin de page builder mal" } ] } ] } ```