Web-Site Front-End Analysis Project #2

Transcrição

1 Web-Site Front-End Analysis Project #2 Applications for the Internet 2008/2009 Author: Rui Gaspar:

2 Índice 2 Índice 1 Introdução Escolha dos Web-Sites Regras Rule 1 - Reduzir o número de HTTP Requests Rule 2 Usar CDN s (Content Delivery Network) Rule 3 - Adicionar Expires Header Rule 4 Utilize Gzip Rule 5 - Colocar Stylesheets no topo da página Rule 6 Colocar os Scripts no fim da página Rule 7 Evitar expressões em CSS Rule 8 - Colocar JavaScript e CSS no código HTML Rule 9 Reduzir os acessos ao DNS Rule 10 Minimizar o JavaScript Rule 11 Evitar Redireccionamentos Rule 12 Remover Scripts Duplicados Rule 13 - Configure ETags Ferramentas utilizadas IBM Page Detailer YSlow Análise aos WebSites ZeroZero.pt Avaliação YSlow Análise Regra a Regra Comentário Final Publico.pt Avaliação YSlow Análise Regra a Regra Comentário Final API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

3 Índice Cm-Condeixa.pt Avaliação YSlow Análise Regra a Regra Comentário Final Hi5.com Avaliação YSlow Análise Regra a Regra Comentário Final Uefa.com Avaliação YSlow Análise Regra a Regra Comentário Final Conclusões Planeamento Anexos Page Detailer Zerozero Page Detailer Publico Page Detailer Cm-Condeixa Page Detailer Hi Page Detailer Uefa YSlow Zerozero YSlow Publico YSlow Cm-Condeixa YSlow Hi YSlow Uefa API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

4 Introdução 4 Índice de figuras Figura 1 Estatísticas dos tipos de ficheiros do site 14 Figura 2 - Botões de topo do site 15 Figura 3 Estatísticas dos tipos de ficheiros do site 18 Figura 4 DNS Lookup com Redirect do site publico.pt para publico.clix.pt Figura 5 Estatísticas dos tipos de ficheiros do site 23 Figura 6 Atraso introduzido pelo JavaScript Figura 7 Estatísticas dos tipos de ficheiros do site 28 Figura 8 Tempo de carregamento dos JavaScripts no Hi5.com Figura 9 Estatísticas dos tipos de ficheiros do site 32 API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

5 Introdução 5 1 Introdução Com o crescente volume de utilização da internet e da expansão dos sites, um dos factores que muitas vezes dita o sucesso ou insucesso de um website é o seu desempenho. Um utilizador não está para esperar 10 segundos que um site abra sem lhe dar algum tipo de feedback. Por este motivo é interessante analisar e avaliar como são feitos alguns websites relativamente às boas políticas de programação, design e organização das componentes. Para esta análise seguimos as regras que Steve Souders aconselha para a criação de websites. Utilizamos também duas ferramentas para ajudar a avaliar estes pontos e fizemos uma descrição e comentário aos 5 websites escolhidos. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

6 Escolha dos Web-Sites 6 2 Escolha dos Web-Sites Para a escolha dos websites, escolhemos de entre os 5, 3 portugueses, dos quais um deles mais desconhecido e os restantes internacionais mais conhecidos e populares API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

7 Escolha dos Web-Sites API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

8 Escolha dos Web-Sites API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

9 Regras 9 3 Regras 3.1 Rule 1 - Reduzir o número de HTTP Requests Quanto menor for o numero de requests necessários para descarregar os componentes de uma página maior o desempenho da mesma. Uma das técnicas consiste na junção dos vários ficheiros JavaScript ou StyleSheet em menos ficheiros. Outra técnica é em vez de utilizar várias imagens por exemplo vários icons para vários botões, usar apenas uma imagem e usar a técnica de Image Map para definir a zona de selecção do botão. 3.2 Rule 2 Usar CDN s (Content Delivery Network) Consiste em usar vários servidores mais próximos do cliente com o conteúdo estático e principalmente de maiores dimensões, com o objectivo de libertar o servidor principal de trabalho repetitivo e pesado ficando liberto para atender novos clientes. Este processo tem que ser totalmente transparente para o cliente final. 3.3 Rule 3 - Adicionar Expires Header Como os browsers podem fazer cache de dados, podemos colocar nas páginas tags que indicam durante quanto tempo aquele conteúdo é valido. Assim, o cliente deixa de ter necessidade de pedir ao servidor o mesmo conteúdo sempre que faz um refresh ao site ou enquanto navega pelo site e existem componentes em comum entre as diferentes páginas. 3.4 Rule 4 Utilize Gzip Quando uma página contém muitos elementos (imagens, css, etc.) pode-se comprimir todo este conteúdo e enviar para o cliente com muito menos dimensão. Actualmente a maioria dos browsers já suportam esta funcionalidade. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

