Reduzir os pedidos HTTP do WordPress: Como otimizar a velocidade do seu sítio Web

Os pedidos HTTP do WordPress determinam a rapidez com que as suas páginas aparecem, porque cada pedido de CSS, JS, imagens ou tipos de letra demora algum tempo. Vou mostrar-lhe como reduzir o número de pedidos, evitar o bloqueio de renderização e otimizar a website imediatamente percetível acelerar.

Pontos centrais

Os seguintes pontos focais conduzirão rapidamente a um menor número de pedidos de informação e a uma melhor LCP com estabilidade Função:

• Armazenamento em cache utilização: A cache do navegador, da página e do objeto reduz significativamente os pedidos repetidos.
• CSS/JS otimizar: Reduzir, agrupar, integrar CSS essenciais, evitar bloqueios de processamento.
• fotos modernizar: WebP/AVIF, carregamento lento, dimensões fixas, sem deslizadores de heróis.
• Scripts atraso: adiar/atrasar para análises, pixéis, recursos externos.
• CDN/Hosting escolher: HTTP/3, caching de ponta, TTFB curto para utilizadores globais.

O que são pedidos HTTP no WordPress?

Cada recurso da página gera o seu próprio pedido, ou seja, ficheiros CSS, JavaScript, imagens, ícones e Fontes. Os temas e plugins modernos adicionam rapidamente muitos ficheiros pequenos, o que aumenta o número de Pedidos de informação unidades. Cada pedido envolve a pesquisa de DNS, o aperto de mão TCP e a transferência, e é precisamente esta sobrecarga que aumenta. Sem otimização, vejo frequentemente mais de 70 pedidos por página, o que atrasa visivelmente a visualização. Os valores-alvo são claramente inferiores a estes: menos de 50 é bom, menos de 25 é excelente para a velocidade máxima. Uma pequena redução por tipo de página tem um grande impacto porque os modelos, cabeçalhos e rodapés são carregados em todo o lado.

Porque é que cada pedido de informação conta

Qualquer ficheiro adicional pode bloquear a renderização, especialmente os carregados de forma síncrona CSS e JavaScript. Se estes recursos continuarem a bloquear o processamento na parte superior da página, os utilizadores esperam pelos espaços em branco e saltam. Isto tem um impacto nos Core Web Vitals: O LCP atrasa-se, o TBT cresce e o CLS aumenta sem medidas fixas para imagens ou anúncios. Por isso, verifico sistematicamente quais os recursos que são realmente críticos e quais os que posso atrasar. Se não tiver a certeza da razão pela qual os pedidos estão a abrandar apesar dos pequenos tamanhos de ficheiro, leia o meu guia Porquê bloquear pedidos HTTP para explicações práticas.

Início rápido: medidas com maior efeito de alavanca

Começo com o caching, a minificação e o lazy loading porque estes passos produzem grandes efeitos e podem ser implementados rapidamente. são. Um bom plugin de cache cria páginas HTML estáticas e guarda as Base de dados. A minimização remove espaços e comentários, combina ficheiros e reduz significativamente as transferências. O Lazy Loading move as imagens fora do ecrã para a parte de trás, o que ajuda o First Paint e o LCP. Com apenas alguns cliques, é possível obter melhorias diretas sem alterar o tema.

Medida de otimização	Pedidos de redução	Ferramentas/Plugins
Armazenamento em cache (navegador, página, objeto)	50-80% para visitas de retorno	WP Rocket, LiteSpeed Cache, W3TC
Reduzir e combinar	20-50% menos transferências	Otimização automática, Perfmatters
Imagens de carregamento lento	30-60% inicial	WP Rocket, função principal
CDN com HTTP/2/3	para 40% mais eficiente	Cloudflare, QUIC.cloud

Utilização inteligente do caching

Em primeiro lugar, ativo o cache do navegador para que os utilizadores que regressam possam guardar activos localmente a partir do Cache e nunca mais do Servidor carregar. O armazenamento em cache de páginas gera HTML estático para os visitantes e poupa a execução de PHP e as consultas à base de dados. Com o armazenamento em cache de objectos (por exemplo, Redis), as consultas frequentes permanecem na memória, o que reduz a carga nas páginas de administração e da loja. Além disso, o Gzip/Brotli reduz a transferência, o que reduz o tempo de transferência e o volume de dados. Em seguida, verifico os tempos de expiração (controlo da cache, expirações) e se as cadeias de consulta excluem desnecessariamente os scripts de marketing da cache.

CSS e JavaScript: Reduzir, combinar, carregar

