10 dicas para um site WordPress mais rápido

Vi no PainelWP um artigo muito legal da Jem Turner com 10 micro-otimizações para tornar seu site WordPress mais rápido. Entrei em contato com ela pedindo permissão para traduzir e aqui estamos nós. Ela tem um estilo bem dinâmico de escrever, o que eu curto bastante, então para não mudar muito e deixar o texto chatão, eu (Felipe) mantive todos os “eu” dela (Jem).

A velocidade do site é um fator importantíssimo para o posicionamento do seu site nos mecanismos de busca, especialmente o Google:

Como parte deste esforço, hoje estamos incluindo um novo fator nos nossos algoritmos de posicionamento de busca: velocidade. A velocidade do site reflete o quão rápido um site responde a requisições.

Using site speed in web search ranking — Official Google Webmaster Central Blog

Sites mais rápidos aumentam muito a probabilidade de converter um visitante em cliente:

Reconstruir as nossas páginas com foco em desempenho resultou em uma diminuição de 40% de tempo de espera dos usuários, um aumento de 15% no tráfego de SEO e um aumento de 15% na taxa de conversão na criação de conta.

Driving user growth with performance improvements — Pinterest_Engineering

E um site rápido melhora a experiência do usuário de modo geral. Essa nem precisa de fontes, todo mundo sabe que um site lento irrita qualquer um.

A maioria de nós já ouviu os conselhos genéricos: usar imagens menores, comprimi-las, evitar muitos plugins, escolher uma hospedagem mais rápida, aproveitar os sistemas de cache dos navegadores. E depois? Se isso tudo já está feito, como podemos melhorar ainda mais? Como podemos otimizar sites WordPress para aumentar sua velocidade e fazer com que o Google nos posicione melhor?

Diminuir o número de requisições HTTP do WordPress

Uma solicitação HTTP é, em termos simples, uma forma de obter informação de um servidor. Quando você visita um site (para ler este post, por exemplo), seu navegador solicita as informações relacionadas à página que você está vendo: imagens, arquivos JavaScripts, arquivos HTML, etc. O servidor então manda estes arquivos de volta. Quanto mais arquivos você solicita, mais tempo o servidor leva para responder e mais tempo a página demora para carregar.

Por experiência própria, este é um dos elementos mais esquecidos na otimização de velocidade e é uma ótima forma de conseguir resultados rápidos. Aqui vão algumas formas de reduzir as solicitações HTTP do seu WordPress:

1. Remover o jQuery Migrate
2. Remover o wp-embed.min.js
3. Remover estilos de plugins (De-queue ou de-register)
4. Desabilitar o Gutenberg e remover scripts e estilos
5. Remover os estilos dos emoji
6. Incluir scripts e estilos condicionalmente

1. Remover o jQuery Migrate

O jQuery Migrate é uma biblioteca JavaScript normalmente usada para que códigos usados com versões antigas do jQuery não quebrem. Ele mantém essa compatibilidade conservando funcionalidades que foram removidas do código principal do jQuery. Em outras palavras, se você está executando um plugin que depende de uma versão muito antiga do jQuery ou de uma funcionalidade muito antiga dele, então o Migrate mantém tudo funcionando direitinho.

Entretanto, como nós todos somos muito espertos, nós mantemos o nosso WordPress e seus plugins atualizados, e isso inclui usar plugins que foram atualizados para usar padrões “modernos” (você mantém o seu site atualizado, não é?). O WordPress inclui o jQuery Migrate por padrão desde o WordPress 3.6. Sendo assim, a maioria de nós está carregando esta biblioteca com código antigo sem realmente precisar dela. O seguinte snippet verifica se o jQuery Migrate realmente é uma dependência necessária e, se não for, o remove.

function remove_jquery_migrate( $scripts ) {
    if ( ! is_admin() && isset( $scripts->registered['jquery'] ) ) {
        $script = $scripts->registered['jquery'];

        if ( $script->deps ) {
            $script->deps = array_diff(
                $script->deps,
                array(
                    'jquery-migrate',
                )
            );
        }
    }
}
add_action( 'wp_default_scripts', 'remove_jquery_migrate' );

Você pode colocar este código no arquivo functions.php do seu tema ou criar um plugin.

2. Remover o wp-embed.min.js

A primeira vez que eu vi uma requisição para o wp-embed.min.js nas minhas páginas WordPress, eu pensei a única coisa lógica a se pensar: bom, isso deve ser alguma coisa relacionada ao suporte para oEmbed do WordPress. E então eu deixei isso para lá. Depois de muito tempo eu dei mais uma olhada e percebi que o wp-embed.min.js só impacta realmente a habilidade de incorporar posts WordPress de outras pessoas no seu próprio blog, graças a este comentário extremamente subestimado.

