CliqCCEE Cross-browser test & performance

ÍNDICEINTRODUÇÃO 03

ARQUITETURA DO BROWSER 04

CONFIGURAÇÕES UTILIZADAS NOS TESTES 05

PREFERÊNCIAS DOS USUÁRIOS 06

TESTES DE PERFORMANCE 07

ACID3 08

JAVASCRIPT PERFORMANCE TEST 10

CSS STRESS TEST 13

BENCHMARK PERFORMANCE 15

BROWSER LAYOUT ENGINE 23

ENTRE A APLICAÇÃO E O USUÁRIO: O DOM E O RENDERTREE 30

PERFORMANCE CLIENT-SIDE NA VISÃO DA ARQUITETURA E USER EXPERIENCE (UX) 31

PRINCIPAIS CONCLUSÕES 32

REQUISITOS DE USO DO SISTEMA 33

PARA PC COM WINDOWS 34

PARA PC COM LINUX 35

PARA MAC 36

GLOSSÁRIO 37

LINKS ÚTEIS 39

3

INTRODUÇÃO

OBJETIVOS DOS TESTES

A camada online do CliqCCEE está homologada para uso nos navegadores GoogleChrome, Internet Explorer 8 e Mozilla Firefox, selecionados pela Arquitetura desde o início doProjeto Novo SCL, levando em consideração o grande share que estes softwares possuem como preferência dos usuários.

Existem inúmeras opções de navegadores com características similares ou idênticas em rela-ção às especificações e desenvolvimento dos componentes de sua Arquitetura. Estes navega-dores são classificados como softwares parcialmente habilitados para utilização do CliqCCEE.

A diversidade de modelos e versões que foram identificadas somam cerca de 40 navegadores ativos, que seguem as mesmas especificações dos navegadores homologados pela CCEE.

O nível de detalhes dos testes realizados resultaram em uma análise minuciosa dos padrões e da performance dos navegadores disponíveis no mercado, com foco nos detalhes inerentes ao seu funcionamento: motores, interpretadores de códigos e configurações.

Em linhas gerais, este documento foi produzido para avaliar a performance do CliqCCEE nos diversos browsers e sugerir a configuração de hardware que proporcionará um ambiente con-fortável para utilização do sistema.

• Benchmark de performance e padrões dos navegadores para uso do CliqCCEE.

• Testar os browsers populares que possuem o mesmo motor de layout (engine) dos navegadores (browsers) homologados.

• Medir o nível de qualidade e performance em tempo real (RUM).

• Explorar cenários e situações de navegação nas telas do sistema, focando em usabilidade e acessibilidade do browser.

• Entender pontos críticos inerentes ao desenvolvimento client-side (JavaScript, HTML e CSS).

• Projetar combinações de situações diversas que afetam a experiência do usuário – hardware, rede, segurança, etc.

• Definir o requisito mínimo e o recomendado para melhor aproveitamento do sistema.

• Colaborar com recomendações e melhorias importantes para futuras versões do sistema.

Visando alcançar o maior número de interessados que queiram entender sobre o cross-browser, elaboramos um glossário com os termos e siglas mais utilizados neste documento.

Consulte a página 38

4

Arquitetura do BrowserEste infográfico demonstra de maneira simplificada como é a Arquitetura de um navegador web.

Interface de Usuário - É o espaço onde a interação entre os usuários e o navegador ocorre. A maioria dos navegadores têm entradas comuns para interface do usuário como uma barra de endereços, botões de avanço e retorno, página inicial, atualização, favoritos, etc.

Browser Engine - Motor encarregado pela comunicação de entradas de Interface do Usuário em conjunto com o Rendering Engine (Motor de Renderização). Seu papel é consultar e manipular o Rendering Engine de acordo com as requisições que ocorrem entre a aplicação e a interface de usuário.

Rendering Engine - Componente responsável por exibir o conteúdo solicitado na tela, primeiramente analisando o código recebido e, em seguida, usando os estilos para construir parte da árvore de renderização do layout que exibe o conteúdo na tela. Está entrelaçado com execuções do inter-pretador de JavaScript em carregamentos específicos que ocorrem em tempo de execução (runtime).

Networking - A fração do código escrito no navegador, responsável por enviar chamadas de rede diferentes. Por exemplo o envio de solicitações HTTP para o servidor.

JavaScript Engine - Motor Interpretador de JavaScript do navegador.

Backend UI - Camada de Interface Usuário padrão de cada navegador como caixas de confirmação, janelas, abas e botões.

Data Storage - É um pequeno banco de dados criado no disco local do computador onde o navegador está instalado. Este banco de dados armazena arquivos diversos, como cache, cookies, etc.

Processo DOM

Quando termina o processamento(evento DOMContentReady)

USER INTERFACE

Rendering Engine

JavaScript EngineMotor de interpretação do JavaScript

Motor de Renderização

Networking

Data Storage

UI Backend

Browser EngineMotor do Browser

5

Workstation

HARDWARE BROWSERS

SISTEMAS OPERACIONAIS

CONFIGURAÇÕES UTILIZADAS NOS TESTES

Homologados

Google Chrome

Outros

Versões: 5.0 +

Google ChromeVersões: 3.6 +

Internet ExplorerVersões: 8

SafariVersões: 4.0 +

OperaVersões: 11.X

Internet ExplorerVersões: 7, 9 e 10 (preview)

Google Chrome CanaryVersões: 24.X

Android Webkit BrowserVersões: 4.0.3

SkyfireVersões: 2.0

Dolphin HDVersões: 5.4.1

Dell - PCIntel Core i71.5GB RAM

HP - NotebookCentrino X86 - 2394 Mhz1GB RAM

Apple Ipad 2 - WIFI - 64GB

Windows XP Profissional (SP3) Mac OS X Version 10.7.4 (Lion)

Apple iMac Intel Core i3 - 3.06 GHz4GB 1333MHZ RAM DDR3

Apple Macbook Pro Intel Core 2 Duo - 2.6 GHz8GB 1333 MHZ RAM DDR3

HP - PCPentium 4 HT - 3.0 GHz1GB 400MHZ RAM DDR

Samsung Galaxy GT 1000

Windows Vista Home

Samsung Galaxy Tab

Windows 7 Professional

Apple Iphone 4 - 16GB

Sony Ericsson Xperia X10

Samsung Galaxy SII

Mac OS X Version 10.6.8 (Snow Leopard)

Windows 8 (Release Preview - Set. 2012)

Linux Redhat 5.7 (Tikanga) 5.1.1 e 6.0 2.3 Gingerbread

6

PREFERÊNCIAS DOS USUÁRIOS

7

ACID31234

JavaScript Performance Test

CSS Stress Test

Benchmark PerformanceRUM – Real User Monitoring - Monitoramento de performance dos browsers em tempo real.

Testando a compatibilidade para padrões W3C.

Testando os interpretadores de script.

Estressando a camada visual.

Testes de performanceCRUZAMENTO DE TESTES PARA MENSURAR A PERFORMANCE ECOMPATIBILIDADE DE CADA NAVEGADOR

5 Browser layout engineO que há dentro de cada browser e versões, quais as vantagens e restrições.

MétodoPara validar a aderência das características dos navegadores quanto às necessidades requeri-das pelo CliqCCEE e, consequentemente promover a melhor experiência para o usuário, foram utilizadas ferramentas que comparam os pontos chave da estrutura de cada browser.

Os três testes iniciais: Acid3, JavaScript Performance Test e CCS Stress Test testam as características específicas dos browsers que, quando cruzados no tópico 4 Benchmark Pefor-mance, determinam o grau de conforto do usuário no acesso ao CliqCCEE.

Após o cruzamento dos resultados temos a conclusão de quais os melhores browsers, configu-rações e características gerais mapeadas e descritas no tópico 5 Browser layout engine.

