O presidente da Microsoft, Bill Gates, atribuiu na sexta-feira à Internet avanços "fenomenais" na transparência das finanças dos governos, citando o caso das prestações de conta na Escandinávia.
"Os países nórdicos, com Suécia e Dinamarca, realmente levaram isso a um nível incrível", disse Gates numa conferência sobre governos na América Latina, preparatória para a reunião anual do Banco Interamericano de Comércio em Miami.
"Quando um ministro [nórdico] sai para almoçar, você pode ver quanto ele gastou no almoço e quanto no táxi. Literalmente aparece [na Internet] em poucas horas", disse ele.
Ele se referia aos registros detalhados das atividades do governo nos sites oficiais, onde constam agendas ministeriais, orçamentos e dados de concorrências públicas.
"Em cada oferta feita [nas concorrências], os autores aparecem nas redes, você vê os termos que eles oferecem", afirmou Gates, referindo-se a novos procedimentos adotados em lugares como a Suécia.
"É um processo de concorrência muito aberto, muito transparente," disse ele, acrescentando que "coisas do governo que realmente importam" agora estão acessíveis no computador de qualquer um.
"Ainda há muito a ser feito," ressalvou o empresário. "A qualidade da governança melhorou, e podem melhorar muito mais, por causa da transparência da Internet."
Nos EUA também, segundo ele, há muitos dados do governo online, mas normalmente o jargão e as dificuldades de navegação afastam a maioria dos usuários.
"É aí que os países nórdicos são melhores. Nós [os EUA] não somos modelo para esse esforço em particular", afirmou Gates, que em junho deixará suas tarefas cotidianas na Microsoft para se dedicar exclusivamente à filantropia por intermédio da sua fundação.
Fonte: Tom Brown.
sábado, 5 de abril de 2008
sexta-feira, 4 de abril de 2008
Picasa Web Albums para Windows Mobile
Depois de lançar uma versão exclusiva do PicasaWeb para o iPhone, a Google resolveu abusar dos recursos do Windows Mobile 6[bb], com touchscreen, e lançou uma versão exclusiva do PicasaWeb para Windows Mobile.
A nova versão também conta com a integração com o Google Gears para celulares[bb]. Disponível somente para Windows Mobile, o Plug-in permite aos usuários utilizarem aplicações web mesmo estando sem internet.
Para visualizar o PicasaWeb em seu aparelho com Windows Mobile, visite picasaweb.google.com
A nova versão também conta com a integração com o Google Gears para celulares[bb]. Disponível somente para Windows Mobile, o Plug-in permite aos usuários utilizarem aplicações web mesmo estando sem internet.
Para visualizar o PicasaWeb em seu aparelho com Windows Mobile, visite picasaweb.google.com
(YSlow) Melhore a Performance do seu Website (Por Thiago Ferreira)
O YSlowé uma ferramenta de perfomance para web, desenvolvido pela equipe de desenvolvimento do Yahoo!. Ela segue as melhores práticas de web performance para front-end, adotadas pela equipe de performance do Yahoo!.
Seu funcionamento é integrado ao plugin FireBug, para o browser Firefox. Portanto, antes de instalar o YSlow no Firefox, é necessário instalar o Firebug.
Este artigo não é uma tradução, mas é baseado nas regras de performance do YSlow, disponíveis da documentação da ferramenta. Além de trechos de adaptados do link original, há opiniões, comentários e conclusões deste que vos "fala".
Mas, por que a performance do front-end é importante?
apenas 5% do tempo de carregamento da página é gasto com o download do código HTML. Os outros 95% são gastos com imagens, CSS, Javascripts, etc..
Uma pesquisa mostrou que 9 dos 10 maiores sites americanos têm, no máximo, 20% do tempo de carregamento gasto com HTML.
Isso nos indica que devemos cuidar da performance do front-end das nossas páginas WEB, a fim de melhorar a experiência do visitante.
As três principais razões para começar pela performance do front-end, segundo os especialistas em performance do Yahoo!:
Para medir a performance de uma página, o YSlow basea-se em 13 regras. De acordo com a taxa de aderência da página às regras, é dada uma pontuação de A a F para cada regra, onde A representa a nota máxima e F representa a nota mínima. Também é calculada a nota final, com a média das notas obtidas nas 13 regras.
O detalhamento das notas para cada página pode ser vista na aba Performance, do YSlow.
Algumas dessas regras, como veremos a seguir, são proibitivas para a maioria dos sites devido ao custo, complexidade ou freqüência de uso. Vamos às regras!
Regras para Alta Performance
As regras são classificadas de acordo com o seu grau de importância.
Regra 1: Fazer poucas requisições HTTP
Segundo Steve Souders, que é o CARA do time de performance do Yahoo!, 80% do tempo gasto por um usuário numa página é carregando o front-end e que a maior parte desse tempo de carregamento é tomado pelo download de imagens, scripts, css, flash, etc., como já vimos anteriormente.
Então, para melhorar a performance no carregamento da página é importante utilizarmos o menos possível de imagens, css, etc. Para isso, além de otimizar essas requisições fazendo somente as necessárias, pode-se utilizar técnicas citadas por ele:
CDN (Content Delivery Network) pode ser traduzido como "Entregador de Conteúdo na Rede". Embora a (má) tradução tenha dificultado o entendimento, isso é simples de entender. Digamos que você tenha um site de acesso global, como YouTube. Suponha que os arquivos estejam num único servidor aqui no Brasil. Agora imaginem os usuários de outros países e continentes acessando esse conteúdo. O caminho é longo, certo? Caminho longo significa maior tempo para acesso e carga desses arquivos.
O CDN serve justamente para eliminar isso, pois trata-se de uma coleção de servidores de conteúdo distribuídos geográficamente, de forma a minimizar a distância entre o usuário e o conteúdo estático de seu site. O cálculo de proximidade entre usuário e conteúdo é calculado através de saltos (hops) de roteamento ou do tempo de resposta à solicitação.
Mas como eu havia dito antes, há regras do YSlow que são proibitivas pelo custo. Esse é o caso da Regra 2 que, além de ser cara, só é necessário para uma parcela pequena de sites.
Regra 3: Adicione Expires no cabeçalho
O cabeçalho Expires diz ao browser a data que os componentes daquela requisição irão expirar, ou seja, se você determina um prazo de 5 anos para uma página expirar, todos componentes nela contidos somente expirarão em 5 anos. Com isso, todos os componentes (imagens, CSS, scripts, Flash, etc.) serão colocados em cache e, nas próximas visitas, o número de requisições HTTP será menor pois os componentes poderão ser acessados diretamente do cache do browser.
Aí você pergunta: "Mas e se eu fizer uma alteração num componente?". Se você fizer uma alteração, precisará alterar também o nome deste componente. É altamente recomendado que seja acrescentado nos nomes dos componentes informações de versão. Exemplo: estilo_1.css.
Quando você fizer uma alteração neste arquivo, basta alterar a numeração da versão, colocando estilo_2.css.
O uso da linha de código a seguir faz com que os componentes da página que a contém expirar somente em 2012.
[code][/code]
Acontece que o HTTP/1.1 não recomenda o uso de datas de expiração maiores do que um ano. Eu penso que realmente não há necessidade de ser maior do que um ano pois normalmente os caches são limpos pelos usuários com freqüência.
Não recomendo o uso dessa técnica durante o desenvolvimento do projeto pois será mais difícil corrigir bugs e fazer alterações.
Regra 4: Compacte componentes
Esta regra de performance indica que é recomendado que os componentes sejam compactados através da requisição HTTP para que o tempo de resposta seja menor, fazendo com que os componentes sejam carregados mais rapidamente no cliente.
A configuração da forma de compactação e o algoritmo de compactação utilizados variam de acordo com o servidor WEB utilizado.
A compactação é recomendada para qualquer arquivo de texto, como HTML, Javascript, folhas de estilo, XML, JSON, etc. Ela só não é recomendada para alguns tipos de arquivos como imagens e PDF, pois eles já são comprimidos e a compactação seria ineficiente e tomaria recursos do servidor desnecessariamente.
Regra 5: Coloque o CSS no topo
Essa é uma das regras mais simples de seguir. Ela diz que a declaração das folhas de estilo (CSS) deve estar dentro do HEAD do documento. Isso é um tanto quanto óbvio, pois a especificação do HTML já diz isso.
O CSS deve estar no HEAD pois o browser pode renderizar o conteúdo de acordo com a progressão do carregamento dos componentes. Isso trás melhor experiência ao usuário pois ele, além de ver que algo está acontecendo, pode acessar um link que já tenha aparecido no browser antes mesmo da página terminar de carregar.
Quando o CSS não está no HEAD, alguns browsers esperam todo o carregamento da página, para que não tenha que haver reposicionamento ou redesenho de componentes. Enquanto não aparecem, o usuário vê somente uma página em branco. Browsers como o Firefox, que mostram o conteúdo independente do local de declaração do CSS, "correm o risco" de ter que redesenhar ou reposicionar os componentes na tela.
Regra 6: Coloque os scripts embaixo
Os arquivos externos de javascript funcionam da forma contrária aos arquivos CSS, quanto à renderização progressiva. Enquanto o CSS bloqueia a renderização de tudo o que está antes dele até seu carregamento completo, o javascript bloqueia o carregamento de tudo o que está depois dele, até o seu carregamento.
Assim, se você colocar os arquivos de script o mais próximo possível da tag de fechamento do BODY, a renderização de tudo o que está antes do script poderá ser feita independente do carregamento desses arquivos.
Outro fator que justifica a colocação dos scripts tão próximo do fechamento de BODY quanto possível é que os browsers não fazem download de nenhum outro arquivo enquanto fazem o download de um script javascript, independente se é do mesmo servidor ou não.
Eu até achava que os scripts não poderiam ser colocados dentro do BODY, mas, depois que li essa regra, fiz uma pesquisa e constatei que a especificação do HTML não tem nenhuma contra-indicação quanto a isso.
Regra 7: Evite expressões CSS
É possível declarar expressões em CSS através do método expression. Uma expressão CSS utiliza javascript para calcular algum valor que será utilizado como valor de uma propriedade. Um exemplo de expressão CSS:
Além das expressões CSS só funcionarem no Internet Explorer, também há outro problema envolvido: diferentemente do que se possa imaginar, as expressões não são calculadas apenas ao carregar da página ou quando se redimensiona a janela. Elas também são calculadas a cada movimento do mouse sobre a página e quando movemos a barra de rolagem. Se a cada movimento do mouse sobre a tela geramos um cálculo dessa expressão, o movimento horizontal retilíneo de um extremo ao outro de uma página com resolução de 800 x 600 gera 800 cálculos!!!
Se realmente for necessário utilizar expressões CSS, prefira colocar essa expressão no arquivo javascript e setar a propriedade CSS através do Javascript. A vantagem é que você controlará os eventos que manipularão esse cálculo.
Regra 8: Utilize CSS e Javascript em arquivos externos
Em algumas regras anteriores falamos sobre a gerência de arquivos externos pelo HTTP. Aparentemente, há uma recomendação para que os códigos javascript e CSS sejam colocados no mesmo arquivo do código HTML, para diminuir o número de requisições HTTP. Mas não é bem assim!!
Colocar o javascript e CSS em arquivos separados, além de facilitar o reuso e manutenção desses arquivos, possibilitam que o navegador mantenha esses arquivos em cache.
Por outro lado, o javascript e CSS colocados "inline" no HTML não podem ser colocados em cache e têm que ser carregados a cada requisição. Outro fator contrário ao "inline" é que aumentam o tamanho do arquivo HTML e, por conseqüência, o tempo de carregamento desses arquivos.
Por outro lado (quantos lados, hein!), páginas que tem um estilo "único" dentre as outras páginas e normalmente são acessadas apenas uma vez por sessão devem ter seus javascript e CSS "inline", desde que não sejam muito grandes.
Regra 9: Reduza as pesquisas DNS
O DNS mapeia hostnames em endereços IPs para que possam ser feitas as conexões HTTP, assim como uma agenda telefônica mapeia nomes em números telefônicos.
Quando você digita www.tmferreira.com.br/blog/ no seu browser, antes de qualquer coisa, o seu browser solicita ao DNS o IP de www.tmferreira.com.br.
O cache de DNS em sistemas operacionais ou browsers expira rapidamente. Assim, é recomendado que não sejam utilizados muitos hostnames para um website, para que seja reduzido o tempo em pesquisas DNS.
Se você, assim como eu, tem um e-mail do BOL, já deve ter percebido que eles utilizam muitos hostnames. Isso melhora o tempo de carregamento das páginas com os downloads simultâneos, mas aumenta o número de pesquisas DNS.
Essa também é uma das regras que havia mencionado que não se aplicam a grande maioria dos sites, que tem o mesmo hostname para a aplicação toda.
Regra 10: Reduza os Javascripts
Essa regra preconiza que os arquivos javascript em produção devem ser reduzidos. A redução consiste em remover espaços, tabulações, comentários, etc., ou seja, tudo o que não é necessário para o funcionamento do código e que aumentam o tamanho dos arquivos.
Essa técnica é muito utilizada em scripts e frameworks distribuídos na internet. Essas distribuições normalmente são chamadas de packs.
A redução de scripts não tem efeitos colaterais e é indicada sempre que o arquivo já está em produção. Durante o desenvolvimento, a redução dificulta a alteração do código e remoção de bugs.
Regra 11: Evite redirecionamentos
Os redirecionamentos acontecem pelos mais diversos motivos. A aplicação que mais vejo acontece em fóruns. Após você fazer um post, é mostrada uma mensagem (de sucesso ou erro) e depois há o redirecionamento para outra página.
Obviamente que isso deixa aborrecido os usuários que estão acessando de uma conexão lenta.
No iMasters, retiramos o redirecionamento para que a experiência do usuário seja melhor.
Mas há ocasiões em que não dá para escapar do redirecionamento. No meu blog, houve mudança de domínio. Como fazer com que os links do domínio antigo continuassem íntegros? Só com redirecionamento mesmo. Mas há formas e formas de fazer um redirecionamento. A mais rápida e recomendada é diretamente através de um cabeçalho HTTP com resposta 301 ou 302 (no blog foi feito assim). Uma forma de redirecionamento que é mais lenta é através da tag meta refresh.
O importante é ter bom senso e utilizar os redirecionamentos onde é extritamente necessário.
Regra 12: Remova scripts duplicados
Essa regra diz que não devemos fazer inclusões duplicadas (ou triplicadas, ...) de scripts.
Eu não considero isso como uma regra pois não faz o menor sentido em incluir um mesmo script duas ou mais vezes na mesma página. Para mim, isso é um erro e nem precisaria de regra para que os desenvolvedores não o cometam.
Regra 13: Configure ETags
ETags é o acrônimo para Entity Tags. Isto é um mecanismo que servidores WEB e browsers usam para determinar se o arquivo do servidor é o mesmo que está no cache do browser.
O valor da ETag é gerado dependendo das configurações do servidor e de acordo com as características atuais do arquivo.
Essa configuração faz com que o Apache calcule um hash do arquivo baseado na data e hora da sua última modificação. O browser armazena essa ETag em cache. Se eu modificar o arquivo e salvá-lo, a data e hora da última modificação será alterada e, com isso, os valores de ETag entre servidor e browser ficarão diferentes, fazendo com que o arquivo seja recarregado.
A configuração de ETags torna desnecessário o uso de versão no nome dos arquivos de imagens, CSS, Javascript, etc.
Conclusão
Nesse artigo, vimos que o YSlow pode nos dar o caminho das pedras para diminuir o tempo de carregamento das páginas e melhorar a experiência dos visitantes.
Eu não encaro essas regras literalmente. Encaro-as como boas práticas que devem ser seguidas com bom senso e com análise caso a caso. Penso que a nota C é uma ótima nota para a grande maioria dos sites.
Thiago Ferreira
Seu funcionamento é integrado ao plugin FireBug, para o browser Firefox. Portanto, antes de instalar o YSlow no Firefox, é necessário instalar o Firebug.
Este artigo não é uma tradução, mas é baseado nas regras de performance do YSlow, disponíveis da documentação da ferramenta. Além de trechos de adaptados do link original, há opiniões, comentários e conclusões deste que vos "fala".
Mas, por que a performance do front-end é importante?
apenas 5% do tempo de carregamento da página é gasto com o download do código HTML. Os outros 95% são gastos com imagens, CSS, Javascripts, etc..
Uma pesquisa mostrou que 9 dos 10 maiores sites americanos têm, no máximo, 20% do tempo de carregamento gasto com HTML.
Isso nos indica que devemos cuidar da performance do front-end das nossas páginas WEB, a fim de melhorar a experiência do visitante.
As três principais razões para começar pela performance do front-end, segundo os especialistas em performance do Yahoo!:
- Há mais potencial de melhoria de performance no front-end. Melhorar a performance do front-end pela metade reduz em 40% o tempo de resposta, enquanto melhorar pela metade a performance do back-end reduz apenas 10% do tempo de resposta.
- A melhoria de performance através do front-end tipicamente requer menos tempo e recursos do que o back-end.
- É provado que o tuning de performance do front-end funciona! Mais do que 50 equipes do Yahoo! reduziram o tempo de resposta para o usuário em 25% ou mais, seguindo as melhores práticas da equipe de performance do Yahoo!.
Para medir a performance de uma página, o YSlow basea-se em 13 regras. De acordo com a taxa de aderência da página às regras, é dada uma pontuação de A a F para cada regra, onde A representa a nota máxima e F representa a nota mínima. Também é calculada a nota final, com a média das notas obtidas nas 13 regras.
O detalhamento das notas para cada página pode ser vista na aba Performance, do YSlow.
Algumas dessas regras, como veremos a seguir, são proibitivas para a maioria dos sites devido ao custo, complexidade ou freqüência de uso. Vamos às regras!
Regras para Alta Performance
As regras são classificadas de acordo com o seu grau de importância.
Regra 1: Fazer poucas requisições HTTP
Segundo Steve Souders, que é o CARA do time de performance do Yahoo!, 80% do tempo gasto por um usuário numa página é carregando o front-end e que a maior parte desse tempo de carregamento é tomado pelo download de imagens, scripts, css, flash, etc., como já vimos anteriormente.
Então, para melhorar a performance no carregamento da página é importante utilizarmos o menos possível de imagens, css, etc. Para isso, além de otimizar essas requisições fazendo somente as necessárias, pode-se utilizar técnicas citadas por ele:
- Mapa de imagens: quando se tem imagens que podem ser "coladas" umas nas outras, pode-se utilizar mapas de imagens para se detectar onde foi efetuado o clique. Embora o tamanho da imagem unificada seja o mesmo da soma das imagens separadas, o número de requisições diminui. Assim, toda aquela burocracia do HTTP 1.1 para abrir uma conexão e fazer a requisição é diminuída.
- CSS Sprites: podemos utilizar essa técnica quando há substituição de uma imagem por outra, quando passamos o mouse sobre a imagem, por exemplo. As duas imagens são colocadas num mesmo arquivo e, através de CSS só uma delas é mostrada ao usuário. Quando o mouse está sobre a imagem, ela é deslocada, sendo mostrada a parte que estava oculta. Isso dá a impressão que a imagem foi mudada, mas na verdade é a mesma imagem em outra posição.
- Combinar os arquivos de script em um único arquivo. Também podemos fazer isso com arquivos de estilo (CSS). Reduzir o número de requisições HTTP é o principal ponto para melhorar a experiência dos usuários que não estão com os arquivos da sua página em cache.
CDN (Content Delivery Network) pode ser traduzido como "Entregador de Conteúdo na Rede". Embora a (má) tradução tenha dificultado o entendimento, isso é simples de entender. Digamos que você tenha um site de acesso global, como YouTube. Suponha que os arquivos estejam num único servidor aqui no Brasil. Agora imaginem os usuários de outros países e continentes acessando esse conteúdo. O caminho é longo, certo? Caminho longo significa maior tempo para acesso e carga desses arquivos.
O CDN serve justamente para eliminar isso, pois trata-se de uma coleção de servidores de conteúdo distribuídos geográficamente, de forma a minimizar a distância entre o usuário e o conteúdo estático de seu site. O cálculo de proximidade entre usuário e conteúdo é calculado através de saltos (hops) de roteamento ou do tempo de resposta à solicitação.
Mas como eu havia dito antes, há regras do YSlow que são proibitivas pelo custo. Esse é o caso da Regra 2 que, além de ser cara, só é necessário para uma parcela pequena de sites.
Regra 3: Adicione Expires no cabeçalho
O cabeçalho Expires diz ao browser a data que os componentes daquela requisição irão expirar, ou seja, se você determina um prazo de 5 anos para uma página expirar, todos componentes nela contidos somente expirarão em 5 anos. Com isso, todos os componentes (imagens, CSS, scripts, Flash, etc.) serão colocados em cache e, nas próximas visitas, o número de requisições HTTP será menor pois os componentes poderão ser acessados diretamente do cache do browser.
Aí você pergunta: "Mas e se eu fizer uma alteração num componente?". Se você fizer uma alteração, precisará alterar também o nome deste componente. É altamente recomendado que seja acrescentado nos nomes dos componentes informações de versão. Exemplo: estilo_1.css.
Quando você fizer uma alteração neste arquivo, basta alterar a numeração da versão, colocando estilo_2.css.
O uso da linha de código a seguir faz com que os componentes da página que a contém expirar somente em 2012.
[code][/code]
Acontece que o HTTP/1.1 não recomenda o uso de datas de expiração maiores do que um ano. Eu penso que realmente não há necessidade de ser maior do que um ano pois normalmente os caches são limpos pelos usuários com freqüência.
Não recomendo o uso dessa técnica durante o desenvolvimento do projeto pois será mais difícil corrigir bugs e fazer alterações.
Regra 4: Compacte componentes
Esta regra de performance indica que é recomendado que os componentes sejam compactados através da requisição HTTP para que o tempo de resposta seja menor, fazendo com que os componentes sejam carregados mais rapidamente no cliente.
A configuração da forma de compactação e o algoritmo de compactação utilizados variam de acordo com o servidor WEB utilizado.
A compactação é recomendada para qualquer arquivo de texto, como HTML, Javascript, folhas de estilo, XML, JSON, etc. Ela só não é recomendada para alguns tipos de arquivos como imagens e PDF, pois eles já são comprimidos e a compactação seria ineficiente e tomaria recursos do servidor desnecessariamente.
Regra 5: Coloque o CSS no topo
Essa é uma das regras mais simples de seguir. Ela diz que a declaração das folhas de estilo (CSS) deve estar dentro do HEAD do documento. Isso é um tanto quanto óbvio, pois a especificação do HTML já diz isso.
O CSS deve estar no HEAD pois o browser pode renderizar o conteúdo de acordo com a progressão do carregamento dos componentes. Isso trás melhor experiência ao usuário pois ele, além de ver que algo está acontecendo, pode acessar um link que já tenha aparecido no browser antes mesmo da página terminar de carregar.
Quando o CSS não está no HEAD, alguns browsers esperam todo o carregamento da página, para que não tenha que haver reposicionamento ou redesenho de componentes. Enquanto não aparecem, o usuário vê somente uma página em branco. Browsers como o Firefox, que mostram o conteúdo independente do local de declaração do CSS, "correm o risco" de ter que redesenhar ou reposicionar os componentes na tela.
Regra 6: Coloque os scripts embaixo
Os arquivos externos de javascript funcionam da forma contrária aos arquivos CSS, quanto à renderização progressiva. Enquanto o CSS bloqueia a renderização de tudo o que está antes dele até seu carregamento completo, o javascript bloqueia o carregamento de tudo o que está depois dele, até o seu carregamento.
Assim, se você colocar os arquivos de script o mais próximo possível da tag de fechamento do BODY, a renderização de tudo o que está antes do script poderá ser feita independente do carregamento desses arquivos.
Outro fator que justifica a colocação dos scripts tão próximo do fechamento de BODY quanto possível é que os browsers não fazem download de nenhum outro arquivo enquanto fazem o download de um script javascript, independente se é do mesmo servidor ou não.
Eu até achava que os scripts não poderiam ser colocados dentro do BODY, mas, depois que li essa regra, fiz uma pesquisa e constatei que a especificação do HTML não tem nenhuma contra-indicação quanto a isso.
Regra 7: Evite expressões CSS
É possível declarar expressões em CSS através do método expression. Uma expressão CSS utiliza javascript para calcular algum valor que será utilizado como valor de uma propriedade. Um exemplo de expressão CSS:
Além das expressões CSS só funcionarem no Internet Explorer, também há outro problema envolvido: diferentemente do que se possa imaginar, as expressões não são calculadas apenas ao carregar da página ou quando se redimensiona a janela. Elas também são calculadas a cada movimento do mouse sobre a página e quando movemos a barra de rolagem. Se a cada movimento do mouse sobre a tela geramos um cálculo dessa expressão, o movimento horizontal retilíneo de um extremo ao outro de uma página com resolução de 800 x 600 gera 800 cálculos!!!
Se realmente for necessário utilizar expressões CSS, prefira colocar essa expressão no arquivo javascript e setar a propriedade CSS através do Javascript. A vantagem é que você controlará os eventos que manipularão esse cálculo.
Regra 8: Utilize CSS e Javascript em arquivos externos
Em algumas regras anteriores falamos sobre a gerência de arquivos externos pelo HTTP. Aparentemente, há uma recomendação para que os códigos javascript e CSS sejam colocados no mesmo arquivo do código HTML, para diminuir o número de requisições HTTP. Mas não é bem assim!!
Colocar o javascript e CSS em arquivos separados, além de facilitar o reuso e manutenção desses arquivos, possibilitam que o navegador mantenha esses arquivos em cache.
Por outro lado, o javascript e CSS colocados "inline" no HTML não podem ser colocados em cache e têm que ser carregados a cada requisição. Outro fator contrário ao "inline" é que aumentam o tamanho do arquivo HTML e, por conseqüência, o tempo de carregamento desses arquivos.
Por outro lado (quantos lados, hein!), páginas que tem um estilo "único" dentre as outras páginas e normalmente são acessadas apenas uma vez por sessão devem ter seus javascript e CSS "inline", desde que não sejam muito grandes.
Regra 9: Reduza as pesquisas DNS
O DNS mapeia hostnames em endereços IPs para que possam ser feitas as conexões HTTP, assim como uma agenda telefônica mapeia nomes em números telefônicos.
Quando você digita www.tmferreira.com.br/blog/ no seu browser, antes de qualquer coisa, o seu browser solicita ao DNS o IP de www.tmferreira.com.br.
O cache de DNS em sistemas operacionais ou browsers expira rapidamente. Assim, é recomendado que não sejam utilizados muitos hostnames para um website, para que seja reduzido o tempo em pesquisas DNS.
Se você, assim como eu, tem um e-mail do BOL, já deve ter percebido que eles utilizam muitos hostnames. Isso melhora o tempo de carregamento das páginas com os downloads simultâneos, mas aumenta o número de pesquisas DNS.
Essa também é uma das regras que havia mencionado que não se aplicam a grande maioria dos sites, que tem o mesmo hostname para a aplicação toda.
Regra 10: Reduza os Javascripts
Essa regra preconiza que os arquivos javascript em produção devem ser reduzidos. A redução consiste em remover espaços, tabulações, comentários, etc., ou seja, tudo o que não é necessário para o funcionamento do código e que aumentam o tamanho dos arquivos.
Essa técnica é muito utilizada em scripts e frameworks distribuídos na internet. Essas distribuições normalmente são chamadas de packs.
A redução de scripts não tem efeitos colaterais e é indicada sempre que o arquivo já está em produção. Durante o desenvolvimento, a redução dificulta a alteração do código e remoção de bugs.
Regra 11: Evite redirecionamentos
Os redirecionamentos acontecem pelos mais diversos motivos. A aplicação que mais vejo acontece em fóruns. Após você fazer um post, é mostrada uma mensagem (de sucesso ou erro) e depois há o redirecionamento para outra página.
Obviamente que isso deixa aborrecido os usuários que estão acessando de uma conexão lenta.
No iMasters, retiramos o redirecionamento para que a experiência do usuário seja melhor.
Mas há ocasiões em que não dá para escapar do redirecionamento. No meu blog, houve mudança de domínio. Como fazer com que os links do domínio antigo continuassem íntegros? Só com redirecionamento mesmo. Mas há formas e formas de fazer um redirecionamento. A mais rápida e recomendada é diretamente através de um cabeçalho HTTP com resposta 301 ou 302 (no blog foi feito assim). Uma forma de redirecionamento que é mais lenta é através da tag meta refresh.
O importante é ter bom senso e utilizar os redirecionamentos onde é extritamente necessário.
Regra 12: Remova scripts duplicados
Essa regra diz que não devemos fazer inclusões duplicadas (ou triplicadas, ...) de scripts.
Eu não considero isso como uma regra pois não faz o menor sentido em incluir um mesmo script duas ou mais vezes na mesma página. Para mim, isso é um erro e nem precisaria de regra para que os desenvolvedores não o cometam.
Regra 13: Configure ETags
ETags é o acrônimo para Entity Tags. Isto é um mecanismo que servidores WEB e browsers usam para determinar se o arquivo do servidor é o mesmo que está no cache do browser.
O valor da ETag é gerado dependendo das configurações do servidor e de acordo com as características atuais do arquivo.
Essa configuração faz com que o Apache calcule um hash do arquivo baseado na data e hora da sua última modificação. O browser armazena essa ETag em cache. Se eu modificar o arquivo e salvá-lo, a data e hora da última modificação será alterada e, com isso, os valores de ETag entre servidor e browser ficarão diferentes, fazendo com que o arquivo seja recarregado.
A configuração de ETags torna desnecessário o uso de versão no nome dos arquivos de imagens, CSS, Javascript, etc.
Conclusão
Nesse artigo, vimos que o YSlow pode nos dar o caminho das pedras para diminuir o tempo de carregamento das páginas e melhorar a experiência dos visitantes.
Eu não encaro essas regras literalmente. Encaro-as como boas práticas que devem ser seguidas com bom senso e com análise caso a caso. Penso que a nota C é uma ótima nota para a grande maioria dos sites.
Thiago Ferreira
Assinar:
Postagens (Atom)
