--- title: "Como reduzir requests HTTP no WordPress" description: "Reduzir requests HTTP no WordPress é diminuir quantos arquivos, scripts, estilos, fontes e imagens, o navegador precisa baixar para montar a página." url: https://full.services/como-reduzir-requests-http-no-wordpress/ date: 2026-06-21 author: "Clayton Margiotti" --- # Como reduzir requests HTTP no WordPress No seu site WordPress, **reduzir os requests HTTP** é cortar o número de arquivos que cada página pede ao servidor, o que acelera o carregamento direto. Segundo a [documentação do WordPress](https://developer.wordpress.org/), cada script e estilo enfileirado vira uma requisição. O erro mais comum é desativar scripts no site inteiro sem testar página a página, o que quebra recursos que só rodam em telas específicas. Reduzir requests HTTP no WordPress é diminuir quantos arquivos, scripts, estilos, fontes e imagens, o navegador precisa baixar para montar a página, porque cada um é uma ida ao servidor que custa tempo. Com o Perfmatters, você desativa o que não é usado e adia o que pode esperar, sem reescrever o tema. O resultado é uma página de [melhor performance](https://full.services/glossario/performance-wordpress/), com menos idas ao servidor e um carregamento mais leve. Este guia faz parte do hub de [performance WordPress da FULL](https://full.services/performance-wordpress/) e mostra o passo a passo real, da medição dos requests à validação do ganho. --- ## O que são requests HTTP e por que eles pesam Requests HTTP são as requisições que o navegador faz ao servidor para baixar cada recurso da página, um script, um estilo, uma fonte ou uma imagem, e cada uma adiciona tempo ao carregamento. Quanto mais arquivos a página pede, mais idas e vindas acontecem antes de tudo aparecer na tela. Na prática, um tema e vários plugins enfileiram dezenas de scripts e estilos, muitos deles inúteis na maioria das páginas, e cada um vira uma requisição. Com o Perfmatters, você corta os que não servem e adia os que podem esperar. Nos atendimentos da FULL sobre [performance no WordPress](https://full.services/o-que-esta-matando-sua-performance-veja-como-acelerar-seu-site-wordpress/), o tropeço campeão é desativar um script no site inteiro sem testar, e descobrir tarde que ele era necessário em uma página específica, como o checkout.

Legenda: cada arquivo na lista é uma requisição que o navegador faz para montar a página.