8

ACID31Testando a compatibilidade para padrões Web Standard.

Especificações testadas:

O Acid3 Test é referência em teste de compatibilidade com padrões web (Web Standards) para navegadores. O teste oferece uma suite com 100 diferentes tipos de testes de browser, com alto nível de exigência em relação aos padrões e especificações estipuladas.

O CliqCCEE é um sistema desenvolvido dentro dos padrões de tecnologia Web Standard, especificados pelo consórcio internacional W3C, que visa desenvolver padrões para a criação e a interpretação de conteúdos para a Web publicando um conjunto de normas, diretrizes e recomendações de caráter técnico. Padrões como HTML, XHTML e CSS são muito populares, contudo, em muitos casos são utilizados de forma incorreta, devido ao desconhecimento da especificação.

Os padrões de acessibilidade e usabilidade são publicados pelo Web Standards Project para expor o grau de compatibilidade necessário no desenvolvimento com os padrões web existen-tes dos navegadores.

Fundada em 1998, The Web Standards Project (WaSP) luta para elaborar e manter normas que reduzam o custo e a complexidade de desenvolvimento, aumentando a acessibilidade e viabilidade a longo prazo de qualquer aplicação publicada na web. Trabalham em conjunto com empresas fabricantes de navegadores.

Voltando ao cenário de testes, é frequente que desenvolvedores de browser entreguem relea-ses e correções que atendem aos padrões estabelecidos pelo consórcio, além de otimizações feitas nos motores.

Na prática, a compatibilidade do browser influencia diretamente na performance, pois está atrelada à capacidade de interpretação dos motores de layout.

Quanto maior o grau de compatibilidade (de 0 a 100), melhor será o tempo que o navegador levará para interpretar o “texto“ enviado pelo servidor até a renderização do layout.

• DOM2 Core

• DOM2 Events

• DOM2 HTML

• DOM2 Range

• DOM2 Style (getComputedStyle, …)

• DOM2 Traversal (NodeIterator, TreeWalker)

• DOM2 Views (defaultView)

• ECMAScript

• HTML4 (<object>, <iframe>, …)

• HTTP (Content-Type, 404, …)

• Media Queries

• Selectors (:lang, :nth-child(), combinators, dynamic changes, …)

• XHTML 1.0

• CSS2 (@font-face)

• CSS2.1 (’inline-block’, ‘pre-wrap’, parsing…)

• CSS3 Color (rgba(), hsla(), …)

• CSS3 UI (’cursor’)

• data: URIs

• SVG (SVG Animation, SVG Fonts, …)

Exemplo da tela de resultado

9

ACID31Resultados:

10

Testa a performance dos interpretadores de script dosprincipais navegadores.

2 JavaScript Performance Test

O Java Script é a principal linguagem de programação client-side para páginas web. O de-sempenho do interpretador de javascript é uma característica importante de um navegador e deve ser levada em consideração no desenvolvimento de uma aplicação, como no caso do CliqCCEE. A utilização de um grande volume de JavaScript impacta no tempo de carregamento das telas e no processamento das informações no client-side (DOM). A expectativa dos usuários é que suas requisições sejam rapidamente carregadas e, para isso, é fundamental saber otimizar a comunicação de entregas entre o servidor e o browser. No caso, este benckmark demonstra o desempenho dos motores de layout dos diversos nave-gadores, auxiliando o usuário na escolha da melhor opção, considerando suas possibilidades e necessidades. Também é importante avaliar aspectos como a capacidade do hardware utilizado. Em certos casos, é perceptível que alguns navegadores mais velozes apresentem um consu-mo maior de memória da máquina, ou seja, para usufruir de um maior desempenho, o equipa-mento precisa ter recomendações técnicas adequadas. Usuários com máquinas antigas enfrentarão dificuldades em relação ao desempenho, pois os padrões atuais dos navegadores exigem mais da memória e do processador. Sobre o resultado do teste, é perceptível que o JavaScript Engine V8 utilizado pelo Chrome e o SquirrelFish implementado no Safari são os mais rápidos em comparação com navegadores como o Firefox, IE8 e Opera. No entanto, os resultados do Internet Explorer 10 demonstram uma relevante melhora que colocará o browser da Microsoft entre os mais rápidos quando for lançado, mas isso exigirá máquinas mais atualizadas.

Como funciona?Os testes são automatizados através dos próprios browsers, utilizando frameworks em JavaScript

executados através de um HTML simples.

O benchmark testa a capacidade do núcleo da linguagem JavaScript para medir a capacidade

de tempo de leitura de cada browser. O teste compara as diferenças entre os navegadores e as

diferenças entre versões do mesmo navegador incluindo testes de descompressão de código,

criptografia, JSON, e as mais complexas interpretações que são relevantes para interpretação da

linguagem.

Parte das referências de benchmark é disponibilizada pelos próprios desenvolvedores (Mozilla,

Google, Microsoft) e o resultado pode sofrer leves variações, consequentes dos processos ativos

na máquina, rede, memória, etc.

Portanto, o resultado é a média de 3 rodadas, mantendo um intervalo de confiança de 95% para

assertividade do resultado.

Com exceção do Internet Explorer, a maioria das versões dos browsers possuem o mesmo inter-

pretador de JavaScript, mas é importante ressaltar que qualquer mudança de versão do browser

pode trazer pequenas variações nos resultados deste teste.

Entenda o que é o JavaScript e JavaScript Engine no glossário do documento.

Página 38

11

Resultados:2 JavaScript Performance Test

12

2 JavaScript Performance Test

Análise de performance dos Interpretadores de JavaScript

Iniciamos o comparativo com uma análise resumida dos principais JavaScript Engines homolo-gados ou habilitados para o CliqCCEE: SpiderMonkey e V8.

O Firefox utiliza no seu engine o SpiderMonkey, desenvolvido pela Mozilla Corporation.

O Google Chrome opta pelo Engine V8, open source, desenvolvido pela própria comunidade do Google, dentre outras empresas consorciadas. O V8 é a promessa do Google em manter um dos mais rápidos interpretadores de JavaScript do mercado, mas está diante de uma cres-cente batalha com o interpretador do Safari (browser da Apple), seu concorrente direto pelo uso do mesmo Layout Engine (Webkit). O Safari desenvolve o JavaScript Engine SquirrelFish, que obteve os melhores resultados de performance.

Entre os mais performáticos, a maior diferença está na compilação. SpiderMonkey foi escrito para o Netscape (browser antigo) que funciona compilando o JavaScript para uma linguagem intermediária que é interpretada. A proposta do V8 é acelerar o desempenho de uma aplicação compilando JavaScript para instruções de máquina, eliminando a necessidade de um intérpre-te.

Durante a compilação e recompilação, eles realizam várias otimizações. As otimizações são usualmente específicas para cada Browser Engine (Gecko vs. Webkit), paralelo à forma como eles são construídos junto com o motor de renderização. As otimizações não são um grande diferencial, já que geralmente o foco em aspectos semelhantes, como melhorar a coleta de lixo e o equilíbrio em tempo de execução, entre muitas outras otimizações ainda não evoluiram tanto quanto poderiam.

Diferenças de desempenho entre os V8 e SpiderMonkey são mínimas. É interessante notar que quando o V8 foi introduzido teve sua publicidade apoiada no desempenho do Google Chrome. Atualizações subsequentes para SpiderMonkey, incluindo TraceMonkey e JagerMonkey nas últimas versões do Firefox, ajudaram a fechar a lacuna, tornando-o tão performático quanto seu concorrente no conjunto da obra.

