Nossos amigos do WP Engine lançaram recentemente uma bela nova página inicial construída com Beaver Builder. Compartilhamos um link para a página no Grupo Beaver Builders no Facebook e algumas pessoas notaram que o tempo geral de carregamento da página era bastante alto. Nosso bom amigo e extraordinário desenvolvedor de WordPress, Jon Brown, veio ao resgate com uma ótima explicação.

A conversa no Facebook

Deixe-me parafrasear a conversa aqui bem rápido:

Beaver Builder preocupado: fiz um teste de carregamento de página com a ferramenta de teste XYZ e demorou quase 10 segundos para carregar!

Jon: Velocidade e desempenho são uma escolha de design e são essenciais para as conversões de vendas, mas isso não significa que não sejam uma compensação em relação a outras ferramentas MAIS valiosas.

Vejo pessoas olhando as notas das letras e o tempo total de carregamento muitas vezes sem entender a cascata. Isso o desviará do caminho, a menos que você esteja olhando para sites muito simples…

Essas notas das ferramentas de teste são realmente grosseiras e ignoram muitas realidades práticas. Eles dirão para evitar redirecionamentos quando forem para anúncios, scripts de rastreamento e outras coisas que necessariamente funcionam dessa maneira. Eles muitas vezes ignoram o HTTP/2 e recomendam a redução de solicitações e a concatenação de ativos que não importariam e poderiam até prejudicar... Eles não se concentram no índice de velocidade e na renderização acima da dobra...

O verdadeiro carregamento da página é <1,5s

Vamos cavar mais fundo

Perguntei a Jon se ele poderia responder a mais algumas perguntas sobre desempenho e ele gentilmente concordou. Estas são as minhas perguntas (de Robby) com as respostas de Jon.

Ah, eu mencionei que Jon administra uma loja de desenvolvimento personalizado chamada 9seeds, então ele está disponível para locação para ajudá-lo a ajustar o desempenho do seu site WordPress!

1. Você mencionou a “cachoeira”. Você pode explicar um pouco mais sobre o que é a cachoeira?

Existem muitas ferramentas para avaliar o desempenho do site. Muitos deles fornecem um relatório que inclui uma nota de carta fácil de entender. No entanto, essas notas por letras são ferramentas bastante contundentes e, embora seja bom quando você obtém todos os As, não é particularmente esclarecedor, muito menos útil, quando você não vê As corretamente. A única nota de letra que considero útil é para compactação de imagem, que é uma solução fácil, execute suas imagens por meio de um otimizador.

Muitas vezes vejo desenvolvedores leigos e novatos ficarem cegos pelas letras. Existem muitos fatores que influenciam o desempenho do frontend web e é realmente necessário olhar para a “cascata”, que é apenas um gráfico que mostra todas as solicitações HTTP, quando foram iniciadas e quando foram concluídas. Eu uso WebPageTest.org para gerá-los.

A “cascata” é onde você “vê” qual é o ativo específico que está demorando muito para carregar e/ou que está bloqueando o carregamento de outras coisas.

Por fim, reconheça que o As pode exigir escolhas de design (como a remoção de controles deslizantes) e a eliminação de ativos de terceiros (como Google Analytics, HotJar, etc.), que são mais valiosos para o proprietário do site do que obter um A. Nem todo site pode ser feito para endireitar-se sem sacrifícios dolorosos.

2. Você recomendou o WebPageTest como sua ferramenta de teste preferida. Por que você prefere e como ele difere de ferramentas como Pingdom, GTmetrix (e/ou Google Page Speed?)?

Pessoalmente, nunca encontrei nada melhor e mais flexível para fazer isso do que WebPageTest.org. No entanto, eu também usei GTMetrix, Pingdom, Google Page Speed ​​e outros no passado e eles estão bem. Alguns dos novos, como o Lighthouse, são muito legais para aplicativos da web progressivos (não 99% dos sites WordPress). Certamente não estou dizendo às pessoas para trocarem de ferramentas, usem a ferramenta que você conhece e entende. Se você não conhece nenhuma ferramenta, o WPT é uma ótima ferramenta gratuita para aprender. Basta ir além das notas em letras e começar a entender o que está causando essas notas em letras.