## Quando vale reduzir requests em vez de só ativar cache Vale reduzir requests quando a página carrega muitos scripts de plugins, quando o cache sozinho não resolveu a lentidão ou quando o relatório de performance aponta excesso de recursos, e vale focar só no cache quando a página já é enxuta e o gargalo é o tempo de servidor. A redução de requests rende quando há excesso de arquivos enfileirados. Use este teste antes de mexer. Diga SIM à redução de requests se a sua página pede dezenas de scripts e estilos, muitos de plugins que só atuam em telas específicas, e o carregamento está pesado. Diga NÃO se a página já é leve e a lentidão vem do servidor, porque aí o ganho está em [cache e otimização de entrega](https://full.services/como-usar-o-wp-rocket-para-melhorar-seu-seo-no-google/). O encaixe ideal é o site cheio de plugins que enfileiram recursos. Os [Core Web Vitals](https://full.services/glossario/core-web-vitals/) mostram se o excesso de requests está pesando. ## Pré-requisitos antes de reduzir os requests Antes de reduzir os requests você precisa de três peças no lugar, o Perfmatters ativo para controlar os recursos, uma ferramenta de medição para ver os requests antes e depois, e a disposição de testar página a página, e a falta de qualquer uma leva a cortar no escuro e quebrar recursos. Sem medir antes, você não sabe quanto realmente ganhou. Checklist de prontidão antes de começar: - Perfmatters instalado e ativo no site. - Uma ferramenta de medição de requests, como o teste de velocidade. - Um backup do site antes de desativar recursos. - A lista das páginas críticas a testar, como checkout e contato. - A medição inicial dos requests, para comparar depois. - Paciência para testar cada mudança em vez de cortar tudo de uma vez. - Acesso de administrador para o Script Manager do Perfmatters. Pense nos requests como a lista de compras de uma receita: cada item é uma ida ao mercado, e quanto mais idas, mais demora o jantar. O Perfmatters é o cozinheiro que revisa a lista e corta o que não entra no prato de hoje. Mas cortar um ingrediente essencial estraga a receita, então a revisão precisa ser página a página, não no escuro. ## Como reduzir os requests HTTP em 5 passos Reduzir os requests segue cinco passos, da medição inicial à validação do ganho, e respeitar a ordem evita o erro mais comum: desativar scripts no site inteiro sem testar onde eles são usados. Cada passo corta um excesso com segurança. Confirme antes que o Perfmatters está ativo e você tem um backup, porque desativar recursos pode quebrar páginas.
Reduzir requests HTTP: etapas, objetivo e validação
Etapa Objetivo Check de validação
Medir os requests atuais Ter a linha de base Número de requests anotado
Desativar recursos globais inúteis Cortar o óbvio Emojis e embeds desligados
Usar o Script Manager por página Cortar com precisão Scripts desativados onde não usados
Adiar o que sobrar Liberar o carregamento Scripts não críticos adiados
Re-medir e validar Confirmar o ganho Menos requests, nada quebrado
### Passo 1: Meça os requests atuais Antes de cortar qualquer coisa, rode um teste de velocidade e anote quantos requests a página faz hoje, porque é essa linha de base que vai mostrar o ganho real depois. Use uma ferramenta que liste os recursos carregados, separando scripts, estilos, fontes e imagens. Identifique de onde vêm os arquivos, o tema ou cada plugin, para saber o que atacar. Esse passo evita cortar no escuro: medir antes e depois é o que prova que a otimização funcionou. Reserve um tempo para entender o relatório, porque ver quais plugins enfileiram mais recursos já aponta onde está o maior excesso a reduzir nos próximos passos. ### Passo 2: Desative os recursos globais inúteis No Perfmatters, desligue os recursos que o WordPress carrega por padrão e que a maioria dos sites não usa, como os scripts de emojis, os embeds e as query strings nos assets, porque cada um é uma requisição que some sem prejuízo visível. Esses itens são seguros de desativar na maior parte dos casos e dão um ganho rápido. Ative as opções de desativação no painel do Perfmatters. Confira a página após cada mudança para garantir que nada essencial quebrou. Esse passo colhe os ganhos fáceis primeiro: são recursos globais raramente necessários, então desligá-los reduz requests sem o risco das otimizações mais cirúrgicas que vêm a seguir. ### Passo 3: Use o script manager para desativar por página Abra o Script Manager do Perfmatters e desative, página por página, os scripts de plugins que não atuam ali, porque é assim que você corta com precisão sem quebrar telas onde o recurso é necessário. Um plugin de formulário, por exemplo, só precisa carregar na página que tem o formulário, não no site inteiro. Use a regra de exceção para manter o script onde ele é usado. Teste cada página crítica após desativar. Esse é o passo de maior ganho e maior risco: desligar um script global sem a exceção certa quebra o recurso, então trabalhe com cuidado e teste sempre, página a página, em vez de cortar tudo de uma vez. ### Passo 4: Adie o que sobrar para liberar o carregamento Para os scripts que precisam ficar, configure o adiamento no Perfmatters, deixando o JavaScript não crítico carregar depois do conteúdo principal, porque adiar libera a página para aparecer antes de tudo terminar de baixar. O carregamento adiado melhora a sensação de velocidade mesmo quando o número de arquivos não cai tanto. Ative o atraso e o adiamento de scripts com cuidado, testando a interação. Se o site começar a retornar erro de excesso de requisições por automações ou bots, veja como corrigir o [erro 429 Too Many Requests no WordPress](https://full.services/wp-fixer/como-corrigir-erro-429-wordpress/), que trata do limite de requisições ao servidor. ### Passo 5: Re-meça e valide o ganho Rode o teste de velocidade de novo e compare o número de requests com a linha de base do passo 1, confirmando que caiu e que nenhuma página crítica quebrou, porque só a comparação prova o ganho real. Navegue pelas telas importantes, como checkout e contato, para garantir que tudo funciona. Confira a página no celular, já que o mobile sente mais o peso dos requests. Se o banco fica lento com tantas consultas de plugins, veja como [otimizar o wp_options para consultas lentas](https://full.services/wp-fixer/otimizar-wp-options-queries-lentas/), que ataca o gargalo no servidor além dos requests do navegador.