Nos browser baseados no Layout Engine Webkit (Chrome e Safari) há uma sutíl vantagem do interpretador JavaScript SquirrelFish em relação ao V8 do Chrome. O interpretador utilizado pelo Safari, apesar de ser cross-plataform, tem seu diferencial verificado somente em desktops Mac OS X devido às diferenças arquiteturais com Windows.

A Microsoft, desenvolvedora do Internet Explorer, atualmente é responsável pelo Chakra (JavaScript Engine das versões do IE9 e IE10), que oferece desempenho e performance compe-titivo com os concorrentes.

Porém, o que leva aos resultados ruins do Internet Explorer é a capacidade de tempo de inter-pretação da versão 8 do browser da Microsoft.

O CliqCCEE é configurado para renderizar em modo IE8, independente das versões posteriores do browser. Isso torna sua interpretação lenta em relação às versões recentes.Este hoje pode ser considerado nosso principal ponto de melhoria para o futuro pois o desempe-nho da versão 8 afeta a experiência do usuário.

Alguns fatores sobre o Internet Explorer 8 justificam o resultado inferior aos concorrentes. O fato do IE8 não incluir nenhuma funcionalidade de script nativa, como todos os outros, expõe a fragilidade da versão com o uso de JavaScript. No caso do IE8, o MSHTML.dll expõe uma API que permite que um programador desenvolva o script que deverá ser encarregado por acessar a árvore DOM (Document Object Model). O browser inclui ligações para o motor Active Scripting, que é uma parte do Microsoft Windows e permite que qualquer linguagem implementada como este módulo possa ser utilizada para desenvolvimento client-side. Por consequência, apenas os módulos de JScript e VBScript são fornecidos; implementações de terceiros como ScreamingMonkey (para suporte ECMAScript 4) também podem ser usados . Há um excesso de dependência do sistema operacional e, por consequência, do uso do processador da máqui-na. Por outro lado, nos browsers concorrentes a exigência é maior em memória, uma tendência que já é realidade nas versões mais recentes do IE.

A guerra para criar o melhor interpretador irá favorecer aplicações complexas com muito uso de JavaScript, como é o caso do CliqCCEE.

Mas isso só será concretizado quando os browsers mais recentes tiverem estabelecido na prefe-rência do usuário.

13

Estressando a camada visual do navegador.

Todo o layout da aplicação é formatado por meio dos arquivos de CSS (Cascading Style Sheets), uma linguagem que agrega seletores e atributos que deverão desencadear na forma-tação visual da tela. Esta é a parte do código que de fato dá forma ao conteúdo.

Um dos principais problemas de padrões nos diferentes browsers está relacionado com esta linguagem, em maior grau com o Internet Explorer devido à ausência de adequação aos padrões da web (W3C), como demonstrado no teste 1. Acid3. Aqui começa o cross-browser de uma interface: arquivos para as diferentes versões do Internet Explorer são construídos e importados como exceção pelo browser. Neste caso somente o Internet Explorer entende o comentário destacado:

Aplicado em doses incorretas ou não equilibradas, o CSS pode comprometer sensivel-mente o tempo de carregamento de uma página. Algumas práticas não recomendas, mesmo que necessárias, aumentam o problema, como, por exemplo, a adição de Style inline em runtime - prática que também é comum em plugins de jQuery (framework de JavaScript). O CSS Stress Test é uma forma de medir a capacidade do browser em lidar com as situações dos diversos seletores disponíveis nesta linguagem. É um método interessante para identificar os seletores específicos que afetam a perfor-mance por navegador a fim de melhorar o código. Navegadores baseados no Layout Engine Webkit, como o Chrome e o Safari, trazem a melhor experiência visual para as aplicações web. O teste pode ser expandido para os navegadores nativos do dispositivos mobile iOS e Android. Neste teste, o Opera Browser teve o pior desempenho entre as versões mais recentes.

Como funciona?440 seletores são disparados numa cadeia de 40 a 50 testes - a quantidade de testes varia confor-

me a capacidade de interpretação trazida pelo motor do navegador.

O framework de teste indexa todos os elementos e suas classes - classe por classe - posterior-

mente as remove para calcular o tempo que leva para rolar a página. A “classe“ é um atributo do

HTML utilizado para o CSS da página identificar o que representa aquela parte do layout. Ex. Textos,

posicionamento de caixas, campos, listas, etc.

Os seletores que economizam uma quantia considerável de tempo quando removidos indicam a

área problema para aquele browser.

Foi extraída a média dos 3 melhores resultados num total de 6 testes por navegador, em até 3

versões diferentes, sistema operacional Windows e Mac OS X.

3 CSS Stress Test

14

Resultados:3 CSS Stress Test

15

RUM – Real User MonitoringMonitoramento de performance dos browsers em tempo real.

4 Benchmark PerformancePara o comparativo de performance dos navegadores foi planejada uma PoC pela equipe de Arquitetura do projeto, utilizando a ferramenta NewRelic monitorando acessos em tempo real (RUM) em uma aplicação local.

O principal objetivo era simular cenários de requisição de telas inciais, telas comple-xas e telas de resposta do sistema e fazer um comparativo de performance por browser. Foram criados 3 cenários baseados no feedback dos usuários em tempo de homologação, mas as melhorias sugeridas no final deste relatório aplicam-se para todo o sistema.

Como funciona?Os agents do software configurados na aplicação coletam as informações dos processos que são

executados no aplicativo. A implementação é similar ao Google Analytics. Através da injeção de

JavaScript nas telas em runtime (tempo de execução), que envia as informações coletadas nos

processamentos que ocorrem na aplicação (client-side), cada browser é identificado por um

user-agent que nada mais é que a configuração do motor e do esquema para cada tipo de

dispositivo ou sistema operacional. As informações coletadas são enviadas de forma assíncrona

para não influenciar o tempo de carregamento das páginas.

A camada de rede inclui o tempo de redirecionamentos e solicitação / recebimento do HTML. Não

inclui o tempo de serviço para ativos estáticos, o que é ótimo pois traz resultados mais puros.

O Monitoramento em Tempo Real possui inteligência para ignorar páginas em cache, detectando

as páginas que já haviam sido processadas, comparando o tempo total do Back-end com o tempo

de fila da aplicação. Quando a soma de aplicação e tempo de entrega é maior que o tempo de

Back-end total, o resultado assume que a página foi armazenada em cache e modifica a fórmula

de cálculo. De qualquer forma, cada cenário foi rodado com o cache resetado e todas as extensões

e os processos do navegador foram finalizados antes do início do monitoramento.

O monitoramento foi realizado com 2 usuários ativos e foram cruzados os tempos de resposta da

aplicação, com características e oscilações da rede, árvore de processamento da aplicação feita

pelo browser (DOM) e o resultado do carregamento da página para o usuário em cinco escalas:

1. Tempo médio de Front-end

Calcula o tempo de processamento do navegador (DOM) com o tempo que o usuário recebe a

página processada para a etapa de carregamento.

2. Tempo médio de carregamento das páginas

Tempo médio que cada navegador levou para carregar o HTML processado - Página Carregada /

Entrega da tela.

3. Percentual de tempo do Front-end

Percentual que o Front-end corresponde no carregamento da tela da aplicação. Comparativo que

leva em conta inúmeros cruzamentos, que vão desde a inteligência de leitura do motor do browser

à qualidade e o tipo de implementação que o programador utilizou.

4. Percentual de carregamento das páginas

Representa em percentual o quanto a tela impacta a experiência do usuário no tempo de carrega-

mento desde a requisição inicial (clique no link).

5. Rendimento

Capacidade e rendimento do browser calculados em PPM (páginas por minuto). Estes números

não foram importantes na nossa análise, mas são interessantes de serem analisados num futuro

monitoramento em tempo real do sistema.

16

4 Benchmark Performance