Eu não quero incorporar os posts WordPress de outras pessoas no meu blog. Nem eu nem a grande maioria dos meus clientes comerciais, então eu desligo isso usando o seguinte snippet no arquivo functions.php do tema:

function deregister_wp_embed() {
    wp_deregister_script( 'wp-embed' );
}
add_action( 'wp_footer', 'deregister_wp_embed' );

Bum! Menos duas requisições HTTP.

3. Remover estilos de plugins (De-queue ou de-register)

Esse é controverso — talvez não tanto quanto a número 4, mas a gente chega lá — porque requer que você fique de olho em mudanças futuras. Basicamente, quando eu instalo um plugin no site de um cliente que eu sei que usa um CSS que muito provavelmente não vai mudar, ou melhor ainda, vai ser substituido por um CSS criado por mim de qualquer forma, eu desenfilero a folha de estilos do plugin.

Pequena nota do tradutor que vai no meio do texto mesmo: o WordPress tem dois conceitos importante no uso de JavaScripts e CSS. O primeiro é o registrar (register), que diz para o core que o arquivo existe. O segundo é o enfileirar (queue), que diz para o core que o arquivo precisa ser usado e, por isso, sua chamada deve ser incluída no HTML a ser exibido. Segue o texto.

Se eu preciso de algum ou de todos os estilos do plugin, eu minimizo o CSS original do plugin e o coloco como um bloco só no começo da folha de estilos principal do tema, para que eu não esqueça dele (eu também faço isso com alguns arquivos JavaScript em um .js central do tema, mas eu sou hardcore, beleza?).

Isso funciona bem com plugins como o Contact Form 7, onde os estilos raramente foram modificados e o Shiftnav, um menu mobile que eu gosto de personalizar bastante para cada cliente. Eu já fiz isso até para o WooCommerce (removendo e reestilizando), mas isso requer um esforço maior para funcionar certinho.

A maioria das folhas de estilo podem ser desenfileiradas (dequeued) usando o seguinte snippet:

function dequeue_unnecessary_styles() {
    wp_deregister_style( 'stylesheet-id' );
}
add_action( 'wp_print_styles', 'dequeue_unnecessary_styles' );

…onde stylesheet-id é o conteúdo do atributo id na tag <link />, sem o “-css”. Por exemplo, a folha de estilos do Social Warfare é mais ou menos assim:

<link rel='stylesheet' id='social_warfare-css'  href='https://www.jemjabella.co.uk/.../style.min.css?ver=3.6.1' type='text/css' media='all' />

O ID da folha de estilos é “social_warfare”. Você pode adicionar tantos wp_deregister_style( 'stylesheet-id' ); quanto quiser dentro dessa mesma função.

Isso pode não funcionar se o autor do plugin bagunçou as prioridades ou, ainda pior, não usou o sistema do WordPress para chamar o CSS, mas injetou a chamada diretamente usando outras formas. Não dá pra desejar nada de bom para quem faz uma coisa dessas.

4. Desabilitar o Gutenberg e remover scripts e estilos

Calma, não precisa pegar nem a foice nem o forcado para me pegar. Bem devagar, eu estou me acostumando com o Gutenberg como o nosso editor do futuro, mas agora ainda existem várias aplicações onde essa fera é redundante, especialmente para clientes onde as páginas são tão cheias de código proprietário, shortcodes e widgets esquisitos que não vale a pena migrar ainda. Eu ainda não fiz a mudança aqui no jemjabella pela mesma razão (sério, é um site muito antigo, peguem leve).

Se instalar o Editor clássico resolve o problema na tela de edição, por alguma razão (manter a retrocompatibilidade no caso de alguém tentar usar o Gutenberg, talvez?), ele não remove alguns dos estilos do editor de blocos. Para isso temos esse pequeno snippet para arrematar o trabalho:

function deregister_gutenberg_styles() {
	wp_dequeue_style( 'wp-block-library' );
	wp_deregister_style( 'wp-block-library' );
}
add_action( 'wp_print_styles', 'deregister_gutenberg_styles', 100 );

(Eu tive alguns problemas fazendo isso sem passar a prioridade, pode ser diferente com você). Eba! Adeus requisição HTTP desnecessária do Gutenberg!

5. Remover os estilos dos emoji

Não é preciso grandes explicações para esse aqui. Clientes realmente precisam de suporte a emojis em seus sites? Não. Tchau, scripts e estilos dos emoji.

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );

É só colocar isso no functions.php do seu tema.

6. Incluir scripts e estilos condicionalmente