Legenda: cada passo corta um excesso, da medição inicial à validação do ganho.

## Erros comuns ao reduzir requests HTTP Os três erros mais comuns ao reduzir requests são desativar scripts no site inteiro sem testar, não medir antes e depois, e adiar scripts críticos demais. O primeiro é o mais grave: desligar um script global sem conferir onde ele atua quebra recursos em páginas específicas, como um formulário ou um checkout que param de funcionar. O segundo erro é cortar recursos sem medir os requests antes, ficando sem saber se a mudança realmente ajudou. A correção é sempre anotar a linha de base e comparar. O terceiro caso é adiar um script essencial para a primeira tela, o que faz a página aparecer quebrada por um instante. Quando o servidor responde com erro de requisição malformada após as mudanças, vale ver como corrigir o [erro 400 Bad Request no WordPress](https://full.services/wp-fixer/como-corrigir-erro-400-wordpress/). ## Como manter a performance em produção Manter a performance em produção exige cuidar de duas frentes, a revisão dos requests a cada plugin novo e a estabilidade das regras do Script Manager a cada atualização, porque um plugin novo enfileira mais recursos e uma atualização pode mudar os scripts que ele carrega. O site ganha plugins ao longo do tempo, então a redução de requests é manutenção contínua, não um ajuste único. Sempre que instalar um plugin, meça de novo os requests e use o Script Manager para limitar onde ele carrega, porque cada novo plugin tende a enfileirar scripts no site inteiro. Depois de cada atualização, refaça um teste de velocidade nas páginas críticas. Para padronizar a otimização de performance em vários sites sem licença avulsa, o guia de [o que está matando a sua performance](https://full.services/o-que-esta-matando-sua-performance-veja-como-acelerar-seu-site-wordpress/) mostra a rotina. ## Como a FULL faz isso em escala A FULL padroniza a redução de requests com Perfmatters porque acompanha mais de 150 mil sites WordPress, e sites pesados de plugins que enfileiram scripts demais aparecem o tempo todo, onde revisar os recursos de cada projeto na unha vira gargalo. Em vez de licença avulsa do Perfmatters por instalação, a ferramenta entra no bundle e o padrão de otimização de requests fica replicável de um site para outro. No plano PRO da FULL, por [R$849](https://full.services/planos), o Perfmatters já vem no pacote para até dez sites, o que dá R$85 por site em vez de pagar cada licença separada. Para quem cuida de vários sites pesados, a gente vê isso trocar um custo recorrente espalhado por um padrão único: as mesmas regras de desativação e adiamento de scripts são exportadas e reaproveitadas de um projeto para outro, sem revisar os requests do zero a cada site. É a economia que só aparece quando o stack é o mesmo em toda a base. ## Checklist final da redução de requests O checklist final da redução de requests confirma, em uma passada, que a página ficou mais leve sem quebrar nada antes de você considerar a otimização pronta. Rode esta lista depois do passo 5 e a cada plugin novo, porque é a instalação de plugins que reintroduz requests. Antes de declarar pronto, confirme: - O número de requests inicial foi medido e anotado. - Os recursos globais inúteis, como emojis e embeds, estão desativados. - O Script Manager desativou os scripts onde eles não são usados. - As páginas críticas, como checkout e contato, seguem funcionando. - Os scripts não críticos foram adiados sem quebrar a primeira tela. - A nova medição mostra menos requests que a linha de base. - A página carrega bem no celular, não só no desktop. Se qualquer item falhar, principalmente uma página crítica quebrada, volte ao passo correspondente antes de considerar a otimização pronta. ## Perguntas frequentes sobre reduzir requests HTTP no WordPress
Preciso do Perfmatters ou dá para reduzir requests sem ele?