RUM – Real User MonitoringResumo do processo de temporização de carregamento da página.

17


Cenários aplicados no monitoramento:Telas de Pesquisa

Módulo:Cadastro Corporativo

1. Requisitar somente a tela inicial de todas Funcionalidades do módulo.

Inclusão de Ativo Pesquisar e Editar Dados Horários

Módulo:Medição Contábil

Módulo:Contratos

1 2 3

1. Tela Inicial de Medição Contábil (Pesquisa)

2. Menu de Ações: “Incluir novo Ativo”

3. Incluir Início de Vigência

4. Incluir Hora

5. Incluir Código

6. Incluir Nome Completo

7. Incluir Nome Resumido

8. Selecionar o Tipo de Ativo

9. Selecionar Status

10. Clicar em Gravar

11. Voltar para tela de pesquisa

12. Pesquisar o item incluso e aguardar resultado

Cache Limpo e extensões desativadas para todos os browsers.

Código do Agente: 11 Sigla: CEB

Cache limpo somente na primeira Tela e extensões desativadas para todos os browsers.

Cache Limpo e extensões desativadas para todos os browsers.

Código do Agente: 11 Sigla: CEB

1. Gerenciamento de Contratos

2. Consultar Contratos do Agente

3. Clicar em “Editar” Contrato CCEAl 6069

4. Abrir a aba “Montantes de Energia”

5. Clicar no ícone Editar para abrir janela modal de Dados Horários

6. Clicar na aba “Patamar/MWmédio” (Confirmar janela de diálogo)

7. Clicar na aba “Patamar/MWh” (Confirmar janela de diálogo)

8. Fechar Janela e Voltar para tela inicial de Gerencia-mento de Contratos.

18


Tempo médio do Front-end

Resultados:

Cálculo do tempo de processamento do navegador (DOM) com o tempo que o usuário recebe a página processada para a etapa de carregamento da tela (page load time).

19


Tempo médio de carregamento da página

Resultados:

Após a aplicação dos três cenários, o gráfico demonstra o tempo médio que cada navegador levou para interpretar o HTML processado pelo DOM para renderização da página e entrega da tela.

20


Percentual de tempo do Front-end da aplicação

Resultados:

Percentual que o Front-end corresponde no carregamento da tela da aplicação cruzando os processos (tempo de rede, tempo do servidor de aplicação, etc.).

21


Percentual de carregamento das páginas

Resultados:

Percentual de quanto a tela representa no tempo desde a requisição (clique inicial) para o carregamento da tela.

22


Gráfico de conclusão do RUM (Real User Monitoring)

Overview do RUM

CONCLUSÕESComo analisado nos testes anteriores,

os browsers com motores Webkit (Chrome e Safari) proporcionam maior agilidade no

processamento e carregamento das telas para o usuário, ao contrário do Internet Explorer em

todas as versões testadas (7, 8, 9 e 10) que principalmente no percentual de Front-end

aumenta o tempo de espera do usuário.

Portanto, o teste traduz em suas variáveis que entre os browsers homologados para o

uso do CliqCCEE o Google Chrome é o que oferece a melhor performance e experiência

para o usuário em tempo de processamento e carregamento da tela.

O gráfico ao lado foi extraído da ferramenta de monitoramento para demonstrar um overview das oscilações e picos ocorridos durante os cenários de testes no período de uma hora. A visualização mostra os quatro processos monitorados.

23

5 Browser layout engine

Relatório do Engine

Observações

Foram testados todos os componentes de interface do CliqCCEE, considerando os aspectos não-funcionais, usabilidade e acessibilidade do browser. O CliqCCEE também foi homologado através de testes exploratórios utilizando o browser Google Chrome a partir da versão 10 (atualmente na versão 22 no Windows).

A homologação garante funcionamento do Layout da aplicação nos browsers baseados no Layout Engine Webkit para desktop, como por exemplo o Safari (a partir da versão 4), navegador nativo do sistema operacional Mac OS, que também possui instalação para versões do Windows (a partir do XP).

O resultado do teste evidencia que poucos problemas são encontrados utilizando os nave-gadores WebKit-based nas versões mais estáveis em dispositivos móveis.

O WebKit é o principal motor da atualidade. No Brasil representa aproximadamente 35% dos navegadores utilizados pelos usuários, mesmo assim ainda perde no ambiente corpo-rativo. É mantido e melhorado por grandes empresas da indústria de desenvolvimento de software e hardware, dentre as principais Nokia, Google e Apple inc., o que nos faz crer que em breve poderá dividir a liderança também no mercado corporativo, como já ganhou

Foram encontradas algumas restrições de uso para os browsers Webkit em dispositivos mobile no uso do CliqCCEE. Os problemas de usabilidade mais comuns foram identificados em browsers que utilizam atributos e tags específicas para navegação com mouse. Um exemplo é o ToolTip que não é identificado devido à ausência de atributos CSS específicos para telas “Touch”. Se o usuário não tiver familiaridade com o sistema, e o ícone não tiver um desenho de fácil identificação, não será possível saber qual a ação.o.

força entre os usuários domésticos.

É caracterizado principalmente pela boa performance em múltiplas plataformas, pela popularidade dos browsers Chrome, Safari e browsers nativos de IOS e Android. O que os diferencia é a implementação das especificações do JavaScript Engine, além das caracte-rísticas específicas de cada User Interface.

Devido à acirrada disputa entre os browsers Webkit-based, os principais desenvolvedores vem aprimorando os recursos com extrema velocidade, oferecendo cada vez mais recursos para softwares Web-Standard (como o CliqCCEE) e, consequentemente, em performance. Além disso, força as melhoras significativas no Trident (motor do Internet Explorer da Microsoft) que já é notado na versão 10, nativo na instalação do Windows 8 (release preview).

A percepção que se tem dos atributos dos browsers Webkit é que estes oferecem a melhor experiência de navegação para os usuários de internet em termos de performance e visual.

Restrições de uso na funcionalidade de upload de arquivo que não funcionam em tablets e smartphones.

A interface gráfica do CliqCCEE é 100% funcional em todos os navegadores Webkit testa-dos, mas a recomendação é pelo uso do Chrome no sistema operacional Windows.

LAYOUTENGINE

WebKit

Browsers principais Browsers Alternativos Mobile Engine Developer(s) Sistema Operacional

Chrome e Safari Cross-plataformComodo Dragon,

RockMelt, SRWare Iron e iCab

iOS, Android, BlackBerry Tablet OS, WebOS, Dolphin

HD, Chronium e Steel

Apple, KDE, Nokia, Goo-gle, RIM, Palm, Samsung,

outros

O que diferencia cada browser e suas versões.Quais as vantagens e problemas para o CliqCCEE.

24


Gecko

Browsers principais


Observações


Browsers Alternativos Mobile Engine Developer(s) Sistema Operacional

Foram testados componentes de interface considerando os aspectos não-funcionais, usabilidade e acessibilidade, client-side, importantes para o uso do CliqCCEE. O sistema também foi homologado através de testes de cenário e testes exploratórios utilizando o browser Mozilla Firefox a partir das versões 3.6 (atualmente na versão 15.0.1).

Foram encontradas pequenas falhas nas versões 6.0.2 até a 8.0.1 relativas à versão do Layout Engine, corrigidas e estabilizadas nas versões posteriores. Basicamente, os problemas são causados quando o browser é iniciado em Modo de Segurança. Outros problemas como lentidão na navegação causados por um bug no scroll, também foram corrigidos nas versões recentes.

O uso dos browsers desenvolvidos com o Layout Engine Gecko garante funcionamento do sistema nos browsers para desktop, e os principais recursos são acessíveis em tablets com Android e IOS, destacado pela excelente performance.

Foram encontradas algumas restrições de uso para os browsers Gecko em dispositivos mobile.

