Velocidade é usabilidade.
Para dizer com mais precisão, a velocidade do site é uma parte importante da usabilidade. A interface mais intuitiva já criada pela mente do homem não será boa se o usuário for pee off no momento em que for carregado.
É isso aí. O artigo está pronto… Ok, então há muito mais, mas a primeira frase é metade do que você precisa saber. Temos que tornar nossos sites rápidos.
Eu poderia usar muitas expressões superlativas como “muito rápido”, ou “extremamente rápido”, ou até mesmo “mais rápido que uma bala”, mas elas seriam inadequadas. É mais simples dizer que não existe “muito rápido”.
Precisamos tirar um minuto para falar sobre o tipo de velocidade a que estou me referindo. Em suma, toda a velocidade. Mais especificamente, três tipos de velocidade:
Esse será o tempo que leva para que todas as informações sejam baixadas para os dispositivos de seus usuários. Isso é afetado principalmente pela velocidade da conexão com a Internet e pelo tamanho real dos arquivos.
Você não pode fazer muito sobre a conexão, mas você pode fazer muito sobre o tamanho do arquivo.
Depois que seus arquivos são baixados, eles precisam ser processados e renderizados pelo navegador. Todo esse processamento e renderização é afetado pelo quão bem o seu código foi escrito e tudo o mais acontecendo no telefone, tablet ou laptop / desktop do usuário.
A única coisa que você pode controlar é o seu próprio código, mas isso faz uma grande diferença.
E depois há o fator psicológico. Websites rápidos podem parecer que estão indo devagar. Sites lentos podem ser levados a se sentir um pouquinho mais rápidos com a aplicação judicial de alguns truques.
Esta parte é toda sobre o estudo do seu usuário, e deixá-los saber o que está acontecendo quando eles interagem com seu site ou aplicativo.
Você precisa prestar atenção a todos os três aspectos da velocidade do site para fazer com que o seu site ache que está indo rápido. E quanto maior o site, mais há para otimizar.
Vamos começar então.
Muitas vezes, especialmente naqueles projetos experimentais menores que eu tanto amo, me passo mais tempo no CSS do que em qualquer outra parte do código. Muitas vezes, há mais CSS escrito do que HTML ou JavaScript. Então, bem aí, é um indicador de quanto seu CSS pode afetar o tamanho do arquivo.
Então, é claro, há a questão de quão rápido seu website será realmente executado no desktop, laptop, tablet ou telefone de seu usuário. Grande parte do “trabalho” real ou renderização de uma página da web é feita pelo software, com uma pequena ajuda da sua GPU.
Pode carregar rapidamente, mas role devagar. A forma como o seu CSS é escrito tem um efeito direto na rapidez com que um determinado dispositivo é capaz de exibir a página da web assim que os arquivos forem baixados.
Ao otimizar um site para rodar mais rápido, o CSS geralmente é um bom lugar para começar.
CSS que fica na sua folha de estilo e não faz nada torna seus arquivos desnecessariamente maiores. Ok, então este pode parecer um acéfalo; mas ainda acontece com o melhor de nós.
Você tira algum conteúdo e esquece de apagar o antigo CSS. Você altera a classe ou o ID de um elemento de contêiner e se esquece de excluir o CSS antigo. Você escreve algum CSS, percebe que há uma maneira melhor, e esquece ... você entende.
Lance vários desenvolvedores de front-end na mistura e você terá uma receita para uma folha de estilos difícil de gerenciar e não gerenciável, ou uma coleção deles, se não tiver cuidado. Código não utilizado retarda o carregamento da página em virtude de sua própria existência como dados. Isso atrasa o desenvolvimento porque pode confundir as pessoas que lêem a folha de estilo.
Isso também pode significar tempos de renderização mais lentos, porque é apenas mais CSS para o navegador olhar enquanto combina todo o CSS com os elementos HTML apropriados.
Quer você revise e exclua todo o CSS antigo manualmente, use ferramentas automatizadas para ajudá-lo a encontrar seletores CSS não usados, ou simplesmente excluir coisas aleatoriamente até que algo quebre (não faça isso), você precisa tirar esse código antigo.
Falando de como o navegador combina o CSS com o HTML apropriado, é hora de olhar para os seletores CSS. Muito tem sido escrito sobre quais seletores processam o mais rápido, quais são lentos, se você deve se preocupar com os lentos, e assim por diante.
O problema é que muitas dessas informações são antigas. No ano 2000, Dave Hyatt (um desenvolvedor trabalhando no Safari e membro ativo do CSS Working Group do W3C) escreveu o seguinte:
A triste verdade sobre os seletores CSS3 é que eles realmente não devem ser usados se você se preocupa com o desempenho da página.
Se você der uma olhada o documento essa citação veio, você verá que ele estava falando sobre seletores como : primeiro filho e outros pseudo-seletores. E ele estava certo.
Ele ainda é; mas nos últimos quinze anos, os computadores avançaram um pouco. Hoje em dia, o esforço extra exigido do computador para tornar esse CSS não deve ser notado por ninguém, exceto aqueles que usam o mais barato dos dispositivos móveis baratos.
Essa é uma preocupação em si, então, realmente, dependerá do projeto em questão, da sua demografia alvo e assim por diante. Simplificando, use seu melhor julgamento e talvez não exagere nos pseudo-seletores.
Caso contrário, a menos que suas páginas atinjam o tamanho do livro, os seletores usados devem ter pouco efeito no desempenho do site. Ainda assim, dê uma olhada no documento vinculado acima e conheça o que é mais rápido e o que não é. Você ainda pode achar as informações úteis.
Você também pode ver Este artigo de CSS-Tricks para um pouco mais recente sobre o assunto.
Naturalmente, também existem propriedades CSS que demoram mais para renderizar do que outras. As propriedades clássicas como largura, altura e cor ainda são as mais rápidas. Os que tendem a demorar um pouco mais (e podem variar de navegador para navegador) tendem a ser propriedades CSS3 como box-shadow.
O processo de adicionar um sombreamento a um elemento é complexo, no que se refere à renderização de páginas da web. O que é interessante notar é que, como apontado em Rochas HTML5 , a potência de processamento necessária pode variar muito dependendo das dimensões específicas da sombra projetada.
Este artigo indica que o mesmo vale para outras propriedades, como border-radius e transform.
Novamente, isso teria pouco efeito na renderização de uma página em um computador ou laptop comum. Dispositivos móveis podem ter um impacto maior, e a experiência pode sofrer como resultado. Todo mundo odeia rolagem irregular.
Ainda assim, isso tem que ser pesado contra o custo de usar imagens para produzir os mesmos efeitos. Alguém se lembra das coisas que fizemos para obter cantos arredondados, uma vez?
Só não exagere, e seus estilos devem renderizar rápido o suficiente.
Agora entramos em outro território. As animações CSS podem ser incrivelmente rápidas, ou podem retardar o navegador até o ponto em que as plataformas de jogos têm dificuldade em acompanhar.
Isto é parcialmente porque nem toda animação é renderizada igualmente. Parte do trabalho pesado é feito pelo hardware, enquanto outros tipos de animação precisam ser renderizados inteiramente pelas próprias funções do navegador. Isso é especialmente caro em dispositivos móveis.
Dentro outro artigo em Rochas HTML5, as propriedades CSS que são as mais rápidas para animar são posição , escala , rotação e opacidade.
Confira o artigo para uma visão geral mais completa do que pode ser animado, mantendo o "custo" baixo.
Aqui é onde eu ofereço os conselhos mais práticos que eu, o autor, posso lhe dar. Use pré-processadores CSS como LESS, SASS e Stylus. Claro, se você usá-los erradamente, você pode gerar folhas de estilo maiores do que pretendia; mas os benefícios potenciais valem a pena.
Por exemplo, se você quiser reduzir o número de solicitações HTTP feitas ao servidor (sempre uma boa ideia), inclua todas as redefinições, estruturas, em um arquivo LESS / SASS. Quando compila, tudo estará em uma única folha de estilo. Além disso, a maioria dos pré-processadores oferece a opção de produzir todos os CSS em formato minificado.
Dessa forma, você pode usar quantos arquivos diferentes forem necessários para fins de organização de código, sem afetar o tamanho do arquivo.
JavaScript pode ser muito lento. Para ser mais específico, o JavaScript pode ter um efeito muito mais direto na parte “processamento” da equação de velocidade do que o CSS. Pior, o JS pode se tornar exponencialmente mais pesado em termos de tamanho de arquivo para conseguir coisas aparentemente triviais.
É um golpe duplo de lentidão dolorosa, e nossos usuários são frequentemente vítimas, especialmente aqueles em navegadores móveis. Isso não é, no entanto, culpa da linguagem. O quanto as nossas atividades de JS estão estragadas é muitas vezes diretamente proporcional à nossa ignorância de programação em geral.
Eu sou um não desenvolvedor. Eu sempre usei bibliotecas como o jQuery, ou plug-ins JS independentes individuais para fazer as coisas. Quanto mais eu preciso fazer, mais plugins eu preciso para fazer tudo funcionar. Esses plugins e estruturas vêm com opções e recursos extras que eu nunca utilizarei.
Há o inchaço de roubo de largura de banda, ali mesmo.
Além disso, os plugins podem não funcionar bem juntos. Eles podem desacelerar um ao outro, ou pode-se impedir que outro trabalhe por completo.
Há o poder de processamento desperdiçado, ali mesmo.
Se você realmente quiser acelerar o seu site, raspe milissegundos (ou segundos inteiros, em alguns casos), aqui está o que você precisa fazer:
Assim como o CSS, é melhor manter o JS em arquivos externos e vinculado ao seu HTML. Você pode achar que não é grande coisa se você não tem muito código JS, e ele adiciona uma requisição HTTP, mas aqui está a coisa: arquivos CSS e JS externos são armazenados em cache pelo navegador.
Assim, quando essa mesma página é solicitada novamente ou outras páginas em seu site que usam o mesmo CSS ou JS são solicitadas, esses arquivos externos armazenados em cache são usados em vez de serem baixados novamente. Isso é um tempo de carregamento de site mais rápido e um processamento ligeiramente mais rápido. Vale a pena a chamada extra para o servidor de vez em quando.
Basicamente, a teoria é assim: o navegador renderiza o que estiver no topo do código-fonte de uma página primeiro. É por isso que coisas como a tag chegam perto do topo.
No entanto, os arquivos JavaScript podem reduzir a velocidade, impedindo que o navegador renderize seu HTML até que eles sejam carregados. Como a maioria dos plug-ins e efeitos JS normalmente usados só precisam funcionar depois que o restante da página estiver na tela, isso é menos do que ideal.
Melhore a experiência do usuário e reduza o tempo de carregamento percebido vinculando-se a esses arquivos externos na parte inferior da página, antes da tag.
No momento em que um usuário começa a interagir com qualquer coisa que exija JS, ele deve estar pronto.
Se você está criando um aplicativo completo, você pode e talvez deva ignorar esta seção. Um framework bom, flexível e leve pode dar aos desenvolvedores uma vantagem enorme. Para sites de pequeno a médio porte, no entanto, incluir uma estrutura JavaScript pode ser um exagero. Nesses sites, o JS será usado principalmente no back-end do CMS para administrar o conteúdo. No front-end, você pode ter um controle deslizante de imagem ou um layout de alvenaria ou dois. Se você for realmente chique, poderá ter autocompletar na barra de pesquisa.
A maioria dos conteúdos não precisa ser imaginada e animada assim. O JavaScript deve, tanto quanto possível, ser reservado para melhorar a experiência do usuário. Confiar nele para simplesmente criar um site pode resultar em um site lento e lento, especialmente em dispositivos móveis.
De certa forma, todas as estruturas de código são todas iguais, seja JavaScript, PHP, Python, HTML ou CSS: cada recurso é um monte de código. Ao escolher um framework ou plug-in para um trabalho, pergunte-se se você usará todos os recursos oferecidos ou a maioria deles.
Se não, a estrutura é modular? Você pode escolher apenas as partes que realmente precisa? Se assim for, e você acredita que o trade-off do tamanho do arquivo vale a pena, então, por favor, vá em frente! Caso contrário, é uma boa prática ver o que você pode tirar mais do que você pode espremer.
Não permanentemente! Pense nisso desta maneira, existe algum conteúdo ou funcionalidade em seu site escondido pelo JS? As pessoas podem acessá-lo sem ter o JS ativado em seus navegadores?
Se sim, então ótimo. No entanto, se as pessoas não puderem ver informações importantes, entrar em contato com você ou navegar adequadamente sem o JavaScript, você terá um problema. Claro, você pode confiar na maioria das pessoas que ainda estão ativadas, mas você sempre tem esses casos extremos.
Como isso se relaciona com a velocidade do site? Imagine como a navegação lenta vai ficar se uma parte do seu site de repente simplesmente não funcionar.
Não seriamente, se você não for um desenvolvedor e tiver orçamento para um, consiga um, mesmo para trabalhos pequenos e simples. É mais barato, a longo prazo, contratar alguém experiente para fazer isso certo uma vez.
No caso de as coisas darem errado (e estamos falando de computadores aqui, então algo vai dar errado), eles descobrirão o que deu errado mais rápido. Eles terão experiência em encontrar esses tipos de problemas e resolvê-los. Se nada mais, eles serão melhores em googling esses tópicos específicos.
Mais importante, eles saberão como fazer o que precisa ser feito com menos código. Menos código (geralmente) é executado mais rapidamente e (sempre) é baixado mais rápido. Esse é o conselho mais simples que posso dar.
(Se você é um desenvolvedor ou está aprendendo, eu compilei uma lista de tutoriais que estarão no final deste artigo. Incluídos estão alguns guias para iniciantes em escrever JavaScript que são executados rapidamente.)
Quando você tira o vídeo da equação, a maior coisa em qualquer site de conteúdo é as imagens. As imagens tendem a ser grandes, volumosas e lentas quando não são otimizadas.
Agora, com a proliferação de telas de retina nos forçando a usar imagens maiores se quisermos que as coisas fiquem bem em todos os dispositivos, o problema não será mais fácil de resolver. E pior, é um problema fácil de esquecer até que você acabe gastando mais do que o previsto em largura de banda.
Quando cada byte conta, não podemos nos dar ao luxo de esquecer.
A boa notícia é que este não é um problema novo por qualquer meio. Por que isso é bom? Isso significa que existem várias soluções possíveis para escolher e você pode usar mais de uma delas por vez. Na verdade, isso geralmente é uma boa ideia.
Então, até ISPs e empresas de hospedagem começarem a nos dar uma banda larga ilimitada (não prenda a respiração), aqui estão algumas coisas que você pode fazer:
Simplificando, faça o máximo que puder, visualmente falando, com CSS e JavaScript antes de usar as imagens. O código sempre será mais barato para transferir do que as imagens, então fique com isso o máximo que puder. Apesar do poder de processamento consumido pelas sombras, gradientes e afins baseados em CSS, considere os trade-offs.
Lembre-se também de que as imagens SVG contam, neste caso, como "código", porque isso é tudo o que elas são: código XML que é renderizado como uma imagem. Assim, eles devem ser usados sempre que você precisar de algo relacionado a vetores.
Agora, voltando para as telas de retina acima mencionadas, o que fazemos sobre elas? Como economizamos largura de banda?
É aqui que nos voltamos para o elemento e a propriedade do conjunto de imagens . Eles são relativamente novos e não são totalmente compatíveis, mas permitem que os navegadores escolham o tamanho de imagem apropriado para o dispositivo que está sendo usado.
Portanto, embora isso não economize largura de banda para alguém que esteja visualizando seu site no iMac, isso não é tão grande, pois é provável que eles tenham banda larga. Alguém no telefone, por sua vez, recebe uma versão menor da mesma imagem, evitando que esperem por muito tempo.
Muitos problemas de tamanho de imagem são corrigidos quando você aprende qual formato de imagem usar em qualquer situação. Eu poderia falar sobre os formatos de imagem específicos, como a compressão funciona, e assim por diante, mas você realmente só precisa se lembrar de algumas coisas:
Isso é tudo mesmo. Se você fizer isso e brincar com as configurações de otimização ao salvar as imagens, poderá obter uma qualidade bastante satisfatória em arquivos de tamanho relativamente pequeno.
No entanto, existe um novo formato chamado WebP, que é suportado pelo Chrome e pelo Opera automaticamente. Google reivindicações os arquivos WebP são 26% menores que os PNGs e 25-34% menores, dependendo de alguns fatores.
Esta é uma ótima notícia, exceto por duas coisas: Firefox e IE. Agora, se você não se importar em usar fallbacks e um script extra, poderá usar o formato WebP agora, hoje. Apenas faça o download WebPJS e você é bom para ir.
O WebPJS usa JavaScript e um pouco de Flash ( suspiro… mas isso é apenas para o IE) para fazê-lo funcionar, mas funciona. Você pode considerá-lo se precisar fornecer muitas imagens maiores rapidamente, com a desvantagem de não funcionar sem o JS.
Existem dois tipos de compactação que você pode usar em suas imagens. Primeiro, temos compressão com perdas . Isso é usado em formatos com perdas, como JPEG. Ele permite que você comprima qualquer imagem o quanto quiser com a compreensão de que a qualidade ficará cada vez pior e pior. As coisas ficarão pixeladas e perderão a definição.
A compactação sem perdas é usada em formatos como PNG e pode reduzir seu tamanho de arquivo até certo ponto. No entanto, tem seus limites. Chega sempre um ponto em que é impossível tornar uma imagem menor sem perder qualidade.
Se você tem o Photoshop ou um editor de imagens avançado similar, geralmente é melhor usá-los para compactar suas imagens, de modo que você possa ver a aparência da saída quando terminar.
(Ferramentas automáticas, especialmente ferramentas on-line, na minha experiência, tendem a comprimir as coisas talvez um pouco longe demais. No entanto, vou listar as melhores ferramentas de compactação que encontrei na seção de links abaixo.)
Se você estiver usando um CMS como o WordPress, ele redimensionará automaticamente as imagens que são muito grandes. Também é fácil encontrar plugins que os compactarão automaticamente para você.
Lembre-se, eu só recomendo a compressão automática nos casos em que você sabe que vai enviar lotes e muitas imagens de qualidade semelhante para o mesmo propósito. Um blog de fotos é um exemplo.
Se você está rodando um site onde os usuários estão fazendo upload de suas próprias imagens, bem… redimensionamento e compressão automáticos é uma necessidade absoluta, e é por isso que toda rede social faz isso.
Aqui estão alguns conselhos que não se encaixam em nenhuma das três categorias acima.
"Minimizar" seu código significa que todos os espaços extras e quebras de linha são removidos. Isso pode reduzir significativamente o tamanho do arquivo.
Pode soar como um monte de trabalho, mas existem ferramentas para minimizar CSS e JS automaticamente, e manter os arquivos minificados separados para seus arquivos de origem, por razões bastante óbvias.
Como mencionado anteriormente, vários pré-processadores CSS podem gerar todo o seu código em formato minificado.
Desde que seu servidor esteja configurado corretamente, todo o seu código pode ser enviado para o navegador em um formato compactado. Arquivos de texto compactam muito bem, reduzindo consideravelmente o tamanho dos arquivos enviados.
Agora, seu servidor precisa ter um ou dois instantes para compactar os arquivos que envia, e o navegador do usuário precisa descompactá-los, mas isso geralmente vale a troca de largura de banda.
Para uma explicação completa de como isso funciona, veja Como otimizar seu site com compactação GZIP .
O cache do navegador acontece automaticamente até certo ponto graças aos navegadores modernos. Um navegador vai para um site e armazena temporariamente as imagens e outras informações que encontrar lá.
Dessa forma, se o mesmo usuário retornar dentro de um determinado período de tempo, o navegador não precisará solicitar as mesmas imagens novamente. Ele apenas carrega os que já possui e solicita qualquer nova imagem que possa não ter.
Há, no entanto, algo que você pode fazer para dizer aos navegadores o que armazenar em cache e por quanto tempo, como visto em este guia .
E depois há o cache do servidor. O cache do servidor basicamente apenas pega o seu site e coloca uma espécie de “cópia” dele entre seus usuários e seu servidor real. Por que você se incomodaria?
Bem, é especialmente útil para pessoas que estão usando sistemas de gerenciamento de conteúdo em larga escala. Ter seus usuários acessando uma cópia temporária do seu site, em vez de reduzir o número de chamadas para o seu banco de dados. As informações são exibidas e carregadas com mais rapidez porque não precisam ser processadas novamente todas as vezes.
Dependendo de como é configurado, o cache do servidor também pode reduzir os custos de largura de banda em geral. Basicamente, quanto maior o seu site, mais razões você tem que olhar para armazená-lo em cache.
E agora, a seção que todos esperavam: a lista de links! Temos tutoriais e guias, principalmente, e algumas ferramentas de compactação de imagens para recomendar.
Yahoo! pode não ser tão grande quanto antes, mas sua rede de desenvolvedores tem muita coisa boa nisso. Isso inclui sua Melhores práticas para acelerar o seu site , que abrange algumas das coisas básicas que você pode fazer. Algumas delas abrangem o mesmo fundamento deste artigo, mas há mais além disso.
Na introdução, mencionei a velocidade percebida no site, também conhecida como percepção de desempenho. Se você quiser ler mais sobre isso, confira Um guia para iniciantes sobre o desempenho percebido: 4 maneiras de fazer seu site para celular parecer um aplicativo nativo .
Effeckt.css é um conjunto de animações baseadas em CSS que são projetadas para renderizar rapidamente, não importa em qual plataforma o usuário está.
este é um guia para garantir que seu CSS seja baixado e processado o mais rápido possível pelo navegador.
Quando você está apenas começando, aprendendo a codificar corretamente pode ser um aumento de velocidade tão grande quanto as dicas aleatórias de truques que você pode aprender. Código incorreto custa mais em termos de tempo de processamento, então aprenda a fazer as coisas da maneira certa.
Aqui está um guia básico que se concentra mais especificamente em escrever JavaScript que seja executado rapidamente.
É como o título diz, esta é todo conselho direcionado especificamente ao JavaScript V8.
E, às vezes, você provavelmente acabará usando o jQuery. Se você vai fazer isso, pelo menos você deve saber como escrever seletores de jQuery que não vão te atrapalhar. E aqui é onde Sitepoint tem você coberto .
Leia isso para mais informações sobre formatos de imagem na web. A informação é um pouco antiga, mas ainda é válida e é bom saber.
este é um guia mais técnico para otimização de imagens fornecido pela Rede de desenvolvedores do Google.
Compressor.io é uma das ferramentas mais impressionantes que encontrei pessoalmente. É um aplicativo on-line, então você terá que fazer upload de todos os arquivos que deseja compactar, mas pode fazer maravilhas para JPGs. Ele oferece opções de compactação com perdas e sem perda, cada uma com resultados surpreendentes, e também pode processar em lote.
Trimagem é especializado em compactação sem perdas, mas pode ser instalado em seu próprio computador, no Windows, Mac ou Linux. Como ele é instalado em seu computador (e, sim, vem com várias opções de linha de comando, bem como uma GUI), ele pode ser executado automaticamente como parte de um fluxo de trabalho de desenvolvimento.
Como sempre, há muito mais a aprender. Mas, com as informações que fornecemos e os recursos aos quais nos vinculamos, você estará pronto para criar sites e aplicativos que não incomodem o Inferno de seus usuários.
E esse é o primeiro passo para impressioná-los.