Resumo: como acelerar JavaScript no seu site
- Adiar não basta: Cada guia de desempenho JavaScript diz-lhe para adiar scripts não essenciais, mas as mesmas tags que adiou continuam a expedir acesso ao DOM não utilizado, dependências de fornecedor caducadas e risco estilo Polyfill de domínio expirado em 490.000 sites que nunca as removeram.
- Veja o que roda onde: O agente JavaScript first-party da cside observa o comportamento em runtime de cada script de terceiros no navegador, então você vê qual código roda onde, serve scripts estáticos mais rápido via cache, sem amostragem e com bloqueio autônomo por cima.
- Um dono, um dashboard: Antes da próxima revisão de Core Web Vitals, decida se o desempenho e a segurança de scripts de terceiros têm um dono e um dashboard, ou continuam divididos entre engenharia e marketing até um CDN caducado derrubar ambos.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Eliminar recursos que bloqueiam a renderização, reduzir JavaScript não utilizado e minimizar o trabalho da thread principal geralmente são encontrados no topo do relatório do PageSpeed Insights. Eles falam sobre economias potenciais, mas além de usar a tag defer, não há muita informação sobre como fazer isso.
Embora existam algumas maneiras extras de fazer suas páginas carregarem mais rápido ao lidar com JavaScript.
Vamos primeiro resolver o adiamento e depois dar algumas opções extras.
Defer ou async?
Resumindo - adiar o carregamento de scripts faz seu site parecer carregar mais rápido do que usar 'async'. Dependendo do seu uso, pode ou não ser a melhor opção, no entanto.
O atributo 'defer' permite que o navegador continue analisando o HTML enquanto o script é baixado em segundo plano. Mas ele aguarda a execução do script até que a análise do HTML esteja completa. É por isso que a 'pintura' do conteúdo no seu site está carregando mais rápido. A página da web é totalmente carregada para o seu visitante ver mais rapidamente do que sem o atributo ou com o atributo 'async'.
O atributo 'async' permite que o navegador continue analisando o conteúdo HTML enquanto o script está sendo baixado em segundo plano. Mas uma vez que o script é baixado, ele é executado imediatamente. Se a análise do HTML não estiver pronta, isso a interromperia. Então, embora o HTML carregue mais rápido do que sem usar async, a potencial interrupção do carregamento do HTML pode fazer seu site parecer carregar mais lentamente.
Quando usar defer ou async?
Scripts 'async' são executados assim que são baixados, o que não é necessariamente na ordem em que aparecem no documento. O atributo 'defer' preserva a ordem e garante que os scripts sejam executados após o documento ter sido analisado.
'Async' é particularmente útil para scripts que NÃO dependem de nenhum elemento do Document Object Model (DOM) ou de outros scripts. Um script adiado aguarda até que o DOM esteja pronto, tornando-os uma aposta mais segura para scripts que precisam manipular o DOM.
Que tipo de scripts manipulam o DOM?
Bibliotecas como jQuery ou scripts personalizados em geral. Estes manipulam o DOM e devem ser carregados com o atributo 'defer' para garantir que o DOM esteja totalmente carregado antes de serem executados. E, se você tiver scripts que dependem de outros scripts para serem carregados primeiro, usar 'defer' garante que eles sejam executados na ordem em que aparecem no documento.
Scripts de análise, anúncios e coisas menos vitais, geralmente falando, não precisam ser carregados o mais rápido possível. É uma escolha que você tem que fazer, mas a maioria das pessoas prefere um site de carregamento mais rápido em comparação com alguns milissegundos a mais de scripts funcionando mais rápido.
Uma boa regra geral é usar defer para JavaScript não essencial. Se o script não depende do DOM ou de outros scripts, então usar async ou nenhum atributo está bem.
Reduzir JavaScript não utilizado
Hora de fazer uma limpeza de primavera. Sacuda a árvore e livre-se de código morto, aqui significando JavaScript não utilizado. Isso beneficia tanto a velocidade quanto a segurança. Escrevemos vários artigos até agora sobre os problemas que podem vir com JavaScript de terceiros. Toda a nossa empresa foi fundada para ajudar a proteger contra as vulnerabilidades associadas a isso. E muitas vezes, sites continuam executando scripts que não são mais usados com grandes riscos que vêm com isso.
Este foi recentemente o caso no ataque à cadeia de suprimentos web do Polyfill, onde um domínio antigo foi comprado por uma nova parte e depois usado para fins maliciosos. Mais de 490.000 sites haviam referenciado este domínio e potencialmente sofreram ataques.
Outras formas são na forma de ferramentas que foram usadas uma vez, mas não mais, ou frameworks que vêm com uma infinidade de bibliotecas JavaScript que não estão em uso em um site específico. Leia mais sobre os riscos de como domínios expirados podem levar a problemas de cibersegurança aqui.
Quanto mais JavaScript você tiver no seu site, maior o risco que você corre.
Costumava ser praticamente impossível detectar mudanças em scripts de terceiros. Felizmente, isso não é mais o caso. Estamos muito orgulhosos de ter construído uma solução que monitora e alerta, e que consegue até bloquear scripts maliciosos de forma autônoma antes que os ataques aconteçam.
Se você usar uma ferramenta de monitoramento como a cside, você poderá facilmente ver qual código está sendo carregado onde, bem como o que esse código realmente faz. Com essas informações, é muito mais fácil realizar essa limpeza de primavera e remover scripts indesejados.
Mas a cside vai ainda mais longe, o que nos leva ao próximo ponto.
Otimizando JavaScript para carregar mais rápido
A cside carrega todos os outros scripts no seu site num proxy para analisá-los antes de serem carregados no navegador. Esta é de longe a solução mais segura. Nada malicioso pode tocar o navegador dos seus utilizadores, o que os protege a eles e a si completamente.
Mas isso vem com alguns desafios. Como o JavaScript é verificado antes de carregar, isso naturalmente adiciona latência. Simplesmente adiar nem sempre é possível, pois carregamos todos os scripts no proxy, também os necessários que impactam os elementos do Document Object Model (DOM), como explicado antes.
Para algumas aplicações, isso ainda estaria bem. Para outras, isso seria um impedimento.
Para nós, isso também foi um impedimento. Sim, segurança em primeiro lugar. Mas se as desvantagens ficarem demasiado grandes, as empresas hesitarão em adotar os melhores padrões. E devemos garantir que haja o mínimo de desvantagens possível.
É por isso que projetámos a cside para realmente otimizar scripts, fazendo-os carregar mais rápido do que o normal, mitigando completamente a latência. Muitas vezes, isto torna esses scripts, e portanto os sites, mais rápidos em vez de mais lentos.
Como verificamos todas as sessões o tempo todo, encontramos os mesmos scripts milhares de vezes por dia. Armazenamos cada versão de um script e, se possível, fazemos cache dele. Isso faz com que possamos carregar as versões em cache, o que é mais rápido do que até mesmo carregar as versões originais de novo.
Reescrevemos especificamente os cabeçalhos de cache para que possamos bloquear um script e mantê-lo bloqueado para clientes que já possam tê-lo no cache, preservando ao mesmo tempo o desempenho do cache.
Também concebemos a nossa infraestrutura para funcionar incrivelmente rápido. Em comparação com outros fornecedores que não serão nomeados, a cside serve um script de 20,3 kb mais rápido do que eles conseguem servir um script de 1,2 kb. O nosso demorou 10ms enquanto o deles demorou 13ms nos nossos testes, um ganho de velocidade de 22x, assumindo que todos os outros fatores permaneçam constantes.
Finalmente, o JavaScript é frequentemente minificado e ofuscado. Minificar é uma maneira comum de obter alguns pequenos ganhos de velocidade. O último pode ter efeitos negativos no desempenho. Saiba apenas que, na cside, pode ver as versões desofuscadas dos scripts para entender melhor o que o código está a fazer.
Compressão
Outra maneira de otimizar JavaScript é usar GZip, Brotli ou outra compressão. São algoritmos que reduzem o tamanho dos ficheiros enviados do servidor para o navegador. Funciona identificando e eliminando dados redundantes dentro de um ficheiro.
Existem algumas ressalvas para isso, mas geralmente é melhor usá-lo do que não. Leva tempo para compactar e descompactar os ficheiros, mas normalmente menos do que o tempo economizado ao descarregar um ficheiro maior. Portanto, você ainda sai a ganhar.
Isso funciona especialmente bem em ficheiros de texto, como HTML, CSS e também JavaScript.
Pré-carregamento e pré-busca
O pré-carregamento permite que você busque recursos críticos (como JavaScript) antes de serem necessários pelo navegador. Esses recursos ficam então disponíveis assim que são necessários, reduzindo os tempos de carregamento. O navegador priorizará esses recursos, descarregando-os durante o carregamento inicial da página.
Por exemplo, pré-carregar um ficheiro JavaScript garante que ele esteja disponível quando o navegador chegar ao ponto no HTML onde normalmente carregaria esse script. Isso evita atrasos causados pela necessidade de o navegador buscar o ficheiro nesse ponto.
Isso pode soar o mesmo que os atributos 'defer' ou 'async', mas existem algumas diferenças importantes.
O pré-carregamento garante que recursos críticos como CSS, fontes e ficheiros JavaScript importantes sejam buscados cedo e priorizados pelo navegador para disponibilidade imediata.
Lembre-se de que o atributo 'defer' é usado para atrasar a execução de JavaScript até que o documento HTML tenha sido totalmente analisado. E, novamente, o atributo 'async' permite que scripts sejam buscados e executados assim que estiverem disponíveis, sem esperar que a análise do HTML seja concluída.
Outro exemplo de pré-carregamento é usar uma fonte personalizada no seu site. Se essa fonte não for carregada rapidamente, os utilizadores podem ver uma fonte padrão primeiro, levando a um flash de texto sem estilo. Ao pré-carregar a fonte, garante-se que isso não ocorra.
A pré-busca, por sua vez, concentra-se em buscar recursos durante o tempo ocioso do navegador para necessidades futuras, como recursos para a próxima página para a qual o utilizador provavelmente irá navegar. Carregar durante esses tempos ociosos reduz significativamente os tempos de espera.
Minimizar o trabalho da thread principal
A thread principal é onde o navegador faz a maior parte do trabalho necessário para exibir uma página, como analisar e executar HTML, CSS e JavaScript. Mantê-la rápida e eficiente é necessário para uma experiência de utilizador geralmente boa.
O PageSpeed Insights dá algumas dicas sobre isso.
A renderização pode ser otimizada aderindo a propriedades exclusivas do compositor. Estas são propriedades CSS que podem ser tratadas inteiramente pelo compositor do navegador, contornando a thread principal e a necessidade de operações de layout ou pintura. Simplificar a complexidade de pintura, reduzindo as áreas que precisam ser pintadas, pode ajudar ainda mais o navegador a renderizar a página de forma mais eficiente, acelerando os tempos de carregamento.
Quando se trata de estilo e layout, simplificar o seu CSS e evitar seletores complexos pode reduzir significativamente o tempo gasto em cálculos de estilo. Provavelmente será um equilíbrio entre design e desempenho.
Evitar layout thrashing é essencial. Layout thrashing ocorre quando realizamos leituras e escritas consecutivas no DOM, impedindo o navegador de otimizar o layout. Isso força o navegador a calcular um layout que nunca é renderizado no ecrã.
Considere adiar CSS não crítico, carregando estilos não essenciais de forma assíncrona para evitar que bloqueiem operações da thread principal durante o caminho crítico de renderização.
Voltando ao JavaScript.
Para avaliação de scripts, o debouncing de manipuladores de entrada é útil. Ajuda a reduzir a frequência com que os manipuladores de eventos são chamados, o que diminui a carga na thread principal. Note que os web workers têm um ambiente restrito. Não podem manipular diretamente o DOM nem usar certas APIs disponíveis para a thread principal.
Finalmente, a recolha de lixo pode ser otimizada monitorizando o uso de memória. Usar ferramentas como 'measureMemory()' ajuda a rastrear e gerir o uso de memória, reduzindo o tempo gasto na recolha de lixo. A gestão eficiente de memória ajuda a manter a thread principal livre para tarefas mais críticas.
Ligar o desempenho à segurança
Todas essas soluções vão ajudá-lo a acelerar o JavaScript para alcançar melhor desempenho. A cside também pode ajudar, fazendo cache e otimizando scripts.
Mas gostaríamos de sublinhar que, antes de tudo, somos sobre segurança. O facto de acelerarmos scripts foi sobretudo necessário para a adoção por parte dos nossos utilizadores. Os ataques à cadeia de suprimentos do navegador estão em ascensão. E os agentes maliciosos frequentemente visam JavaScript de terceiros. A cside analisa cada script antes de ele carregar no navegador e bloqueia tudo o que for malicioso.
Uma abordagem proativa que o protege a si e aos seus utilizadores antes que algo mau aconteça.
Você pode começar com a cside gratuitamente.