10 Regras Rule 5 - Colocar Stylesheets no topo da página Colocar os Stylesheets no topo da página permite ao utilizador conseguir visualizar pelo menos a estrutura do site, enquanto este é descarregado. O que proporciona ao utilizador um feedback que muitas vezes pode ditar o sucesso do site. 3.6 Rule 6 Colocar os Scripts no fim da página Ao contrário dos CSS, os scripts devem ser colocados no final da página. Ao colocar no final da página, estes serão os últimos elementos a serem carregados, e vão permitir que o conteúdo do site seja descarregado em primeiro lugar. Se algum script interferir com o conteúdo do site enquanto este está a ser descarregado ou que o programador pretenda que um certo script seja logo disponibilizado para o utilizador, então deve-o colocar na tag <HEAD>. 3.7 Rule 7 Evitar expressões em CSS O principal problema de usar expressões em CSS é o facto de na maioria dos casos estas expressões serem avaliadas mais vezes do que necessário. Por exemplo: Quando o CSS avalia determinada condição desnecessariamente sempre que o rato se move. Quando se define uma cor de fundo dinâmica que é alterada todos os dias. Assim, esta verificação tem que ser feita constantemente, quando apenas bastava um script em php, jsp, etc. para resolver este problema. 3.8 Rule 8 - Colocar JavaScript e CSS no código HTML Ao colocar os CSS e JavaScripts no código HTML, faz com que não seja necessário fazer mais requests para os descarregar. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

11 Regras 11 O ponto contra desta regra, é o facto de não ser possível fazer caching dos ficheiros. Se num site a sua utilização for maioritariamente na home page apenas com um acesso, a colocação dos JavaScript e CSS embutido no HTML terá vantagem, uma vez que são necessários menos requests. Por outro lado, se os utilizadores usarem várias páginas do site, é aconselhado o uso dos JavaScripts e CSS em ficheiros á parte, para facilitar o processo de caching. Na primeira visita ao site, o utilizador poderá ter que fazer mais requests, mas depois deixará de ter que fazer download dos ficheiros JavaScript ou CSS uma vez que ficam em cache, 3.9 Rule 9 Reduzir os acessos ao DNS A redução de diferentes endereços no site, reduz o número de acesso ao servidor de DNS. Por exemplo, se tem referências para objectos noutros sites, é preferível incorpora-los no próprio site. Com este processo reduz o número de acessos ao servidor de DNS para resolver o endereço ip dos objectos externos Rule 10 Minimizar o JavaScript Uma boa programação, implica um código bem estruturado. Mas quando se publica um site, os caracteres de espaço e de tabulações usados para estruturar o código, ocupam espaço. Um bom método é limpar o JavaScript desses caracteres desnecessários para a publicação, diminuindo visivelmente o tamanho dos ficheiros e por consequente o aumento da velocidade do site Rule 11 Evitar Redireccionamentos Evitar o redireccionamento entre páginas aumenta o desempenho do site e retira a sensação ao utilizador que está a ser mandado de uma página para a outra. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