Se dermos um passo a mais no desenfileiramento (palavra estranha, eu sei, mas existe) e na compressão de estilos, podemos pensar nos estilos de plugins que continuamos incluindo e questionar se e quando estes plugins são necessários. Por exemplo, eu uso os botões de compartilhamento do Social Warfare no blog só em posts e snippets. Por isso, não parece necessário carregar seus estilos na página inicial.

Eu uso o seguinte snippet para fazer o WordPress incluir os estilos do Social Warfare só nos dois tipos de página necessários:

function conditionally_deregister_styles() {
    if ( ! is_singular( array( 'post', 'snippet' ) ) ) {
        wp_deregister_style( 'social_warfare' );
    }
}
add_action( 'wp_print_styles', 'conditionally_deregister_styles' );

Na verdade eu combino isso com o código que exclui as coisas do Gutenberg, já que os dois usam a ação wp_print_styles.

E agora? O que mais a gente pode otimizar?

Reduzir o tamanho do nosso código

Na busca do primeiro lugar cada byte importa. Aqui vão algumas otimizações que você pode fazer para reduzir a saída HTML do seu WordPress para diminuir alguns milissegundos do seu tempo de carregamento:

1. Remover funcionalidade duplicada
2. Limpar os menus do WordPress
3. Enxugar o wp_head()
4. Ah, e não se esqueça…

7. Remover funcionalidade duplicada

Ontem eu migrei do YoastSEO para o The SEO Framework depois que o Yoast apresentou problemas para guardar minhas configurações (entre outras coisas). No processo eu percebi que tanto o The SEO Framework quanto o Social Warfare estavam gerando as meta tags Open Graph e Twitter Card (juntanto o Yoast com o Social Warfare também aconteceria isso). Eu desabilitei a implementação de og/twitter card do Social Warfare e deixei isso nas mãos do The SEO Framework.

Isso me fez pensar: enquanto construímos nossos sites e adicionamos plugins atrás de plugin, provavelmente nos deparamos com situações onde dois plugins fazem a mesma coisa duas vezes. Para evitar conflitos e códigos desnecessários, faça auditorias regulares nos seus plugins para ver quais você pode desabilitar (seja uma configuração ou até removendo um plugin inteiro).

8. Limpar os menus do WordPress

Um dos meus clientes tinha um “mega menu” em seu site com cerca de 300 itens. Além de quebrar a tela de menus do WordPress com frequência, este menu sozinho gerava milhares de bytes de código. Entretanto, a maior parte do código era das classes aleatórias que o WordPress insiste em incluir, o que torna coisas simples como

<li class="current-menu-item"><a href="https://www.website.com/some-page/">Some Page</a></li>

em

<li id="menu-item-15564" class="menu-item menu-item-type-custom current-menu-item menu-item-object-custom ss-nav-menu-item-depth-3"><a href="https://www.website.com/some-page/">Some Page</a></li>

…multiplicado por 300.

Um salve para o maravilhoso Purify WP Menus. Esse plugin permite que você ligue e desligue várias classes, gerando menus WordPress lindos, limpos e otimizados, sem afetar nenhum estilo de “item de menu ativo” ou bagunçando sua hierarquia. Bum!

9. Enxugar o wp_head()

Essa é uma dica genérica que frequentemente é recomendada por razões de segurança: remova um monte de URLs e informações da sua tag <head> e, de uma hora para outra, seu site é impenetrável! Tcharam! Pode não ser tão simples, mas você pode diminuir seu wp_head e remover algumas coisas que provavelmente você não precisa, reduzindo assim alguns bytes. Bacana.

Se você não usa nenhum dos clientes de blog compatíveis com o WordPress, você pode chamar:
remove_action( 'wp_head', 'rsd_link' );

Se você não usa o Windows Live Writer, você pode usar:
remove_action( 'wp_head', 'wlwmanifest_link' );

Se você não quer ou não precisa de feeds para categorias, busca, tags e comentários de posts (isso não afeta o URL do feed principal do seu blog), você pode usar:
remove_action( 'wp_head', 'feed_links_extra', 3 );

Por último, mas não menos importante, eu não posso pensar em nenhuma razão para você precisar da metatag generator do WordPress, então todo mundo pode usar:
remove_action( 'wp_head', 'wp_generator' );

(Isso também pode ir no functions.php)

10. Ah, e não se esqueça…

Use imagens menores e não esqueça de comprimi-las, evite usar plugins demais, escolha um serviço de hospedagem mais rápido e aproveite o cache do navegador… 😉 De nada!

A imagem destacada é do Braden Collum. Peguei lá no Unsplash.