Mas falar de otimiza\u00e7\u00f5es de browser em um evento como o QCon pode parecer b\u00e1sico. Tantos arquitetos, discuss\u00f5es de alto n\u00edvel sobre novas plataformas como Node.JS e processamento ass\u00edncrono, diversas palestras sobre cloud computing, todo mundo usando memcache e tantas outras t\u00e9cnicas avan\u00e7adas.<\/p>\n
Ent\u00e3o, para contextualizar mais ainda a discuss\u00e3o, analisei os dados dos Sites de todos os participantes do evento<\/a>. Com base nos e-mails dos inscritos (descartando webmails como GMail, Hotmail etc), separei mais de 100 dom\u00ednios para testes, incluindo grandes portais brasileiros, empresas de tecnologia, Sites do governo e outros. Submeti todos ao WebPageTest.org e compilei os resultados.<\/p>\n O n\u00famero mais importante, o tempo total de carregamento, j\u00e1 d\u00e1 uma ideia da situa\u00e7\u00e3o. Os sites analisados demoram, em m\u00e9dia, 9 segundos para carregar<\/strong>, sendo que alguns demoraram mais de 40s. E a grande verdade \u00e9 que a performance final para o usu\u00e1rio depende muito mais do client-side<\/em> que do server-side<\/em>. De todos os Sites analisados, a esmagadora maioria, 75%, tinha um tempo de processamento de menos de 400ms no servidor.<\/p>\n Boa pr\u00e1tica em qualquer aplica\u00e7\u00e3o distribu\u00edda, diminuir o payload<\/em>, ou seja, o volume de dados trafegados, \u00e9 um princ\u00edpio b\u00e1sico. E h\u00e1 diversas formas de se fazer isso.<\/p>\n Na an\u00e1lise das p\u00e1ginas dos participantes do evento, a m\u00e9dia de tamanho foi de 860kb<\/strong>. Al\u00e9m disso, 35% dos Sites t\u00eam mais de 1MB de tamanho, sendo que o pior caso chegava a ter incr\u00edveis 8MB.<\/p>\n <\/a>#1 \u2013 Habilite GZIP<\/p>\n N\u00e3o leva mais de 30s para ser feito e \u00e9 suportado em todos os navegadores e servidores dos \u00faltimos 15 anos. Com ele, todo conte\u00fado textual (HTML, CSS, JS etc) \u00e9 comprimido antes de ser enviado para o cliente, chegando a cortar mais de 50% do tr\u00e1fego total.<\/p>\n Apesar disso, na an\u00e1lise dos Sites, descobri que 43% de todos os requests textuais n\u00e3o estavam gzipados. Mais: apenas 14% dos Sites tinha gzip em todos os requests<\/strong>.<\/p>\n <\/a>#2 \u2013 Minifique JavaScript<\/p>\n Um c\u00f3digo JS bem feito \u00e9 bem documentado, todo identado e possui nomes de vari\u00e1veis leg\u00edveis. Mas nada disso conta na execu\u00e7\u00e3o do script, e trafegar esse monte de bytes \u00e9 desperd\u00edcio. Em poucos minutos, \u00e9 poss\u00edvel integrar uma ferramenta de minifica\u00e7\u00e3o de JavaScript, como YUI Compressor, Google Closure Compiler<\/a> ou UglifyJS<\/a>.<\/p>\n Muitos Sites costumam incluir alguns scripts j\u00e1 minificados como o jQuery (com seu arquivo jquery-min). Apesar disso, dos Sites analisados, apenas 13% minificavam todos os JavaScripts<\/strong>.<\/p>\n <\/a>#3 \u2013 Minifique CSS<\/p>\n Minificar os arquivos CSS \u00e9 igualmente importante. Para isso, podemos usar o YUI Compressor e at\u00e9 o LESS compiler<\/a>.<\/p>\n <\/a>#4 \u2013 Comprima o HTML<\/p>\n O c\u00f3digo HTML tamb\u00e9m pode ser comprimido, removendo espa\u00e7os, coment\u00e1rios e at\u00e9 certas aspas e fecha tags desnecess\u00e1rias. O Google, por exemplo, n\u00e3o fecha O excelente HTML Compressor permite diversas otimiza\u00e7\u00f5es e \u00e9 bastante configur\u00e1vel. Comprimir o HTML n\u00e3o costuma ser simples porque, em geral, tratamos com p\u00e1ginas din\u00e2micas.<\/p>\n <\/a>#5 \u2013 N\u00e3o redimensione imagens no HTML<\/p>\n Princ\u00edpio b\u00e1sico das otimiza\u00e7\u00f5es, nunca deixe para diminuir imagens setando o <\/a>#6 \u2013 Otimize as imagens<\/p>\n Dentro de um arquivo PNG ou JPG muitos dados s\u00e3o guardados. Al\u00e9m das informa\u00e7\u00f5es da imagem em si, h\u00e1 metadados como EXIF, e \u00e0s vezes, at\u00e9 uma miniatura da pr\u00f3pria imagem. Nada disso \u00e9 necess\u00e1rio para renderizar a imagem na tela e podem ser removidos. Esse tipo de otimiza\u00e7\u00e3o, chamada de lossless<\/em>, sem perda de qualidade visual, \u00e9 o m\u00ednimo que toda aplica\u00e7\u00e3o deveria fazer. Com o Smush.it, por exemplo, basta enviar as imagens e receb\u00ea-las de volta otimizadas. Outras ferramentas incluem o ImageOptim<\/a> al\u00e9m de diversas op\u00e7\u00f5es em linha de comando para automatiza\u00e7\u00e3o (pngquant, optipng, pngcrush, pngout, advpng).<\/p>\n Otimizar imagens \u00e9 essencial porque costumam ser a parte mais pesada das p\u00e1ginas Web. Na an\u00e1lise dos Sites dos conferencistas, em m\u00e9dia, 47% dos bytes da p\u00e1gina eram de imagens<\/strong>.<\/p>\n Apesar disso, apenas 15% dos Sites otimizam todas as imagens. Para 1\/4 dos Sites, otimizar as imagens economizaria mais de 40% dos bytes totais.<\/p>\n Mas \u00e9 poss\u00edvel tamb\u00e9m aplicar transforma\u00e7\u00f5es lossy<\/em>, isto \u00e9, diminuir a qualidade das imagens em prol de uma melhora na performance. Muitos designers nem cogitam essa possibilidade, mas fato \u00e9 que muito no mundo \u00e9 lossy<\/em>. Um MP3, por exemplo, diminui a qualidade do \u00e1udio original para favorecer a mobilidade. Diminuir a qualidade de uma foto JPEG com pouco impacto visual percept\u00edvel pode trazer imensos ganhos. O novo servi\u00e7o JPEGMini, por exemplo, tem um avan\u00e7ado algoritmo que diminui a qualidade de JPEGs baseado em um modelo matem\u00e1tico que simula as caracter\u00edsticas da percep\u00e7\u00e3o humana. O resultado s\u00e3o imagens com menos da metade do tamanho e visualmente id\u00eanticas.<\/p>\n <\/a>#7 \u2013 Pense no formato das imagens<\/p>\n Os formatos de imagens us\u00e1veis na Web s\u00e3o PNG, JPEG e GIF. Mas qual usar e como escolher o formato correto? H\u00e1 diversos fatores. PNG e GIF mant\u00e9m fidelidade da imagem; j\u00e1 o JPEG \u00e9 um formato lossy<\/em> cuja compress\u00e3o sempre causa perda de qualidade (ali\u00e1s, \u00e9 por isso que jamais se deve editar JPEGs diretamente; cada vez que se salva o arquivo, perde-se qualidade). Com isso, um PNG costuma ser mais interessante para gr\u00e1ficos quando fotos ficam com tamanhos menores em JPEGs.<\/p>\n Outro ponto \u00e9 que PNGs suportam transpar\u00eancia com canal alpha, equanto que GIFs t\u00eam apenas transpar\u00eancia total e JPEG n\u00e3o suporta transpar\u00eancia. De modo geral, PNGs hoje s\u00e3o superiores a GIFs e o \u00fanico motivo para usar o \u00faltimo \u00e9 quando h\u00e1 anima\u00e7\u00f5es.<\/p>\n Mas mesmo ao usar PNG, \u00e9 poss\u00edvel escolher entre dois formatos diferentes: PNG8 e PNG24. O PNG cl\u00e1ssico \u00e9 o de 24bits que suporta milh\u00f5es de cores e \u00e9 exportado por padr\u00e3o por todas as ferramentas gr\u00e1ficas. Mas o PNG8 diminui a palheta para 8bits, 256 cores no m\u00e1ximo, assim como os antigos GIFs. A vantagem do PNG8 \u00e9 que tem um tamanho bem menor e \u00e9 muito \u00fatil para imagens com poucas cores (logos, gr\u00e1ficos simples etc).<\/p>\n <\/a>#8 \u2013 Diminua cookies e headers<\/p>\n Um \u00faltimo passo para diminuir o tr\u00e1fego \u00e9 minimizar os headers envolvidos na requisi\u00e7\u00e3o e na resposta. Destes, os cookies costumam ser o pior vil\u00e3o pois s\u00e3o enviados a cada request entre cliente e servidor. H\u00e1 at\u00e9 a recomenda\u00e7\u00e3o de servir conte\u00fados est\u00e1ticos de dom\u00ednios sem cookies<\/a>.<\/p>\n Outro princ\u00edpio base de qualquer sistema distribu\u00eddo, minimizar o n\u00famero de invoca\u00e7\u00f5es remotas \u00e9 essencial para boa performance. Na Web, isso significa diminuir os requests feitos na p\u00e1gina para recursos externos \u2013 arquivos JS, CSS, imagens, Flash, v\u00eddeos etc.<\/p>\n No estudo dos Sites dos participantes da QCon, a m\u00e9dia de requests \u00e9 de 65 por p\u00e1gina, sendo que 17% possuem mais de 100 requests.<\/p>\n <\/a>#9 \u2013 Junte arquivos JavaScript<\/p>\n A an\u00e1lise mostrou que, em m\u00e9dia, os Sites chamam 10 arquivos JavaScript externos. O pior caso era um Site que chamava incr\u00edveis 54 arquivos JS. A solu\u00e7\u00e3o \u00e9 simples: juntar v\u00e1rios arquivos e diminuir o total. O ideal \u00e9 isso ser feito dinamicamente pela aplica\u00e7\u00e3o ou em build time, para que n\u00e3o seja necess\u00e1rio fazer manualmente. N\u00e3o existe um n\u00famero ideal de arquivos JS, mas eu recomendo entre 3 e 5 arquivos, no m\u00e1ximo.<\/p>\n <\/a>#10 \u2013 Juntar arquivos CSS<\/p>\n O mesmo princ\u00edpio vale para arquivos CSS. Nesse caso, recomendo 1 ou 2 arquivos externos. Na an\u00e1lise dos Sites, a m\u00e9dia foi de 5 arquivos por p\u00e1gina, sendo que o pior caso chegou a 24 arquivos CSS externos.<\/p>\n <\/a>#11 \u2013 Use Sprites<\/p>\n Aplicar a mesma ideia de juntar arquivos a imagens n\u00e3o \u00e9 t\u00e3o simples. As sprites s\u00e3o imagens que unem diversas outras em uma s\u00f3, como essa usada no Google:<\/p>\n O problema \u00e9 criar essas imagens, algo dif\u00edcil de se automatizar, e de gerenciar o CSS necess\u00e1rio para posicionar cada peda\u00e7o no lugar certo. H\u00e1 ideias para automatiza\u00e7\u00e3o como o Sprite.me, o SpriteMapper, o SpriteCow<\/a> e o SmartSprites.<\/p>\n Ao criar sprites, muitos pontos precisam ser pensados: \u00e9 dif\u00edcil lidar com imagens que precisem de repeti\u00e7\u00f5es. \u00c9 preciso pensar em espa\u00e7amentos entre as imagens para facilitar o posicionamento no CSS, ao mesmo tempo que n\u00e3o se deixe a sprite com \u00e1rea muito grande, o que causaria um grande uso de mem\u00f3ria no navegador. \u00c9 preciso pensar na similaridade das imagens para que, ao junt\u00e1-las, n\u00e3o tenhamos uma palheta de cores maior e pouca compress\u00e3o. Temos que decidir o formato da sprite (PNG? JPEG?) e como unificar as mesmas caracter\u00edsticas de qualidade e compress\u00e3o de diversas imagens.<\/p>\n \u00c9 complicado fazer Sprites mas, essencial para uma otimiza\u00e7\u00e3o s\u00e9ria. Na an\u00e1lise dos Sites dos participantes da QCon, mais da metade referencia 36 imagens ou mais<\/strong>. No pior caso, 144 imagens foram inclu\u00eddas em uma \u00fanica p\u00e1gina.<\/p>\n <\/a>#12 \u2013 Use Data URIs<\/p>\n Esse \u00e9 um recurso perigoso mas extremamente \u00fatil. Assim como podemos embutir conte\u00fados de CSS e JS no meio do HTML quando conveniente, com as data URIs<\/a><\/em>, podemos embutir imagens e outros elementos bin\u00e1rios. N\u00e3o \u00e9 um recurso para ser abusado, j\u00e1 que aumenta o tamanho do HTML e n\u00e3o permite que a imagem seja cacheada e referenciada em lugares diferentes. \u00c9 poss\u00edvel usar data URIs em arquivos CSS cache\u00e1veis, pr\u00e1tica mais recomendada.<\/p>\n A ideia \u00e9 transformar os dados bin\u00e1rios de uma imagem em base64 e colocar diretamente no src de uma imagem. Um problema \u00e9 que s\u00f3 h\u00e1 suporte no IE a partir da vers\u00e3o 8, apesar de todos os outros browsers suportarem h\u00e1 bastante tempo. Isso n\u00e3o impede que se sirva vers\u00f5es diferentes do Site para browsers antigos, por exemplo. O Google Images \u00e9 um exemplo emblem\u00e1tico de uso de data URIs<\/a>.<\/p>\n <\/a>#13 \u2013 Configure os headers<\/p>\n A estrat\u00e9gia aqui \u00e9 permitir que recursos est\u00e1ticos sejam cacheados pelo navegador<\/a>, evitando novos requests quando o usu\u00e1rio visitar a p\u00e1gina novamente. Em poucos segundos \u00e9 poss\u00edvel configurar o servidor para servir requests com valores apropriados de No estudo dos Sites, descobri que ao acessar a mesma p\u00e1gina duas vezes, o segundo acesso dispara, em m\u00e9dia, 46 novos requests. E, ainda, 87% dos Sites disparam mais que 10 requests nesse segundo acesso, um forte ind\u00edcio de que pouco se usa o recurso de cache do navegador. Um valor razo\u00e1vel seria manter esse n\u00famero em menos de 5 requests e, se poss\u00edvel, apenas 1 ou 2.<\/p>\n <\/a>#14 \u2013 Tire firulas do design<\/p>\n Pol\u00eamico, esse t\u00f3pico prop\u00f5e que o layout seja feito com performance em mente. Talvez muitos designers discordem, mas os n\u00fameros mostram que velocidade \u00e9 mais importante para o usu\u00e1rio do que designs detalhistas e carregados.<\/p>\n Essa pr\u00e1tica inclui diminuir a depend\u00eancia do layout por imagens externas, evitar o uso de fontes externas, n\u00e3o usar Flash para design, entre outros.<\/p>\n A percep\u00e7\u00e3o humana \u00e9 muito menos racional do que imaginamos. E, na Web, isso reflete diretamente em como os usu\u00e1rios percebem a velocidade do Site (e credibilidade, atratividade etc). H\u00e1 estudos que mostram que a percep\u00e7\u00e3o de tempo de carregamento dos usu\u00e1rios \u00e9, em m\u00e9dia, 15% pior que a real. E, quando perguntados tempos depois sobre a performance de um Site, a lembran\u00e7a costuma ser 35% pior que a velocidade real (fonte).<\/p>\n Na Web, o n\u00famero de segundos para a p\u00e1gina carregar e a nota do YSlow s\u00e3o m\u00e9tricas importantes, mas n\u00e3o s\u00e3o tudo. Performance Web tem tudo a ver com com Usabilidade e UX, e \u00e9 o usu\u00e1rio final quem fala o qu\u00e3o r\u00e1pido est\u00e1 um Site ou n\u00e3o.<\/p>\n Existem diversas t\u00e9cnicas de otimiza\u00e7\u00e3o que n\u00e3o afetam o tempo de carregamento da p\u00e1gina e talvez n\u00e3o melhorem sua nota no YSlow. S\u00e3o t\u00e9cnicas para tornar a percep\u00e7\u00e3o do usu\u00e1rio mais favor\u00e1vel ao seu Site, dando a sensa\u00e7\u00e3o de velocidade mesmo que o rel\u00f3gio diga o contr\u00e1rio.<\/p>\n <\/a>#15 \u2013 Especifique o tamanho das imagens<\/p>\n F\u00e1cil de implementar, essa pr\u00e1tica tem um grande impacto visual para o usu\u00e1rio. Quando n\u00e3o especificamos o tamanho da imagem, o navegador n\u00e3o reserva um espa\u00e7o na p\u00e1gina para ela. O efeito \u00e9 que, quando a imagem chega, ela \u00e9 posicionada em seu lugar empurrando o restante do conte\u00fado. Isso d\u00e1 a sensa\u00e7\u00e3o de que os elementos da p\u00e1gina est\u00e3o se movendo e que ela ainda n\u00e3o est\u00e1 carregada. \u00c9 uma p\u00e9ssima pr\u00e1tica de usabilidade e d\u00e1 a sensa\u00e7\u00e3o de mais lerdeza.<\/p>\n Simplesmente especificar o tamanho correto da imagem no width e height do HTML ou CSS<\/a> faz com que o browser j\u00e1 reserve o espa\u00e7o para a imagem mesmo antes de seu download acabar. Quando ela chega, o navegador n\u00e3o precisa abrir espa\u00e7o e empurrar os outros elementos, dando a sensa\u00e7\u00e3o de que a p\u00e1gina est\u00e1 sendo carregada mais rapidamente. Al\u00e9m disso, ao evitar o reposicionamento de elementos, evita-se reflows e repaints<\/a> desnecess\u00e1rios.<\/p>\n <\/a>#16 \u2013 Coloque o JavaScript no fim<\/p>\n C\u00f3digo JavaScript, interno ou externo, bloqueia a renderiza\u00e7\u00e3o de tudo que vem abaixo dele. Em alguns browsers, bloqueia inclusive o download de componentes seguintes. Para evitar esse bloqueio, coloque o JavaScript o mais pra baixo que puder; se poss\u00edvel, logo antes de fechar o body.<\/p>\n O efeito mais comum de JavaScript mal posicionado \u00e9 a tela ficar em branco durante muito tempo, adiando o in\u00edcio da renderiza\u00e7\u00e3o. O senso comum manda colocar os JavaScripts no head, o que causa o bloqueio da renderiza\u00e7\u00e3o da tela toda. Na an\u00e1lise dos Sites dos conferencistas, a m\u00e9dia de espera para o in\u00edcio da renderiza\u00e7\u00e3o foi de 4,3s<\/strong>. O pior caso deixava o browser totalmente branco durante 25s.<\/p>\n <\/a>#17 \u2013 Coloque o CSS no topo<\/p>\n O CSS tamb\u00e9m bloqueia a renderiza\u00e7\u00e3o da tela mas, neste caso, isso \u00e9 melhor na maioria das vezes. Colocar o CSS para baixo causaria o efeito conhecido como FOUC \u2013 Flash of Unstyled Content<\/a><\/em>. A p\u00e1gina \u00e9 renderizada sem estilo e, quando o CSS acaba de baixar, ela \u00e9 redesenhada com o estilo.<\/p>\n Embora isso fa\u00e7a com que a p\u00e1gina comece a ser mostrada antes para o usu\u00e1rio, na maioria dos Sites, mostrar uma p\u00e1gina sem estilos n\u00e3o tem valor algum para o usu\u00e1rio. O layout fica sem estrutura, sem organiza\u00e7\u00e3o, e o efeito \u00e9 aparentar que a p\u00e1gina est\u00e1 demorando mais para carregar. Por isso, coloque o CSS no topo do documento<\/a>, de prefer\u00eancia no head.<\/p>\n <\/a>#18 e #19 \u2013 Adie o carregamento do que puder e Abuse do carregamento ass\u00edncrono<\/p>\n Uma das t\u00e9cnicas avan\u00e7adas mais discutidas ultimamente \u2013 e das mais eficazes \u2013 \u00e9 o uso de carregamento ass\u00edncrono de componentes da p\u00e1gina. Isso evita bloqueios na renderiza\u00e7\u00e3o e faz a p\u00e1gina ficar mais responsiva.<\/p>\n <\/a>#20 \u2013 Otimize o First-View e o Above the Fold Time<\/p>\n Como diz o ditado, a primeira impress\u00e3o \u00e9 a que fica. Isso significa otimizar ao m\u00e1ximo a primeira visita do usu\u00e1rio, aquele onde o cache do navegador vai estar vazio, aquela quando ele ainda n\u00e3o conhece seu Site, e aquele onde ele traz todas suas expectativas.<\/p>\n \u00c9 preciso entender como a intera\u00e7\u00e3o do usu\u00e1rio acontece, e priorizar os componentes e a ordem da renderiza\u00e7\u00e3o da p\u00e1gina para esse primeiro contato. H\u00e1 quem fale em uma nova m\u00e9trica, o Above the Fold Time<\/em> \u2013 AFT \u2013 que mede o tempo de tempo de carregamento do in\u00edcio da p\u00e1gina, \u201cacima da dobra\u201d, aquela parte que o usu\u00e1rio v\u00ea sem fazer scroll. O scroll infinito<\/a> do Twitter \u00e9 um exemplo disso; os dados mais para baixo s\u00f3 s\u00e3o carregados quando o usu\u00e1rio faz scroll at\u00e9 l\u00e1. Ou ainda a p\u00e1gina de produtos da Amazon que deixa para carregar alguns componentes do fim da p\u00e1gina s\u00f3 quando o usu\u00e1rio chega l\u00e1.<\/p>\n Mesmo sem usar t\u00e9cnicas avan\u00e7adas como o scroll infinito, priorizar o AFT \u00e9 pensar na ordem dos elementos no HTML para que as coisas que ser\u00e3o exibidas antes carreguem primeiro. \u00c9 adiar aquele widget do Facebook que fica no fim da p\u00e1gina para ser carregado s\u00f3 depois do onload, por exemplo. \u00c9 prover um menu de op\u00e7\u00f5es que n\u00e3o dependa de JavaScript para funcionar, j\u00e1 que este ser\u00e1 executado por \u00faltimo. No fim, \u00e9 focar na primeira experi\u00eancia do usu\u00e1rio e adiar tudo aquilo que n\u00e3o \u00e9 necess\u00e1rio para isso.<\/p>\n <\/a>#21 \u2013 Design perform\u00e1tico<\/p>\n Uma \u00e1rea que mereceria um post por si s\u00f3 \u00e9 como o design da p\u00e1gina pode afetar a percep\u00e7\u00e3o de velocidade do usu\u00e1rio. O Google Reader antigamente usava um fundo azul claro em sua barra lateral e resolveu experimentar trocar para branco. Quando perguntados, os usu\u00e1rios, em sua maioria, afirmaram que o \u201cnovo Site\u201d era mais r\u00e1pido que o anterior (fonte).<\/p>\n A Psicologia da Performance<\/em> envolve muitos t\u00f3picos de design, UX e usabilidade. Uma layout mais leve, uma arquitetura de informa\u00e7\u00e3o mais simples, um call-to-action<\/em> mais direto influenciam diretamente em como os usu\u00e1rios percebem a performance.<\/p>\n <\/a>#22 \u2013 Automatize<\/p>\n O segredo para um Site com performance consistente e dur\u00e1vel \u00e9 automatizar o processo. Fa\u00e7a um script que minifique JS e CSS, automatize a otimiza\u00e7\u00e3o das imagens, etc. Qualquer processo repetitivo deve ser automatizado, caso contr\u00e1rio ser\u00e1 logo deixado de lado pela equipe.<\/p>\n <\/a>#23 \u2013 Use ferramentas de diagn\u00f3stico<\/p>\n Monitore suas p\u00e1ginas constantemente com ferramentas de diagn\u00f3stico. H\u00e1 diversas dispon\u00edveis:<\/p>\n <\/a>#24 \u2013 Pr\u00e9-carregue componentes<\/p>\n Em alguns casos, ao visitar uma p\u00e1gina, voc\u00ea quase que certamente sabe qual ser\u00e1 a pr\u00f3xima p\u00e1gina visitada pelo usu\u00e1rio. Pense na home do Google que certamente ser\u00e1 seguida por uma visita \u00e0 p\u00e1gina de resultados da busca. Ou ainda em um fluxo de fechamento das compras de uma loja virtual em v\u00e1rios passos.<\/p>\n Nessas situa\u00e7\u00f5es, pode ser interessante que a primeira p\u00e1gina pr\u00e9-carregue elementos que ser\u00e3o utilizados na p\u00e1gina seguinte. CSS, JavaScript e imagens podem ser pr\u00e9-carregados via c\u00f3digo, antecipando o download de componentes que tem grande chance de serem usados depois. Obviamente, essa pr\u00e1tica s\u00f3 deve ser usada se voc\u00ea configurou os headers de cache apropriadamente, sen\u00e3o os componentes ser\u00e3o baixados duas vezes.<\/p>\n Essa pr\u00e1tica tem um imenso ganho de velocidade ao visitar a segunda p\u00e1gina. Deve-se, por\u00e9m, tomar cuidado para que n\u00e3o se prejudique a performance da primeira. O ideal \u00e9 fazer esses pr\u00e9-carregamentos somente quando a p\u00e1gina inicial terminar de carregar todos os seus componentes, possivelmente depois do onload da mesma.<\/p>\n <\/a>#25 \u2013 Escreva c\u00f3digo eficiente<\/p>\n Em alguns raros casos o performance pode ser bastante afetada por m\u00e1s pr\u00e1ticas de codifica\u00e7\u00e3o de HTML, CSS ou JavaScript. Note, por\u00e9m, que a maioria das t\u00e9cnicas mais eficazes costumam ser pouco influenciadas por micro otimiza\u00e7\u00f5es de c\u00f3digo; o problema costuma ser mais estrutural.<\/p>\n Por\u00e9m, quando a aplica\u00e7\u00e3o \u00e9 carregada, cheia de recursos ricos, o c\u00f3digo pode ser otimizado. H\u00e1 diversos seletores CSS que deixam a renderiza\u00e7\u00e3o bem mais lenta<\/a>. O alto n\u00famero de elementos no DOM tamb\u00e9m diminui a performance<\/a>. Usar iframes em excesso ent\u00e3o \u00e9 um quase um crime<\/a>. E h\u00e1 tamb\u00e9m as pr\u00e1ticas de otimiza\u00e7\u00e3o de c\u00f3digo e l\u00f3gica JavaScript<\/a>, como quebrar longas tarefas em peda\u00e7os menores com WebWorkers ou setTimeout, evitando bloqueio da tela.<\/p>\n <\/a>#26 \u2013 Dispare logo o onload<\/p>\n O evento de onload \u00e9 esperado por muitos scripts para que sua execu\u00e7\u00e3o prossiga. Al\u00e9m disso, costuma ser a m\u00e9trica usada para medir performance em ferramentas como Analytics e Webmasters Tools. Desde 2010, o Google usa a velocidade do Site<\/a> como uma das vari\u00e1veis do rankeamento das buscas, e isso tem a ver com o onload. Depois do disparo do onload, o indicador de carregamento do navegador para de girar, dando a impress\u00e3o de fim do carregamento.<\/p>\n H\u00e1 v\u00e1rios motivos para se otimizar o tempo de onload, muitos explicados por Steve Souders<\/a> em seus livros. Abusar do carregamento ass\u00edncrono ajuda a implementar essa pr\u00e1tica.<\/p>\nT\u00e9cnicas de otimiza\u00e7\u00e3o<\/h2>\n
\n
Diminua o tamanho dos requests<\/h2>\n
<\/html><\/code> ou <\/body><\/code> em sua home, j\u00e1 que isso n\u00e3o prejudica nenhum navegador e economiza mais alguns bytes.<\/p>\nwidth<\/code> e o height<\/code> no HTML ou CSS. Sempre redimensione o arquivo original e referencie o tamanho direto.<\/p>\nDiminua a quantidade de requests<\/h2>\n
![\"Nav](\"https:\/\/www.google.com\/images\/nav_logo83.png\"){kind=logo}
<\/p>\nExpires<\/code>, Last-Modified<\/code>, Cache-Control<\/code> e ETag<\/code>.<\/p>\nPerformance \u00e9 medida pela percep\u00e7\u00e3o do usu\u00e1rio<\/h2>\n
B\u00f4nus: mais t\u00f3picos<\/h2>\n
\n