Dá para reduzir alguns requests com código no tema, mas é arriscado e trabalhoso. O Perfmatters faz isso pela interface, com o Script Manager que desativa scripts por página sem você editar arquivos. Use a ferramenta quando quer controle fino e segurança, porque mexer no código do tema pode quebrar o site numa atualização. Reserve a abordagem manual só para quem domina o desenvolvimento. Para a maioria dos sites, um plugin de performance dedicado entrega o mesmo resultado com muito menos risco de errar e mais facilidade de reverter.

Por que desativar um script quebrou uma página do site?

Porque esse script era necessário naquela página específica, e a desativação foi aplicada de forma global. Muitos plugins carregam scripts no site inteiro, mas só atuam em uma tela, como o formulário ou o checkout. A causa do problema é cortar sem testar página a página. Para resolver, use a regra de exceção do Script Manager para manter o script onde ele é usado e desligá-lo no resto. Prefira testar cada mudança nas telas críticas, porque a economia de um request não compensa um recurso quebrado.

Como descubro quais scripts desativar com segurança?

Você identifica a origem de cada script no teste de velocidade e cruza com onde aquele recurso é usado. Os globais do WordPress, como emojis e embeds, costumam ser seguros de desligar em quase todo site. Já os de plugins exigem cuidado: desligue só onde o plugin não atua. Use o Script Manager para testar uma página de cada vez. Reserve a desativação ampla para os recursos comprovadamente inúteis, porque com scripts de plugin o seguro é cortar por página e validar.

É possível reduzir requests sem prejudicar o visual da página?

Sim, desde que você desative só o que não é usado e adie o que não é crítico. O visual quebra quando um estilo necessário é cortado ou um script da primeira tela é adiado demais. Por isso, a redução segura foca nos recursos inúteis e no JavaScript não essencial. Use a medição e o teste para confirmar que a aparência se manteve. Reserve os cortes mais agressivos para depois de validar os seguros, porque o objetivo é uma página mais leve que continue idêntica aos olhos do visitante.

Quando o cache resolve melhor que reduzir requests?

Quando a página já é enxuta e a lentidão vem do tempo de resposta do servidor, não do número de arquivos. Nesse caso, o cache entrega a página pronta e ataca o gargalo real, enquanto cortar requests daria pouco ganho. Prefira o cache quando o problema é o servidor demorar a montar a página. Reserve a redução de requests para quando a página pede recursos demais. Na prática, os dois se complementam: o cache acelera a entrega e a redução de requests aliviam o que o navegador precisa baixar.

