davidson!fellipe!da!silva! keepfast!–!um!ambiente ... · com acesso à web. este trabalho...
TRANSCRIPT
!
! !!
Davidson!Fellipe!da!Silva!
Keepfast!–!Um!ambiente!extensível!dirigido!por!modelos!para!avaliação!de!
desempenho!de!páginas!web!!
Dissertação!de!Mestrado!
Dissertação! apresentada! como! requisito! parcial!
para!obtenção!do!grau!de!Mestre!pelo!Programa!de!
Pós9graduação!em!Informática!do!Departamento!de!
Informática!da!PUC9Rio.!
!Orientador:!Prof.!Daniel!Schwabe!
Rio!de!Janeiro!!
Setembro!de!2015!
!
!!
Davidson!Fellipe!da!Silva!
Keepfast!–!Um!ambiente!extensível!dirigido!por!modelos!para!avaliação!de!
desempenho!de!páginas!web!!
Dissertação! apresentada! como! requisito! parcial!para!obtenção!do!grau!de!Mestre!pelo!Programa!de!Pós9Graduação!em!Informática!do!Departamento!de!Informática! do! Centro! Técnico! Científico! da! PUC9Rio.!Aprovada!pela!Comissão!Examinadora!abaixo!assinada.!!
Prof.!Daniel!Schwabe!Orientador!
Departamento!de!Informática!9!PUC9Rio!
!Prof.!Arndt!Von!Staa!
Departamento!de!Informática!9!PUC9Rio!
!Prof.!Alessandro!F.!Garcia!
Departamento!de!Informática!9!PUC9Rio!!
Prof.!José!Eugenio!Leal!Coordenador!Setorial!do!Centro!!Técnico!Científico!9!PUC9Rio!
!
Rio!de!Janeiro,!03!de!setembro!de!2015!
!
Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.
!
Davidson!Fellipe!da!Silva!
Graduou-se em Engenharia de Computação pela Universidade de Pernambuco em dezembro de 2009, Técnico em eletrônica pelo IFPE, em dezembro de 2007. Tem experiência na área de Ciência da Computação, com ênfase em Desenvolvimento de Software para web. Tem trabalhado em engenharia de sistemas desde 2005, e no atualmente é engenheiro de software sênior na Loadsmart.com, empresa americana da área de logística.
Ficha!Catalográfica!
!!!!!!!!!!!!
!
CDD:!004!
Silva,!Davidson!Fellipe!da!!!!!!!Keepfast!:!Um!ambiente!extensível!dirigido!por!modelos!para!avaliação!de!desempenho!de!páginas!web!/!Davidson!Fellipe!da!SilvaY!orientador:!Daniel!Schwabe.!–!2015.!
!!!!!76!f.!:!il.!Y!30!cm!
!!!!!!!!!!!Dissertação! (mestrado)–Pontifícia! Universidade!Católica!do!Rio!de!Janeiro,!Departamento!de!Informática,!2015.!!!!!!Inclui!bibliografia!
!!!!!!!!!!!!1.!Informática!–!Teses.!!2.!Avaliação!de!desempenho.!3.!Web.!4.!Frameworks.!5.!Modelagem.! I.!Schwabe,!Daniel.!II.! Pontifícia! Universidade! Católica! do! Rio! de! Janeiro.!Departamento!de!Informática.!III.!Título.!!
!
Agradecimentos!
A Deus.
A minha esposa Juliana Malta pelo apoio, amor, compreensão durante esse tempo.
Aos meus pais, que apesar de não terem tido essa oportunidade ofereceram base
para que eu tivesse.
Ao meu orientador Professor Daniel Schwabe, que acreditou na ideia e me
incentivou nessa conclusão até o fim.
Aos amigos da PUC-Rio, Flávio Ribeiro, Franklin Amorim, Daniel Ferreira, Ícaro
Medeiros pelos fins de semana que passamos na Globo.com estudando.
Ao amigo Sidney Lima, que mesmo no final de seu doutorado ajudou na revisão
desse trabalho.
A Globo.com, pelo financiamento e benefícios concedidos para tornar possível
minha participação no mestrado. Em especial ao Rodrigo Veiga pela aprovação na
época.
Aos professores da Comissão examinadora.
!
!
Resumo!
Silva, Davidson Fellipe da; Schwabe, Daniel. Keepfast – Um ambiente extensível dirigido por modelos para avaliação de desempenho de páginas web. Rio de Janeiro, 2015. 76p. Dissertação de Mestrado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Ao longo dos anos, houve um aumento da complexidade no lado do cliente
da arquitetura de aplicações web. Por conseguinte, a adição de uma funcionalidade
ou mudança na implementação de uma existente, pode levar a uma regressão de
desempenho, que deve ser evitada. Este efeito é agravado devido à constante
evolução das tecnologias de implementação e o crescente número de dispositivos
com acesso à Web. Este trabalho apresenta um ambiente de software para avaliação
de desempenho de páginas web dirigido por modelos, focado no lado cliente da
aplicação. Para lidar com a evolução das tecnologias e a variedade de contextos de
avaliação de desempenho, este ambiente pode ser estendido e personalizado
conforme as características mais relevantes que o projetista queira avaliar. Um
estudo de caso é apresentado, mostrando os resultados obtidos em um cenário real,
e o compara com outras abordagens propostas.
PalavrasLchave!Avaliação de desempenho; Web; Frameworks; Modelagem.
!
Abstract!
Silva, Davidson Fellipe da; Schwabe, Daniel (Advisor). Keepfast - A model-driven framework for the evaluation web page performance. Rio de Janeiro, 2015. 76p. MSc. Dissertation – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro
Over the years, there has been an increase in complexity on the client side of
Web application architecture. Consequently, the addition of functionality or change
in the implementations on the client side often leads to a drop in performance, which
should be avoided. This effect is compounded due to the constant evolution of
implementation technologies and the growing number of devices with web
connection. This work presents a Model-driven framework for the assessing web
page performance, in the application client side, allowing for a variety of
performance evaluation contexts. This environment can be extended and
customized to reflect the most important features that the designer wants to
evaluate. A case study is presented, showing the results obtained in a real scenario
compared to other methodologies available.
Keywords!Performance evaluation; Web; Frameworks; Modeling.
!
Sumário!
1! Introdução! 14!
1.1! Objetivos! 16!
1.2! Questões!de!Pesquisa! 17!
1.3! Estrutura!da!dissertação! 17!
2! Fundamentos! 19!
2.1! Aplicações!web!e!o!HTTP! 19!
2.2! Anatomia!de!uma!requisição!HTTP! 21!
2.2.1! Configurações!da!requisição!HTTP! 22!
2.2.2! Estabelecimento!da!comunicação! 22!
2.2.3! Tempo!para!o!envio!do!primeiro!byte! 22!
2.2.4! Carregamento!do!conteúdo! 23!
2.3! Desempenho!no!lado!cliente!da!aplicação! 23!
2.3.1! Comparativo!entre!o!carregamento!no!lado!cliente!e!servidor! 23!
2.3.2! Regra!de!ouro!de!desempenho!de!páginas!web! 25!
2.3.3! Etapas!de!processamento!no!navegador! 25!
2.4! Regras!para!melhorar!o!carregamento!de!páginas!web!no!lado!
cliente! 27!
2.4.1! Evitar!requisições!HTTP!para!recursos!inexistentes! 27!
2.4.2! Concatenação!de!arquivos! 28!
2.4.3! Compressão!do!código!dos!recursos! 28!
2.4.4! Reduzir!o!número!de!nós!de!elementos!HTML! 29!
2.4.5! Redefinição!de!largura!e!altura!nas!imagens! 29!
2.4.6! Número!de!recursos!transferidos!sem!compactação!Gzip! 29!
2.4.7! Número!de!domínios!usados!para!buscar!a!página! 30!
2.4.8! Reduzir!o!número!de!requisições!a!partir!de!um!único!domínio! 30!
2.5! Ferramentas!para!avaliação!de!desempenho! 30!
2.5.1! Phantomas! 31!
2.5.2! WebPageTest! 33!
!
2.5.3! PageSpeed! 35!
2.5.4! YSlow! 36!
2.5.5! Comparação!entre!as!ferramentas! 37!
3! Modelo!para!especificação!de!avaliações!de!desempenho!de!
páginas!web! 39!
3.1! Modelo!para!Regras!e!Sensores! 39!
3.2! Modelo!para!Critérios! 41!
3.3! Definição!de!Perfis! 42!
3.4! Modelo!para!Páginas!e!Servidor! 42!
3.5! Modelo!para!Medição! 43!
4! Visão!geral!da!ferramenta! 45!
4.1! Keepfast!macro9visão!e!premissas! 45!
4.2! Fundamentação!sobre!as!tecnologias!utilizadas!no!Keepfast! 46!
4.2.1! JavaScript! 46!
4.2.2! MongoDB! 47!
4.2.3! Mongoose! 48!
4.3! Visão!conceitual!da!arquitetura! 48!
4.4! O!Framework! 49!
4.5! Perfis!de!avaliação! 50!
4.6! Extensibilidade!da!ferramenta! 51!
4.7! Obtendo!uma!avaliação!de!desempenho!e!armazenando!as!
avaliações! 53!
4.8! Apresentação!do!dashboard! 54!
5! Estudo!de!caso! 56!
5.1! Características!do!projeto!e!da!equipe! 56!
5.2! Características!do!estudo! 57!
5.3! O!processo!baseado!em!planilhas! 57!
5.4! O!processo!de!avaliação!de!desempenho!usando!o!Keepfast! 60!
5.5! Considerações!finais! 62!
6! Conclusões! 63!
6.1! Trabalhos!Futuros! 63!
!
6.2! Contribuições! 64!
7! !Referências!Bibliográficas! 65!
8! Apêndice! 70!
8.1! API!REST! 70!
8.1.1! Interfaces!disponíveis!na!API!REST! 70!
8.1.2! Domínios! 71!
8.1.3! Páginas!de!um!domínio! 71!
8.1.4! Medições!realizadas!por!uma!página! 71!
8.1.5! Medições!de!uma!página!em!um!dado!tempo! 72!
8.1.6! Regras!utilizadas!por!uma!página! 72!
8.2! Schema!das!entidades!no!banco!de!dados! 74!
8.2.1! Schema!da!entidade!domínio!no!banco!de!dados! 74!
8.2.2! Schema!da!entidade!usuário!no!banco!de!dados! 74!
8.2.3! Schema!da!entidade!regra!no!banco!de!dados! 74!
8.2.4! Schema!da!entidade!medição!no!banco!de!dados! 75!
8.2.5! Schema!da!entidade!perfil!no!banco!de!dados! 75!
8.2.6! Lista!com!outras!ferramentas!disponíveis!no!mercado! 75!
!
!
!
Lista!de!Figuras!
Figura!01!–!Páginas!iniciais!dos!1000!maiores!websites.! 14!
Figura!02!–!Requisição!HTTP!no!navegador!Chrome.! 21!
Figura!03!–!Gráfico!que!exibe!o!carregamento!de!uma!página!web.! 24!
Figura!04!–!Processo!de!geração!do!DOM.! 26!
Figura!05!–!Resultado!do!WebPageTest!para!o!http://fellipe.com.! 33!
Figura!06!–!Resultados!do!PageSpeed!para!o!http://fellipe.com.! 35!
Figura!07!–!YSlow!para!o!navegador!Chrome.! 36!
Figura!08!–!Página!Keepfast!disponível!no!GitHub.! 46!
Figura!09!–!Linguagens!mais!utilizadas!no!GitHub!(La,!2015).! 47!
Figura!10!–!Visão!conceitual!da!arquitetura!do!Keepfast.! 49!
Figura!11!–!Visão!do!painel!de!métricas!do!Keepfast.! 55!
Figura!12!–!Avaliação!baseada!em!planilhas.! 59!
!
!
!
Lista!de!Tabelas!
Tabela!1!–!Sensores!utilizados!no!Phantomas.! 32!
Tabela!2!–!Relação!entrar!ferramentas!e!funcionalidades.! 38!
!
!
!
!
Lista!de!Quadros!
Quadro!1!–!Modelo!de!uma!mensagem!do!tipo!requisição!no!HTTP.! 20!
Quadro!2!–!Modelo!de!uma!mensagem!do!tipo!resposta!!HTTP.! 21!
Quadro!3!–!Modelo!de!uma!Regra!no!Keepfast.! 40!
Quadro!4!–!Modelo!de!um!Sensor!no!Keepfast.! 40!
Quadro!5!–!Modelo!de!um!Critério!no!Keepfast.! 41!
Quadro!6!!–!Modelo!de!uma!Página!no!Keepfast.! 42!
Quadro!7!!–!Modelo!de!um!Servidor!no!Keepfast.! 43!
Quadro!8!!–!Modelo!de!um!Servidor!no!Keepfast!no!formato!JSON.! 43!
Quadro!9!!–!Modelo!de!uma!Medição!no!Keepfast.! 44!
Quadro!10!!–!Perfil!mais!simples!possível!no!Keepfast.! 50!
Quadro!11!!–!Valores!de!referências!para!o!sensor!para!extensão!PSI.! 52!
Quadro!12!!–!Interface!entre!o!sensor!e!o!módulo!de!extração.! 53!
Quadro!13!!–!Perfil!da!Loadsmart!para!o!Keepfast.! 61!
!!
!
!
!
Lista!de!Siglas!
API! Application!Programming!Interface!
BSON! Binary!JSON!
CDN! Content!Delivery!Network!
CSS! Cascading!Style!Sheets!
CSSOM! CSS!Object!Model!
DNS! Domain!Name!System!
DOM! Document!Object!Model!
FOUC! Flash!Of!Unstyled!Content!
HTML! Hypertext!Markup!Language!
HTTP! Hypertext!Transfer!Protocol!
HTTPS! HTTP!over!TLS!
IETF! Internet!Engineering!Task!Force!
JSON! JavaScript!Object!Notation+
KB! Kilobytes!
NPM! Node!Package!Manager!
SPA! Single9page!Application!
TCP! Transmission!Control!Protocol!
TLS! Transport!Layer!Security!
URL Uniform!resource!locator
! !
! !
! !
!
!
!
1! !Introdução!
Na época em que as conexões de internet discada predominavam, havia a
necessidade de esperar vários segundos, ou até minutos para uma página web ser
completamente carregada no navegador. Desde então, a velocidade média da
internet no mundo vem duplicando a cada ano, como mostra a lei formulada por
Jakob Nielsen para estimar o crescimento da largura de banda da Internet (Nielsen,
1998).
O aumento da velocidade contribuiu para uma crescente utilização de
recursos de mídia em páginas web. Só no último ano, o tamanho médio das páginas
iniciais dos 1000 maiores websites (Alexa, 2015) cresceu em 19% (HTTP Archive,
2015), como pode ser observado na Figura 01.
Figura 01 – Páginas iniciais dos 1000 maiores websites.
Conforme os usuários passam a ter acesso às conexões de Internet mais
velozes, eles se tornam mais exigentes, e isso eleva os requisitos de desempenho
que os projetistas devem atender em seus projetos (Lohr, 2012). Consequentemente,
eles buscam utilizar ferramentas e técnicas de desenvolvimento mais sofisticadas,
visando elevar a qualidade e reduzir o tempo gasto com a manutenção.
Outro requisito importante é o crescimento da demanda por interfaces
responsivas que se adaptem às diferentes resoluções de telas e a inúmeros tipos de
dispositivos diferentes. Essa variedade pode chegar a milhares, caso se considere
um grande website, como The Guardian1 (Stirling, 2015). No futuro, esse número
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!1 http://www.theguardian.com/us
!
!
!
15!
pode ser ainda maior, já que previsões indicam que existirão cerca de 50 bilhões de
dispositivos conectados à Internet até 2020 (Evans, 2011).
Além dessa demanda para atender vários dispositivos, vale destacar que
projetar para o lado cliente de aplicações web, vai além de implementar interfaces
gráficas, e também apresenta os seguintes desafios:
1)! Buscar o carregamento mais eficiente dos recursos referenciados;
2)! Reduzir o consumo de processamento e energia dos dispositivos
(Thiagarajan, Aggarwal, Singh, Boneh, & Nicoara, 2012);
3)! Evitar regressões de desempenho, que podem ser introduzidas por
adições de novas funcionalidades ou alterações das implementações
existentes.
As combinações desses desafios buscam evitar que a experiência do usuário,
seja comprometida por problemas de desempenho, e isso gere prejuízos aos
negócios. Esta dissertação apresenta uma proposta para o desafio 3, que permita
reduzir regressões de forma automatizada.
Em paralelo a esse contexto, temos um crescente interesse na utilização de
ferramentas baseadas em modelos e abstrações, para facilitar o desenvolvimento de
software. Estas abordagens incluem trabalhos mais focados em aplicá-los na
construção de interfaces web, mantendo os requisitos de qualidade, desempenho e
visando à redução do tempo de desenvolvimento, como visto em (Bertti &
Schwabe, 2015).
As páginas web são concebidas e implementadas por um conjunto de padrões,
muitos deles relacionados à programação distribuída, às recomendações definidas
no protocolo HTTP, à manipulação de eventos no navegador do usuário, ao
gerenciamento do consumo de memória. Baseado nisto, buscou-se uma
representação em modelos dos elementos das regras de avaliação de desempenho
mais utilizadas, e o foco deste trabalho é o lado cliente dessas recomendações. Esse
lado pode chegar a ser responsável por 90% do tempo total de resposta para o
usuário final (Souders, 2007).
Diante desse cenário, os projetistas de páginas web têm o desafio de rever a
forma de trabalho com avaliações de desempenho, a fim de adaptar um modelo para
representar esse contexto. Alguns trabalhos propuseram novos tipos de avaliações
de desempenho de aplicações baseados em modelos, com diferentes abordagens,
Kogekar (Kogekar, 2008), em sua tese de doutorado, propôs uma avaliação de
!
!
!
16!
desempenho de sistemas complexos baseada em modelos, separando o sistema em:
estrutura, configuração e comportamento. O trabalho demonstrou como uma
alteração de um aspecto pode gerar uma regressão de um sistema como um todo.
Já Xiong (Xiong, 2012), em sua tese de doutorado, apresenta uma forma
dinâmica de monitoramento e gestão de desempenho de aplicativos em nuvem,
trazendo predições baseadas em técnicas de aprendizado de máquinas. Porém
ambas as teses são focadas no lado servidor da aplicação.
A literatura ainda apresenta a modelagem de uma ontologia de desempenho
para web e comportamentos, apresentada por Carlos Guerrero (Guerrero, Juiz, &
Puigjaner, 2008), que fornece um modelo para informações sobre todos os
elementos significativos de uma aplicação web. A utilização dessa ontologia para
regras de avaliação de desempenho envolve processamento de sinais (ou atributos)
no lado do servidor.
O método e arquitetura utilizados no framework proposto nesse trabalho são
baseados em três pilares: 1) ambiente de software extensível dirigido por modelos
para avaliação desempenho; 2) avaliação de desempenho de páginas web, no lado
cliente da aplicação; e 3) gestão de desempenho de páginas web ao longo do tempo.
1.1# #Objetivos##
Este trabalho apresenta um método para avaliação de desempenho de páginas
web dirigido por modelos, que aplica regras relacionadas à manutenção de boas
práticas para o bom de desempenho de páginas web, com foco no lado cliente da
aplicação. Apresenta também um ambiente que faz uso desses modelos, chamado
Keepfast.
O ponto principal desse framework é a capacidade de ser estendido e
personalizado, para que possa atender aos critérios que o projetista busca avaliar.
Este framework pode ser integrado com outros analisadores de desempenho,
bastando que se desenvolva um módulo de interface e defina seus critérios para
nova regra adicionada.
O Keepfast também indica sugestões relacionadas a melhorias de
desempenho da aplicação, buscando diminuir a incidência de regressões, muitas
!
!
!
17!
vezes adicionadas de forma não-intencional, decorrentes da inclusão de
funcionalidades, ou modificação de alguma existente.
Os projetistas podem redefinir critérios que desejam utilizar em seus testes de
desempenho. Outra funcionalidade é a disponibilidade dos dados obtidos em cada
avaliação de desempenho, possibilitando a integração com outros sistemas, via uma
API (Application Programming Interface) disponibilizada.
Um experimento em ambiente real de desenvolvimento é apresentado, com
os resultados obtidos, relatando as principais dificuldades que os projetistas
enfrentaram ao utilizar o framework.
1.2# #Questões#de#Pesquisa##
A principal questão de pesquisa nessa dissertação é como aplicar uma
metodologia para evitar regressões de desempenho em páginas web, utilizando uma
abordagem dirigida por modelos. Através da observação dos principais impactos de
um monitoramento de desempenho, no lado cliente de páginas web, atua-se de
forma proativa no processo, a fim de evitar regressões de desempenho, a cada nova
versão das páginas.
Para validar a proposta, realizou-se um comparativo entre o monitoramento
manual e o proativo, levantando quais foram as métricas mais relevantes, num
experimento realizado no time de desenvolvimento da empresa Loadsmart2.
1.3# #Estrutura#da#dissertação#
Além da introdução que apresenta a motivação, objetivos e questões de
pesquisa, os demais capítulos desta dissertação estão organizados da seguinte
forma:
O capítulo 2 apresenta os principais conceitos usados neste trabalho, e
também, os principais trabalhos relacionados ao tema da dissertação. Os conceitos
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!2 https://loadsmart.com/
!
!
!
18!
apresentados nesse capítulo são: HTTP; desempenho no lado cliente de páginas
web; e as principais ferramentas para avaliação de desempenho do lado cliente.
O capítulo 3 descreve os modelos do Keepfast para especificação de testes
de avaliação de desempenho, com uma visão sobre a metodologia de otimização de
desempenho para o lado cliente de páginas web.
O capítulo 4 mostra uma visão geral da ferramenta implementada,
apresentando o ambiente Keepfast, a sua arquitetura de software modularizada.
Apresenta também como se pode criar novos módulos para o ambiente, e como
criar novos casos de testes. A sua arquitetura de implementação é descrita, e mostra
como integrar os dados desse ambiente com outros sistemas.
O capítulo 5 descreve um estudo de caso que apresenta um experimento em
um ambiente real, onde um time de desenvolvimento de software, adota o modelo
de otimização de desempenho e o ambiente proposto por esse trabalho.
O capítulo 6 apresenta as conclusões, relatando os principais resultados
obtidos na experimentação em ambiente real. Além disso, esse capítulo apresenta
as contribuições e trabalhos futuros que trazem algumas oportunidades de evolução
do ambiente, baseadas nos resultados obtidos na experimentação.
!
!
!
19!
2# #Fundamentos#
Este capítulo traz uma visão dos conceitos utilizados nesse trabalho, com as
devidas considerações gerais, sobre como eles foram utilizados nesse projeto.
Incluindo, fundamentos sobre o HTTP, otimização de desempenho para web,
ferramentas de avaliação de desempenho no lado cliente e conceitos de modelagem
de sistemas, baseados em padrões.
2.1# #Aplicações#web#e#o#HTTP!
Uma aplicação web pode ser acessada via uma rede Intranet ou Internet, e por
um bom tempo, os usuários a acessavam apenas através de um navegador, mas hoje,
ela pode ser acessada via uma gama de dispositivos diferentes, e se estima que a
evolução da "Internet das Coisas" eleve esse número de dispositivos a 50 bilhões,
até 2020 (Evans, 2011).
Aplicações web são centradas no protocolo HTTP, que é a forma padrão de
comunicação entre um navegador web e um servidor web. Sua especificação é
mantida pelo W3C3 (World Wide Web Consortium) e o IETF4 (Internet Engineering
Task Force), que define o protocolo da seguinte forma:
O HTTP é um protocolo de comunicação de hipertexto, a nível de aplicação
para sistemas distribuídos e informações de hipertexto, ele é baseado em uma
arquitetura de cliente-servidor, onde o servidor entrega recursos baseados nos
padrões HTML, JavaScript, CSS, imagens, entre outros (IETF, 2014).
A arquitetura do HTTP é baseada em troca de mensagens, que podem ser
divididas em requisições e respostas, um modelo de mensagem de requisição
HTTP, pode ser visualizado no Quadro 1. Ele representa uma solicitação de um
determinado recurso disponível em uma URL e um conjunto de configurações que
o navegador suporta. Entre as configurações exibidas nessa requisição estão:
•! Método e versão do HTTP utilizado pelo navegador (GET e HTTP/1.1);
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!3 http://www.w3.org/Protocols/ 4 https://tools.ietf.org/html/rfc7230
!
!
!
20!
•! Domínio do servidor requisitado (Host);
•! Formatos de documentos aceitos pelo navegador (Accept);
•! Informações sobre o navegador e sistema operacional (User-Agent);
•! Tipo de compactação de arquivos aceitos pelo navegador (Accept-
Encoding);
•! Idiomas aceitos conforme as configurações do usuário (Accept-
Language).
GET / HTTP/1.1 Host: fellipe.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8,de;q=0.6,es;q=0.4,pt;q=0.2 Quadro 1 – Modelo de uma mensagem do tipo requisição no HTTP.
Os itens do tipo “Accept-“ podem ser acompanhados de valores numéricos
(parâmetro q:) indicando uma preferencia do cliente por cada opção. O servidor
deve procurar atender as preferencias do cliente conforme a ordem dos pesos.
Após a requisição representada no Quadro 1 ser enviada pelo navegador, uma
resposta é retornada, cujo modelo pode ser visualizado no Quadro 2. Esse exemplo
apresenta uma resposta de uma requisição que foi atendida com sucesso, e essa
mensagem retorna com o código 200. Esse código depende do método utilizado na
requisição, para esse exemplo foi utilizado o GET. A resposta contém, além das
informações sobre o documento requisitado, um conjunto de configurações do
servidor:
•! Código da resposta do servidor e versão do HTTP (HTTP/1.1 200 OK);
•! Data da última atualização desse recurso requisitado (Last-Modified);
•! Tipo do servidor utilizado (Server): Apache;
•! Padrão de compactação usado pelo recurso (Content-Encoding): Gzip;
•! Tipo do conteúdo do recurso solicitado (Content-Type): HTML;
•! Tamanho do recurso retornado, em bytes (Content-Length);
•! Tipo da conexão com o servidor (Connection): close, este valor significa
que o servidor web irá fechar a conexão TCP imediatamente após a
transferência desta resposta.
!
!
!
21!
HTTP/1.1 200 OK Date: Thu, 13 Jun 2015 01:16:51 GMT Server: Apache Last-Modified: Mon, 20 Oct 2014 17:14:18 GMT Content-Encoding: gzip Content-Length: 1387 Content-Type: text/html; charset=utf-8 Connection: close Quadro 2 – Modelo de uma mensagem do tipo resposta HTTP.
2.2# #Anatomia#de#uma#requisição#HTTP!
Para um navegador web carregar uma página por completo, ele pode precisar
executar dezenas de requisições a mais, além do documento HTML principal. Para
cada um dos recursos referenciados pelo documento principal, será necessário
realizar uma nova requisição HTTP para obter seu conteúdo. Esses recursos
referenciados podem ser arquivos HTML, folhas de estilo CSS, scripts de
JavaScript, imagens, fontes, vídeos, entre outros suportados (IETF, 2014).
Figura 02 – Requisição HTTP no navegador Chrome.
As etapas de carregamento de uma requisição HTTP estão ilustradas na
Figura 02, que apresenta um detalhamento com a sequência das etapas desde a
configuração da requisição até a carga do conteúdo do recurso. Para esse exemplo,
foi considerado uma requisição onde o cliente inicia uma solicitação HTTP, do tipo
GET para o servidor, e o servidor retorna uma resposta para a solicitação com
sucesso.
A requisição é iniciada pela etapa de configuração, em seguida, é realizada
uma consulta ao DNS (Domain Name System), onde o endereço IP é descoberto,
iniciando-se um processo de estabelecimento de uma conexão TCP com o servidor
desse recurso, utilizando o protocolo three-way handshake, e posteriormente temos
início da carga do recurso e, por fim, a carga é completada (IETF, 2014).
!
!
!
22!
2.2.1# #Configurações#da#requisição#HTTP#
A definição de configurações é o primeiro passo para se obter uma resposta
HTTP. Nesta etapa, há um tempo necessário para realizar uma pesquisa de
resolução do domínio no DNS, necessária para encontrar qual é o endereço de IP
associado à URL requisitada, para que o navegador consiga estabelecer uma
conexão com o servidor remoto.
A cada novo domínio ou subdomínio que o navegador não tenha acessado
anteriormente, será necessário um novo ciclo pergunta-resposta no DNS para obter
uma nova resolução. Na requisição mostrada na Figura 02, esse processo está
representado pelo identificador DNS Lookup, e foi responsável por cerca de 2% do
tempo total de carregamento dessa requisição.
2.2.2# #Estabelecimento#da#comunicação�
Entre os requisitos para o estabelecimento de uma comunicação entre o
navegador e servidor, é necessário que essa comunicação seja trafegada via o
protocolo TCP (Transmission Control Protocol), que é um protocolo orientado à
conexão, localizado na camada de transporte do Modelo OSI.
Na requisição da Figura 02, esse processo está representado pelo
identificador Initial Connection, e foi responsável por 17% do tempo total de
carregamento dessa requisição.
2.2.3# #Tempo#para#o#envio#do#primeiro#byte#
O tempo para o envio do primeiro byte é o tempo de espera para a resposta
inicial chegar ao requisitante. Ele é iniciado logo após o estabelecimento da
conexão. Este tempo corresponde à latência de uma requisição ir e voltar do
servidor somados ao tempo de espera para que o servidor forneça a resposta.
Na requisição apresentada na Figura 02, ele tá representado pela sigla TTFB
(Time To First Byte), e foi responsável por 56% do tempo total de carregamento
dessa requisição.
!
!
!
23!
2.2.4# #Carregamento#do#conteúdo#
Após o recebimento do primeiro byte, é iniciada a etapa de carga do recurso
requisitado, onde o tempo gasto será diretamente proporcional ao tamanho deste
recurso. Na requisição exemplo da Figura 02, esse tempo correspondeu a 15% do
total.
2.3# #Desempenho#no#lado#cliente#da#aplicação#
Em 2004 Steve Souders e sua equipe, formada por especialistas em
desempenho para web no Yahoo!5, iniciaram experimentos em seus produtos,
buscando principalmente reduzir o tempo de carregamento total das páginas para
melhorar a experiência dos usuários (Yahoo, 2007).
As contribuições dessa equipe impulsionaram bastante a área de avaliação de
desempenho no lado cliente, criando a ferramenta YSlow (YSlow, 2007), que
analisa as páginas web e avalia seu perfil de desempenho com base em regras
definidas pelo Yahoo!, determinando se um site é de alto desempenho (YDN,
2007). Isso desencadeou o surgimento de outras ferramentas similares, tais como,
PageSpeed6, WebPageTest7, Phantomas8, GTmetrix9, entre outras.
2.3.1# #Comparativo#entre#o#carregamento#no#lado#cliente#e#servidor#
A Figura 03 apresenta uma representação gráfica que mostra o tempo de
carregamento de cada recurso de uma página dispostos numa linha de tempo. Esse
gráfico pode ser visualizado utilizando o modo “ferramentas para desenvolvedor”
do navegador Chrome.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!5 https://developer.yahoo.com/performance/ 6 https://developers.google.com/speed/pagespeed/insights/ 7 http://www.webpagetest.org/ 8 https://github.com/macbre/phantomas 9 https://gtmetrix.com/
!
!
!
24!
Figura 03 – Gráfico que exibe o carregamento de uma página web.
O primeiro segmento da Figura 03, representa o ciclo para obter o documento
HTML, após uma requisição HTTP ao servidor. Esse tempo é dado pelo
processamento de geração no lado servidor, juntamente com pesquisas ao banco de
dados, chamadas a serviços remotos, combinações de trechos de HTML para
formação do arquivo final, juntamente com operações de manipulação de arquivos,
ou simplesmente, a leitura e envio de um arquivo estático já gerado no servidor. Em
websites com grande volume de acessos, é comum esse ser acessado via uma
camada de cache do servidor, reduzindo bastante esse tempo completo de entrega
desse primeiro segmento.
Os demais segmentos da Figura 03 representam o carregamento dos recursos
referenciados pela página, que são necessários para criar os elementos de interface
do usuário. Uma grande quantidade desses recursos aumenta o tempo de
carregamento total, devido a fatores como: latência da rede, a execução de
JavaScript e a renderização de estilos e imagens no navegador. Nesse lado da
aplicação há uma grande quantidade regras que se pode aplicar para reduzir o tempo
total de carregamento da aplicação (YDN, 2007), trazendo retornos mais
significativos para redução do tempo de carregamento, a um custo menor que
otimizações no lado servidor (Souders, 2007).
!
!
!
25!
2.3.2# #Regra#de#ouro#de#desempenho#de#páginas#web#
O conceito da “Regra de ouro de desempenho de páginas web” baseia-se na
observação que cerca de 10 a 20% do tempo de resposta para o carregamento de
uma página web é gasto na geração do documento HTML no servidor, e que cerca
de 80 a 90% do tempo restante é gasto pelo lado cliente da aplicação. Após analisar
o carregamento de centenas de websites, Souders concluiu que melhorias nesse lado
trariam reduções mais significativas no tempo total de resposta para os usuários
(Souders, 2007), formulando então a regra de ouro de desempenho de páginas Web,
que pode ser resumida a, “Se quiser otimizar o desempenho de uma página Web,
comece pelo lado cliente” 10.
2.3.3# #Etapas#de#processamento#no#navegador#
Os navegadores web nos últimos anos passaram por melhorias significativas
de desempenho, segurança e usabilidade, tanto nas suas interfaces gráficas quanto
nos seus motores de renderização de conteúdo (Grosskurth & Godfrey, 2006). Esta
seção mostra uma visão geral e simplificada de como navegadores renderizam uma
página web, apresentando os conceitos fundamentais para uma melhor
compreensão sobre otimizações no lado cliente da aplicação.
Após o navegador baixar o arquivo HTML, ele é processado utilizando um
analisador para essa linguagem, cuja função é traduzir o código HTML em um
modelo de representação baseado em objetos, amplamente conhecido por sua sigla
em inglês: DOM11 (Document Object Model). Essa representação codifica a
estrutura lógica dos elementos na página. A Figura 04, extraído de (Grigorik, 2013),
mostra como um interpretador realiza o processo para geração dos nós da árvore
DOM.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!10!http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/!11 Especificação do DOM no W3C: http://www.w3.org/DOM/
!
!
!
26!
Figura 04 – Processo de geração do DOM.
À medida que o gerador do DOM encontra referências a novos recursos, ele
já informa ao navegador quais serão as novas requisições que ele deverá realizar,
antes mesmo de finalizar a geração do DOM correspondente à página.
Antes do navegador iniciar a exibição dos objetos na tela, ele também analisa
todas as folhas de estilos CSS, criando um modelo de objeto também para o CSS,
denominado CSSOM, onde é necessário identificar cada regra de estilo e criar
referências destas ao DOM.
Observa-se que a computação completa do CSSOM bloqueia a renderização,
causando um comportamento conhecido como FOUC (Flash of Unstyled Content)
(Hyatt, 2006), que consiste numa breve exibição da página da web ainda com estilos
padrão do navegador, imediatamente substituída pela renderização dos reais estilos
aplicados na folha de estilo, que ocorre assim que o processamento do CSSOM é
concluído. Este comportamento é extremamente desagradável para o usuário final
e deve ser evitado.
Para o navegador iniciar a exibição dos elementos na tela, o CSSOM deve
estar completamente gerado, ainda que o DOM não esteja. Caso o interpretador do
DOM encontre nós do tipo script12, o processo é interrompido até que esse código
seja processado por completo. Por essa razão se tornou uma prática comum declarar
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!12 Nós que possuem trechos de código, comumente na linguagem JavaScript
!
!
!
27!
folhas de estilo CSS no início dos documentos HTML e scripts no final do arquivo,
visando apresentar os elementos na tela do usuário o mais rápido possível, sem a
ocorrência do FOUC. Desta forma, os projetistas buscam definir a quantidade
mínima de código e recursos para visualização inicial de uma página web,
determinado através do conceito de critical rendering path (Grigorik, 2013).
Em navegadores mais modernos, é possível definir explicitamente que os nós
do tipo script executem sem bloquear a geração do DOM, utilizando os atributos
defer e async (W3C, 2013). Estes atributos são muito utilizados ao se adicionar
códigos de terceiros numa página web (Vinegar & Kovalyov , 2013).
2.4# #Regras#para#melhorar#o#carregamento#de#páginas#web#no#lado#cliente#
Nesta seção serão apresentadas principais regras para acelerar páginas web
no lado cliente. Estas regras estão associadas aos recursos das linguagens HTML,
CSS, JavaScript e imagens, e visam evitar problemas relacionados a concatenação
e compactação de arquivos, forma de carregamento, erros nas configurações para
entrega das respostas HTTP, tempo de expiração não configurados, requisições para
recursos inexistentes, e a complexidade do DOM do documento HTML. As
próximas subseções detalham essas regras.
2.4.1# #Evitar#requisições#HTTP#para#recursos#inexistentes##
Requisições HTTP são custosas, logo ter referências a recursos que retornam
respostas contendo a mensagem do tipo 404 (Not found) informando que o recurso
não foi encontrado, acaba degradando a experiência do usuário.
As respostas HTTP do tipo 404 não apenas prejudicam o carregamento da
página, mas também podem bloquear ou retardar a carga em paralelo de recursos,
caso o recurso não encontrado seja um arquivo do tipo JavaScript, e logo após o
retorno, o navegador pode analisar a mensagem de erro como se fosse código
JavaScript.
!
!
!
28!
2.4.2# #Concatenação#de#arquivos#
A concatenação de arquivos é uma forma de reduzir o número de requisições
HTTP, através da combinação de todos os recursos de um determinado tipo, em um
único arquivo.
A concatenação de arquivos é mais desafiadora em casos onde os scripts e
folhas de estilo CSS variam de uma página para outra; para esses pode optar pela
geração de arquivos combinados por páginas distintas.
Para reduzir o número de requisições para imagens, um método bastante
utilizado é a combinação de imagens de fundo, ou ícones, em um único arquivo.
Após a sua carga, utiliza-se a propriedade CSS background-position para posicionar
corretamente as imagens e exibir o segmento desejado.
2.4.3# #Compressão#do#código#dos#recursos#
Em ambiente de produção, não há necessidade de visualizar o código
documentado, com indentação correta e nomes de variáveis legíveis; trafegar esses
bytes é desperdício. Para evitar isso, é necessário aplicar um processo de
compressão que consiste na remoção de caracteres desnecessários do código,
visando reduzir seus tempos de carregamento.
Na compressão de código todos os comentários e espaços em branco
desnecessários são retirados. Isso reduz o tempo de carregamento, pois o tamanho
do arquivo descarregado é reduzido.
Outra fonte de bytes desnecessários são nomes de variáveis e funções no
código grandes. Pode-se aplicar um processamento de ofuscação de código fonte,
que transforma o código para um formato quase ilegível, renomeando variáveis e
nomes de função para a menor combinação de caracteres possível, considerando
seu escopo, evitando erros de JavaScript. Caso haja necessidade de depuração desse
código, é possível referenciar os arquivos não-ofuscados correspondentes.
Atualmente, os navegadores Chrome e Firefox permitem realizar a depuração
baseados nos arquivos originais.
!
!
!
29!
2.4.4# #Reduzir#o#número#de#nós#de#elementos#HTML#
Desenvolver uma página complexa normalmente, implica em mais bytes para
carga, gerando um acesso ao DOM mais lento usando JavaScript. Reduzir o número
de elementos DOM pode trazer uma considerável diferença de desempenho,
principalmente, ao se associar manipuladores de eventos a elementos do DOM, ou
ainda, adicionar novos elementos de forma automática e ilimitada.
Um número elevado de elementos DOM pode indicar que a marcação HTML
da página pode está usando tabelas HTML aninhadas para fins de layout, excesso
de elementos do tipo div, ou ainda, a ausência de grids (que ajudam a manter
padrões visuais de layout na organização das interfaces). Considerando os 100
maiores websites do mundo, média do número de elementos do DOM é 1140
elementos (HTTP Archive, 2015).
Para reduzir o número total de elementos no DOM, é indicado o uso de
bibliotecas de grids para os estilos da página e bibliotecas de componentes para
interface, que ajudam a reduzir a duplicação de código, que geram arquivos
maiores, aumentando o tempo de carga dos recursos.
2.4.5# #Redefinição#de#largura#e#altura#nas#imagens#
Definir novos valores aos atributos relacionados a largura (width) e a altura
(height) da tag <img> utilizada para adicionar imagens no HTML, faz o navegador
gastar mais tempo de renderização, devido aos redimensionamentos de imagens
desnecessários. O mais indicado é que os arquivos das imagens tenham as
dimensões iguais às declaradas no HTML.
Além disso, imagens em dimensões muito maiores que as necessárias,
acabam aumentando significativamente, o tempo total de carregamento da página.
2.4.6# #Número#de#recursos#transferidos#sem#compactação#Gzip#
Os navegadores web mais modernos, indicam quais os tipos de compressão
que suportam, enviando sua especificação no cabeçalho da requisição HTTP, com
valor da propriedade: Accept-Encoding.
!
!
!
30!
Habilitar o módulo de compactação Gzip contribui de forma significativa para
reduzir o tempo que o HTTP consome para transferir um recurso de resposta por
toda a rede, e ter uma significativa redução no carregamento da página. Essa
compressão, geralmente reduz o tamanho da resposta CSS, JavaScript e HTML, em
cerca de 70% (YSlow, 2007).
2.4.7# #Número#de#domínios#usados#para#buscar#a#página#
O Domain Name System (DNS) mapeia nomes de domínio para endereços IP.
Ao digitar www.fellipe.com em seu navegador, o servidor de DNS retorna o
endereço IP do servidor correspondente. Essa consulta ao DNS tem um custo, pois,
normalmente se gasta cerca de 120 milissegundos para o DNS procurar o endereço
IP de um determinado nome de domínio. O navegador não pode carregar em
paralelo nenhum recurso deste endereço até que a pesquisa de DNS esteja
concluída.
2.4.8# #Reduzir#o#número#de#requisições#a#partir#de#um#único#domínio#
A redução do número de resoluções de nomes de domínios, contribuem
potencialmente para evitar uma grande quantidade de consultas ao DNS, porém a
redução do número de domínios pode aumentar esse tempo de resposta. A
recomendação é dividir os recursos em no máximo quatro nomes de domínio,
gerando uma redução de consultas de DNS e permitindo ao navegador realizar um
maior número de cargas em paralelo (YDN, 2007).
2.5# #Ferramentas#para#avaliação#de#desempenho#
Nos últimos anos, diversas ferramentas têm sido desenvolvidas para enfrentar
os desafios existentes na avaliação de desempenho de páginas web, dentre elas,
!
!
!
31!
encontramos analisadores de configurações HTTP, Bookmarklets13 e extensões
para navegadores. Um levantamento das ferramentas existentes e relacionadas à
avaliação de desempenho de páginas web, está disponibilizado online14 e, de forma
colaborativa, tem se tornando um dos repositórios mais populares relacionados a
desempenho web, no GitHub15.
Essa lista disponibiliza ferramentas classificadas em categorias como:
Analisadores, Bookmarklets, compactadores de imagens e código, monitores de
métricas, entre outros. Grande parte dessas ferramentas são baseadas em
verificações de forma não-automatizadas. Dentre elas, destacaremos as 3 principais
para esse trabalho: YSlow, PageSpeed e o Phantomas.
Podemos dizer que, genericamente, todas as ferramentas são baseadas na
observação de sinais através de sensores, e comparação dos valores destes sinais
com valores de referência para determinar um aspecto do desempenho da página.
2.5.1# #Phantomas#
O Phantomas é uma ferramenta de linha de comando, desenvolvida em
Node.js, utilizando o PhantomJS para simular uma requisição de navegador (sem
interface gráfica) e após o carregamento da página, ele extrai as métricas de páginas
relacionadas ao desempenho no lado cliente. PhantomJS é um navegador
simplificando baseado no motor de renderização WebKit16.
As métricas de desempenho do Phantomas podem ser extraídas nos formatos
em CSV ou JSON, como também, o número de requisições, domínios utilizados,
estratégias de cache, e uma análise detalhada das folhas de estilo CSS e dos scripts
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!13 Programa em JavaScript que é armazenado no formato de uma URL, via atalhos nos Favoritos do
navegador web. 14 Projetos relacionados a “Web performance” no GitHub
https://github.com/search?o=desc&q=web+performance&s=stars&type=Repositories 15 GitHub é uma plataforma de compartilhamento de código na Web, que usa o sistema de controle
de versão baseado em Git. https://github.com/ 16 https://webkit.org/
!
!
!
32!
de JavaScript da página analisada. Ainda é possível obter screenshots e simular
diferentes resoluções de tela.
Os sensores considerados mais importantes do Phantomas, incorporados
posteriormente ao Keepfast são apresentados na Tabela 1. A primeira coluna
apresenta as quatro categorias criadas, a segunda coluna mostra os sensores
considerados, e a terceira coluna, apresenta boas práticas para se evitar regressões
relacionadas a esses sensores:
Categoria Sensores Boas práticas
Número de�requisições
- HTTP/ HTTPS; - HTTP 404; - Arquivos HTML; - CSS/ JavaScript; - Imagem; - Fontes
- Concatenação de arquivos CSS e JavaScript; - Junção de imagens usando técnica conhecida como sprites.
Tamanho das respostas
- HTTP/ HTTPS; - HTTP 404; - Arquivos HTML; - CSS / JavaScript; - Imagem; - Fontes; - Exibir recursos ativos que não foram compactados usando Gzip.
- Minificação de arquivos HTML, SVG, CSS e JavaScript; - Compactação sem perdas das imagens; - Redução de símbolos das fontes; - Habilitar módulo de Gzip no servidor.
Document Object Model (DOM)
- Número de nós no HTML; - Número de imagens sem largura e altura definidos, ou redimensionados; - O tamanho do conteúdo tag body.
- Fluxo de trabalho; - Gerência de projeto; - Organização de calendário.
Domínios
- Número de domínios referenciados para o carregamento completo da página; - Número máximo de solicitações obtido a partir de um único domínio.
- Considerando o HTTP 1.1, a recomendação é dividir os recursos em pelo menos dois domínios, e não mais do que quatro.
Tabela 1 – Sensores utilizados no Phantomas.
!
!
!
33!
Phantomas é uma ferramenta de código aberto, e está hospedada no GitHub17,
assim como o seu módulo18 que foi criado para o Keepfast.
2.5.2# #WebPageTest#
O WebPagetest (WPT) é uma ferramenta online utilizada para o diagnóstico
de desempenho de páginas web originalmente desenvolvida pela AOL19 para uso
interno, e posteriormente se tornou de código aberto, sob a licença BSD.
O WPT permite uma visão sobre cada solicitação - até o nível da conexão
TCP. Ele apresenta alguns indicadores de desempenho importantes para um
website, sendo esses indicadores são baseados nas regras (sinais e valores de
referência) propostas pelo YSlow e pelo PageSpeed.
Atualmente o WPT é mantido pela Web Performance Optimization
Foundation (WPO Foundation, 2012), e tem uma comunidade bastante
participativa no GitHub20. O WPT permite a configuração de uma instância privada
para avaliação de seus projetos internos ou em desenvolvimento.
Figura 05 – Resultado do WebPageTest para o http://fellipe.com.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!17 https://github.com/macbre/phantomas 18 https://github.com/keepfast/keepfast-contrib-phantomas 19 http://www.aol.com/ 20 https://github.com/WPO-Foundation/webpagetest
!
!
!
34!
Para utilizar o WPT, o usuário deve digitar uma URL, escolher qual será o
navegador e em qual local que gostaria que a página fosse carregada. O diferencial
dessa ferramenta consiste na escolha da localização geográfica de onde será́
realizada a requisição, possibilitando realizar testes com valores de latência de rede
mais realistas. A Figura 05 mostra o resultado simplificado de uma avaliação de
uma página Web utilizando o WPT, disponível online21, e nela se observa alguns
escores em divididos em categorias, tais como:
1)! Escore para o tempo de carregamento do primeiro byte;
2)! Verifica o parâmetro Keep-Alive22 do HTTP, que indica se a conexão
HTTP é persistente, com a ideia de se utilizar uma única conexão TCP
para enviar e receber várias requisições/respostas. Sem ele é necessário
abrir uma nova conexão para cada par requisição/resposta.
3)! Verifica se a compressão dos dados está habilitada, normalmente se usa
gzip ou deflate, e só funcionam em recursos de texto;
4)! Verifica se a compressão das imagens está sendo realizada. Para esse
exemplo, temos um escore errado, pois esta página não contém nenhuma
imagem;
5)! Verifica se a página tem políticas de cache de conteúdo habilitadas;
6)! Verifica se a página utiliza rede de distribuição de conteúdo, para reduzir
a latência baseada na localização do cliente.
Além desses escores, essa avaliação apresenta outras informações relevantes
como o tempo para o primeiro carregamento da página, e quanto tempo para uma
segunda visualização, além do valor do DOM Elements, que indica a quantidade de
elementos HTML que a página contém. Este exemplo é uma página de baixa
complexidade.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!21 http://www.webpagetest.org/result/150818_3X_NWX/ 22 Documentação do parâmetro Keep-Alive: http://tools.ietf.org/id/draft-thomson-hybi-http-
timeout-01.html
!
!
!
35!
2.5.3# #PageSpeed#
O PageSpeed foi implementado como uma extensão para o navegador
Chrome, e posteriormente incorporada à ferramenta padrão de depuração desse
navegador. Tem o objetivo de apoiar o processo de avaliação de desempenho de
páginas web, e tem como referência o conjunto de regras (sinais e valores de
referência) praticadas pela Google. Atualmente é formado por um par de
ferramentas: Módulos PageSpeed e PageSpeed Insights.
Módulos PageSpeed estão disponíveis para os servidores web Apache23 e
Nginx24. Ao ser configurado, ele aplica filtros para otimizar páginas e seus recursos
associados, tais como concatenar folhas de estilo CSS e JavaScript, compactar o
HTML, CSS, JavaScript e imagens, e ainda, aplicar configurações de cache para
um dado conjunto de páginas.
PageSpeed Insights é uma ferramenta online (PageSpeed Insights, 2010),
que realiza uma análise de uma página web, e avalia o quão otimizado o documento
principal está, e os arquivos referenciados por ela. Verifica ainda a codificação de
caracteres, a especificação de tempos de cache, a compressão de imagens, entre
outros. Após essa análise, apresenta um escore e um resumo com sugestões, para as
otimizações que ainda podem ser feitas.
Figura 06 – Resultados do PageSpeed para o http://fellipe.com.
A Figura 06 mostra um resultado para a avaliação de uma página web
utilizando o PageSpeed Insights. Nela se percebe um escore de 97, onde o máximo
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!23 https://github.com/pagespeed/mod_pagespeed 24 https://github.com/pagespeed/ngx_pagespeed
!
!
!
36!
é 100, essa avaliação utilizou a página do endereço http://fellipe.com, e ainda
apresenta em que a URL pode ser melhorada para se atingir o escore máximo, nesse
caso, a página deveria otimizar o carregamento, realizando a transferência apenas
do que é necessário para primeira visualização da página.
2.5.4# #YSlow#
O YSlow25 é uma ferramenta de código aberto que foi criada pela equipe de
desempenho do Yahoo!, inicialmente lançada como extensão para o navegador
Firefox26. Essa ferramenta avalia uma página web baseada em 23 regras,
disponíveis em (YDN, 2007). O YSlow apresenta um relatório com uma nota que
varia de A a F (escala convertida de 0 a 100 na versão em Node.js), com sugestões
relacionadas as melhorias que podem ser feitas, baseadas na medição obtida.
Figura 07 – YSlow para o navegador Chrome.
A Figura 07 apresenta um resultado para a avaliação de uma página web
utilizando o YSlow, nela foi obtida a nota A, para a página do endereço
http://fellipe.com. Ela ainda apresenta todas as 6 categorias de regras que o YSlow
utiliza: conteúdo, cookies, CSS, imagens, JavaScript e servidor.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!25 http://yslow.org/ 26 https://www.mozilla.org/en-US/firefox/new/
!
!
!
37!
O YSlow suporta os navegadores Safari, Google Chrome e Opera, e
utilizando um Bookmarklet27 é possível realizar testes no Internet Explorer e
dispositivos móveis, e ainda, a opção de integração com ferramentas de linhas de
comando.
O módulo YSlowJS28 baseado em Node.js pode ser integrado ao Keepfast,
através do módulo Keepfast-contrib-yslow29. Os sensores fornecidos por esse
módulo são: Extração do Tempo de Carregamento da página e o escore do YSlow.
2.5.5# #Comparação#entre#as#ferramentas#
As ferramentas YSlow, Phantomas, PageSpeed e WebPageTest são as
principais alternativas utilizadas no mercado para avaliar o desempenho de páginas
web, que ajudam os projetistas a identificar deficiências, corrigi-las baseadas nas
sugestões fornecidas.
Um comparativo entre as ferramentas de análise de desempenho para web é
apresentado na Tabela 2. Ela relaciona as ferramentas com requisitos desejáveis
para o processo de análise de desempenho.
Customização de critérios é a capacidade de adaptar os critérios de uma
ferramenta a novos valores. Em algum momento, um determinado critério pode ter
um valor considerado como ideal, mas o surgimento de uma nova tecnologia pode
acarretar que esse valor, não corresponda mais a uma boa referencia de
desempenho. Apenas com o YSlow é possível customizar critérios, via
modificações em seu código fonte.
Testes geolocalizados é a capacidade de simular o carregamento de uma dada
página, em relação a requisições vindas de uma geolocalização, para observar como
usuários de uma região estão carregando aquele recurso. Essa avaliação afeta os
sensores relacionados à latência de rede, e permite terem valores de referência mais
adequados à realidade de uma dada região. Apenas com o WebPageTest é possível
realizar testes geolocalizados.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!27 http://yslow.org/mobile/ 28 https://github.com/jmervine/node-yslowjs/ 29 https://github.com/keepfast/keepfast-contrib-yslow/
!
!
!
38!
Histórico de avaliações é a capacidade de armazenamento das avaliações
anteriores, permitindo analisar como foi a evolução, ou regressão de uma página ao
longo de um dado período de tempo. O WebPageTest disponibiliza apenas o último
mês.
Acesso à ferramenta via Linha de comando e/ou Node.js, essa capacidade
permite os projetistas integrarem os resultados de uma avaliação com outras
ferramentas. Já a versão online auxilia a extrair simples medições de uma URL,
utilizando o navegador. Todas ferramentas avaliadas permitem acesso via linha de
comando.
Phantomas PageSpeed WebPageTest YSlow
Customização de critérios �
Testes geolocalizados � �
Histórico das avaliações � �
Acesso via Linha de
comando/Node.js � � � ��
Acesso Online � �� �� �
Tabela 2 – Relação entrar ferramentas e funcionalidades.
Os maiores desafios relacionados à área de avaliação de desempenho no lado
cliente correspondem à criação de mecanismos para verificar de uma forma
automatizada e que contribuam para evitar regressões (Duran, 2012). Além disso,
é essencial ter a possibilidade de personalização das regras para que se adaptem ao
contexto do projeto avaliado, visto que, os critérios podem mudar conforme este
contexto.
O Keepfast é um framework extensível, permitindo a integração a outros
módulos, sendo assim, é possível integrá-lo a todas as ferramentas citadas na Tabela
2. Ele permite ainda criar novos módulos, sendo possível também, a redefinição dos
critérios de referência de cada sensor suportado, para permitir que os projetistas
adaptem o framework para os critérios que eles buscam atender.
!
!
!
39!
3# #Modelo#para#especificação#de#avaliações#de#desempenho#de#páginas#web##
Este capítulo descreve os modelos utilizados pelo Keepfast para estruturação
das regras relacionadas às avaliações de desempenho de páginas para web,
descrevendo as principais regras, e apresentando como uma regra expressa um
critério que avalia o valor observado de algum sinal com respeito ao valor de
referência correspondente.
Uma avaliação de desempenho é extraída a partir de uma requisição HTTP
para uma determinada URL, nessa requisição são aplicados um conjunto de
sensores, que extraem os sinais medidos por cada um. Após essa etapa, os valores
obtidos são avaliados por regras que obtém os resultados baseados em valores de
referência definidos para aquele sensor. Por fim, os resultados são armazenados,
registrando o momento da medição e os critérios válidos para aquele momento.
Novos critérios podem ser redefinidos, e caso o sejam, também serão levados em
consideração na execução a partir daquele momento.
Um modelo baseado em melhorias de desempenho, que permite a alteração
de critérios auxilia o projetista a adequar métricas de desempenho à realidade do
projeto, que provavelmente irão mudar ao longo do tempo. Os aspectos propostos
para uma avaliação de desempenho, usando os modelos descritos nesse capítulo
são:
•! Modelo das regras e sensores que serão executados;
•! Modelo páginas que serão executadas;
•! Modelo de definição de critérios;
•! Modelo de avaliações
3.1# Modelo#para#Regras#e#Sensores#
Cada uma das regras relacionadas ao desempenho no lado cliente da aplicação
web, descritos na seção 2.3, podem ser representadas no Keepfast utilizando o
modelo do Quadro 3.
!
!
!
40!
Rule = { Label, Suggestion, Reference: [ { Platform Expected Condition Result Unit } ] } Quadro 3 – Modelo de uma Regra no Keepfast.
Esse modelo representa as formas de classificar o valor de um sinal medido
(Result). Uma regra é definida pelas seguintes propriedades:
Label: Nome dado a regra, exemplo: escore do PageSpeed.
Suggestion: Caso o valor medido não atenda aos critérios de uma regra, o
Keepfast retornará essa informação, juntamente com uma URL com informações
sobre o problema.
Reference: Essa propriedade define um conjunto de propriedades de um
sinal, tais como, plataforma, valor esperado, condição esperada, valor obtido, e a
unidade desse valor obtido.
Platform: Essa propriedade define para quais plataformas a regra será
considerada. Por padrão, é definido pelo par: desktop e mobile.
Expected: Essa propriedade exibe o valor de referência que o critério espera
que a medição retorne para a regra, e pode assumir valores inteiros, flutuantes,
arrays e strings. Os valores por padrão podem ser sobrescritos.
Condition: Essa propriedade específica o operador de comparação com os
valores obtidos, para determinar se o critério foi satisfeito.
Result: Essa propriedade define qual é o valor de comparação esperado que
o critério visa atender. Se a operação de comparação entre o valor observado pelo
sinal e o resultado for satisfeito, o critério foi atendido, caso o contrário não.
Sensor = { [Rule] } Quadro 4 – Modelo de um Sensor no Keepfast.
!
!
!
41!
Um sensor (Sensor) contém um conjunto de regras (Rule) que podem ser
aplicadas, representado no Quadro 4.
3.2# #Modelo#para#Critérios#
Este modelo oferece extensibilidade pela capacidade de alterar valores,
permitindo o uso de ferramentas existentes. Considere a regra que indica que é
desejável combinar-se os arquivos JavaScript de uma página para reduzir o número
de requisições, devido à forma que o HTTP 1.1 lida com requisições em paralelo,
tornando custosa a criação e iniciação de conexões TCP (Pagespeed, 2015). Com a
implementação do HTTP 2.0, essa regra passa a ser desnecessária, pois essa versão
permite a multiplexação, onde múltiplas mensagens de requisição/resposta podem
ser transmitidos através da mesma conexão TCP (Peychev, 2014) e, portanto, a
sobrecarga de gerenciamento de várias conexões deixa de existir.
O Quadro 5 apresenta a especificação do modelo para um critério de avaliação
de página no Keepfast, que é composto pelas seguintes propriedades:
Rule_Name: Essa propriedade indica a qual regra pertence o sensor que se
pretende alterar.
Sensor_Name: Essa propriedade indica de qual sensor que se pretende
alterar.
Reference: Essa propriedade define um conjunto de propriedades de um sinal
que se deseja redefinir, e possui as propriedades plataforma, valor esperado,
condição esperada, valor obtido, e a unidade desse valor obtido.
Criteria = { Rule_Name Sensor_Name Reference [ { Platform Expected Condition Result Unit } ] } Quadro 5 – Modelo de um Critério no Keepfast.
!
!
!
42!
3.3# #Definição#de#Perfis#
A definição de perfis de análise de desempenho contendo conjuntos de regras
permitem representar, de uma maneira compacta, as decisões sobre o que pode ou
não ser avaliado, considerando valores tido como referência. Ele também pode
fornecer alguma justificativa sobre qual motivo alguma regra foi omitida, ou se uma
outra, exige requisitos mais elevados de desempenho.
3.4# #Modelo#para#Páginas#e#Servidor#
O modelo de página representa a entrega de um recurso num endereço
específico na Web. O Keepfast considera que as regras e critérios de avaliação estão
associados à página. O Quadro 6 apresenta a especificação do modelo de uma
Página no Keepfast, composto pelas seguintes propriedades:
Page = { Path, Criteria, } Quadro 6 – Modelo de uma Página no Keepfast.
Path: Este parâmetro, juntamente com a URL, é utilizado para criar um
identificador único no Keepfast, onde os outros modelos definidos devem fazer
referência a esse, caso estejam relacionados à mesma avaliação.
Criteria: Conjunto de novos critérios de avaliação. As configurações de
melhorias no servidor podem ser aplicadas a uma página ou a um conjunto de
páginas sob um mesmo localizador. Devido a isso, o conjunto de critérios pode estar
associado à página.
Na arquitetura de uma aplicação web, os servidores normalmente são
considerados como elementos passivos, na qual os clientes primeiramente buscam
estabelecer uma conexão, após efetuada com sucesso, esses clientes executam um
conjunto de requisições de páginas baseadas na sua URI, utilizando o protocolo
HTTP.
!
!
!
43!
Server = { Domain: { Name, URL }, Pages: [] } Quadro 7 – Modelo de um Servidor no Keepfast.
O Quadro 7 apresenta a especificação do modelo Server, que indica a
representação de um servidor, composta pelas seguintes propriedades:
Domain: Representa um recurso da Web que pode ser identificado pela sua
URL, por exemplo: http://www.fellipe.com, ou ainda, pelo endereço IP. O atributo
Name é apenas utilizado para definir um nome mais legível para identificar o
domínio;
Pages: Representa o conjunto de páginas que o servidor pode entregar, para
as avaliações de desempenho no Keepfast. Normalmente é escolhido um
subconjunto do total de páginas que o servidor tem disponível. Por exemplo, caso
tenhamos um website sobre times de futebol, realizar a avaliação em várias páginas
de times diferentes, pode não trazer diferenças significativas, pois provavelmente
essas páginas utilizam a mesma estrutura, por esse motivo iremos escolher uma,
dado um conjunto de páginas semelhantes.
O Quadro 8 nos apresenta um exemplo com o modelo para entidade do
servidor (Server), representado no framework.
{ "domain": { "name": "fellipe", "url": "http://fellipe.com" }, "pages": [Pages] } Quadro 8 – Modelo de um Servidor no Keepfast no formato JSON.
3.5# #Modelo#para#Medição#
O modelo do Quadro 9 representa uma agregação de todos os modelos
representados nesse capítulo, pois ele é a representação da medição através de um
determinado sensor (Sensor), em um dado momento (Timestamp), executado para
!
!
!
44!
uma dada página (Page) de um Servidor (Server), e os critérios para adaptar a
medição a um novo critério (Criteria) definido.
Measurement = [{ Server, Page, Sensor, Timestamp, Criteria}, ... ] Quadro 9 – Modelo de uma Medição no Keepfast.
Essa extensibilidade permite ao Keepfast flexibilizar o uso de ferramentas de
avaliação de desempenho no lado cliente, pois as mesmas só permitem avaliações
baseadas em valores tidos como referências por elas. Porém, com o advento de
novas ferramentas no lado servidor, ou até mudanças nas implementações nos
navegadores, podem acarretar alterações nas regras tidas como padrões de mercado.
Por exemplo, quando os servidores suportarem a implementação 2.0 do HTTP
(IETF HTTP Working Group, 2015), não haverá mais a necessidade de
concatenação CSS e JavaScript, que antes eram concatenados para reduzir o
número de requisições, caso uma ferramenta de avaliação não tenha uma
atualização para remoção dessa regra, suas avaliações podem ser prejudicadas
devido à presença de uma regra defasada. Já utilizando o Keepfast, basta desabilitar
esta regra no modelo do perfil, flexibilizando as regras para o contexto que o
projetista deseja priorizar.
!
!
!
45!
4# #Visão#geral#da#ferramenta#
Este capítulo irá apresentar as tecnologias e os protocolos utilizados no
Keepfast, explicando de forma detalhada qual é o papel de cada componente da
arquitetura de implementação e o porquê das tecnologias utilizadas em cada
componente.
4.1# #Keepfast#macro`visão#e#premissas#
O Keepfast é um framework de código aberto para avaliação de desempenho
de páginas web, no lado cliente da aplicação. Ele fornece um conjunto de módulos
capazes de receber um perfil de página como entrada, e produzir como saída, uma
avaliação baseada nos critérios deste perfil. Foi escrito utilizando a linguagem
JavaScript, executada via Node.js (Dahl, 2009), juntamente com a base de dados
orientado a documentos MongoDB (MongoDB Inc., 2009), e a manutenção de
todos os esquemas de dados é gerenciado pelo Mongoose (LearnBoost, 2010),
facilitando futuras alterações na estrutura da base de dados.
O Keepfast desde o início foi idealizado como um projeto de código aberto e
uma licença de uso pouco restritiva30, essa diretriz contribuiu para utilização de um
conjunto de dependências com larga aceitação da comunidade de desenvolvedores,
principalmente para os mais especializados no lado cliente de aplicações.
O código fonte do Keepfast está aberto e disponível31 no GitHub, e desde a
liberação do código, o projeto já recebeu 11 contribuições, que incluem melhorias
em tratamentos de erros, refatoração de código e aumento da cobertura de testes
automatizados.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!30 Licença de uso do Keepfast: http://davidsonfellipe.mit-license.org/ 31 Repositório do Keepfast no GitHub: https://github.com/keepfast/keepfast
!
!
!
46!
Figura 08 – Página Keepfast disponível no GitHub.
4.2# #Fundamentação#sobre#as#tecnologias#utilizadas#no#Keepfast#
A escolha da linguagem JavaScript foi baseada na grande quantidade de
extensões disponíveis, para avaliação de desempenho no lado cliente32, fato
verificado após levantamento dos trabalhos relacionados. Isto facilitará futuras
integrações entre essas extensões com o Keepfast.
4.2.1# #JavaScript#
O JavaScript é um padrão aberto que foi desenvolvido inicialmente para o
lado cliente de aplicações web, é também a principal linguagem de projetistas
focados em desenvolver para o lado cliente de aplicações, e há dois anos se tornou
a linguagem mais utilizada no GitHub, conforme apresentado na Figura 09. Estes
fatos contribuem para reduzir a curva de aprendizado de futuros contribuintes do
projeto.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!32 https://github.com/davidsonfellipe/awesome-wpo
!
!
!
47!
Quanto à maturidade, o JavaScript evoluiu bastante nos últimos anos, e vem
sendo utilizado no lado servidor, em grandes empresas como Netflix33, New York
Times34, Linkedin35, entre outras.
Figura 09 – Linguagens mais utilizadas no GitHub (La, 2015).
4.2.2# #MongoDB#
A escolha do banco de dados não-relacional, MongoDB36 foi baseada na
maneira como ele armazena os dados, pois ele utiliza uma forma similar a notação
de objetos na linguagem JavaScript, porém nessa ferramenta é chamado de Binary
JSON (BSON) (MongoDB Inc., 2009), o que facilita o armazenamento de cada
métrica obtida pelo Keepfast, assim como as configurações de cada perfil, sem
necessidade de criar uma estrutura mais complexa, como a de um banco de dados
relacional.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!33 http://techblog.netflix.com/2014/11/nodejs-in-flames.html 34 https://source.opennews.org/en-US/articles/nyt-redesigns-mobile/ 35 https://engineering.linkedin.com/42/and-running-nodejs-tech-talk-tom-hughes-croucher 36 Website oficial do MongoDB: https://www.mongodb.org/
!
!
!
48!
4.2.3# #Mongoose#
O Mongoose facilita o acesso a camada de dados do Keepfast, ele é uma
biblioteca escrita em JavaScript para ser executado via Node.js. Ele proporciona a
criação de esquemas para modelar as estruturas de dados utilizadas no MongoDB.
Seu mapeamento é conhecido como ODM (Object-Document Mapper) e oferece
uma forma bem intuitiva para conversão de tipos, validações de dados e criações de
consultas à base de dados.
4.3# #Visão#conceitual#da#arquitetura#
O Keepfast é um framework dirigido por modelos que dá suporte à avaliação
de desempenho de páginas web, no lado cliente da aplicação. Ao fornecer um perfil
como entrada, contendo os sensores e critérios que serão utilizados na avaliação, é
executada uma extração de métricas para cada URL informada no perfil. Após a
extração, é executada uma avaliação comparando as medidas obtidas com os
critérios utilizados pelo modelo do perfil, e, o resultado dessa avaliação. O Keepfast
também oferece um painel que auxilia na visualização e consulta avaliações numa
interface gráfica através de qualquer navegador web.
A Figura 10 apresenta uma visão conceitual da arquitetura de software
modular utilizada no Keepfast. As caixas com cantos arredondados representam os
módulos que controlam o comportamento da aplicação e as caixas com cantos
quadrados representam os módulos auxiliares utilizados pelo framework.
!
!
!
49!
Figura 10 – Visão conceitual da arquitetura do Keepfast.
4.4# #O#Framework#
O framework pode ser executado via linha de comando37, ou via alguma suíte
de integração contínua que possua uma interface para linha de comando disponível,
tal como o Jenkins38. As dependências necessárias são Node.js39 e MongoDB40
configurados. Após configurados, basta fazer a carga do Keepfast, e executar o
processo de instalação disponível na página do projeto41.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!37 https://github.com/keepfast/keepfast-cli 38 https://jenkins-ci.org/ 39 Configurando o Node.js: https://nodejs.org/download/ 40 Configurando o MongoDB: http://docs.mongodb.org/manual/installation/ 41 https://github.com/keepfast/keepfast
!
!
!
50!
O Keepfast não tem o objetivo de ser um extrator de métricas, e sim um
framework extensível de análise de desempenho. Para simples medições pode ser
usado via linha de comando, e para medições com a intenção de manter um histórico
das avalições pode ser usado com sua versão com o painel de métricas. Com a
definição de um perfil de avaliação, é possível especificar os sensores que serão
utilizados, ou possíveis critérios customizados.
4.5# #Perfis#de#avaliação#
O processamento do framework se inicia com a execução desse módulo, que
é responsável por carregar o perfil que será avaliado. Há dois fluxos possíveis nesse
momento:
1)! Caso o perfil ainda não esteja na base de dados, ele armazena as informações
do perfil;
2)! Caso o perfil já exista na base de dados, ele apenas verifica se houve alguma
atualização da propriedade name, caso tenha sido atualizada, essa
informação é atualizada na base de dados. Após essa etapa, ele gera as URLs
que serão avaliadas.
O Quadro 10 apresenta um modelo simplificado de um perfil no framework
Keepfast de um exemplo onde temos a representação para avaliação de desempenho
da página inicial da página da empresa Loadsmart, em formato JSON. Nele
observamos dois nós, o domain para o domínio, e o nó pages, contendo um array
com as páginas que se pretende avaliar.
{ "domain": { "name": "loadsmart", "url": "http://loadsmart.com" }, "plugin": [ "keepfast-contrib-phantomas", "keepfast-contrib-psi", ], "pages": [{ "path": "/" }, { "path": "/carrier/" }] } Quadro 10 – Perfil mais simples possível no Keepfast.
!
!
!
51!
4.6# #Extensibilidade#da#ferramenta#
As extensões para o Keepfast devem ser escritas em JavaScript, ou ao menos,
deve possuir um módulo em Node.js para que seja possível a comunicação com a
estrutura do framework.
Esses módulos tem uma importância fundamental, pois através deles é
possível adicionar novas regras ao modelo do Keepfast. Esse suporte a extensões
permite que ele seja mais flexível quando uma determinada regra ou sensor tenha
seus valores de referências modificados, devido ao surgimento de uma nova
ferramenta ou devido à modificação de alguma metodologia utilizada.
Para exemplificar, criaremos um plugin para disponibilizar os sensores do
PageSpeed42 no Keepfast, que permita extrair os resultados para as plataformas
móveis e de desktop do Google PageSpeed Insights. O primeiro passo para a criação
dessa extensão, é clonar o repositório43 com o padrão de criação de plugins para o
framework.
O segundo passo é definir os valores de referência para o sensor, conforme o
Quadro 11, nessa dissertação os valores de referências são baseados nos dados
abertos do (HTTP Archive, 2015) , considerando os 1000 maiores websites do
mundo.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!42 https://github.com/addyosmani/psi 43 https://github.com/keepfast/keepfast-init-plugin/
!
!
!
52!
module.exports = { 'plugin': 'keepfast-contrib-psi', 'sensors': { 'score': { 'label': 'PageSpeed Score', 'criteria': [{ 'plataform': 'desktop', 'expected': '90', 'condition': '>', 'result': true, 'unit': '' }, { 'plataform': 'mobile', 'expected': '95', 'condition': '>', 'result': true, 'unit': '' }] } } }; Quadro 11 – Valores de referências para o sensor para extensão PSI.
O terceiro passo é definir a forma que o sensor se comunicará com o módulo
de extração de métricas, conforme apresentado no Quadro 12. Configurando e
instalando a extensão é possível adaptar os perfis definidos, para realizar avaliações
de desempenho considerando um novo critério. Também é possível utilizar como
referência a documentação44 oficial de criação de extensões para o Keepfast,
disponível no GitHub, apenas em inglês, e que é continuamente atualizada, caso
haja adaptações no modelo existente.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!44 https://github.com/keepfast/keepfast-init-plugin/
!
!
!
53!
#!/usr/bin/env node var Promise = require('bluebird'); var psi = Promise.promisifyAll(require('psi')); var reference = require('./reference'); exports.getReference = function() { return reference; }; exports.output = function(url) { return new Promise( function (resolve, reject) { resolve() }) .then(function() { return psi(url, { nokey: 'true', strategy: 'desktop' }) .then(function (data) { return { 'url': url, 'plugin': reference.plugin, 'sensors': data.ruleGroups.SPEED }; } ); }); }; Quadro 12 – Interface entre o sensor e o módulo de extração.
4.7# #Obtendo#uma#avaliação#de#desempenho#e#armazenando#as#avaliações#
Após a execução do módulo de obtenção de métricas da página atual, as
métricas obtidas são repassadas para o módulo capaz de interpretar os valores de
referências e realizar uma comparação com os escores obtidos na etapa anterior. As
sucessivas medições constituem uma avaliação. Cada aplicação possui uma
instância de avaliação, pois os critérios podem variar entre diferentes páginas de
um mesmo domínio.
Caso o resultado de uma determinada regra não atenda aos critérios, uma
mensagem sobre como melhorar a mesma é exibida, juntamente com uma URL de
referência sobre o assunto.
!
!
!
54!
O módulo de persistência trata da manipulação e acesso dos dados das
avaliações, que são armazenados no formato BSON na base de dados não-
relacional, MongoDB.
O maior diferencial do Keepfast em relação às outras ferramentas está na
facilidade de estender o modelo de acordo com o contexto da aplicação, quais as
resoluções de tela que pretende considerar, a facilidade para adição de suporte a
novas ferramentas, permitindo a criação de novos contextos.
4.8# #Apresentação#do#dashboard#
O painel do Keepfast é um módulo do framework que obtém dados via API
REST que está disponível na ferramenta, e apresenta os dados obtidos via interface
gráfica. Ele se divide em dois sub-módulos:
1.! Módulo conversor de métricas, que consulta dados da API disponível no
Keepfast, e no momento que obtém os dados, realiza um mapeamento
para exibir esse conjunto de dados no componente de interface
correspondente.
2.! Módulo widgets se constituem de vários módulos independentes, cada
qual obtendo os dados num formato de array da linguagem JavaScript,
e os apresenta na interface gráfica. Os dados são obtidos num intervalo
de tempo configurável.
!!
!
!
!
55!
!Figura 11 – Visão do painel de métricas do Keepfast.
A Figura 11 apresenta o painel de métricas do Keepfast, que contém, o
acompanhamento de uma página web, trazendo os indicadores avaliados por padrão
e os indicadores baseados em extensões. Buscou-se apresentar de uma forma mais
destacada as alterações em escores, tendo como referência os valores definidos nos
critérios em um dado momento.
Apesar da disponibilidade de visualização no dashboard próprio, durante os
testes e avaliações a equipe que o utilizava julgou mais interessante a sua integração
ao painel de métricas do Geckoboard45, ferramenta que já era utilizada pela equipe.
Essa integração foi realizada via API do Keepfast, e apresentada pelos widgets
disponíveis nessa ferramenta de métricas. Este processo ilustra como a arquitetura
do Keepfast, disponibilizando sua funcionalidade via APIs REST, facilitou a
adoção de interfaces alternativas. Da mesma forma, esta arquitetura facilitaria
também a integração com outras ferramentas (semi) automatizadas.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!45 https://www.geckoboard.com/
!
!
!
56!
5# #Estudo#de#caso#
Este capítulo apresenta um estudo realizado para avaliar o quanto o Keepfast
pode ajudar no ciclo de desenvolvimento de uma aplicação web, aplicando-o em
um projeto real. O capítulo começa explicando sobre as características do projeto e
da equipe, metodologia de aplicação do estudo, e os resultados obtidos.
5.1# #Características#do#projeto#e#da#equipe#
Para esse estudo de caso para experimentar a aplicação do Keepfast num
projeto real, foi utilizada a aplicação web principal da Loadsmart, empresa
localizada em Nova Iorque, que atua na área de logística.
Esse projeto consiste de uma aplicação web de página única, técnica mais
conhecida pelo seu termo em inglês: Single-Page Application (SPA). A aplicação
avaliada é autocontida, em um documento HTML, e possui um próprio
gerenciamento de rotas e se comunica de forma assíncrona com o servidor,
reduzindo assim, o número de requisições HTTP e o tempo de carregamento de
cada nova solicitação do usuário. Essa SPA foi desenvolvida baseada no framework
JavaScript: AngularJS46.
As seções internas requerem a autenticação do usuário, e devido a isso, apenas
7 rotas que não exigem autenticação, fazem parte do experimento. Essa SPA não
possui nenhum processamento no lado servidor, pois toda a sua regra de negócio e
controle de acesso é realizado por um projeto separado, e disponibilizado via API,
que encapsula a lógica do negócio da aplicação, e a separa da lógica da interface.
Na Loadsmart, a equipe é formada por seis desenvolvedores. O engenheiro
de software mais especializado no lado cliente da aplicação, denominado
engenheiro de front-end, que é o responsável pelo acompanhamento das métricas
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!46 https://angularjs.org/
!
!
!
57!
de desempenho, por buscar melhorias dos escores e também evitar regressões a cada
nova entrega de código em produção.
A equipe faz uso da metodologia ágil SCRUM47, que pratica a abordagem de
ciclos curtos de entrega de código para produção, geralmente à medida que
pequenas funcionalidades são implementadas ou erros corrigidos, e possui um
grande foco em automatização de tarefas visando reduzir, ao máximo,
procedimentos manuais.
5.2# #Características#do#estudo#
Para aplicação desse estudo de caso, foram realizados dois experimentos, em
paralelo, para comparação do método tradicional e o desenvolvido por este trabalho.
O primeiro experimento, denominado método tradicional, leva em
consideração a manutenção de avaliações e detecções de regressões de forma
manual, utilizando planilhas, que é apresentado na seção 5.3.
O segundo experimento utiliza o Keepfast, apresentando uma forma
automatizada para manutenção de avaliações de desempenho, detecção de
regressões, e possibilidade de especificação de critérios, que é apresentado na seção
5.4.
5.3# #O#processo#baseado#em#planilhas#
Inicialmente, o processo de avaliação de páginas web na Loadsmart se dava
pela utilização de planilhas. A cada entrega de código em ambiente de produção era
realizado uma avaliação utilizando as ferramentas YSlow e PageSpeed, via
extensões disponíveis para os navegadores Chrome e Firefox.
Esse teste consistia em coletar os escores de cada combinação, que eram
estruturados na forma de triplas (página, navegador e plataforma). Em seguida os
escores eram coletados manualmente em uma planilha, que era analisada para
verificar se houve alguma variação significativa.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!47https://www.scrum.org/Resources/What-is-Scrum
!
!
!
58!
A avaliação de um conjunto de páginas em diferentes plataformas e
navegadores, mesmo em aplicações web de pequeno porte, como o Loadsmart.com,
que contém apenas 7 páginas externas, é bastante trabalhoso. Devido a isso, para
apenas um teste, é necessário acompanhar um total de 28 combinações possíveis,
considerando:
•! 7 rotas que não exigem autenticação;
•! Dois navegadores: Chrome e Firefox;
•! Duas plataformas: Celular e Desktop.
Uma entrega de código em produção normalmente leva, em média, 15
minutos, considerando: o fechamento de versão, a execução de testes automatizados
e a instalação da versão no ambiente. A adição dessa etapa de testes de desempenho
em 28 combinações, elevou o tempo para cerca de 45 minutos, nos casos em que
não haviam erros ou regressões detectadas.
Essa equipe de engenharia segue princípios de desenvolvimento baseado em
entrega contínua de código em produção (Fowler, 2006). Como o número de
entregas para produção pode chegar a cinco no mesmo dia, um processo de
avaliação de desempenho considerando todas essas variações se torna bastante
custoso, logo, buscou-se simplificá-lo.
Para diminuir este tempo, passou-se a avaliar um conjunto de páginas apenas
na plataforma desktop e no navegador Chrome, considerando as mesmas 7 rotas,
com os testes sendo executados utilizando as ferramentas YSlow e PageSpeed.
As variáveis consideradas em ambas as metodologias foram: escore do
PageSpeed e do YSlow, peso da página em kilobytes, número total de requisições
HTTP, tempo total de carregamento da página em milissegundos, e o tempo para o
carregamento do primeiro byte. Com essa abordagem o tempo de entrega de código
em produção passou a gastar de 22 minutos, no total.
!
!
!
59!
!Figura 12 – Avaliação baseada em planilhas.
Uma amostra dessa forma de avaliação pode ser visualizada na Figura 12, que
traz todas as variações de desempenho de uma página48, considerando as 10 últimas
versões do Loadsmart.com em ambiente de produção.
A linha em destaque na Figura 12, apresenta um caso de regressão, onde uma
requisição a menos gerou um acréscimo de mais de 1 segundo no tempo total de
carregamento dessa página. Essa regressão foi causada devido à remoção indevida
de uma referência a uma biblioteca JavaScript de terceiros no HTML, que levou o
navegador a aguardar até o seu tempo máximo para uma requisição, gerando esse
retardo.
Essa detecção de regressão mostra que o uso da metodologia baseada em
planilhas permite encontrar alguma variação a cada entrega. Mas a falta de
automatização pode deixar uma regressão de desempenho muito mais tempo em
produção, caso algum um projetista menos criterioso execute a entrega do código,
sem realizar a avaliação de desempenho.
A literatura ainda traz alguns avanços na avaliação de desempenho baseada
em planilhas do GoogleDocs49, juntamente com a ferramenta WebPageTest
(Davies, 2014). Mesmo com esse avanço, essa metodologia em relação a proposta
do Keepfast, tem as desvantagens de ser ainda um processo manual, limitado a
ferramenta, e complexo caso se queira personalizar critérios para uma página
específica, e sujeito a erros dos projetistas.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!48 https://loadsmart.com/carrier 49 https://www.google.com/docs/about/
!
!
!
60!
A principal limitação na avaliação baseada em planilhas, é que as ferramentas
de análise de desempenho são baseadas nos valores de referência tidos como
padrão. E esses valores não podem ter seus critérios redefinidos, com o objetivo de
se adequar aos requisitos do projeto.
5.4# #O#processo#de#avaliação#de#desempenho#usando#o#Keepfast#
Para as avaliações de desempenho usando o Keepfast na Loadsmart, foi
criado um perfil para descrever quais seriam as URLs analisadas, neste caso, sete
páginas, e foram considerados os conjuntos de sensores presentes no Phantomas e
PageSpeed Insights, e uma customização de critério, devido a maiores exigências
de desempenho para página principal.
O perfil da Loadsmart, apresentado no Quadro 13 foi o utilizado nas
avaliações do Keepfast. Esse perfil contém as informações relativas ao domínio
para configuração do mesmo, as sete páginas a serem avaliadas, e em uma delas há
uma definição personalizada para um critério, nesse caso para a regra escore,
associada a extensão do PageSpeed Insights. A partir da definição desse perfil foi
possível se utilizar o Keepfast via linha de comando e via alguma ferramenta de
integração contínua.
!
!
!
61!
{ "domain": { "name": "loadsmart", "url": "http://loadsmart.com" }, "plugin": [ "keepfast-contrib-phantomas", "keepfast-contrib-psi", ], "pages": [{ "path": "/", "criteria": [{ "plugin": "keepfast-contrib-psi", "sensors": { "score": { "criteria": [{ "platform": "desktop", "expected": "93", "condition": ">", "result": true }] } } }] }, { "path": "/carrier/" }, { "path": "/#/login" }, { "path": "/#/signup" }, { "path": "/#/privacy-policy" }, { "path": "/#/user-agreement" }, { "path": "/#/freight-broker" }] } Quadro 13 – Perfil da Loadsmart para o Keepfast.
Definindo um perfil e executando o Keepfast, para cada nova entrega de
código em produção, pode se detectar uma regressão de desempenho. Baseado em
uma análise estática das páginas definidas no perfil, é possível visualizar os
resultados via linha de comando ou painel de métricas, sem a necessidade de
realizar o teste manualmente, página a página.
Ambas as técnicas testam todas as regras com base em um critério
configurável, produzindo uma indicação de exatamente quais testes foram bem-
sucedidos e quais falharam.
!
!
!
62!
A execução dos testes de desempenho do perfil do Quadro 13, consome em
média 15 segundos para cada combinação de URL e plataforma. Considerando as
14 combinações, logo era necessário entre 3,5 e 4 minutos para execução completa
do perfil.
Porém essa média de 15 segundos não vale para qualquer página web, já que
esse tempo de carregamento é diretamente proporcional ao tamanho das páginas,
latência de rede e tempo de execução.
5.5# #Considerações#finais#
A adoção de um processo de avaliação de desempenho de websites de forma
contínua nem sempre é uma tarefa fácil, principalmente quando ela é realizada de
uma forma manual, como apresentado na seção 5.3.
Na literatura não há uma metodologia estabelecida, pois, os critérios variam
bastante entre diferentes companhias e projetos. O Keepfast utiliza seus critérios
para cada sensor, baseados na média dos dados do (HTTP Archive, 2015), para os
maiores 1000 websites do mundo.
Alguns pontos merecem ser destacados quando se busca mostrar as vantagens
da avaliação de desempenho no desenvolvimento de websites. É necessário um
apoio fundamentado em métricas, enfatizando que essa cultura de otimização não
pode acontecer só em engenharia, abrangendo também gerentes de produto e
designers.
Na empresa Loadsmart, ainda não é possível comprovar se essas melhorias
de desempenho geraram mais usuários e sessões de utilização mais longas, pois é
um produto que está em fase de testes no mercado. Ainda assim, alguns resultados
do mercado podem ser usados para exemplificar a importância, em empresas como
Yahoo! (Stefanov, 2008), Mozilla (Cutler, 2010), Google (Mayer, 2006).
Vale destacar que para deixar um site mais veloz e mantê-lo exige o empenho
de todos os envolvidos com o projeto, pois a cada funcionalidade adicionada se
pode ocorrer regressões, e nesse momento o Keepfast, apresentando seu painel em
tempo real, apresentando as últimas medições, contribui para essa monitoração da
qualidade do produto.
!
!
!
63!
6# #Conclusões#
Após o desenvolvimento do Keepfast, ele foi aplicado em um ambiente real
de desenvolvimento de software, na empresa Loadsmart. Nesse experimento, ele
era executado a cada nova entrega de código em ambiente de produção, onde se
verificava a existência de regressões de desempenho, no lado cliente da aplicação.
Essa verificação era feita de forma automática, sem a necessidade de abrir a URL
de cada página e coletar informações baseadas em extensões do navegador.
Uma limitação diz respeito ao painel de métricas, devido ao acesso limitado
ao histórico e à uma melhor gestão do controle de acesso, com definição de grupos
e usuários, e a possibilidade de alterações dos perfis via interface gráfica.
Do ponto de vista de implementação, a arquitetura utilizada se mostrou
flexível, ao ser migrado para o painel de métricas do Geckoboard50, ferramenta que
já era utilizada pela equipe. Essa integração foi realizada via API do Keepfast, e
apresentada pelos widgets disponíveis nessa ferramenta de métricas.
A arquitetura baseada em modelos foi concebida para ser genérica e permitir
que as regras possam ser adaptadas, diante de novos requisitos de desempenho que
o projetista tenha que monitorar, sendo esse o maior diferencial do Keepfast.
6.1# #Trabalhos#Futuros#
Após a validação do experimento, uma das principais limitações levantadas
foi, a manipulação a nível de interface gráficas dos modelos de cada perfil de
avaliação de desempenho, e ainda que permitam a análise ao longo do tempo do
desempenho de um conjunto de páginas.
Além disso, há possibilidade de implementar uma generalização das funções
de comparação em cada critério e agregação de sensores, permitindo um aumento
da flexibilidade na comparação entre o valor medido e o esperado pelo modelo.
Outra necessidade é o desenvolvimento de mais extensões, que incluam a
capacidade de testes baseados na extração de métricas da complexidade
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!50 https://www.geckoboard.com/
!
!
!
64!
computacional da execução de código JavaScript e CSS, devido à importância desse
fator para a degradação do desempenho no navegador.
A arquitetura extensível proposta pelo Keepfast permite a possibilidade de
estender a ferramenta para outros domínios, tais como banco de dados, análise de
padronização de código fonte, e complexidade ciclomática.
6.2# #Contribuições#
Ao desenvolver este trabalho, buscou-se estudar técnicas e processos de
avaliação de desempenho de páginas web, no lado cliente da aplicação. Juntamente
com a implementação de um modelo para avaliação dessas páginas, através de um
vocabulário definido para este fim. Permitindo criar um framework extensível, onde
critérios podem ser aplicados, e também redefinidos. As principais contribuições
que se pode destacar nesse trabalho são:
•! A criação de um novo modelo para descrever a avaliação de desempenho de
páginas web no lado cliente da aplicação. Este modelo é implementado
através de um vocabulário definido para este fim;
•! Esse modelo criado é extensível, e novos módulos poderão ser adicionados
ou alterados, a medida que surja uma nova tecnologia, ou mudanças nos
valores dos sinais tidos como referência, tornando a ferramenta future-
proofing ou agnóstica de linguagem/tecnologia;
•! A implementação de um framework com a capacidade de extensão que
possibilita a realização de avaliações de desempenho com novas
ferramentas que venham surgir no mercado;
•! Uma API REST que permite o acesso às avaliações realizadas, que torna
possível a integração do framework com outras ferramentas;
•! Implementação de um painel de métricas em JavaScript para monitoramento
das avaliações de desempenho e com acesso a serviços disponíveis via API
REST.
!
!
!
65!
7# #Referências#Bibliográficas#
Alexa.! (2015).!Acesso!em!03!de! fevereiro!de!2015,!disponível!em!Alexa!
Rank:!http://www.alexa.com/topsites!
Bertti,! E.,! &! Schwabe,! D.! (2015).! MIRA! P! A! ModelPDriven! Interface!
Framework!for!REST!Applications.!(p.!90).!Rio!de!Janeiro:!PUCPRIO.!
Csikszentmihalyi,!M.,!Harper,!&!Row.! (1990).!FLOW:&The&Psychology&of&
Optimal& Experience.!
http://www.ode.state.or.us/opportunities/grants/nclb/title_i/a_basicpr
ograms/schoolimprovement/transformation7flow.pdf.!
Cutler,!B.!(4!de!abril!de!2010).!Firefox&&&Page&Load&Speed&–&Part&II.!Acesso!
em! 3! de! julho! de! 2015,! disponível! em! Mozilla! Blog! of! Metrics:!
https://blog.mozilla.org/metrics/2010/04/05/firefoxPpagePloadPspeedP
%E2%80%93PpartPii/!
Dahl,!R.!(2009).!Website&Oficial&do&Node.js.!Acesso!em!01!de!Maio!de!2015,!
disponível!em!https://nodejs.org/!
Davies,!A.!(14!de!dezembro!de!2014).!Driving&WebPagetest&from&a&Google&
Docs&Spreadsheet.!Acesso!em!10!de!agosto!de!2015,!disponível!em!
Performance!Calendar:!http://calendar.perfplanet.com/2014/drivingP
webpagetestPfromPaPgooglePdocsPspreadsheet/!
Duran,! M.! (24! de! dezembro! de! 2012).! Proactive& Web& Performance&
Optimization.! Acesso! em! 15! de! maio! de! 2015,! disponível! em!
Performance! Calendar:!
http://calendar.perfplanet.com/2012/proactivePwebPperformanceP
optimization/!
Evans,!D.!(4!de!2011).!A&Internet&das&Coisas&Como&a&próxima&evolução&da&
Internet& está& mudando& tudo.! Acesso! em! 17! de! Junho! de! 2015,!
disponível! em! Cisco:!
!
!
!
66!
http://www.cisco.com/web/BR/assets/executives/pdf/internet_of_thi
ngs_iot_ibsg_0411final.pdf!
Fowler,!M.!(01!de!maio!de!2006).!Continuous&Integration.!Acesso!em!15!de!
agosto! de! 2015,! disponível! em!
http://www.martinfowler.com/articles/continuousIntegration.html!
Google.!(2010).!Acesso!em!28!de!maio!de!2015,!disponível!em!PageSpeed!
Insights:!https://developers.google.com/speed/pagespeed/insights/!
Grigorik,! I.! (2013).!Optimizing!Application!Delivery! .!Em! I.!Grigorik,!High&
Performance&Browser&Networking.!O'reilly.!
Grosskurth,! A.,! &! Godfrey,! M.! W.! (junho! de! 2006).! Architecture! and!
evolution!of!the!modern!web!browser.!
Guerrero,! C.,! Juiz,! C.,! &! Puigjaner,! R.! (2008).! Web! Performance! and!
Behavior! Ontology.! 2010& International& Conference& on& Complex,&
Intelligent&and&Software&Intensive&Systems!(p.!7).!Barcelona,!Spain:!
IEEE.!
HTTP!Archive.! (2015).!Acesso!em!01!de!agosto!de!2015,!disponível!em!
HTTP!Archive:!http://httparchive.org/!
Hyatt,!D.!(1!de!setembro!de!2006).!The&FOUC&Problem.!Acesso!em!1!de!
maio! de! 2015,! disponível! em! Webkit:!
https://www.webkit.org/blog/66/thePfoucPproblem/!
IETF.!(junho!de!2014).!Request&for&Comments&HTTP.!Acesso!em!2!de!junho!
de!2015,!disponível!em!http://tools.ietf.org/html/rfc7230!
IETF!HTTP!Working!Group.! (maio!de!2015).!HTTP/2.!Acesso!em!19!de!
maio! de! 2015,! disponível! em!
https://httpwg.github.io/specs/rfc7540.html!
Kogekar,! A.! (2008).! MODELPDRIVEN! COMPOSITION! AND!
PERFORMANCE!EVALUATION!OF!PATTERNPBASED!SYSTEMS.,!
(p.!52).!Nashville,!Tennessee.!
!
!
!
67!
La,!A.!(19!de!agosto!de!2015).!Language&Trends&on&GitHub.!Acesso!em!19!
de! agosto! de! 2015,! disponível! em! https://github.com/blog/2047P
languagePtrendsPonPgithub!
LearnBoost.! (2010).! Acesso! em! 15! de! agosto! de! 2015,! disponível! em!
Repositório! do! mongoose! no! Github:!
https://github.com/Automattic/mongoose!
Lohr,!S.!(12!de!fevereiro!de!2012).!For&Impatient&Web&Users,&an&Eye&Blink&
Is&Just&Too&Long&to&Wait.!Acesso!em!02!de!abril!de!2015,!disponível!
em! New! York! Times:!
http://www.nytimes.com/2012/03/01/technology/impatientPwebP
usersPfleePslowPloadingPsites.html?_r=0!
Mayer,!M.!(09!de!novembro!de!2006).!Marissa&Mayer&at&Web&2.0&.!Acesso!
em! 15! de! julho! de! 2015,! disponível! em!
http://glinden.blogspot.com/2006/11/marissaPmayerPatPwebP20.html!
MongoDB!Inc.!(2009).!Website&oficial&do&BSON.!Acesso!em!1!de!maio!de!
2015,!disponível!em!http://bsonspec.org/!
Nielsen,!J.!(5!de!abril!de!1998).!Nielsen's&Law&of&Internet&Bandwidth.!Acesso!
em! 2! de! fevereiro! de! 2015,! disponível! em!
http://www.nngroup.com/articles/lawPofPbandwidth/!
Pagespeed.! (2015).!Combine& JavaScript& .! Acesso! em! 20! de! agosto! de!
2015,! disponível! em!
https://developers.google.com/speed/pagespeed/module/filterPjsP
combine?hl=en!
PageSpeed!Insights.! (2010).!Acesso!em!28!de!maio!de!2015,!disponível!
em! PageSpeed! Insights:!
https://developers.google.com/speed/pagespeed/insights/!
Peychev,! I.! (14!de!dezembro!de!2014).!HTTP&2.0& is& coming,&be& ready& .!
Acesso! em! 15! de! agosto! de! 2015,! disponível! em!
http://calendar.perfplanet.com/2014/httpP2P0PisPcomingPbePready/!
!
!
!
68!
Souders,! S.! (2007).! High& performance& web& sites.! San! Francisco,! CA:!
O'Reilly.!
Stefanov,!S.!(2008).!YSlow&2.0.!Acesso!em!5!de!julho!de!2015,!disponível!
em!http://www.slideshare.net/stoyan/yslowP20Ppresentation!
Stirling,!P.!(12!de!janeiro!de!2015).!Introducing&theguardian.com&responsive&
takeover.! Acesso! em! 1! de! fevereiro! de! 2015,! disponível! em! The!
Guardian:!http://next.theguardian.com/blog/responsivePtakeover/!
Thiagarajan,!N.,!Aggarwal,!G.,!Singh,!J.,!Boneh,!A.,!&!Nicoara,!A.!(2012).!
Who! Killed! My! Battery:! Analyzing! Mobile! Browser! Energy!
Consumption.!WWW&2012&–&Session:&Mobile&Web&Performance!(p.!
10).!Lyon:!WWW!2012.!
Vinegar,!B.,!&!Kovalyov!,!A.!(2013).!Third_Party&JavaScript.!San!Francisco,!
CA,!USA:!Manning.!
W3C.! (28! de! maio! de! 2013).!HTML:& The& Markup& Language& (an& HTML&
language&reference).!Acesso!em!12!de!junho!de!2015,!disponível!em!
W3C!Website:!http://www.w3.org/TR/htmlPmarkup/script.html!
W3C.! (2015).!WebPerf& Working& Group.! Acesso! em! 15! de! 1! de! 2015,!
disponível!em!http://www.w3.org/2010/webperf/!
WPO!Foundation.!(27!de!04!de!2012).!Webpagetest.!Acesso!em!12!de!03!
de! 2015,! disponível! em! Official! repository! for! WebPagetest! :!
https://github.com/WPOPFoundation/webpagetest!
Xiong,! P.! (2012).! Dynamic! monitoring,! modeling! and! management! of!
performance!and!resources!for!applications!in!the!cloud.!
Yahoo.! (20! de! Março! de! 2007).! High& Performance& Web& Sites:& The&
Importance&of& Front_End&Performance.! Acesso!em!27!de!Abril! de!
2015,! disponível! em! YUI! Blog:!
https://developer.yahoo.com/blogs/ydn/highPperformancePsitesP
importancePfrontPendPperformanceP7160.html!
!
!
!
69!
YDN.!(2007).!Best&Practices&for&Speeding&Up&Your&Web&Site.!Acesso!em!
12! de! junho! de! 2015,! disponível! em! Developer! Yahoo!:!
https://developer.yahoo.com/performance/rules.html!
YSlow.!(2007).!Acesso!em!12!de!Junho!de!2015,!disponível!em!YSlow!P!
Official!Open!Source!Project!Website:!http://yslow.org/!
!
!
!
!
70!
8# #Apêndice#
8.1# #API#REST#
O Keepfast possui uma camada composta por diversos serviços REST (API),
minimizando o acoplamento de dados entre o serviço e os aplicativos que a utilizam.
Cujas respostas estão padronizadas no formato JSON51, que irão expor os dados das
avaliações, permitindo que outras aplicações possam processá-los. Dessa forma, as
avaliações podem ser enviadas para outras aplicações ou ferramentas de exibição
de métricas, sem que essas aplicações necessitem entender os detalhes relacionados
aos modelos.
Para utilização em aplicativos externos, eles devem implementar solicitações
HTTP baseadas num conjunto de rotas disponíveis, cuja a versão mais recente está
disponível na documentação online52 do projeto.
8.1.1# #Interfaces#disponíveis#na#API#REST#
Esta seção apresenta os serviços disponíveis na API do Keepfast. Cada
seção a seguir, apresenta a ação do serviço juntamente com o formato da resposta.
Em relação aos tipos retornados, eles podem assumir os tipos: inteiros, string,
timestamp53, objectId54 que consistem uma string com 12 bytes para criação de um
número único, misto55 que consistem em um armazenamento de qualquer estrutura
suportada pelo MongoDB.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!51 http://json.org 52 http://github.com/keepfast/keepfast 53 Especificação do timestamp: http://dotat.at/tmp/ISO_8601-2004_E.pdf 54 http://docs.mongodb.org/manual/reference/object-id/ 55 http://mongoosejs.com/docs/schematypes.html
!
!
!
71!
8.1.2# #Domínios#
URI: /api/domains/
Ação: Listar todos os domínios
Estrutura: Estrutura JSON do retorno de uma lista com os domínios disponíveis
[ { "id": ObjectId, "name": STRING, "url": STRING, "updatedAt": TIMESTAMP, "createdAt": TIMESTAMP }, ... ]
8.1.3# #Páginas#de#um#domínio#
URI: /api/pages/{{ Id do domínio }}
Ação: Listar todas as páginas de um domínio.
Estrutura: Estrutura JSON do retorno de uma lista de páginas disponíveis para um
domínio.
[ { "id": ObjectId, "url": STRING, "createdAt": TIMESTAMP }, ... ]
8.1.4# #Medições#realizadas#por#uma#página#
URI: /api/measurements/{{ Id da página}}
Ação: Listar todas as medições realizadas por uma página.
Estrutura: Estrutura JSON do retorno de uma lista avaliações disponíveis para uma página.
!
!
!
72!
[ TIMESTAMP, ...
]
8.1.5# #Medições#de#uma#página#em#um#dado#tempo#
URI: /api/measurements/{{ ID da página}}/{{ Timestamp da avaliação }}
Ação: Listar todas as medições de uma página em um dado tempo.
Estrutura: JSON do retorno de uma lista de medições disponíveis para uma página
em um dado tempo.
[ { "url": STRING, "plugin": STRING, "rule": STRING, "value": MISTO, "createdAt": TIMESTAMP, "criteria": [{ "platform": STRING, "expected": MISTO, "condition": STRING, "result": BOOLEANO }, ... ] }, ... ]
8.1.6# #Regras#utilizadas#por#uma#página##
URI: /api/rules/{{ ID da página }}
Ação: Listar todas as regras utilizadas por uma página.
Estrutura: Estrutura JSON do retorno de uma lista medições disponíveis para uma página em um dado tempo.
!
!
!
73!
[ { "rule": STRING, "sensor": STRING, "score": [{ "mobile": MISTO }, { "desktop": MISTO } ] }, ... ]
!
!
!
74!
8.2# #Schema#das#entidades#no#banco#de#dados#
8.2.1# #Schema#da#entidade#domínio#no#banco#de#dados#
var mongoose = require('mongoose'); var Schema = mongoose.Schema; var domain = new Schema({ name: String, url: String, thumbnail: String, createdAt: { type: Date, default: Date.now }, updatedAt: { type: Date, default: Date.now }, disabledAt: { type: Date, default: Date.now }, disabled: Boolean });
8.2.2# #Schema#da#entidade#usuário#no#banco#de#dados#
var mongoose = require('mongoose'); var Schema = mongoose.Schema; var user = new Schema({ email: String, createdAt: { type: Date, default: Date.now }, updatedAt: { type: Date, default: Date.now }, disabledAt: { type: Date }, disabled: Boolean }); module.exports = mongoose.model('User', user);
8.2.3# #Schema#da#entidade#regra#no#banco#de#dados#
var mongoose = require('mongoose'); var Schema = mongoose.Schema; var rule = new Schema({ url: String, rule: String, plugins: String, conditions: String, createdAt: { type: Date, default: Date.now }, hidden: Boolean });
!
!
!
75!
module.exports = mongoose.model('Rule', rule);
8.2.4# #Schema#da#entidade#medição#no#banco#de#dados#
var mongoose = require('mongoose'); var Schema = mongoose.Schema; var measurement = new Schema({ url: String, plugins: String, rule: String, value: Schema.Types.Mixed, createdAt: { type: Date } }); module.exports = mongoose.model('Measurement',measurement);
8.2.5# #Schema#da#entidade#perfil#no#banco#de#dados#
var mongoose = require('mongoose'); var Schema = mongoose.Schema; var rule = new Schema({ domain: String, path: String, platforms: [String], rules: [String], createdAt: { type: Date, default: Date.now }, updatedAt: { type: Date, default: Date.now }, hiddenAt: { type: Date }, hiddenBy: Number, hidden: Boolean }); module.exports = mongoose.model('Page', page);
8.2.6# #Lista#com#outras#ferramentas#disponíveis#no#mercado#
•! Grunt-WebPagetest – Extensão para o GruntJS que faz medições usando o
WebPagetest;
•! Grunt-YSlow – Uma extensão para GruntJS para avaliar o desempenho da
página usando PhantomJS;
!
!
!
76!
•! Grunt-Perfbudget - Uma extensão para GruntJS para estimar um orçamento
de desempenho;
•! Web Tracing Framework - É um conjunto de bibliotecas, ferramentas e
visualizadores para a detecção e investigação de eventos de páginas web
complexas;
•! Yellow Lab Tools - ferramenta online para simples auditorias que revelam
problemas de desempenho no JavaScript.