Recentemente, estava conversando com um amigo que trabalha com árvores. O assunto dos sugadores de árvore surgiu. Como ele estava descrevendo sua natureza destrutiva e a poda que você deve realizar para removê-los, não pude deixar de pensar em desenvolvimento web. De acordo com o HttpArchive.org, o site médio está tendo um pico em torno de 1,7 MB e mais de 90 solicitações HTTP . Minha pesquisa pessoal mostra uma realidade ainda pior. Os sites são muito grandes e os nutrientes necessários para fazer um site florescer estão sendo drenados. Estudo após estudo provam que sites mais rápidos têm melhores taxas de conversão, o que significa que eles ganham mais dinheiro.
Meu arborista um amigo explicou que um sugador de árvore se forma como um ramo da raiz da árvore. Eles brotam do solo ao redor da base da árvore. As ventosas estão presas à raiz da árvore, drenando nutrientes vitais da árvore. O topo da árvore é privado do sustento necessário para crescer e manter uma vida saudável. Os sites sofrem com os mesmos problemas, na forma de recursos desnecessários. Sites saudáveis carregam rápido e podem ser mantidos.
Referências de biblioteca duplicadas
Uma das muitas piadas no espaço do JavaScript é: se um jQuery não é suficiente, adicione outro 2 ou 3 jQuery referências. Infelizmente, isso acontece com mais frequência do que você imagina. Eu examino rotineiramente sites e sites de alto perfil e alto tráfego, que incluem várias referências de jQuery. É aqui que a página carrega a biblioteca jQuery mais de uma vez. Para piorar as coisas, muitas vezes a página carrega versões diferentes e de locais diferentes.
O problema, claro, é carregar a mesma coisa mais de uma vez. Só porque o navegador já carregou a biblioteca, não significa que ele não carregará a referência adicional. O navegador carrega todas as instâncias e avalia cada script. Isso significa que o conteúdo precisa ser baixado uma segunda ou terceira vez. Cada vez que um script é carregado, o navegador avalia o script. Todo JavaScript, usado ou não, leva tempo para ser avaliado. Este é o tempo que falta para que a página possa ser usada. No momento, o jQuery está pairando sobre 90kb reduzido, o que é uma carga muito pesada quando o dobro ou triplicado por referências em excesso.
Carregar diferentes versões do jQuery também é problemático porque a última versão carregada é a versão usada. A menos que seu código dependente seja carregado e executado antes que a próxima versão do jQuery seja carregada. Isso torna a solução de problemas difícil ou difícil saber qual versão sua função usou. Um problema comum é carregar a versão mais recente do jQuery, apenas para sobrescrever posteriormente a versão mais recente, contendo correções de bugs importantes, por uma versão anterior.
Como desenvolvedor, pode ser frustrante ter o código funcionando em um ambiente controlado e, em seguida, transferir o código para um aplicativo apenas para que ele falhe. Você acha que está usando a mesma base (versão jQuery) quando, na realidade, está usando uma versão de 2 anos atrás. Vejo isso acontecer em ambientes de grandes equipes, onde diferentes equipes são responsáveis por diferentes componentes. O Time A’confia’no layout mestre da página para incluir a biblioteca jQuery principal. A Equipe B adiciona outra referência de jQuery ao seu componente local por uma variedade de razões. O código da Equipe B é enviado e não é atualizado ou revisado e, um ou dois anos depois, surgem problemas. Este não é apenas um problema de desempenho, é um pesadelo de manutenção.
Outro produto de revisão de código, teste e comunicação deficientes é fazer referência à mesma biblioteca em vários locais. Vamos modificar o exemplo anterior. O layout mestre faz referência ao jQuery mais recente do CDN do Google. O código da equipe B faz referência à versão mais recente do jQuery CDN. Para complicar as coisas, a equipe C faz referência à versão mais recente do CDN da Microsoft. Não apenas três instâncias são carregadas e avaliadas, mas todas são carregadas de locais diferentes. Nenhuma dessas referências se beneficia do cache HTTP, além disso, quem pode dizer que todos esses três CDNs hospedam exatamente a mesma versão ao mesmo tempo?
Muitos pedidos HTTP
Outro nutriente muito comum prática de drenagem é muitas solicitações HTTP. Quando envio um aplicativo para produção, tenho um arquivo JavaScript. O script é construído como parte do meu processo de desenvolvimento e implantado no ambiente de produção. Durante o desenvolvimento, carrego dezenas e dezenas de minúsculos arquivos JavaScript, tornando-o mais fácil de depurar. Mas quando eu empurro para a produção, esses arquivos são agrupados e minimizados em um único arquivo. Este blog, por exemplo, tem um único arquivo JavaScript contendo cerca de 35kb de JavaScript reduzido. Existem 22 referências de script em desenvolvimento. Na maioria das vezes, quando um site é colocado em produção, as 22 referências de script são mantidas. Isso significa que o navegador deve fazer 22 solicitações HTTP diferentes, parar tudo o que está fazendo 22 vezes e avaliar cada script antes de carregar e avaliar o próximo script.
Hoje é muito fácil incluir um pacote e uma etapa de minimização na construção do seu projeto. Eu prefiro GruntJS , que tem até uma extensão de inspetor que executa continuamente seus scripts Grunt, poupando a você a etapa de executá-los manualmente. Tenho um capítulo inteiro dedicado ao uso de ferramentas como o Grunt para construir seu aplicativo da web em meu novo livro, Aplicativos da web de página única de alto desempenho .
Um cenário comum são referências individuais a cada plugin jQuery usado no site. Muitos sites usam dezenas de plug-ins, criando dezenas de solicitações extras. Freqüentemente, essas solicitações são de 1 a 2 kb, o que pode ser muito ineficiente. Plugins tendem a não depender uns dos outros, apenas jQuery. Portanto, se você precisa de um lugar para começar, meu conselho é agrupar e minimizar todos os seus plug-ins em um único arquivo de produção. Execute alguns testes sintéticos com a cascata de rede de cada navegador ou usando a API de tempo de desempenho. Se seu aplicativo for público, use uma ferramenta como http://webpagetest.org para comparar os resultados entre as versões não agrupadas e agrupadas. Acho que você notará um aumento no desempenho.
JavaScript não reduzido
Eu já mencionei isso, mas todo o JavaScript de produção deve ser reduzido. Este é o processo de remoção de comentários desnecessários e espaços em branco. Um bom minificador também otimiza o código alterando nomes longos de variáveis para letras únicas, removendo variáveis não utilizadas, etc. Freqüentemente, minhas versões de script de desenvolvimento ou depuração são cortadas pela metade para produção. A página da web média agora inclui cerca de 300 kb de JavaScript. Costumo ver grandes marcas carregando 1 MB ou mais. Supondo que o JavaScript não esteja reduzido, o site médio pode economizar cerca de 150-500 KB quando uma página é carregada. Isso pode melhorar o tempo de carregamento percebido em vários segundos.
Resumo
Estes são apenas três exemplos de sugadores da web, ervas daninhas que drenam a saúde de um site. Eles fazem com que as páginas carreguem mais lentamente e aumentam a sobrecarga de manutenção de longo prazo. Eles se ligam ao site por meio de práticas de programação preguiçosas ou descuidadas. Cada um é fácil de remover, mas geralmente são ignorados pelas equipes de desenvolvimento. A menos que você procure por eles, você não pode vê-los, embora eles estejam à vista de todos. Esses problemas não são problemas de jQuery, são problemas de desenvolvedor e DevOps. Existem muitas outras formas de web sugadores, estes são apenas três lugares em que toda equipe de desenvolvimento deve levar algumas horas para podar hoje. Deixar de limpar a base do site pode fazer com que o site comece a morrer de cima (a experiência do usuário) para baixo. Quando o site morre, também morrem os empregos necessários para construir e manter o negócio.