Muitos ficheiros pequenos significam muitos Pedidos, por isso, resumo os estilos e os guiões o menos possível. Pacotes juntos. A minimização reduz o tamanho, mas o mais importante é ter menos ficheiros para o caminho crítico. Incluo CSS críticos em linha para que o conteúdo acima da dobra seja estilizado imediatamente. Carrego os estilos não críticos de forma assíncrona ou através do atributo media. Defino o JavaScript para adiar ou atrasar, mas testo a sequência para que as dependências não se quebrem.

Imagens e suportes: grandes poupanças

As imagens causam frequentemente a maior percentagem de Pedidos de informação, por isso, converto para WebP ou AVIF e defino a Dimensões. O carregamento lento atrasa as imagens fora do ecrã, mas eu pré-carrego a imagem do herói especificamente para um LCP rápido. O srcset responsivo garante que os dispositivos móveis carregam pequenas variantes. Evito os cursores no herói porque causam muitos ficheiros e repinturas. Também utilizo formatos específicos modernos para reduzir ao mínimo os artefactos.

Tipos de letra, fornecedores terceiros e scripts externos

Carrego fontes externas localmente para ter controlo total sobre Armazenamento em cache e Pré-carga têm. Combino os estilos de letra com moderação, sendo muitas vezes suficientes os estilos regular e negrito com tipos de letra variáveis. Para análises, gestores de tags e pixéis, defino atrasos até depois da primeira interação ou carrego-os apenas depois do evento onload. Isto mantém o caminho crítico livre de ficheiros desnecessários. Também verifico os widgets das redes sociais e substituo-os por pré-visualizações estáticas que recarrego ao clicar.

Escolher sabiamente a CDN e o alojamento

Uma CDN aproxima os activos dos utilizadores e reduz a latência e o número de Viagens de ida e volta percetível no primeiro Apelo. O HTTP/2/3 permite a multiplexagem, a definição de prioridades e a aceleração dos "handshakes" TLS. O armazenamento em cache de HTML no limite torna os grupos-alvo internacionais, em particular, mais rápidos. No servidor, presto atenção ao armazenamento NVMe, às versões actuais do PHP e ao TTFB curto. Os bons hosters oferecem ferramentas como o Brotli, Early Hints e QUIC, que utilizo ativamente.

Casos especiais: REST-API e Admin-Ajax

Muitas instalações geram pedidos em segundo plano através do API REST ou admin-ajax.php, por exemplo, para formulários, pesquisa ou dinâmica Widgets. Identifico estas chamadas no separador de rede e verifico se os intervalos de sondagem podem ser reduzidos ou se os pedidos podem ser resumidos. Sempre que possível, coloco em cache as respostas da API no lado do servidor e defino limites de taxa. Para optimizações mais aprofundadas, consulte o meu guia para Desempenho da API REST, que mostra travões e soluções típicas. É assim que reduzo as consultas em segundo plano repetidas sem perder funções.

Medição e controlo da velocidade sustentada

Testo todas as alterações com o PageSpeed Insights, o Lighthouse e o GTmetrix para obter a verdadeira Efeito ver e não Regressões captura. Objectivos: menos de 50 pedidos por página, LCP inferior a 2,5 s, TBT inferior a 200 ms e CLS inferior a 0,1. Também olho para o gráfico em cascata para visualizar os recursos de bloqueio, as pesquisas no DNS e as filas de espera. Lembre-se: o número de pedidos conta muitas vezes mais do que o tamanho puro do ficheiro; é exatamente isso que explico no artigo sobre o Foco nos pedidos de informação. A monitorização contínua mantém as optimizações estáveis e mensuráveis.

Avançado: HTTP/2/3, CSS não utilizado e manutenção de BD

Com o HTTP/2/3, beneficio de multiplexagem, priorização e maior rapidez Apertos de mão, o que significa que os tempos de espera para as cargas paralelas Arquivos abreviado. Removo as CSS não utilizadas para tornar as folhas de estilo mais pequenas e reduzir os pedidos. No caso de layouts recorrentes, vale a pena usar CSS críticas por modelo e não por página. Na base de dados, elimino revisões, transientes expirados e cadáveres do cron para que o back end e as funções dinâmicas permaneçam rápidos. Estes passos aceleram visivelmente o processo, especialmente em grandes projectos com muitos plug-ins.

Higiene de plugins e temas

Verifico regularmente quais os plugins que duplicam funções ou que raramente são utilizados. tornar-se, e substituir as embalagens pesadas por outras mais leves Alternativas. Os temas Lean, como o Astra ou o GeneratePress, geram muito poucos pedidos e podem ser optimizados de forma limpa. Dentro do tema, desativo os módulos de que não preciso, como coleções de ícones ou sliders. Também configuro os construtores de páginas de uma forma minimalista para que só carreguem os widgets que são utilizados. Os sinalizadores de funcionalidades e as filas modulares ajudam a evitar o desperdício de ficheiros.