Problemas de usabilidade mais comuns foram identificados em browsers que utilizam atri-butos e tags específicas para navegação com mouse. O mais comum é o ToolTip que não é identificado. Se o usuário não tiver familiaridade com o sistema, e o ícone não tiver um desenho de fácil identificação não será possível saber qual a ação em questão.

O resultado do teste evidência que poucos problemas são encontrados utilizando os Nave-gadores Gecko-based, como o Firefox, nas versões mais estáveis em dispositívos móveis.

O principal browser Gecko-based é o Firefox, desenvolvido pela Mozilla Corporation. Trata-se da comunidade mais ativa no mercado de browsers, sofre constantes evoluções e oferece suporte às tecnologias web mais modernas, como HTML5 e CSS3. A alternativa mais popular para tablets e smartphones Android e IOS é o Skyfire.

Os browsers com Layout Engine Gecko oferecem uma ótima experiência de navegação para os usuários de internet em desktop e dispositivos móveis, além de oferecer configura-ções seguras com boa estabilidade.

Outro problema é o fato da funcionalidade de UPLOAD de arquivo não funcionar em tablets e smartphones.

A interface gráfica do CliqCCEE é 100% funcional em todos os browsers Gecko testados sem a necessidade de arquivos CSS e JS para cross-browser.

Firefox Cross-plataformCamino e K-Meleon Firefox e Skyfire Mozilla Corporation

LAYOUTENGINE

25


Trident

Browsers principais



Foram testados todos os componentes de interface do CliqCCEE, considerando os aspec-tos não-funcionais, usabilidade e acessibilidade, client-side, em Layout Engine Trident, motor nativo das versões 7, 8, 9 e 10 do Internet Explorer. O motor deste browser sofrerá inúmeros ajustes antes do lançamento oficial da versão 10, mas já traz bons resultados.

O CliqCCEE será lançado com a configuração padrão de front-end e back-end para o motor do Internet Explorer 8. Isto significa que mesmo utilizando as versões 9 e 10 do IE, o sistema estará carregando o motor de layout da versão 8 padrão. Tendo em vista esta particularidade, foram realizados testes com objetivo de avaliar qual seria o impacto de uso das versões mais recentes do IE e que tipo de ajustes seriam necessários.

Foram encontradas pequenas variações visuais no sistema devido à característica do motor do IE8 não ser um browser 100% Web Standard. Mas não fere aspectos funcionais do CliqCCEE.

O IE7 possui a interface funcional, com alguns bugs e foi descartada em dezembro de 2011 quando foram encontrados problemas no uso da tag <canvas> aplicadas nos módulos que utilizam a Topologia (Medição Física e Medição Contábil). O plugin jQuery chamado Ecotree realiza manipulações no browser que não são suportadas na versão 7.

Outros fatores foram relevantes para a decisão como segurança, performance e até o baixo percentual de uso desta versão por usuários que acessam o ambiente da CCEE. O IE7 deixou de ser suportado pela Microsoft recentemente.

Internet Explorer Microsoft WindowsMSN Explorer, AOL Explorer

(descontinuado) e Real-Player

Internet Explorer Mobile Microsoft

Document ModeA simulação é gerada através do próprio browser habilitando o módulo de desenvolvedo-res (F12) e configurando o Document Mode (Modo de Documento) para a renderização standard de cada versão específica.

Outro software utilizado é o IETester na versão de Windows XP.

A prova limpa é realizada utilizando a versão nativa IE8 no Windows XP.

Não foi testado o plugin IETab que roda o motor do IE no Chrome por questões de confia-bilidade no desenvolvimento e resultados diferentes.

Não foram testadas as versões alternativas devido ao share insignificante que represen-tam. Caso o usuário opte por alguns destes browsers em vez do IE, o próprio front-end da aplicação está configurado para realizar o switch para o IE8 Standard, mas não há garantia de integral funcionamento, uma vez que o suporte destes browsers é mínimo.

Observações

LAYOUTENGINE


26


Presto

Browsers principais

DESCRIÇÃO DO ENGINE


Foram testados todos os componentes de interface, considerando os aspectos não-funcio-nais, usabilidade e acessibilidade, client-side, utilizados no CliqCCEE

O resultado do teste evidência que poucos problemas são encontrados utilizando o Browser Opera Presto-based nas versões mais estáveis em desktop.

Já nas versões mobile foram encontrados inúmeros problemas, dentre estes se destaca a péssima performance, limitações na compilação do Java Script.

O que motivou o teste é o fato do motor do Opera não fazer parte da premissa de homolo-gação do CliqCCEE, mas corresponde *2.2% de share em âmbito mundial, em desktops, mas é altamente difundido em multiplas plataformas (desktops, tablets e até games), Com exceção das versões Opera-mini ou Mobile com motores limitados, os navegadores com motor Presto são os que possuem maior compatibilidade cross-plataform.

O Presto-based foi sucessivamente migrando seu ECMAScript e tem estabilizado um dos motores mais rápidos e seguros entre os maiores concorrentes.

Opera Browser Cross-PlataformNão há. Opera-mini e Opera Mobile Opera Software

OBSERVAÇÕES

Pequenos problemas de acessibilidade do browser nos componentes de formulário - nave-gação por teclado - não interferem a funcionalidade mas mudam os atalhos do teclado. O que motiva as mudanças é o fato do fornecedor do Engine dar maior foco nas especifica-ções de plataformas “Touch” onde o atalho de teclado é abolido.

Foi identificado que é uma característica do browser quando foram subtraídas as funções js e CSS do browser, testando no HTML puro.

Não é recomendado o uso do Opera mobile ou Opera-mini para manipulação e opera-ção do CliqCCEE pois a maioria dos componentes do sistema é construído a partir de funções de JavaScript e o suporte destes browsers é bastante limitado. O Opera na sua versão mobile limita sua especificação para os scripts e, em determinado ponto da renderização, inevitavelmente trava a tela do usuário.

A interface gráfica do CliqCCEE no Opera para Desktop é 100% funcional. No navegador mobile a interface possui restrições citadas neste relatório, fazendo com que o uso não seja recomendado.

LAYOUTENGINE


27


CONSUMO DE MEMÓRIAConsumo de memória na

primeira execução (KB)20.644

Consumo com tela incial padrão do Pack (KB)

Tela incial padrão do Pack - biblioteca_p_consulta/index.htm

48.304

70.264

92.004

16.676

70.120

38.297

55.500

64.660

124.588

Avaliado somente a versão Internet Explorer 8

Homologados para o CliqCCEE

Faz parte da rotina do usuário a utilização dos recursos de abas, extensões, addons, rss, dentre outras features oferecidas. A exigência dos nave-gadores em relação aos recursos da máquina foi mensurada a partir do consumo de memória RAM durante a sua primeira execução, com a página inicial em branco e após o carregamento de uma das telas do Pack de Design do CliqCCEE. Todos os recursos não nativos do navegador foram desa-bilitados para obtenção dos resultados.


28


SEGURANÇA PRINCIPAIS CARACTERÍSTICAS DE SEGURANÇA

Conta com um dispositivo para criptografar os dados pessoais salvos nele.

Oferece um gerenciador de permissões. É possível definir se o navegador deve memorizar senhas, compartilhar localização, armazenar cookies, abrir popups e preservar conteúdo offline.

Possui o filtro Smartscreen, que tem o objetivo de avisar o usuário quando um link for redirecioná-lo para um endereço de confiança duvidosa. Por sua vez, a Proteção Contra Rastreamento permite que você defina quais informações pessoais podem ser coletadas por sites de terceiros.Leia mais em: http://windows.microsoft.com/pt-BR/windows-vista/Security-and-privacy-features-in--Internet-Explorer-8