12 Regras Rule 12 Remover Scripts Duplicados Durante o desenvolvimento de um site, é muito comum existirem vários intervenientes. Com esta situação também se torna comum existirem Scripts com código duplicado, o que por razões óbvias, diminui o desempenho do site Rule 13 - Configure ETags As ETags são Strings que identificam especificamente um determinado componente univocamente. É usado para verificar se um determinado componente em cache corresponde ao componente existente no servidor. O uso de ETags em sites que não usem por exemplo vários clusters é uma boa opção, agora, se a infra-estrutura do site possuir vários clusters, é conveniente não existir ETags, uma vez que se existir informação replicada, em cada cluster vai existir uma ETag diferente para o mesmo ficheiro. Por esse motivo é preferível que em sistemas com vários clusters que não se utilizem ETags. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

13 Ferramentas utilizadas 13 4 Ferramentas utilizadas 4.1 IBM Page Detailer Esta ferramenta permite visualizar todos os componentes que uma página possui e os seus detalhes como o seu tempo de download, tamanho, header, bem como visualizar o progresso de download de todos os componentes em árvore. 4.2 YSlow O YSlow é um plugin que corre no Firefox por cima da ferramenta Firebug. Este plugin simula e avalia segundo as regras de Steve Souders das boas práticas de desenvolvimento de um website. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

14 Análise aos WebSites 14 5 Análise aos WebSites 5.1 ZeroZero.pt Avaliação YSlow Regra Total Avaliação (A-F) F F F F C C A - F F A A F F Tabela 1 - Avaliação do site segundo Steve Saunders através do YSlow Figura 1 Estatísticas dos tipos de ficheiros do site Análise Regra a Regra Regra 1 A primeira regra de Steve Souders neste site é completamente esquecida. O site tem 12 ficheiros JavaScript, 17 ficheiros StyleSheets e 29 imagens de background que na maioria dos API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

15 Análise aos WebSites 15 casos são imagens brancas com uma linha desenhada, que podia ser facilmente substituída por um elemento style num css. Quanto aos ficheiros JavaScript e StyleSheets, estes poderiam ser agrupas em 2 ficheiros ou a pouco mais ficheiros, o que iria diminuir o número de requests ao site. Outra falha neste ponto é o grande abuso da utilização de pequenos ícones como por exemplo no menu de topo como mostra a figura seguinte que poderiam ser facilmente substituídos por uma ou duas imagens usando Image Maps ao invés de 9 imagens pequenas. Figura 2 - Botões de topo do site Regra 2 Não há qualquer uso de CDN s para aproximar (fisicamente) o conteúdo estático do cliente evitando ter que ir sempre ao servidor central Regra 3 Apesar de a maior parte dos ficheiros possuírem a data em que expiram (normalmente com a duração de 1 mês), existem muito outros que não tem qualquer indicação dessa data. Acontece isso com muitas das imagens das bandeiras dos países e dos clubes. Problema este que poderia ser facilmente resolvido com a introdução da data de expiração nesses elementos Regra 4 Apesar de a classificação dada pelo YSlow a esta regra ser a pior (F), temos que ter em conta que os componentes que não tem activa a compressão são componentes de publicidade e alguns que até são externos ao zerozero, como por exemplo os elementos vindos de No entanto, também existem componentes de publicidade próprios que não tem a compressão activa. Por esse motivo uma classificação de C ou D nesta regra seria o mais adequado. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

16 Análise aos WebSites Regra 5 Esta regra, a semelhança da regra anterior, deveria ter uma cotação diferente. O YSlow atribui-lhe uma classificação de C, uma vez que encontrou 2 ficheiros css fora do header da página. Mas mais uma vez estes css pertencem ao sistema de publicidade, mais propriamente a Por esse motivo, considerando apenas o site zerozero, este deveria ter levado nota A Regra 6 Relativamente aos JavaScripts presentes, a maior parte deles são incluídos no Header da página. Apesar de alguns precisarem de ser logo incluídos, como é o caso do prototype, existem outros que poderiam ser deslocados para o final da página, como é o caso do script functions.js que apenas serve para alterar a imagem de um botão quando se passa com o rato por cima. CSS Regra 7 Quanto às expressões CSS nada a apontar, não existem estas expressões nos ficheiros Regra 8 Não existe código JavaScript ou CSS dentro do HTML da página Regra 9 Esta página tem um inúmero número de referências para sites externos o que faz com que seja necessário existir vários DNS lookups. A maior parte destas ligações a sites externos dizem respeito a sites de publicidade (pub.betclick.com, googleads.g.doubleclick.net, etc.) e a sites de vídeos (videos.sapo.pt, youtube.com). Por esse motivo será muito difícil manter os mesmos serviços não recorrendo a estas ligações. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