## Próximos passos para um site mais leve Reduzir requests HTTP no WordPress é, no fundo, fazer a página pedir menos ao servidor: meça a linha de base, desative os recursos globais inúteis, use o Script Manager por página e, acima de tudo, teste cada corte antes de seguir. Desativar scripts no site inteiro sem testar é o que quebra recursos específicos, então trabalhe página a página. Para padronizar o Perfmatters em vários sites sem licença avulsa, conheça os [planos da FULL](https://full.services/planos), e para continuar aprendendo, o [FULL Academy](https://full.services/academy/) reúne os tutoriais de WordPress em um só lugar. --- ## Metadados Estruturados (Schema.org) ```json-ld { "@context": "https://schema.org", "@graph": [ { "@type": "TechArticle", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#article", "headline": "Como reduzir requests HTTP no WordPress", "description": "Reduzir requests HTTP no WordPress é diminuir quantos arquivos, scripts, estilos, fontes e imagens, o navegador precisa baixar para montar a página, porque cada um é uma ida ao servidor que custa temp", "url": "https://full.services/como-reduzir-requests-http-no-wordpress/", "datePublished": "2026-06-21T09:00:00-03:00", "dateModified": "2026-06-21T09:00:00-03:00", "inLanguage": "pt-BR", "articleSection": "Performance WordPress", "keywords": [ "como reduzir requests http no 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/como-reduzir-requests-http-no-wordpress/" }, "wordCount": 2725, "citation": [ { "@type": "CreativeWork", "name": "WordPress Developer Docs", "url": "https://developer.wordpress.org/", "publisher": { "@type": "Organization", "name": "WordPress Developer Docs" } } ] }, { "@type": "FAQPage", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq", "isPartOf": { "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#article" }, "mainEntity": [ { "@type": "Question", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq-q1", "name": "Preciso do Perfmatters ou dá para reduzir requests sem ele?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Dá para reduzir alguns requests com código no tema, mas é arriscado e trabalhoso. O Perfmatters faz isso pela interface, com o Script Manager que desativa scripts por página sem você editar arquivos. Use a ferramenta quando quer controle fino e segurança, porque mexer no código do tema pode quebrar o site numa atualização. Reserve a abordagem manual só para quem domina o desenvolvimento. Para a maioria dos sites, um plugin de performance dedicado entrega o mesmo resultado com muito menos risco de errar e mais facilidade de reverter.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq-q2", "name": "Por que desativar um script quebrou uma página do site?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Porque esse script era necessário naquela página específica, e a desativação foi aplicada de forma global. Muitos plugins carregam scripts no site inteiro, mas só atuam em uma tela, como o formulário ou o checkout. A causa do problema é cortar sem testar página a página. Para resolver, use a regra de exceção do Script Manager para manter o script onde ele é usado e desligá-lo no resto. Prefira testar cada mudança nas telas críticas, porque a economia de um request não compensa um recurso quebrado.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq-q3", "name": "Como descubro quais scripts desativar com segurança?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Você identifica a origem de cada script no teste de velocidade e cruza com onde aquele recurso é usado. Os globais do WordPress, como emojis e embeds, costumam ser seguros de desligar em quase todo site. Já os de plugins exigem cuidado: desligue só onde o plugin não atua. Use o Script Manager para testar uma página de cada vez. Reserve a desativação ampla para os recursos comprovadamente inúteis, porque com scripts de plugin o seguro é cortar por página e validar.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq-q4", "name": "É possível reduzir requests sem prejudicar o visual da página?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Sim, desde que você desative só o que não é usado e adie o que não é crítico. O visual quebra quando um estilo necessário é cortado ou um script da primeira tela é adiado demais. Por isso, a redução segura foca nos recursos inúteis e no JavaScript não essencial. Use a medição e o teste para confirmar que a aparência se manteve. Reserve os cortes mais agressivos para depois de validar os seguros, porque o objetivo é uma página mais leve que continue idêntica aos olhos do visitante.", "author": { "@id": "https://full.services/#org" } } }, { "@type": "Question", "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#faq-q5", "name": "Quando o cache resolve melhor que reduzir requests?", "inLanguage": "pt-BR", "acceptedAnswer": { "@type": "Answer", "text": "Quando a página já é enxuta e a lentidão vem do tempo de resposta do servidor, não do número de arquivos. Nesse caso, o cache entrega a página pronta e ataca o gargalo real, enquanto cortar requests daria pouco ganho. Prefira o cache quando o problema é o servidor demorar a montar a página. Reserve a redução de requests para quando a página pede recursos demais. Na prática, os dois se complementam: o cache acelera a entrega e a redução de requests aliviam o que o navegador precisa baixar.", "author": { "@id": "https://full.services/#org" } } } ] }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://full.services/" }, { "@type": "ListItem", "position": 2, "name": "Como reduzir requests HTTP no WordPress", "item": "https://full.services/como-reduzir-requests-http-no-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/como-reduzir-requests-http-no-wordpress/#howto", "isPartOf": { "@id": "https://full.services/como-reduzir-requests-http-no-wordpress/#article" }, "name": "Passo a passo: como reduzir requests http no wordpress", "description": "Guia passo a passo sobre como reduzir requests http no wordpress para WordPress.", "url": "https://full.services/como-reduzir-requests-http-no-wordpress/", "totalTime": "PT30M", "author": { "@type": "Organization", "@id": "https://full.services/#org" }, "step": [ { "@type": "HowToStep", "position": 1, "name": "Passo 1: Meça os requests atuais", "text": "Antes de cortar qualquer coisa, rode um teste de velocidade e anote quantos requests a página faz hoje, porque é essa linha de base que vai mostrar o ganho real depois. Use uma ferramenta que liste os recursos carregados, separando scripts, estilos, fontes e imagens. Identifique de onde vêm os arquivos, o tema ou cada plugin, para saber o que atacar. Esse passo evita cortar no escuro: medir antes e depois é o que prova que a otimização funcionou. Reserve um tempo para entender o relatório, porque ver quais plugins enfileiram mais recursos já aponta onde está o maior excesso a reduzir nos próximos passos." }, { "@type": "HowToStep", "position": 2, "name": "Passo 2: Desative os recursos globais inúteis", "text": "No Perfmatters, desligue os recursos que o WordPress carrega por padrão e que a maioria dos sites não usa, como os scripts de emojis, os embeds e as query strings nos assets, porque cada um é uma requisição que some sem prejuízo visível. Esses itens são seguros de desativar na maior parte dos casos e dão um ganho rápido. Ative as opções de desativação no painel do Perfmatters. Confira a página após cada mudança para garantir que nada essencial quebrou. Esse passo colhe os ganhos fáceis primeiro: são recursos globais raramente necessários, então desligá-los reduz requests sem o risco das otimizações mais cirúrgicas que vêm a seguir." }, { "@type": "HowToStep", "position": 3, "name": "Passo 3: Use o script manager para desativar por página", "text": "Abra o Script Manager do Perfmatters e desative, página por página, os scripts de plugins que não atuam ali, porque é assim que você corta com precisão sem quebrar telas onde o recurso é necessário. Um plugin de formulário, por exemplo, só precisa carregar na página que tem o formulário, não no site inteiro. Use a regra de exceção para manter o script onde ele é usado. Teste cada página crítica após desativar. Esse é o passo de maior ganho e maior risco: desligar um script global sem a exceção certa quebra o recurso, então trabalhe com cuidado e teste sempre, página a página, em vez de cortar tudo de uma vez." }, { "@type": "HowToStep", "position": 4, "name": "Passo 4: Adie o que sobrar para liberar o carregamento", "text": "Para os scripts que precisam ficar, configure o adiamento no Perfmatters, deixando o JavaScript não crítico carregar depois do conteúdo principal, porque adiar libera a página para aparecer antes de tudo terminar de baixar. O carregamento adiado melhora a sensação de velocidade mesmo quando o número de arquivos não cai tanto. Ative o atraso e o adiamento de scripts com cuidado, testando a interação. Se o site começar a retornar erro de excesso de requisições por automações ou bots, veja como corrigir o erro 429 Too Many Requests no WordPress, que trata do limite de requisições ao servidor." }, { "@type": "HowToStep", "position": 5, "name": "Passo 5: Re-meça e valide o ganho", "text": "Rode o teste de velocidade de novo e compare o número de requests com a linha de base do passo 1, confirmando que caiu e que nenhuma página crítica quebrou, porque só a comparação prova o ganho real. Navegue pelas telas importantes, como checkout e contato, para garantir que tudo funciona. Confira a página no celular, já que o mobile sente mais o peso dos requests. Se o banco fica lento com tantas consultas de plugins, veja como otimizar o wp_options para consultas lentas, que ataca o gargalo no servidor além dos requests do navegador.

Legenda: cada passo corta um excesso, da medição inicial à validação do ganho.

Os três erros mais comuns ao reduzir requests são desativar scripts no site inteiro sem testar, não medir antes e depois, e adiar scripts críticos demais. O primeiro é o mais grave: desligar um script global sem conferir onde ele atua quebra recursos em páginas específicas, como um formulário ou um checkout que param de funcionar. O segundo erro é cortar recursos sem medir os requests antes, ficando sem saber se a mudança realmente ajudou. A correção é sempre" } ] } ] } ```