No WP Rocket, nossa missão é educar os usuários sobre a importância do desempenho da Web, tornando-o o mais simples e acessível possível. É um grande desafio: o desempenho da web não é um assunto fácil, e otimizar um site para melhorar o desempenho é ainda menos fácil de explicar e entender. Além do mais, encontrar informações confiáveis é difícil – o tema é complexo e às vezes subjetivo.
Este artigo destaca alguns conceitos enganosos sobre o que importa ao identificar as principais ações de otimização de desempenho para acelerar um site. Continue lendo e você encontrará uma lista dos equívocos mais comuns que encontramos. Explicaremos por que eles estão incorretos e compartilharemos como enfrentamos os desafios de desempenho da Web com nosso plug-in.
Quais são os equívocos mais comuns sobre desempenho na Web?
Vamos descobrir os equívocos que consideramos mais relevantes em relação à otimização de desempenho web.
1. Atrasar JavaScript
A otimização de arquivos JavaScript é uma das otimizações de desempenho da Web mais desafiadoras. É também um dos mais impactantes para melhorar o desempenho e as principais métricas, como Core Web Vitals. Em outras palavras, você não pode evitar a otimização do JavaScript se quiser um site rápido. Uma maneira eficaz de ir é atrasar os arquivos JS que não precisam ser executados imediatamente. Como resultado, a página carregará mais rapidamente e o navegador executará o JavaScript apenas quando necessário para a interação do usuário.
O equívoco é que todos os arquivos JS devem ser atrasados. A verdade é que muitas vezes isso prejudica a experiência do usuário e pode até interromper a funcionalidade do site. JS críticos nunca devem ser atrasados, como aqueles relacionados aos recursos acima da dobra (por exemplo, menu) e aos scripts de rastreamento (por exemplo, Google Analytics). Esses recursos devem estar disponíveis no início do carregamento da página para garantir uma experiência de usuário tranquila.
Agora é fácil entender por que saber quais arquivos JS devem ser excluídos do atraso e como fazer isso é crucial.
Por exemplo, o WP Rocket permite que você gerencie o recurso de execução Delay JS facilmente. A opção torna mais fácil atrasar o JS – uma tarefa importante de otimização. Além disso, o WP Rocket permite que você exclua arquivos JavaScript manualmente e graças à exclusão de um clique lançada com nossa última versão principal, WP Rocket 3.13.
Perguntamos a Adam Silverstein, engenheiro de relações com desenvolvedores do Google , sua opinião sobre sempre atrasar o JavaScript e seu impacto no desempenho. Ele confirma nossa visão e acrescenta: “Geralmente, para sites renderizados por servidor, como os sites WordPress geralmente são, a maioria do JavaScript pode ser adiada, a menos que seja necessária no início do ciclo da página por algum motivo. Um exemplo são os scripts analíticos nos quais você deseja capturar dados o mais rápido possível: aqui, o atributo assíncrono é mais apropriado. Um risco potencial com scripts adiados é que, se outros scripts ou scripts embutidos dependerem do script adiado (e não forem adiados também), a dependência poderá ser interrompida”.
Portanto, é hora de examinar o equívoco sobre adiar o JavaScript.
2. Adie o JavaScript
Aqui, o equívoco é que todo JS pode ser adiado.
A verdade é que adiar o JavaScript é crucial, desde que respeite as dependências. Em outras palavras, adiar o JS sem considerar as dependências não é recomendado.
Por exemplo, um script embutido usando a biblioteca jQuery precisará de jquery.js para ser executado antes que possa ser executado sem travar. Se jquery.js for adiado, o script embutido não encontrará o jQuery declarado e exibirá um erro de console jQuery não está definido, impedindo a execução do código, interrompendo o recurso relacionado e possivelmente interrompendo o layout e o funcionamento geral da página também.
Adam Silverstein menciona uma nova proposta de API de script WordPress prestes a ser lançada. Isso ajudará a estratégia de adiamento definindo táticas de carregamento e evitando problemas de dependência.
Adam explica: “ Na abordagem proposta para o núcleo, estamos lidando com os casos de adiamento automaticamente com a abordagem do núcleo para a estratégia de script – incluindo a verificação de que os scripts dependentes também são adiáveis e o tratamento da execução atrasada de scripts embutidos que dependem de um script adiado”.
Quando se trata de adiamento de JavaScript, o WP Rocket tem muitas exclusões automatizadas para evitar conflitos. Por exemplo, quando o Avada está ativado, o WP Rocket exclui automaticamente a biblioteca jQuery e o script externo do Google Maps.
A nova API de script permitirá que nosso plug-in estenda ainda mais a biblioteca de exclusões. Como resultado, será cada vez menos provável que seu site quebre ao adiar o JavaScript.
3. Reduza o CSS usado
Além da otimização do JavaScript, reduzir o uso de CSS é uma das maneiras mais eficazes de aumentar o desempenho do seu site. Existem duas maneiras de gerenciar essa otimização:
- Inlining de arquivos CSS, o que significa integrar CSS na mesma página usando uma tag `style`.
- Use arquivos externos separados.
O equívoco é que entregar o CSS usado em arquivos separados é sempre a melhor maneira de lidar com essa otimização.
A verdade é que inlining CSS é perfeitamente adequado e tem duas vantagens importantes do ponto de vista de desempenho e experiência do usuário:
- É um processo mais rápido porque o navegador fará apenas uma pequena solicitação para verificar se a página está atualizada. Se a página não foi alterada, o que geralmente é o caso, o navegador fornecerá uma cópia em cache da página. Por esse motivo, o CSS usado embutido melhorará o desempenho: o navegador não carregará e analisará um arquivo CSS, mas processará diretamente o CSS embutido na página.
- O inlining de todo o CSS da página evita problemas como FOUC (Flash de conteúdo sem estilo) e não afeta a experiência do usuário, como o uso do CSS do caminho crítico, além de um arquivo separado, poderia causar. Para evitar que outras métricas piorem, deve ser necessário ter o CSS do caminho crítico quando o CSS usado for entregue usando um arquivo.
É por isso que o WP Rocket inline CSS e permite que qualquer pessoa aproveite um recurso avançado, como remover CSS não utilizado com apenas um clique:
Mais uma vez, Adam Silverstein, do Google, compartilha nosso ponto de vista. Perguntamos a ele qual é a maneira mais eficaz de entregar o CSS usado. Ele diz: “Minha expectativa é que, pelo menos para tamanhos menores de CSS, o inlining seja mais rápido, reduzindo a necessidade de carregar o arquivo CSS adicional. A “penalidade” para isso pode variar dependendo das condições – por exemplo, o dispositivo e a rede que o usuário está usando”.
4. Hospede fontes localmente
Se você administra um site WordPress, já deve saber que hospedar fontes localmente pode ser outra boa opção para melhorar o desempenho. Além disso, hospedar fontes locais é essencial para cumprir as regras do GDPR.
Em relação às fontes do Google, é importante controlar de onde os arquivos serão enviados para que não dependam do CDN do Google Fonts – principalmente se ele não funcionar bem para grande parte do público.
Um equívoco comum é que hospedá-los melhorará automaticamente o tempo de carregamento do seu site.
A verdade é que as fontes do Google serão mais rápidas apenas se forem exibidas na mesma zona onde o visitante está.
Se o site usar um CDN, as fontes do Google serão mais rápidas apenas se a cobertura do CDN for melhor do que as fontes do Google – o que depende muito da localização do visitante.
Fizemos testes para validar essa suposição e descobrimos que as fontes hospedadas tiveram o menor desempenho para visitantes distantes em relação ao tempo até o primeiro byte, uma métrica fundamental para aumentar a velocidade do seu site.
Esse dado de desempenho é importante porque vai influenciar diretamente no elemento LCP se for um texto usando fontes do Google.
O outro equívoco sobre hospedar fontes localmente é que o WP Rocket não pode pré-carregar as fontes do Google. Isso é falso: nosso plug-in pode pré-carregar fontes do Google automaticamente quando ativado pela opção Remover CSS não utilizado.
5. Dica de recurso de busca prioritária
A dica de prioridade de busca é um atributo que informa ao navegador a prioridade dos recursos a serem descobertos e baixados para que a página possa carregar o mais rápido possível. Atualmente, seu uso ainda é limitado a pouco menos de 70% dos usuários em todo o mundo.
O equívoco é que você sempre deve usar a dica de recurso fetchpriority. A verdade é que a dica de recursos pode parecer obrigatória, mas não é tão simples quanto parece.
Embora a dica fetchpriority disponibilize recursos críticos a tempo, ela pode deteriorar o desempenho se os recursos forem buscados sem a prioridade correta. Esta é uma tarefa de otimização de desempenho muito complexa – e é difícil implementá-la sem testar ou analisar páginas.
Ao mesmo tempo, o impacto dessa tarefa no desempenho é limitado ao que pode ser automaticamente priorizado ou despriorizado.
Listamos alguns exemplos para explicar como o fetchpriority depende de vários fatores.
- Logo e imagem LCP : isso é fácil – esses elementos são candidatos óbvios com alta prioridade de busca.
- Sliders : começa a ficar complicado.
As imagens de um controle deslizante acima ou perto da dobra terão uma prioridade de busca subjetiva, dependendo se causam um problema.
Se o controle deslizante estiver próximo à dobra, mas considerado crítico para a experiência do usuário, sua primeira imagem deve ser altamente priorizada.
Se um slider estiver atrasado, não é necessário priorizar a busca de suas imagens, mesmo que esteja acima da dobra. - CSS, JS e recursos de terceiros : apenas seus respectivos desenvolvedores podem avaliar se devem ser priorizados ou despriorizados. E mesmo com a entrada deles e ao misturar vários plug-ins e recursos, a prioridade de busca seria baseada em casos.
Você pode ver o que queremos dizer quando dizemos que as dicas de recursos não são tão fáceis quanto você pode supor.
É por isso que o WP Rocket ainda não inclui esse recurso, embora o fetchpriority possa impactar positivamente a velocidade do seu site se usado corretamente. Fique tranquilo, nosso plug-in ajuda a obter um desempenho ideal graças a outros recursos poderosos e avançados.
Também perguntamos à equipe do Google qual é a opinião deles sobre o uso de uma alta prioridade de busca para todas as imagens acima da dobra e uma baixa para todas as imagens abaixo da dobra.
Adam Silverstein explica: “Em geral, o objetivo deve ser adicionar fetchpriority=high apenas a imagens críticas porque adicioná-lo a várias imagens geralmente desfaz os benefícios. Normalmente, você deseja que a imagem LCP seja definida com esse atributo, mas pense com cuidado antes de usá-la em muitos outros recursos. Esta página é o melhor recurso para entender a prioridade de carregamento. Em geral, todas as imagens começam com baixa prioridade. As imagens na janela de visualização começam com prioridade “baixa” e, no momento do layout, quando o navegador percebe que estão na janela de visualização, são aprimoradas para “alta”. Marcando-o na marcação usando fetchpriority=”high”, eles podem começar em “high” imediatamente e carregar muito mais rápido. Se você marcar muitas imagens como de alta prioridade, elas competirão pelos mesmos recursos. Uma possível exceção seria tentar marcar a imagem LCP para pontos de interrupção de desktop e móveis (que poderia ser uma imagem diferente). O recurso ‘experiências’ do WebPageTest é uma ótima maneira de testar isso”.
Falando em fetchpriority, é interessante destacar que a equipe de desempenho principal propôs adicionar o atributo fetchpriority=”high” às imagens LCP no núcleo do WordPress para melhorar o desempenho do LCP.
Alerta de spoiler : estamos trabalhando em uma maneira automática de adicionar a prioridade de busca no elemento LCP, tornando o mais fácil possível para nossos usuários se beneficiarem da opção. Você pode ver do que estamos falando em um de nossos próximos lançamentos.
6. Carregamento lento de imagens de plano de fundo
Lazy loading é outra importante técnica de otimização de desempenho da web. Ele permite que o navegador carregue imagens apenas quando necessário, para que nem todas as imagens sejam carregadas simultaneamente e a página possa ser renderizada e exibida rapidamente.
É por isso que o carregamento lento de imagens de plano de fundo pode poupar solicitações de imagens desnecessárias abaixo da dobra, melhorando assim o desempenho.
O equívoco é que imagens de fundo adicionadas em CSS interno (tag `style`) e arquivos CSS podem ser carregados lentamente. A verdade é que o WordPress, as bibliotecas lazyload e o lazyload nativo não permitem essa otimização – que precisa ser precisa, e não é tão simples quanto parece.
No WP Rocket, trabalhamos em um recurso específico para tornar essa otimização fácil e automatizada, mas precisa.
7. Imagens LCP vs. Imagens acima da dobra
Falando em carregamento lento e no atributo de prioridade de busca, outro equívoco é que tudo acima da dobra deve ser definido com um valor alto (fetchpriority=high).
Adam Silverstein explica: “Otimizações de prioridade de busca devem, idealmente, ser aplicadas apenas à imagem LCP. Ao mesmo tempo, todas as imagens acima da dobra devem evitar o carregamento lento”.
E acrescenta um exemplo: “Digamos que haja seis imagens acima da dobra e uma imagem LCP. Então, a melhor abordagem seria omitir o carregamento lento de todas as imagens e aplicar a prioridade de busca à imagem LCP”.
8. Excluir imagens acima da dobra do carregamento lento
Se você estiver familiarizado com as práticas recomendadas de otimização de desempenho da Web, é provável que saiba que excluir as imagens acima da dobra do carregamento lento é uma boa maneira de acelerar o desempenho do site.
Isso é parcialmente um equívoco, pois depende principalmente de como as ferramentas atuais lidam com isso.
Embora a exclusão de imagens acima da dobra possa aumentar a velocidade do seu site, isso pode resultar em pular imagens adicionais do carregamento lento se não for implementado para as imagens atualmente incluídas acima da dobra. Como resultado, a página carregará mais lentamente, e não o contrário.
Além disso, o número de imagens a serem excluídas geralmente difere de uma janela de visualização para outra, tornando a otimização de desempenho mais difícil de gerenciar.
Essa otimização requer auditoria para encontrar imagens precisas para pular do carregamento lento.
As soluções atuais não são automatizadas e são baseadas em um ‘palpite’, em vez de excluir as imagens reais. É por isso que desenvolvemos a solução mais fácil possível para permitir que qualquer pessoa lide com essa otimização de desempenho.
Fizemos alguns testes e obtivemos resultados interessantes. Quando implementado corretamente e excluindo o número exato de imagens acima da dobra do carregamento lento, ele pode melhorar métricas como Primeira exibição de conteúdo , Maior exibição de conteúdo e Índice de velocidade. Além disso, ele pode abordar auditorias do PageSpeed Insights, como Evite cargas de rede enormes e Mantenha a contagem de solicitações baixa e os tamanhos de transferência pequenos.
Enquanto isso, o WP Rocket permite que você resolva isso com um plugin auxiliar.
9. Imagem de visualização do iframe do YouTube
Você pode estar certo se acha que ativar a imagem de visualização do iframe do YouTube aumentará a velocidade do seu site. Essa solução evita o carregamento de scripts do YouTube e inicia o carregamento do vídeo somente se o usuário clicar no botão play.
No entanto, neste ponto do artigo, você deve estar familiarizado com o conceito de: depende.
A implementação da imagem de visualização do iframe do YouTube para otimizar o desempenho não funcionará para todos os sites. Pode causar problemas se o elemento pai que contém as imagens de estilo de vídeo estiver inutilizável. Nesse caso, a imagem de visualização não será exibida corretamente e pode precisar de algum CSS adicional para desfazer o estilo conflitante do elemento pai.
O iframe provavelmente será carregado da mesma forma, pois será reinjetado assim que a imagem de visualização for clicada.
Fizemos alguns testes e validamos a suposição de que a auto-hospedagem da imagem de visualização do YouTube nem sempre oferece melhores resultados. Dados de desempenho melhores se aplicam apenas a audiências locais ou se uma CDN estiver sendo usada.
Nossos testes mostram que o CDN do YouTube ainda tem o melhor desempenho e o TTFB mais baixo, influenciando a velocidade com que a imagem é buscada.
Considerar este resultado é essencial porque tais dados de desempenho influenciam o elemento LCP se a imagem de visualização fizer parte dele.
10. Usando um CDN
O último equívoco que queremos cobrir é o uso constante de um CDN para melhorar o desempenho. Embora seja verdade que um CDN tornará seu site mais rápido se seu público for mundial, não é correto dizer que sempre ajudará no desempenho de seu site.
Depende da localização do visitante e da distância entre o usuário e os ativos solicitados.
Vamos dar alguns exemplos para ficar mais claro.
- Público local : você administra uma empresa local na França e seu site já está hospedado em um servidor local. Usar um CDN que não tenha PoP (Pontos de Presença) na França ou próximo a ele vai piorar a experiência do usuário, pois a página e seus ativos serão enviados de um data center distante, digamos, Nova York. Por outro lado, a distância será menor se você usar apenas o servidor de origem.
- Região ou audiência mundial : você administra uma empresa regional em toda a Europa. Escolher um CDN com forte presença na Europa dará melhores resultados do que escolher um CDN que tenha apenas um ou dois PoPs na Europa.
Resumindo, ao escolher um CDN, você deve garantir que a cobertura de PoPs corresponda aos locais do público.