17 Análise aos WebSites Regra 10 Um outro erro que poderia ser resolvido facilmente e aumentando o desempenho do site era a minimização dos JavaScripts. Existem 8 dos 12 JavaScripts que poderiam ser facilmente minimizados e assim diminuir bastante o seu tamanho. outras Regra 11 Nada a apontar neste ponto, não existem redireccionamentos de umas páginas para as Regra 12 Também nada a apontar neste ponto, não existem funções duplicadas dentro dos ficheiros JavaScript Regra 13 Mais um ponto a ser corrigido é a configuração de ETagas dos componentes do site. A esmagadora maioria dos componentes do zerozero possuem as ETags configuradas, se o servidor do site possuir clusters, convêm retirar todas as ETags, caso contrário, convêm adicionar ETags aos componentes que não possuem para melhorar a eficiência dos sistemas de caching Comentário Final Este site contém vários pontos que segundo as regras de Steve Saunders estão desajustados para um site ter um bom desempenho. Alguns desses pontos poderiam ser facilmente resolvidos enquanto outros não pertencendo directamente ao zerozero, a sua resolução passaria para além do site. Em geral o site tem um grande número de erros que mereciam ser resolvidos. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

18 Análise aos WebSites Publico.pt Avaliação YSlow Regra Total Avaliação (A-F) F F F F B C A - F F A C F F Tabela 2 - Avaliação do site segundo Steve Saunders através do YSlow Figura 3 Estatísticas dos tipos de ficheiros do site Análise Regra a Regra Regra 1 Apesar de não haver neste site nenhuma imagem de backgroud, o que é um ponto positivo, existe um elevado número de JavaScripts. Mais propriamente 32 JavaScripts e 5 StyleSheets. A junção, principalmente dos ficheiros JavaScripts em menos ficheiros poderia diminuir consideravelmente o número de HTTP Requests. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

19 Análise aos WebSites Regra 2 Também este site não faz uso de qualquer CDN para aproximar o conteúdo estático do cliente final. Uma razão para o não uso desta técnica neste site poderá ser o público-alvo do site. Uma vez sendo um site de notícias portuguesas, a maioria dos utilizadores estarão em território nacional, o que pode levar á não adopção desta técnica Regra 3 A maior parte dos componentes não possuem data de expiração. Apenas 7 possuem um tempo de expiração de 24 horas (86400 segundos). Poderiam ser adicionadas datas aos componentes em falta a fim de melhorar o desempenho do sistema de cache, não apenas dos browsers, mas de todos os sistemas que fazem caching até ao cliente final Regra 4 Mais um ponto que não obedece totalmente as regras de Steve Saunders. Apesar de existirem vários componentes com o suporte para compressão activo, muitos outros não permitem esta compreensão, e uma vez sendo na sua maioria ficheiros JavaScript e css, poderiam muito bem ter a opção de compressão activa sem perca de qualidade como é o caso das imagens que podem perder qualidade quando se comprimem Regra 5 Á semelhança do que acontece com o site anterior, este ponto também merecia nota máxima, uma vez que apenas um css não se encontra no header do HTML e é um css que pertence ao sistema de publicidade que é totalmente independente do publico.pt Regra 6 Neste ponto existem várias falhas. Existem vários JavaScripts que são colocados no inicio que poderia ser colocados no final do documento HTML, com a excepção do ficheiro anylink.js que possui elementos que permitem o utilizador interagir com o menu de topo, e API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