3. Falando em “reduzir solicitações e concatenar ativos”, essa não é mais uma prática recomendada? Por que?

Na época em que a maioria dos sites era HTTP, em oposição a HTTPS, e todos os servidores web usavam o protocolo HTTP/1.1, os servidores web só podiam enviar alguns ativos em paralelo. Cada ativo (imagem, script, folha de estilo) foi enviado separadamente e cada um tinha sua própria sobrecarga, o que tornava as coisas mais lentas. Concatenar tudo o que era possível reduziu o número de solicitações HTTP e trouxe enormes benefícios de desempenho.

Nos últimos dois anos, houve um grande impulso em direção ao HTTPS em todos os lugares, e os servidores web começaram a suportar o novo protocolo HTTP/2. O HTTP/2 tem enormes benefícios, como pré-busca e pré-carregamento, mas também pode enviar todos esses pequenos ativos em paralelo, portanto, não há necessidade de concatená-los. Na verdade, pode ser melhor não fazer isso, para que cada pequeno ativo possa ser armazenado em cache de forma independente.

É importante ter em mente que isso só funciona se o seu servidor web suportar HTTP/2 e isso só é possível se o seu site for HTTPS.

Dito isso, todos os sites em que trabalhamos atualmente são HTTPS e rodam em servidores compatíveis com HTTP/2, então estou no ponto em que nem penso mais em concatenar ativos, e certamente não sinto falta disso!

4. Existem outros “mitos” ou recomendações de desempenho desatualizadas que você recomendaria?

A maior delas é simplesmente que cada site pode obter A direto sem fazer concessões dolorosas, como alterações de design ou eliminação de ativos de terceiros que você não controla. No entanto, tudo bem porque você deve começar a olhar para algo chamado Índice de Velocidade! O WPT tem um bom artigo sobre isso, mas basicamente considera quando o “acima da dobra” é percebido como totalmente carregado pelo usuário. É uma questão de velocidade da experiência do usuário, e não de a página ser realmente completa. Essa foi uma das coisas sobre o novo design da página inicial do WP Engine, o índice de velocidade foi incrível. Eram os scripts adiados que demoravam muito para carregar e concluir.

5. Você tem alguma outra ferramenta, dica ou truque de desempenho que recomendaria a alguém?

Ferramentas nas quais confiei ao longo dos anos:

• WebPageTest.org – Meu favorito!
• ImageOptim – aplicativo de desktop para compactar JPGs/PNGs
• ImageAlpha – aplicativo de desktop para compactar PNGs (principalmente reduzindo o número de cores)
• CloudFlare – gratuito como um enorme CDN global e WAF básico. Além de recursos profissionais pagos impressionantes, como otimização de imagem em tempo real, otimização de rota e muito mais.

Plug-ins:

• WP Rocket – Mesmo no WP Engine, usamos WP Rocket, simplesmente funciona.
• Imagify.io – Otimização de imagens baseada em WordPress/nuvem.
• BeaverBuilder – Não fui pago para dizer isso! Somos chamados para fazer auditorias de desempenho em muitos sites e muitas vezes vemos grandes problemas de front-end e back-end com outros construtores de páginas populares. Não vou citar o nome, mas não com o Beaver Builder, e é por isso que o usamos em nosso próprio site como bem!

Obrigado mais uma vez, Jon, por dedicar seu tempo para nos orientar sobre uma abordagem mais moderna de desempenho. Eu queria dar uma última dica para a agência de Jon, 9seeds. Se você está procurando ajuda com qualquer tipo de desenvolvimento WordPress personalizado, avise-os!

Sobre John Brown

Andarilho. Desenvolvedor WordPress. Fotógrafo. Fígado da Vida.