Painel “Privacidade“ desse programa mostra que tipo de dados os sites estão armazenando, dando a opção para que você os remova. É possível personalizar as configurações dos cookies e decidir se os sites têm permissão para solicitar informações sobre a sua localização.

A partir da versão 10.6 foi incorporado um recurso de proteção contra a ação de malwares desenvolvi-do pela AVG. O aplicativo ainda disponibiliza um mecanismo de criptografia para as senhas salvas.

Homologados para o CliqCCEEPara mais informações recomendamos a documentação da NSS Labs:https://www.nsslabs.com/reports/categories/endpoint-security/browser-security

Navegar em aplicações web exige cuidados espe-

cíficos com a segurança. Estamos constantemente

suscetíveis aos ataques de hackers e malwares. Para

evitar problemas é importante que os navegadores

possuam mecanismos que auxiliem na proteção das

informações. Mas a segurança pode ser falha caso

não haja a preocupação mínima do usuário.

Analisamos as funções de navegação privada, ge-

renciamento de senhas salvas e bloqueio de popups,

além de outras funções de defesa que um ou outro

navegador oferece.

Todos os navegadores disponibilizaram um modo de

navegação privada, no qual é possível navegar por

aplicações sem que o browser deixe registrado seu

histórico e ações. Mas as configurações de segurança

só tem efetividade quando são reconhecidas e aplica-

das pelos usuários.

Todos os navegadores operam em compatibilidade

com certificados e protocolos de segurança conven-

cionais da internet (SSL, TSL, etc.).


29


Avaliado somente a versão Internet Explorer 8

Característica positiva do navegador

Velocidade de navegação e

carregamento de telas, pouco con-sumo de memória

durante o uso, interface limpa e suporte contínuo

da comunidade de desenvolvedores.

Ponto negativo

Estabilidade, adequação aos

padrões web gera pouca quebra

de layout, maior usabilidade e facilidade de

configuração sem conhecimentos

avançados.

Integração com Windows o torna

prático para o uso. Permite

gerenciamento de seguraça de forma simples para o usuário.

Navegação muito rápida e ótima

integração entre dispositivos

Apple garante configurações personalizadas para desktop e

mobile.

Bom desempe-nho para nave-gação em telas pouco comple-xas. Recursos de integração

entre diferentes sistemas opera-

cionais

CARACTERÍSTICASQUE SE DESTACAM EM CADA BROWSER

Excesso de atualizações o

torna vulnerável a erros, painel

de configurações avançadas pouco amigável, erros de

certificado.

Alto consumo de memória para pro-cessar documen-

tos HTML exigindo mais da máquina

na primeira iniciali-zação do browser.

Lentidão, travamento,

problemas de compatibilidade falta de suporte

do desenvolvedor para correções

de bugs, erros de script e padrões

web falhos.

Versão para Windows ainda

não é estável como no Mac OS X e a instalação não é muito prática. As

correções enviadas pelo desenvolvedor

geralmente são insuficientes.

Motor de Renderi-zação precisa de aprimoramentos,

falhas de JavaScript, interface pouco intui-tiva com pequenos

bugs visuais e falhas de acessibilidade.

Homologados para o CliqCCEE

Definir qual navegador é mais adequado para as necessi-

dades deve sempre levar em consideração a produtividade

e a disponibilidade de recursos que a workstation oferece.

O quadro ao lado resume quais são as principais carac-

terísticas mais marcantes para cada opção.


30

E O USUÁRIOENTRE A APLICAÇÃO

O DOME O RENDERTree Render Tree

DOM

Criado pelo W3C, O DOM (Modelo de Objetos de Documentos) é uma multi-plataforma que representa como as marcações em HTML, XHTML e XML são organizadas e lidas pelo navegador. É o macro--processo do navegador encarregado de analisar o código HTML, recuperar e executar scripts síncro-nos. Por este motivo é interpretado como a principal inteligência do Front-end que fica entre o client e a aplicação. Pode ser melhor compreendido se comparado com uma árvore de processamento junto aos nós da aplicação que correspondem ao conteúdo carregado pelas marcações do HTML - conforme demonstrado na Figura 1. O DOM é a base para uma outra árvore que é o que realmente um browser monta na tela, a Árvore de Renderização - Render Tree.

Uma vez indexadas, as marcações HTML, XHTML, se transformam em elementos de uma árvore mani-pulável via API – que é o que fazemos quando usamos programas ou scripts para alterar funcionalidades de uma página: conteúdo, estrutura ou folha de estilo. Os browsers que atendem ao esquema “Web Standard” são capazes de processar aplicações como o CliqCCEE pois trazem na implementação a capacidade de interpretação que segue as especificações internacionais da W3C.

Ainda antes da apresentação da tela para o usuário há um processo chamado Render Tree - Árvore de Renderização, que funciona de forma parecida com o DOM. O Render Tree se encarrega de processar os objetos script e folhas de estilo (CSS) - aquilo de fato transforma os elementos HTML da tela em layout (cores, formas, imagens).

A Render Tree é a parte mais importante do processo de renderização. Bem parecida com a árvore DOM, cada objeto corresponde a nós de documentos, elementos ou textos. A diferença é que q Render Tree possui tambem objetos que não possuem nós na árvore DOM, como scripts e folhas de estilos.

O processo de criação da Render Tree passa pelos seguintes passos:1. Attachment: Conforme o resumo da Figura 2, após finalizar a análise do DOM e a criação de seus nós, os navegadores chamam um método attach para começar a renderização. O attach víncula primeiramente as folhas de estilo na árvore DOM e começa a estilização do layout da página. O attach é top down, criando sempre inicialmente os nós parent e depois seus descendentes (nós filhos). Por isso muitas vezes vemos primeiro à página sem layout e depois a mesma aparece estilizada

2. RenderStyle.h que vai guardar objetos de referência com cada uma das propriedades CSS do docu-mento. O nó criado no DOM é verificado no documento de CSS e, caso existam propriedades que incidam naquele elemento, é o momento de aplicar. Esta propriedade fica salva dentro da Render Tree até que ela seja destruída ou que este valor seja alterado por algum script em tempo de execução.

3. CSS Box Model: Após o método RenderStyle ser criado, ele é acessado via RenderObject. O Box model é usado para posicionar um elemento dentro da página.

Todo browser tem uma lista de elementos HTML suportados. Quando o seu markup possui tags presentes na lista, a árvore DOM é montada e o processo de 1. Attachment começa logo na sequência e os estilos são aplicados, dando continuidade a criação da Render Tree.

O grande problema é que cada navegador tem a sua própria lista, que trata situações similares de ma-neiras diferentes. Sabemos que o navegador que mais apresenta problemas para as situações acima é o Internet Explorer, mas todos os navegadores apresentam particularidades quando um elemento não está em sua lista de elementos permitidos, e precisa de um trabalho para fazer tudo acontecer na Render Tree como deve ser feito. Estas particularidades desencadeiam o trabalho de cross-browser no desenvolvimen-to da aplicação.

Figura 1

Figura 2

processamento

DOM Tree

Render Tree Paint!

Style struct

31

PERFORMANCE CLIENT-SIDE

ARQUITETURA ENA VISÃO DA USER EXPERIENCE (UX)

Problemas de cross-browser ocorrem porque no momento do desenvolvimento poucos se preo-cupam em entender a interpretação dos browsers e suas dezenas de versões, as combinações com diferentes sistemas operacionais e o quanto isso influencia na aplicação.