20 Análise aos WebSites 20 colocando este ficheiro no final, iria impedir a utilização desse menu até que este ficheiro fosse carregado Regra 7 Quanto às expressões CSS segundo as regras de Steve Souders nada a apontar, não existem estas expressões nos ficheiros CSS Regra 8 Existe código Stylesheet dentro do código HTML da página que poderia ser colocado junto dos restantes ficheiros css a fim de possibilitar o uso de cache. <style id="ctl00_mystyle" type="text/css"> body { background-color: #FFFFFF; height: 100%; margin: 0px; }.firstcontainer { text-align:center; width:auto; height:100% }.secondcontainer { width:994px; height:100%; margin:auto; text-align:left; }.barraesq { width:680px; height:100%; background-color:#ffffff; border-right:1px dotted #CCCCCC; float: left; left: 0; padding:0; }.barradrt { --width:310px; height:100%; background-color:#ffffff; }.barratotal { width:auto; height:100%; background-color:#ffffff; } </style> API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

21 Análise aos WebSites Regra 9 Existe um grande número de DNS lookups no site mais propriamente 14. Como cada descoberta do ip através do servidor de DNS consome algum tempo, quando temos 14 chamadas a esse servidor, temos um grande período de inactividade que poderia ser aproveitado para processar informação útil para o utilizador Regra 10 Existem vários ficheiros JavaScript que não estão minimizados. Estes ficheiros apesar de muitos pertencerem aos sistemas de publicidade, muitos deles também são da responsabilidade do publico.pt. Estes últimos poderiam passar por um processo de minimização para assim diminuir o seu tamanho e aumentar a sua velocidade de download Regra 11 Neste ponto existe um redireccionamento que a ferramenta YSlow não conseguiu avaliar. O redireccionamento é feito de para Não sabemos até que ponto este redireccionamento poderia não ser feito, mas considerando o site publico.pt a pagina de entrada, ao invés do site publico.clix.pt vemos que só para fazer o redireccionamento de uma página para a outra temos um período de inactividade de informação útil para o utilizador de cerca de 0.2 segundos. Tempo este que era utilizado a fazer o lookup do DNS e do redirect para o novo endereço como mostra a figura seguinte. Figura 4 DNS Lookup com Redirect do site publico.pt para publico.clix.pt API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

22 Análise aos WebSites Regra 12 Existem 2 ficheiros que contem 4 componentes JavaScript redundantes. Estas redundâncias poderiam facilmente ser corrigidas a fim de diminuir o tamanho do ficheiro e assim conseguir um melhor desempenho Regra 13 A maioria dos componentes não possui ETagas configuradas. Mais uma vez o conselho é semelhante ao do site anterior. Se o site usar um cluster convêm retirar as Etags, caso contrario adicionar ETags aos restantes componentes Comentário Final Como sendo um dos maiores sites nacionais de notícias, existem muitos pontos que mereciam ser melhorados. Alguns, como o uso de CDN s talvez não seja possível, mas existem outros pontos de fácil resolução e que aumentaria significativamente o desempenho do site. Como por exemplo o uso de mecanismos para cache-control, de limpeza e agrupamento de código. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

23 Análise aos WebSites Cm-Condeixa.pt Avaliação YSlow Regra Total Avaliação (A-F) C F F F C A A - A F A B F F Tabela 3 - Avaliação do site segundo Steve Saunders através do YSlow Figura 5 Estatísticas dos tipos de ficheiros do site Análise Regra a Regra Regra 1 Apesar de comparando com os sites analisados anteriormente ter um número muito inferior de ficheiros JavaScript e StyleSheets, anda contem um número elevado de ficheiros que poderiam ser agrupados. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

24 Análise aos WebSites Regra 2 Mais uma vez, não existe qualquer uso de tecnologias CDN s. Comparativamente a outros sites nacionais, este ainda tem menos razões para usar uma CDN. Não se justifica o uso destas infra-estruturas para u site que tem como público-alvo os habitantes de uma região Regra 3 Não existem data de expiração em qualquer ficheiro do site da câmara municipal de Condeixa. Apenas um, relativo à gestão dos acessos ao site, fornecido pelo Google é que possui esta característica. Apesar de este ponto não ir de encontro a linha seguida por Steve Saunders, poderá ser uma boa opção. Não colocar data ou um tempo para expiração dos componentes e colocar uma ETag que identifique unicamente cada componente pode melhorar o desempenho do site quando não se tem uma infra-estrutura com clusters Regra 4 Existe alguns ficheiros que não suportam compressão que deveria ser alterados de modo a permitirem esta compressão, uma vez que alguns deles são ficheiros de grandes dimensões, como alguns HTML s que ocupam 38 e 19 Kb cada, bem como alguns JavaScripts e CSS que ocupam 4 e 5 Kb. Activando a compressão nestes ficheiros que contem texto, conseguia-se facilmente passar de 38Kb para 5Kb por exemplo no ficheiro HTML inicial Regra 5 Um dos possíveis erros desta página é usar IFrames o que implica cada IFrame ter que ter o seu próprio JavaScript e StyleSheet. Por esse motivo existem ficheiros css fora do HEAD do HTML da página inicial. Esta situação poderia ser resolvida, removendo as IFrames e introduzindo o código nos ficheiros HTML gerais. Mas como tudo tem contras, o contra desta operação é que impossibilita a hipótese de poder fazer cache destes componentes, uma vez que os IFrames são usados nos menus laterais e barra de topo que durante todo o site nunca se alteram. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

25 Análise aos WebSites Regra 6 Neste ponto o YSlow dá nota máxima ao site, porque não tem qualquer java script no inicio do site. Mas com o uso dos IFrames como no visto no ponto anterior o JavaScript e os StyleSheet tem que ser carregados dentro do IFrame. A figura seguinte mostra o atraso que o ficheiro JavaScript introduz em todo o desempenho do site. Se este JavaScript estivesse mesmo no final do HTML já não teria este atraso que se torna visível para o utilizador. Mas como foi descrito no ponto anterior, a solução passaria por remover as IFrames com todos os pontos a favor e contra que esta acção acarreta. JavaScript Atraso Regra 7 Figura 6 Atraso introduzido pelo JavaScript. Mais uma vez não existem expressões CSS, por esse motivo nada a apontar Regra 8 Este site também possui um pequeno código CSS dentro do HTML que poderia ser colocado num dos ficheiros CSS e possibilitar o seu caching. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

26 Análise aos WebSites 26 <style type="text/css"> <!-- body { margin-left: 0px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; background-color: #FFFFFF; background-image: url(img/fundo03.jpg); background-position:center; background-position:top; background-attachment:fixed; }.style1 { font-family: Verdana, Arial, Helvetica, sans-serif; color: #515858; font-size: 10px; }.style7 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10px; color: #FFFFFF; } --> </style> Regra 9 Não existe qualquer DNS lookup, por esse motivo nada a apontar Regra 10 Existem dois ficheiros JavaScript internos ao site da Câmara Municipal de Condeixa que não estão minimizados e um externo ao site. Como este ultimo não de pode fazer nada, já quanto aos outros podem ser facilmente minimizados e aumentar assim o desempenho do site. outras Regra 11 Nada a apontar neste ponto, não existem redireccionamentos de umas páginas para as API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

27 Análise aos WebSites Regra 12 Existem duas componentes JavaScripts redundantes dentro dos ficheiros js. Estas redundâncias poderiam ser removidas Regra 13 A esmagadora maioria dos componentes possui as ETags bem configuradas. Se o site apenas possuir um cluster (que é o mais provável), a opção está correcta em adoptar esta técnica para facilitar o processo de caching Comentário Final Um site que possui alguns pontos muito bem estruturados do ponto de vista do desempenho, mas que tem algumas carências principalmente no que diz respeito á compressão que não esta activa para alguns componentes e aos JavaScripts que não estão minimizados e tem algum componentes redundantes que poderiam ser corrigidos. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

28 Análise aos WebSites Hi5.com Avaliação YSlow Regra Total Avaliação (A-F) D F C C A C B - B A A B F D Tabela 4 - Avaliação do site segundo Steve Saunders através do YSlow Análise Regra a Regra Figura 7 Estatísticas dos tipos de ficheiros do site Regra 1 Apesar de não conter um grande número de ficheiros JavaScript, StyleSheet e Imagens de Fundo CSS, possui ainda um grande número de ficheiros que poderiam ser reduzidos, como o caso dos JavaScript. Como existem 7 javascripts e a maior parte da responsabilidade do site, poderiam ser agrupados em menos a fim de diminuir o número de requests. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

29 Análise aos WebSites Regra 2 Como o YSlow apenas conhece por defeito as CDN s do Yahoo, não podemos avaliar com certeza se o Hi5 usa ou não usa CDN s para aproximar as componentes estáticas dos clientes Regra 3 Neste ponto, o YSlow avalia o hi5 com nota C uma vez que encontrou 2 componentes que não possuíam uma data de expiração e um deles até uma data inválida tinha. Mas estes dois componentes não pertencem ao Hi5, mas sim ao sistema de publicidade do sapo. Por esse motivo a avaliação do site Hi5 isoladamente deveria ser A Regra 4 Mais uma vez existem componentes de publicidade do sapo que foram avaliados neste ponto pelo YSlow que não deveriam ser avaliados. No entanto o HTML da página inicial do hi5 não suporta compressão e como este HTML tem um tamanho de 56Kb, justificava-se o uso de compressão num ficheiro de texto deste tamanho Regra 5 Os CSS do hi5 estão colocados no inicio da página, por isso nada a apontar Regra 6 Já neste ponto existem JavaScripts que estão locados no HEAD do HTML que poderiam ser movidos mais para baixo e assim aumentar a velocidade com que o utilizador começasse a visualizar o site. Podemos ver na imagem seguinte que só o carregamento de 4 JavaScripts demora cerca de 2.9 segundos (1/4 do tempo total do site) em que o utilizador não vê nada. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

30 Análise aos WebSites Segundos Tempo de carregamento dos JavaScripts Figura 8 Tempo de carregamento dos JavaScripts no Hi5.com Regra 7 Existe uma expressão CSS que faz com que a avaliação desta regra seja B. Esta expressão tem o objectivo de quando é criado um overlay JavaScript, a altura do overlay não ultrapasse a altura da página para evitar possíveis escalonamentos das páginas e que os conteúdos fiquem deformados quando de abre esse overlay. Esta funcionalidade tem que ser feita ao nível do css e processada sempre que é criado um overlay. Como esta expressão não é constantemente avaliada, penso que não consistirá num problema para a máquina do cliente Regra 8 Existe um grande número de JavaScript e CSS embutido no HTML da página que impossibilita o seu processo de caching. Estes scripts deveriam ser colocados dentro de um ficheiro. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

31 Análise aos WebSites Regra 9 Existem 8 DNS lookups, dos quais 3 são referentes a subpáginas do hi5 onde o tempo de procura do ip através do servidor de DNS pode torna-se visível para o cliente final. Uma redução destes endereços poderia aumentar a velocidade do site Regra 10 Os JavaScripts do Hi5.com estão todos minimizados, nada a apontar Regra 11 Também nada a apontar neste ponto, não existem redireccionamentos de umas páginas para as outras. resolvido Regra 12 Existe um ficheiro JavaScript que contém um componente duplicado que poderia ser Regra 13 Praticamente todos os componentes possuem ETags. A eliminação destas ETgas se for usada uma CDN (que é muito provável, visto a popularidade do site) poderá melhorar o desempenho do sistema de caching Comentário Final Tendo em conta a popularidade do site existem vários pontos que mereciam ser revistos. Os pontos principais a corrigir serão o grande número de ficheiros JavaScript e css que poderia ser agrupados e a colocação dos JavaScripts fora do código HTML e no final do as suas chamadas no final do mesmo. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

32 Análise aos WebSites Uefa.com Avaliação YSlow Regra Total Avaliação (A-F) F F F A A B A - B C A A F F Tabela 5 - Avaliação do site segundo Steve Saunders através do YSlow Figura 9 Estatísticas dos tipos de ficheiros do site Análise Regra a Regra Regra 1 A primeira regra de Steve Sounders diz que devemos reduzir ao máximo o número de requests, e neste ponto o site da UEFA mostra preocupação relativamente aos ficheiros JavaScript e Stylesheet. Já não acontece o mesmo com as imagens em css, possuindo 19 imagens. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

33 Análise aos WebSites 33 Analisando o layout do site, consideramos que 19 imagens poderão ser um número excessivo dentro do css, que se destinam a efeitos de layout. Uma solução para este problema poderia passar pela junção de várias imagens numa só e usar as características backgroundimage e background-position dos CSS para definir que sub-imagem se pretende apresentar em cada local Regra 2 Mais uma vez não temos dados relativamente ao uso de CDN s, mas pela dimensão do site e da UEFA, justifica-se o uso de CDN s não apenas pela Europa, mas por todo o mundo onde o futebol é o desporto rei Regra 3 Cerca de metade dos ficheiros do site não possuem qualquer tipo de data de expiração, quer o uso de Expires ou Max-Age. Situação que poderia ser facilmente resolvida com a adição de um destes elementos nos componentes em falta Regra 4 Relativamente ao uso de técnicas de compressão como Gzip nos componentes do site é bem conseguida. Todos os ficheiros que não são imagens permitem o uso de compressão como ficheiros JavaScript, StyleSheets e HTML. As imagens, não permitem compressão para não perderem qualidade com este tipo de mecanismos Regra 5 Os CSS são os primeiros elementos a serem carregados, por isso nada a apontar Regra 6 Relativamente aos JavaScripts, dois deles são descarregados logo no inicio da página. Um deles é o prototype que tem que ser iniciado logo, para o utilizador poder usar os menus e API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

34 Análise aos WebSites 34 as ferramentas que este disponibiliza, o outro é um script que permite o utilizar ver vídeos e áudio num popup. Este ultimo também não convêm ser colocado no final, uma vez que colocado no inicio permite que o cliente clique nos vídeos e nas componentes de áudio enquanto o site ainda esta a ser carregado Regra 7 Não existem expressões CSS, por esse motivo nada a apontar Regra 8 Há semelhança do Hi5, este site também possui uma grande quantidade de JavaScript e CSS embutidos no HTML que deveriam ser retirados Regra 9 Existem alguns DNS lookups. A maioria deles referentes a subdomínios do site da UEFA que poderiam ser revistos de forma a juntar tudo no mesmo domínio, a fim de evitar DNS lookups Regra 10 Existem 2 ficheiros não minimizados referentes ao site da UEFA e um relativo ao sistema de publicidade. Os JavaScripts referentes ao site da UEFA deveriam ser minimizados para assim diminuir o seu tamanho e aumentar a velocidade de transferência Regra 11 Não existe redireccionamentos entre páginas, por esse motivo, nada a apontar. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

35 Análise aos WebSites Regra 12 Também nada a apontar neste ponto, não existem funções duplicadas dentro dos ficheiros JavaScript Regra 13 Praticamente todos os componentes possuem ETags. Se o servidor do site usar um cluster, esta utilização não é recomendada Comentário Final O desempenho do site da UEFA tem vários problemas a este nível. Os de maior relevo dizem respeito à falta de adição do tempo de expiração de cada componente bem como a configuração das ETags. Tem também outros problemas de maior relevância, mas que também poderiam aumentar o desempenho do site, como a colocação dos JavaScripts no final do documento HTML e a redução dos DNS lookups. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

36 Conclusões 36 6 Conclusões Com esta análise, verificamos que existem vários websites que não apostam em políticas desempenho. Testamos websites dos mais populares da internet e até nesses verificamos que simples métodos que aumentariam em muito o desempenho do site não são adoptadas. Relativamente aos sites nacionais, estas políticas são ainda mais escacas. Já nos sites internacionais que testamos, verificamos que algumas simples operações de optimização são feitas, como por exemplo a minimização dos JavaScripts mas não de uma forma consistente em todos os ficheiros, outras políticas mais complexas muitas vezes são postas de parte. Outro ponto que verificamos que algumas vezes os responsáveis pelos sites até se preocupam com o desempenho, mas quase sempre os sistemas de publicidade mais comuns na internet não utilizavam sistemas de optimização do desempenho, colocando em risco o trabalho dos responsáveis do próprio website. Por tudo isto, verificamos que existe ainda muito a fazer na área do desempenho dos websites. API - MEI - DEI - UC Quinta-Feira, 9 de Abril de

37 Planeamento 37 7 Planeamento API - MEI - DEI - UC Quinta-Feira, 9 de Abril de