Utilização orientada dos recursos e definição de prioridades

Para além da colocação em cache e do agrupamento Dicas de recursos os toques finais decisivos. Só utilizo o Preload para recursos realmente críticos: a imagem LCP, o CSS principal (se não estiver em linha como CSS crítico) e o Webfont-file. Demasiados pré-carregamentos bloqueiam a definição de prioridades e podem ter o efeito contrário. Para fontes eu defino exibição de fonte (swap/opcional) para evitar FOIT e criar um pré-carregamento com a como-para que o navegador não carregue o ficheiro duas vezes.

Pré-busca de DNS e Pré-conexão Utilizo-o com moderação para fornecedores terceiros obrigatórios (por exemplo, fornecedores de pagamentos no checkout). O Preconnect poupa-me o trabalho de Aperto de mão TLS, No entanto, isto só faz sentido se o recurso for definitivamente necessário. Pré-busca Utilizo-o para recursos que provavelmente serão necessários na etapa seguinte (por exemplo, a página de paginação seguinte). Em ligação com Dicas iniciais o servidor pode sinalizar os pré-carregamentos mais cedo - isto reduz o tempo para o primeiro byte enquanto a ligação está a ser estabelecida.

• Pré-carregamento: Apenas para a imagem LCP, CSS principal, ficheiro de tipo de letra crítico.
• Preconnect: Para domínios de terceiros seguros e inevitáveis.
• Pré-buscar: Para recursos/páginas que são potencialmente necessários em breve.
• DNS prefetch: Para um trabalho preparatório baixo mas favorável com anfitriões externos.

Sempre que possível, utilizo também Sugestões de prioridade (fetchpriority=“high“ para a imagem LCP), para que o browser compreenda o que tem realmente de vir primeiro. Isto reduz o tempo de carregamento e Sequência do pedido controlo mais preciso.

Recursos do WordPress: carregar apenas o que é necessário

Muitas páginas carregam estilos e scripts globalmente, embora só sejam necessários em alguns modelos. Identifico esses candidatos e carrego-os condicional - Por exemplo, os scripts de formulário apenas nas páginas de contacto, o CSS dos cursores apenas nos locais onde existem cursores e os activos do WooCommerce apenas nas páginas da loja, do produto e de checkout.

Um trabalho de limpeza particularmente gratificante:

• Emoji-Desativar scripts e estilos no frontend, uma vez que os sistemas modernos têm emojis nativos.
• oEmbedfunciona se nenhum conteúdo de terceiros estiver incorporado.
• Dashicons no frontend se o tema não os exigir.
• Migração jQuery se não houver scripts antigos pendurados.
• Gutenberg biblioteca de blocos Carregue CSS apenas se os estilos de bloco forem efetivamente utilizados no frontend.

Para uma gestão de activos mais fina, confio em filas modulares (por modelo/bloco) ou utilizo um plugin de otimização que pode desativar recursos por página. Isto reduz o Lista de pedidos rapidamente de imensos ficheiros para um punhado de bens realmente necessários.

WooCommerce, formulários e outras áreas dinâmicas

As lojas têm os seus próprios casos especiais: A conhecida fragmentos de carrinho-script pode causar muitos pedidos repetidos via admin-ajax.php. Só carrego esta função em áreas onde faz sentido (páginas de produtos, de cestos de compras, de checkout) e desativo-a em blogues ou páginas de destino. Coloco os mini-carrinhos em cache sempre que possível e só os actualizo quando há uma verdadeira interação. Para imagens de produtos, utilizo sistematicamente conjunto de fontes e pré-carregar a primeira imagem visível.

Para os formulários, reduzo Sondagem-intervalos, envio validações em pacotes e utilizo debouncing para que a entrada não seja transmitida com cada batida de tecla. Sempre que possível, realizo pesquisas e filtros através de pontos de extremidade em cache (por exemplo, REST) para que pedidos idênticos repetidos sejam servidos a partir da cache. Isto reduz a carga do servidor, o número de Pedidos HTTP e melhora a perceção da velocidade.

Aperfeiçoar ainda mais as imagens, iframes e media

Para a imagem LCP, utilizo fetchpriority="high" e definir uma pré-carga exacta. Ao mesmo tempo, presto atenção a largura/altura ou um CSSrelação de aspeto, para que não haja mudança de layout. Forneço imagens com descodificação="assíncrono", para não bloquear a renderização, e definir preguiçoso apenas onde faz sentido: O primeiro A imagem não deve ser preguiçosa, todos os outros devem ser.