Esta análise não é atemporal, e o resultado dos testes mostram que não haverá tão cedo uma resposta definitiva sobre qual navegador é o mais rápido, exatamente porque performance é apenas um dos parâmetros que afetam a experiência do usuário com nossos sistemas. Com as novas possibilidades de gadgets, hardware e softwares disponíveis, não cabe mais a quem entrega a solução, limitar ou obrigar o usuário a utilizar browser “A” ou “B”. Nosso papel é mostrar quais são os requisitos mínimos que oferecem suporte e recomendar a melhor configu-ração para obter desempenho e produtividade, sem deixar de lado questões como segurança e limitações do ambiente utilizado pelo usuário.

Tudo isso sem esquecer que neste processo há variáveis não gerenciáveis, como por exemplo a grande frequência em que ocorrem as atualizações dos browsers. Constantemente os dispo-sitivos sofrem alterações de hardware e as preferências do usuário flutuam com as tendências e mudanças que ocorrem a todo instante. Não podemos deixar de lado o fato das grandes empresas evitarem o aprofundamento sobre o assunto e manterem o conhecido navegador da Microsoft como única opção por motivos diversos, mas o principal é a ausência de conhecimento e acompanhamento das tendências da tecnologia web somadas com as preferências do usuário.

Fato é que a guerra dos browsers se tornou um “calo no pé“ de quem não se preocupa com Front-end.

Por fim, não existem formas de impedir que um usuário escolha por browsers alternativos, ou pouco conhecido, mas são desenvolvidos utilizando o mesmo Engine (motor) dos navegadores homologados pelo Projeto Novo SCL para o CliqCCEE. Neste caso, o melhor caminho é co-nhecer as preferências e limitações do usuário, saber quais aspectos envolvem uma recomen-dação e trabalhar para oferecer suporte às suas necessidades.

As tabelas de compatibilidade, o acompanhamento das comunidades e o conhecimento das atu-alizações ajudam a mitigar problemas e a escrever códigos compatíveis para qualquer browser.

Este é o principal motivo pelo qual os testes deste documento foram focados nos Motores do browsers, estudo de interpretadores de JavaScript, teste de estresse da camada visual e user--agent dos navegadores.

32

PRINCIPAIS CONCLUSÕES

• Os browsers homologados possuem compatibilidade para os padrões Web Standard Projetct.

• Entre os browsers homologados o Google Chrome é a alternativa que oferecerá melhor performan-ce e experiência em qualquer sistema operacional.

• O Mozilla Firefox da versão 3.6 à 15.0.1 é uma opção estável para usuários que navegam em desktops mais atualizados e com boa disponibilidade de recursos como memória e processador. A sugestão é mantê-lo sempre atualizado. Todas as versões são disponibilizadas pela comunidade de desenvolvedores (Mozilla) no site oficial.

• o Internet Explorer 8 é um navegador de implementação ultrapassada que oferece a pior perfor-mance entre os homologados para o CliqCCEE, mas é a alternativa mais atualizada da Microsoft para usuários que ainda utilizam o sistema operacional WIndows XP. A utilização das versões mais recen-tes, como o IE9, pouco irá contribuir em termos de performance visto que a aplicação esta configurada para carregar qualquer versão no Modo de Documento Internet Explorer 8, mas oferece melhorias em termos de segurança.

• No quesito performance, restrição funcionais, segurança e usabilidade o Internet Explorer 7 é o pior navegador para uso do CliqcCEE. A versão não está homologada para uso.

• O Opera apresenta interface gráfica funcional mas carece de melhorias na implementação dos moto-rers ficando atrás apenas do Internet Explorer. O Opera não está homologado para uso do CliqCCEE.

• Os navegadores que possuem o Browser Engine idêntico ao Google Chrome (Webkit), como Safari da Apple, Android Webkit Browser, dentre outros, são boas alternativas para o uso do sistema, mas é preciso levar em consideração que ainda não se tratam de navegadores homologados e que nos dispositivos mobile sofrem com restrições de uso para algumas funcionalidades, como por exemplo a importação de arquivos.

33

Os requisitos mínimos são configurações básicas estipuladas para a utilização do CliqCCEE. Os requisitos recomendados são configurações que otimizam o uso do sistema, garantindo melhor performance e estabilidade.

Critérios que estabelecem as tabelas de requisitos levam em consideração:

1. As configurações que permitem a instalação de navegadores com motores cross-plataform nos quais foram homologados pelo Projeto Novo SCL para o CliqCCEE;

2. Versão do sistema operacional compatível com navegadores homologados que possibilitam a instalação;

3. Configurações universais para navegação web em sistemas baseados em Web Standard;

4. Resultado de performance apresentados pelas configuração;

Para homologação do sistema foram utilizados os sistemas operacionais Windows XP e Windows 7.

Estes requisitos serão revistos a cada 12 meses.

REQUISITOS DE USO DO SISTEMA

34

Para PC com WindowsComponentes: Requisitos mínimos: Requisitos recomendados:

Processador

RAM

Sistema operacional

Internet

Resolução da tela

Browsers

PC com processador 1.4 GHz Intel Pentium 4 ou superior

Internet Explorer 8Google Chrome 5.xMozilla Firefox 3.6

* Google Chrome 17.x +* Mozzila Firefox 14.x +Internet Explorer 8 +

Processador 1.83GHz Intel Core Duo ou superior

* É sempre recomendada a instalação da última versão estável.

• JavaScript e Cookies habilitados• Modo de Compatibilidade do Internet Explorer deve estar desativado ou configurado para o modo standard da versão 8• Não é necessário Flash Player

512MB 2GB ou mais

Windows XP Service Pack 2+ Windows XP Professional Service Pack 2+Windows VistaWindows 7

512 Kbps2MB (banda larga) DSL/cabo, T1 ou mais rápida

Placa de vídeo 16 bits (high color) ou superior 24 bits (true color) ou superior

1024x768 pixels 1280x1024 pixels ou superior

Complemento


Para melhor experiência do usuário, recomendamos o uso dos navegadores mais modernos, como Google Chrome 17.x, Firefox 3.6 ou superior.

35

Para PC com LinuxComponentes: Requisitos mínimos: Requisitos recomendados:

Processador

RAM

Sistema operacional

Internet

Resolução da tela

Browsers

Intel Pentium 3/Athlon 64 ou posterior

Mozilla Firefox 3.6 Google Chrome 17.x +Mozzila Firefox 15 +

Processador Intel Core Duo ou superior

• JavaScript e Cookies habilitados• NetworkManager 0.7 ou posterior• DBus 1.0 ou posterior• HAL 0.5.8 ou posterior• GNOME 2.16 ou posterior

512MB 2GB ou mais

Linux 2.2.14 ou superiorUbuntu 10.04+Debian 6+OpenSuSE 11.3+Fedora Linux 14


Placa de vídeo 16 bits (high color) ou superior 24 bits (true color) ou superior


Complemento



36

Para MACComponentes: Requisitos mínimos: Requisitos recomendados:

Processador

RAM

Sistema operacional

Internet

Resolução da tela

Browsers

Computador Macintosh com processador Intel x86

Mozilla Firefox 3.6 ou superior Google Chrome 17.x +Mozzila Firefox 14.x +Safari 4 +

Processador Intel Core 2 Duo - 2.6 GHz

• JavaScript e Cookies habilitados• Não é necessário Flash Player• Não recomendado processadores PowerPC devido as restrições e ausência de suporte dos browsers

1GB 2GB ou mais

Mac OS X 10.5 (Leopard) Mac OS X 10.6 (Snow Leopard)Mac OS X 10.7 (Lion)Mac OS X 10.8 (Lion Montain)


Placa de vídeo 128MB de memória de vídeo 256MB ou mais de memória de vídeo


Complemento



37

GlossárioVisando alcançar o maior número de interessados que queiram entender sobre o cross-browser, elaboramos um glossário com os termos utilizados neste documento.

