Desde a criação da Internet, o tamanho médio dos arquivos tem crescido constantemente. O que começou como kilobytes progrediu para megabytes (sim, plural), e nossos arquivos estão apenas ficando estáveis.
Embora esse fenômeno não seja desconcertante à primeira vista, o impacto que ele tem sobre o desempenho e a facilidade de manutenção é terrível. Adicione dispositivos antigos, restrições de largura de banda ou velocidades baixas em geral ... e temos um problema muito maior.
Felizmente, temos controle não apenas sobre nossos tamanhos de arquivo, mas também sobre como nossas páginas são renderizadas no navegador. Esse tipo de controle oferece aos desenvolvedores da Web, como nós, a chance de ajudar a aliviar esse problema e otimizar nosso código para melhorar o desempenho do processo.
Eu entendo completamente a falta de interesse quando a maioria das conexões de internet nos EUA é bastante rápida hoje em dia. Quer dizer, se tudo funciona bem, por que se incomodar?
O desempenho e a otimização são mais do que a rapidez com que podemos baixar o conteúdo. Há também alguns benefícios de SEO e UX a serem aproveitados ao analisar nosso código. Sem mencionar que diminuir o tamanho dos arquivos otimizando nosso código para obter melhor desempenho tem o bônus adicional de diminuir nossos custos de largura de banda como hosts e diminuir o uso da largura de banda (pense em limites de dados de celular / ISP) também.
Normalmente, o código modular adiciona um inchaço na forma de mais opções. Aqui, queremos pensar modular em termos de combinar tantas partes comuns do nosso código quanto possível. Se podemos combinar duas classes CSS em uma e usar menos código para fornecer o mesmo resultado, devemos.
A modularidade não é tão importante quando se trata de HTML e CSS básicos, mas quando você entra no mundo mais complexo do JavaScript, ter muito inchaço pode prejudicá-lo - especialmente no celular.
As solicitações de dependência são, de longe, o maior fator para reduzir a velocidade de carregamento da página. Cada solicitação adicional adiciona inchaço e outra camada de complexidade ao processo de análise e download. Muitas vezes é fácil esquecer que as imagens de chamada da sua folha de estilo também contam também, portanto, certifique-se de limitá-las e usar métodos alternativos de otimização, como sprites ou SVG, quando possível.
Embora estejamos no tópico de dependências externas, se o seu site for grande o suficiente para exigir algumas solicitações no mínimo… Talvez seja hora de considerar o uso de um CDN. Usar um CDN para distribuir seu conteúdo não diminuirá o tamanho dos arquivos e / ou os tempos de carregamento, além de remover solicitações HTTP extras, mas provavelmente removerá as conexões de servidor lentas da equação, pelo menos.
Deve haver uma diferença muito grande ao comparar suas bases de código de nível de desenvolvimento e produção. Tomando este passo sozinho, às vezes, pode-se ver a maior redução no tamanho dos arquivos.
É comum hoje em dia ver os desenvolvedores se referirem ao seu ambiente de “produção” ou “desenvolvimento”, especialmente em projetos de grande escala. Mas também é útil no final menor das coisas. A maior diferença entre os dois ambientes pode ser vista com a compactação de imagem e a compactação / redução de código. No final, queremos que nosso ambiente de produção seja o mais enxuto e rápido possível, enquanto nosso ambiente de desenvolvimento deve ser o mesmo, apenas menos a otimização de compactação de imagem / código.
Usar as ferramentas internas, como a compactação "Salvar para a Web" do Photoshop, pode ser um bom ponto de partida para imagens. Há uma infinidade de conhecimento a ser explorado em outro lugar bem como com conversas em formatos de imagem, algoritmos de compressão, controle de qualidade e melhores práticas.
Para o código, o melhor uso da compactação geralmente depende do idioma com o qual você está trabalhando. Também é altamente discutível se a compactação de código ajuda ou prejudica outras pessoas que tentam entender seu código, mas isso é uma conversa em outro momento. Quando se trata de HTML e CSS simples, eu uso serviços como Compressor html do Google e a Compressor YUI para CSS.
Às vezes, o código que estamos escrevendo é o link mais lento da cadeia. CSS ineficiente ou JavaScript inchado podem prejudicar os tempos de carregamento mais do que você imagina. este Mozilla O post aborda detalhadamente a importância de escrever seletores CSS e explicar como os navegadores os processam. Em suma, escrever o caminho exato através de uma cadeia de seletores é muito menos eficiente do que simplesmente usar o menor seletor exclusivo identificável. Ambos direcionam o estilo para o mesmo elemento, o último simplesmente faz o trabalho muito mais rápido.
O JavaScript pode ser ainda pior do que o CSS mal escrito e, em muitos casos, é facilmente ignorado. Quantas vezes você copiou e colou uma biblioteca JS externa em seu projeto sem realmente olhar em profundidade a própria fonte? O Typekit é um ótimo exemplo disso, já que quando seus servidores param, pode trazer uma página da Web usando suas fontes e causar 30 segundos adicionais ou mesmo minutos de tempo de carregamento extra.
Felizmente, esses eventos acontecem raramente, mas ainda é uma boa prática chamar o JavaScript por último, se possível, como é o caso do Google Analytics. Isso permite que o navegador analise os arquivos principais (CSS, solicitações HTTP, etc) e exiba a marcação, antes que o JavaScript comece a atrasar as coisas.
De acordo com nossa meta de escrever seletores de CSS mais enxutos e manter o inchaço ao mínimo, escrever um HTML eficiente também deve ser uma prioridade.
As redefinições de CSS geralmente segmentam todos os elementos comuns e impõem o estilo de "redefinição" neles. Portanto, mesmo que você não esteja segmentando esse div extra, é provável que ele ainda atrase as coisas com o preenchimento de preenchimento e margens no mínimo. Normalmente, um div ou dois extra realmente não vai doer nada. Somente quando você começa a acabar com dezenas deles, as coisas ficam loucas. Com a introdução de mais elementos nas especificações do HTML5, também temos muito mais flexibilidade nessa área.
O Google definiu como prioridade colocar a Internet em forma coletiva. Para ocupar posições de destaque em seus resultados de pesquisa, as páginas devem agora prestar atenção crítica a muitos atributos diferentes sobre como eles são renderizados. Chamar muitos recursos externos, ter imagens absurdamente grandes ou até mesmo ter JavaScript mal escrito pode derrubar um site no ranking.
Felizmente, tudo isso é uma boa intenção, pois seus requisitos para um bom ranking de pesquisa são baseados em boas práticas de desenvolvimento. O Google também oferece uma guia muito em profundidade para otimizar diferentes aspectos do seu site para melhor SEO - o que também acontece para promover práticas fantásticas de desenvolvimento ao mesmo tempo.
Ao otimizar nosso código, temos que pensar não apenas no tamanho dos arquivos, mas também considerar como ele será lido; seja por navegadores ou até mesmo outros seres humanos. O uso móvel também deve ser levado em consideração, com muitos provedores de serviços impondo limites de dados muito limitantes nos dias de hoje.
Assim, embora possa levar um tempo extra para realizar toda essa otimização, é certamente um esforço que vale a pena, pois oferece melhor desempenho no navegador e no celular, mas também tem a chance de promover melhores práticas de desenvolvimento e até mesmo melhorar seu conteúdo. em mecanismos de pesquisa como o Google.
Da próxima vez que você se preparar para o lançamento, jogue suas imagens em um mecanismo de compressão… Você pode se surpreender com quantos megabytes ele pode se desfazer!
Imagem em destaque, imagem de velocidade modular via Shutterstock.