Substituo iframes externos (YouTube, Maps, Social) por pré-visualizações de luz. Em vez de carregar imediatamente todo o widget, mostro uma imagem de pré-visualização estática e só carrego a incorporação real depois de clicar. Desta forma, elimino inúmeros pedidos iniciais que são desnecessários para a primeira interação. Para os meus próprios vídeos, utilizo imagens de cartaz, codecs modernos e streaming adaptativo para que nenhum ficheiro grande bloqueie a sincronização.

Limpar cabeçalhos de cache e eliminação de cache

Muitos pedidos surgem porque as caches do browser ou da CDN não funcionam da melhor forma. Defino para activos estáticos (CSS, JS, tipos de letra, imagens) TTLs longos com Controlo da cache e definir a bandeira imutável. Para lançar actualizações de forma segura, utilizo Versionamento em nomes de ficheiros ou no WordPressver-parâmetros. Importante: O CDN deve armazenar em cache as strings de consulta corretamente, caso contrário, você perderá ?ver=-Os parâmetros perdem o seu efeito e são recarregados desnecessariamente.

ETag e Última modificação para que as revalidações sejam efectuadas rapidamente e as respostas "se-nenhuma-correspondência/se-modificado-desde-que" ajudam a poupar o volume de dados. Com obsoleto-enquanto-revalidado o sítio permanece reativo enquanto as actualizações são efectuadas em segundo plano. Em conjunto, isto resulta em menos viagens de ida e volta e actualizações programadas de forma limpa sem caos na cache.

Evitar erros: Quando o empacotamento e a minificação são demasiado bons

Em HTTP/2/3 Não tenho de espremer tudo num único ficheiro. Os pacotes demasiado grandes tornam Acessos ao cache, porque cada alteração invalida o bloco inteiro. Eu encontro um meio-termo: alguns pacotes logicamente separados que mantêm o caminho crítico pequeno e ainda permitem a reutilização (por exemplo, um pacote de núcleo global, um pacote de modelo, um pacote de fornecedor raramente alterado).

A minificação também pode causar problemas: Uglify/Minify pode danificar funções em alguns plugins. Por isso, testo passo a passo e excluo scripts críticos do Minify/Combine, se necessário (por exemplo, JSON em linha, scripts de pagamento, Captcha). O objetivo é um mais estável, caminho crítico curto, pacote sem risco que quebra a cada atualização.

Metodologia de medição: testes fiáveis em vez de conjecturas

Faço medições com perfis reproduzíveis: Desktop e telemóvel separadamente, com larguras de banda realistas e limitação da CPU. Nas DevTools, utilizo Coberturacom o objetivo de CSS/JS não utilizado e o gráfico em cascata para ver que pedidos estão à espera, empilhados ou atrasados por prioridades. Comparo Primeira vista e Repetir vista, para verificar se os cabeçalhos da cache funcionam realmente e se o número de pedidos é efetivamente reduzido para metade ou melhor quando se revisita.

Também estabeleci barreiras de proteção: número máximo Pedidos por tipo de página, objetivo LCP, orçamento para fornecedores terceiros. As novas funcionalidades só são activadas se estiverem em conformidade com os orçamentos. Isto mantém o sítio rápido a longo prazo, e não apenas imediatamente após uma ronda de otimização.

Subtilezas do lado do servidor: TTFB e TLS

Para além do número puro de pedidos, o tempo de resposta do servidor também conta. Eu mantenho OPcache ativo, afinar o PHP-FPM, garantir plug-ins simples e minimizar a base de dadosViagens de ida e volta. Com o TLS, asseguro uma cadeia de certificados curta, o TLS 1.3 atual e ativado Agrafagem OCSP. Juntamente com o HTTP/3, isto reduz os tempos de "handshake" e acelera consideravelmente os pedidos iniciais - especialmente para os utilizadores móveis.

Brevemente resumido

Reduzo o número de pedidos activando o caching, agrupando CSS/JS, modernizando imagens e atrasando scripts externos. carga. Alojo os tipos de letra localmente e pré-carrego os recursos críticos de forma limpa e direcionado. Uma CDN com HTTP/2/3 e um alojamento rápido reduzem a latência e o TTFB. Utilizo medições no PageSpeed, no Lighthouse e no GTmetrix para verificar se o LCP, o TBT e o CLS estão a entrar no corredor alvo. Em apenas algumas horas, este processo dá frequentemente o salto de pedidos lentos de 70+ para páginas rápidas que estão bem abaixo de 50.