Browser (ou Web Browser): também conhecido como Navegador, é um programa de computador que habilita seus usuários a interagirem com documentos virtuais da Internet, também conhecidos como páginas da web. Ex. Internet Explorer, Chrome, Firefox.

Browser Engine: Termo atribuído ao motor de interpretação de um navegador para formatação de um conteúdo estático através da comunicação entre a Interface do usuário (UI) e a manipulação do motor de renderização (Rendering Engine). Também é implementado em softwares de e-mail, ou qualquer aplicação que precisa carregar um conteúdo web. Pode ser descrito como Layout Engine, Motor de Interpretação de Layout ou Web Browser Engine.

Client-side: expressão em inglês que, traduzida, é “lado cliente”. É usado em tecnologia para designar uma aplicação (site, software, plugin, etc) que é executada no micro do usuário e não no servidor que hospeda a aplicação.

Cross-browser: capacidade de uma aplicação web em suportar múltiplos navegadores e que segue as especificações do W3C.

CSS: linguagem de estilo, popularmente conhecido como Folha de estilo ou Cascata de estilos. É utilizado para definir a apresentação de documentos escritos em HTML, XML ou qualquer linguagem de marcação. É uma prática de programação caracterizada pela unificação dos elementos visuais da interface usuário em um ou mais arquivos, excluindo a marcação inline de documentos, o que facilita sua manutenção.O Doctype informado ou a ausência dele determina o quirks mode ou o strict mode modificando o modo como o CSS é interpretado e a página desenhada.

DOM: Document Object Model - Modelo de Objetos de Documentos. Uma das especificações da W3C, independente de plataforma e linguagem, onde pode-se dinamicamente alterar e editar a estrutura, conteúdo e estilo de um documento eletrônico, permitindo que o documento seja mais tarde processado e os resulta-dos desse processamento, incorporados de volta ao próprio documento. A API DOM oferece uma maneira padrão de acessar os elementos de um documento, além de poder trabalhar com cada um desses elemen-tos separadamente, e por esses motivos criar páginas altamente dinâmicas para a web e aplicações móveis.

Doctype: é a marcação inicial do tipo de documento que o browser deverá interpretar e rigorosamente deve ser a primeira linha do código. A ausência de doctype não costuma causar problemas funcionais, mas sua reação em cadeia pode chegar a tal, visto que o browser não identificará qual o tipo de marcação a aplicação esta entregando. O CliqCCEE e o Portal da CCEE são escritos em XHTML 1.0 Transitional/EN. O XHTML é o doctype que antecede o HTML5.

ECMAScript: linguagem baseada em scripts, padronizada pela Ecma International na especificação ECMA-262. A linguagem é bastante usada em tecnologias para Internet, sendo esta base para a criação do JavaScript/JScript e também do ActionScript (Flash)

Front-End e Back-end: referem-se às etapas inicial e final do processo. Em resumo o front-end é a interface do usuário, uma camada responsável por coletar a entrada em várias formas e processá-la para adequá-la a uma especificação útil ao back-end. O front-end é uma espécie de interface entre o usuário e o back-end. Exemplo de linguagens de Front-End: JavaScript, HTML, CSS. Exemplos de linguagem de back-end: JSP, ASP, PHP.

HTML: Linguagem de marcação de hipertexto utilizada para construir as páginas web.

JavaScript ou JS: é a principal linguagem de programação client-side para páginas web. A linguagem é baseada em ECMAScript padronizada pela Ecma Internacional nas especificações ECMA-262 e e ISO/IEC 16262. Possui suporte à programação funcional e apresenta recursos como fechamentos e funções de alta ordem comumente indisponíveis em linguagens populares como Java e C++.

JavaScript Engine: Motor de interpretação de JavaScript que faz parte do conjunto de módulos imple-mentados em um navegador que seguem uma especificação ECMAScript. Também descrito como Motor de JavaScript ou interpretador de JavaScript.

Layout Engine: É o mesmo que Browser Engine, porém é comum que desenvolvedores de browser utili-zem um ou outro termo.

Language-client: conhecido como client-side scripting ou Linguagem do Cliente, é a linguagem que é executada no computador do próprio usuário usada nas situações em que a linguagem server-side não tem alcance. Entre as linguagens há o JavaScript, que é a única linguagem que realmente roda no navegador do usuário. Através do JavaScript é possível manipular a página do usuário diretamente, fazendo coisas dinâmicas que vão desde mudar o valor de um campo do formulário até criar uma área redimensionável que pode ser arrastada pela página.

Navegador: a mesma coisa que Browser.

PoC: Prova de conceito ou PoC é uma sigla utilizada para denominar um modelo de demonstração, que possa provar um conceito que pretendemos adotar ou implementar. Em termos tecnológicos é utilizado para um teste resumido da implementação de uma aplicação antes da sua adoção.

Renderização: Termo comum utilizado em Front-end ou desenvolvimento web, trata-se da finalização do processamento de uma tela que esta pronta para ser carregada no browser do usuário. Quando o processa-mento da aplicação está concluído ocorre o que se chama de “renderização”.

Rendering Engine: Motor responsável por exibir o conteúdo solicitado na tela, os conteúdos de linguagens de estilo (CSS), linguagens de marcação (HTML, XML, XHTML), conteúdos de mídia (imagens, vídeos) e construir a árvore de renderização.

38

GlossárioVisando alcançar o maior número de interessados que queiram entender sobre o cross-browser, elaboramos um glossário com os termos utilizados neste documento.

RUM: Real User Monitoring - Monitoramento de usuários em tempo real.

UX: Sigla que significa Experiência do Usuário, do inglês User Experience.

W3C: Trata-se de um consórcio internacional com cerca de 300 membros, incluindo grandes empresas, órgãos governamentais e organizações independentes, que visa desenvolver padrões para a criação e a interpretação de conteúdos para a Web. É um dever de todo o desenvolvedor Web respeitar e seguir os padrões de acessibilidade do W3C, pois de outro modo poderá impor barreiras tecnológicas a diversas pes-soas, desestimulando e até mesmo impedindo o acesso a suas páginas. Para mais informações consulte: http://www.w3.org/. As telas do CliqCCEE procuram seguir estes padrões na implementação.

Web Standards: é um conjunto de especificações, normas, diretrizes, recomendações, notas, artigos, tuto-riais e afins de caráter técnico, produzidos pela W3C. É destinado a orientar desenvolvedores e projetistas para o uso de práticas que possibilitem a criação de uma Web acessível a todos.

39

Links úteisRelação de links que apoiaram no entendimento de cross-browser:

W3Chttp://www.w3c.org/

WaSPhttp:// www.webstandards.org/

ECMA Internacionalhttp://www.ecma-international.org/

Web browser DOM supporthttp://www.webdevout.net/browser-support-dom

Layout Engine

Webkit (Chrome & Safari)http://www.webkit.org/

Gecko (Firefox developer)https://developer.mozilla.org/en-US/docs/Gecko

Internet Explorer Architecturehttp://msdn.microsoft.com/en-us/library/aa741312(v=vs.85).aspx

Preto (Opera developer specifications)http://www.opera.com/docs/specs/

Lista de Layout Enginehttp://en.wikipedia.org/wiki/List_of_web_browser_engines

Comparação de Layout Enginehttp://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML)

JavaScript Engine

SpiderMonkeyhttps://developer.mozilla.org/en-US/docs/SpiderMonkey

V8https://developers.google.com/v8/intro

SquirrelFishhttps://www.webkit.org/blog/189/announcing-squirrelfish/

Carakanhttp://www.opera.com/docs/browserjs/

GARQ - Gerência de Arquitetura • CEAR - Coordenação Estratégia e Arquitetura

Date post:	29-Jun-2015
Category:	Design
Upload:	julio-ferracini
View:	1,191 times
Download:	3 times