Optimizo a velocidade do Wordpress sem plugins, com intervenções manuais que reduzem visivelmente os tempos de carregamento e atingem de forma fiável os principais sinais vitais da Web. É assim que mantenho o controlo sobre Pedidosrecursos e efeitos secundários e eliminar o lastro na fonte.
Pontos centrais
- fotos Comprimir de forma consistente antes de carregar e converter para o formato WebP
- Carregamento lento nativamente através de um atributo HTML em vez de extensões sobrecarregadas
- Armazenamento em cache via .htaccess/server e estratégia de cabeçalho limpo
- Código Minimizar, agrupar e evitar bloqueadores de processamento
- Balastro remover em WordPress, base de dados e temas
Porque é que eu optimizo sem plugins
Os plug-ins parecem práticos, mas adicionam pedidos, scripts e estilos que bloqueiam os caminhos de renderização iniciais e fazem com que o meu TTFB deteriorar-se. Cada dependência adicional aumenta a superfície de erro e torna mais difícil analisar as causas das quedas de desempenho. Utilizo medidas manuais para reduzir as cadeias de carga e minimizar o número de componentes activos. Isto permite-me reduzir as despesas gerais, manter a flexibilidade e reagir mais rapidamente a novos requisitos. Esta abordagem evita os efeitos secundários causados pelas cadeias de atualização e reduz a manutenção a um mínimo. magro.
Tornar as imagens mais finas: Formatos, tamanhos, compressão
As imagens grandes não eliminam o tempo até ao primeiro byte, mas dominam o tempo de transferência e o LCP, pelo que reduzo todos os activos antecipadamente. Exporto fotografias como JPEG ou WebP e só utilizo PNG para transparências reais. Dimensiono as dimensões exatamente de acordo com as larguras de visualização necessárias, em vez de carregar 4000 px quando 800 px são suficientes. Em seguida, comprimo de forma consistente com Squoosh, ImageOptim ou Photoshop e verifico se há artefactos visíveis. Para as variantes responsivas, confio no srcset/sizes e gosto de utilizar este pequeno Guia de imagens responsivaspara que o browser carregue automaticamente a fonte mais pequena e significativa e o meu Transferência de dados diminui.
Utilizar o carregamento preguiçoso nativamente
Só carrego imagens e iFrames quando entram na janela de visualização, nativamente através de HTML5, em vez de integrar scripts adicionais que significam Linha principal carregar. O atributo loading="lazy" é completamente suficiente nos browsers modernos. Desta forma, reduzo o número de bytes iniciais e igualo a fase crítica de renderização. Ao mesmo tempo, o controlo mantém-se transparente e eu decido quais os elementos acima da dobra que carrego deliberadamente de forma ansiosa. As imagens críticas do herói recebem loading="eager", tudo o resto carrega compensar.
<img src="beispiel.jpg" alt="Exemplo de imagem" loading="lazy">
<iframe src="video.html" title="Vídeo" loading="lazy"></iframe>Acelerar a PBC de uma forma direcionada: Prioridades e espaços reservados
Para melhorar a estabilidade do Largest Contentful Paint, marco explicitamente o meu maior elemento acima da dobra. As imagens recebem fetchpriority="high" e dimensões definidas para que o browser as prefira e CLS evita. Se necessário, adiciono uma pré-carga se o caminho estiver livre.
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="Herói">Para imagens e contentores, defino a largura/altura ou relação de aspetopara excluir os saltos de disposição. Para as áreas não críticas, utilizo content-visibility: auto e conter-tamanho-intrínsecopara que o browser processe posteriormente as áreas fora da janela de visualização sem mover o esquema.
/* Reserva acima da dobra */
.hero { aspect-ratio: 12 / 7; }
/* Dispor as secções não visíveis mais tarde */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Configurar especificamente o armazenamento em cache do navegador
Os visitantes recorrentes devem carregar activos estáticos a partir da cache, pelo que defino os tempos de expiração diretamente ao nível do servidor através de .htaccess ou no vHost. TTLs longos para imagens, moderados para CSS/JS e predefinições curtas para HTML dão-me o equilíbrio entre atualidade e velocidade. Presto atenção ao versionamento consistente dos ficheiros para que as actualizações tenham efeito imediato apesar dos TTLs longos. Combinado com ETags ou cabeçalhos Last-Modified, o tráfego é drasticamente reduzido. Isto poupa-me largura de banda e reduz a perceção do Tempo de carregamento.
ExpiresActive On
ExpiresByType image/jpg "acesso mais 1 ano"
ExpiresByType image/jpeg "acesso mais 1 ano"
ExpiresByType image/gif "acesso mais 1 ano"
ExpiresByType image/png "acesso mais 1 ano"
ExpiresByType text/css "acesso mais 1 mês"
ExpiresByType application/pdf "acesso mais 1 mês"
ExpiresByType text/javascript "acesso mais 1 mês"
ExpiresByType application/x-javascript "acesso mais 1 mês"
ExpiresDefault "acesso mais 2 dias"Estratégia de cache, criação de versões e revalidação
Combino TTLs longos com hashing de nomes de ficheiros para que os clientes façam cache durante o mesmo período de tempo (style.9c2a.css) e as actualizações têm efeito imediato. Para pacotes alterados com frequência, eu defino Cache-Control: public, max-age=31536000, immutableenquanto HTML curto sem cache-estratégias. Para respostas dinâmicas, prefiro Pedidos condicionais via ETag ou Última modificaçãopara que os clientes revalidem com moderação:
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, no-store, must-revalidate"Para conteúdos com variantes de formato (por exemplo, WebP vs. JPEG), verifico se Vary: Aceitar é definido corretamente no Edge; isso evita que as versões erradas acabem no cache. Mantenho o versionamento consistente através de pipelines de compilação para que nenhum ativo se torne obsoleto de forma descontrolada.
Simplificar o CSS e o JavaScript
Eu reduzo o CSS/JS localmente no meu processo de compilação e removo comentários, espaços e Selectores. Empacoto os estilos críticos para o above-the-fold inline, o resto carrego de forma assíncrona ou como um ficheiro diferido. Movo os scripts que bloqueiam a renderização para o final, adiciono defer/async a eles e mantenho o número de bibliotecas externas pequeno. Para frameworks, verifico a agitação da árvore e importo escopos para não carregar tudo o que raramente uso. Sempre que possível, agrupo os ficheiros para reduzir os pedidos sem fazer cache do back end. deteriorar-se.
Melhorar o INP: Aliviar a thread principal
Para uma interação reduzida com a pintura seguinte, divido as tarefas longas em pequenas porções, evito a quebra de layout e separo os manipuladores complexos das interações. Utilizo adiar para módulos, definir ouvintes de eventos passivos e programar trabalho não crítico em tempos de inatividade:
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Dividir tarefas longas
function chunkedWork(items) {
const batch = items.splice(0, 50);
// processa...
if (items.length) requestAnimationFrame(() => chunkedWork(items));
}Meço tarefas longas no DevTools, removo bibliotecas duplicadas e substituo utilitários jQuery por APIs nativas. Resumo as actualizações do DOM, utilizo transformar em vez de topo/esquerda e manter os refluxos a um nível mínimo.
Eliminar o balastro WordPress
Não preciso de muitas funcionalidades do WP em sítios produtivos, por isso desactivei os emojis, os oEmbeds e partes da API REST e poupei dinheiro. Pedidos. Isto encolhe a cabeça e menos scripts bloqueiam o First Paint. Também verifico os pingbacks, as ligações RSD e o manifesto WLW e desligo-os. Desligo também os trackbacks e o XML-RPC se não desempenharem qualquer papel. Desta forma, reduzo a superfície de ataque e mantenho a fase inicial luz.
// Desativar os emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// reduzir oEmbeds e a API REST
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Controlar scripts de terceiros
O código de terceiros é frequentemente o maior travão. Inicializo-o com um atraso, só incluo o que é absolutamente necessário e só o carrego após interação ou consentimento. A análise/rastreamento está a chegar assíncrono depois do First Paint, substituo os widgets sociais por ligações estáticas. Para iFrames, utilizo loading="lazy" e caixa de areiapara limitar os efeitos secundários. As incorporações do YouTube recebem uma imagem de pré-visualização e só carregam o leitor quando clicadas - isto poupa vários pedidos no momento do arranque.
Manutenção de bases de dados sem ajudantes
Elimino as revisões supérfluas, esvazio os transientes e limpo os comentários de spam através do phpMyAdmin para tornar as consultas mais rápidas. resposta. Verifico se as opções de carregamento automático têm um tamanho excessivo, porque acabam por aparecer em todas as consultas. Em instalações mais pequenas, algumas instruções SQL específicas são suficientes para otimizar as tabelas. Verifico se os cron jobs estão suspensos e arrumo os postmeta deixados para trás por plugins antigos. A manutenção regular evita que as consultas fiquem fora de controlo e que o meu backend fique desorganizado. lento ...a vontade.
Cron do sistema em vez de Cron do WP
Para garantir que as tarefas cron funcionam de forma fiável e eficiente, separo-as do carregamento da página. Desactivo o WP-Cron e programo tarefas reais do sistema que funcionam em períodos de silêncio.
// em wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (a cada 5 minutos)
*/5 * * * * * * * /usr/bin/php -q /path/to/wp/wp-cron.php >/dev/null 2>&1Isto significa que nenhum cron bloqueia o tempo de resposta de um pedido regular e que podem ser agendadas tarefas recorrentes, como a limpeza transitória ou a geração de mapas do sítio.
Verificar criticamente o tema, os plugins e os tipos de letra
Removo os temas inactivos e todas as extensões que duplicam funções ou que raramente trazem qualquer benefício, para que o Carregador automático carrega menos. Para os tipos de letra, reduzo as variantes a regular/negrito e dois estilos de letra, alojo-os localmente e ativo o pré-carregamento para o ficheiro principal. Preparo recursos externos com DNS prefetch se precisar mesmo deles. Para as incorporações do YouTube, utilizo miniaturas para inicializar os iFrames mais tarde. Desta forma, mantenho o controlo sobre os caminhos de renderização e mantenho o payload inicial pequeno.
Tipos de letra: comportamento de carregamento, subconjunto, fallbacks
Os tipos de letra da Web influenciam fortemente a velocidade percebida. Eu uso apresentação da fonte: swap ou facultativopara que o texto fique imediatamente visível. Verifico criticamente os tipos de letra variáveis e subconjunto as áreas Unicode para poupar bytes. Um pré-carregamento direcionado do ficheiro WOFF2 mais importante reduz o FOIT.
@font-face {
font-family: 'Brand';
src: url('/fonts/brand-regular.woff2') format('woff2');
peso da fonte: 400;
estilo da fonte: normal;
font-display: swap;
unicode-range: U+000-5FF; /* latin base set */
}Defino fallbacks de sistema limpos (por exemplo, Segoe UI, Roboto, SF Pro, Arial) na pilha de fontes para minimizar os saltos de layout. Sobre o ajustar o tamanho Ajusto as diferenças métricas de modo a que a mudança do tipo de letra de recurso para o tipo de letra da Web seja pouco visível.
Servidor, PHP e protocolos
Sem a infraestrutura certa, qualquer otimização falhará, e é por isso que presto atenção aos SSDs rápidos, actualizados PHP-versões e suporte HTTP/2. A OPcache, o Brotli/Gzip e a multiplexagem HTTP/2 aceleram a entrega e reduzem os bloqueios. Se possível, considero o HTTP/3/QUIC e verifico cuidadosamente a configuração e o TLS; este pequeno artigo sobre Implementar HTTP/3. Os testes de carga e de stress mostram-me como a página reage sob carga. É assim que asseguro que a minha pilha suporta a aplicação transporta e as minhas medidas são eficazes.
| Fornecedor de alojamento | Caraterísticas | Desempenho | Suporte | Relação preço/desempenho |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Concorrente 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Concorrente 2 | HDD, PHP 7.*, sem HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Otimizar PHP-FPM, OPcache e transporte
Configuro o PHP-FPM para que os pedidos não fiquem em filas de espera. pm, pm.max_children e pm.max_requests Dimensiono a carga. A OPcache obtém memória suficiente para evitar recompilações.
php.ini / www.conf
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (valores de exemplo)
pm = dinâmico
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500Na camada de transporte, ativo o Brotli antes do Gzip, mantenho o Keep-Alive aberto e verifico a retoma do TLS. Com o HTTP/2, verifico a priorização para que as imagens CSS/font e LCP tenham prioridade. No HTTP/3, monitorizo a perda de pacotes e ajusto o ritmo.
CDN, cabeçalho de cache e geografia
Para o tráfego internacional, utilizo uma rede periférica para reduzir a latência e manter os activos estáticos perto do utilizador. para entregar. Presto atenção a chaves de cache limpas, cabeçalhos variantes (por exemplo, para WebP) e versionamento consistente. Faço cache de páginas HTML críticas cuidadosamente, respostas de API seletivamente e imagens agressivamente. Uma breve visão geral do Otimização de CDN ajuda-me a evitar armadilhas como a dupla compressão. É assim que combino a cache do servidor e a cache de ponta e mantenho os custos baixos. Ver.
Formatos, negociação e deduplicação na periferia
Reproduzo imagens em formatos modernos (WebP, AVIF opcional) e asseguro que a CDN respeita a negociação de conteúdos. É importante que estejam corretas Aceitar-e a unicidade das chaves da cache. Evito o double-Gzip, comprimindo apenas uma vez (servidor ou Edge) e desativar a bandeira na outra extremidade. Para HTML, defino TTLs conservadores e ETags fortes, os activos permanecem agressivamente armazenados em cache.
Medição, números-chave e definição de prioridades
Começo com um orçamento de desempenho claro e concentro-me no LCP, CLS e INP em vez de no valor de cada milissegundo isolado a considerar. Os dados de campo são superiores aos valores de laboratório, pelo que comparo os sinais dos utilizadores reais com os testes. Os diagramas de cascata revelam activos bloqueadores, os mapas de pedidos mostram bibliotecas duplicadas e ficheiros de tipos de letra desnecessários. Meço cada alteração individualmente para reconhecer rapidamente as regressões. Só quando os valores melhoram de forma consistente é que as implemento de forma mais alargada de.
Método de trabalho: implementar de forma limpa, reverter rapidamente
Incorporo verificações de desempenho no meu processo de implementação: As compilações geram artefactos com versões, os testes do Lighthouse/DevTools são executados na fase de preparação e apenas os pacotes verificados são lançados. Os sinalizadores de funcionalidades permitem-me implementar alterações arriscadas de forma controlada e desactivá-las imediatamente, se necessário. Isto permite-me manter o desempenho estável enquanto desenvolvo novas funções.
Brevemente resumido: Como o aplico
Em primeiro lugar, optimizo o conteúdo com o maior potencial: reduzo o tamanho da imagem, ativo o carregamento lento, coloco em linha partes críticas de CSS e bloqueio scripts deslocação. Em seguida, asseguro estratégias de cache no lado do navegador e do servidor, organizo as funcionalidades do WordPress e a base de dados e removo os plugins desnecessários. Verifico a infraestrutura, HTTP/2/3, Brotli e OPcache e asseguro processos de implementação limpos com controlo de versões. Se necessário, adiciono um CDN e regulo os cabeçalhos e as variantes. Por fim, verifico iterativamente os índices até que o LCP, o CLS e o INP estejam estáveis e ecológicos. Áreas mentira.
