Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

RSS iMasters

[Resolvido] Desenvolvendo perfis CSS para diversão e lucro - nota

Por , em Desenvolvimento frontend

Recommended Posts

RSS iMasters    5

RSS iMasters
Postado

Esta é a segunda parte do meu artigo sobre desenvolvimento de perfis em CSS, composto de várias notas sobre a criação de perfis que utilizam o WebKit e as ferramentas do Opera. A primeira parte está disponível aqui.

 

?

9. No Opera, o nível de zoom da página afeta o desempenho do layout. Diminuir o zoom aumenta o tempo de renderização. Isso é bastante compreensível, pois existem mais coisas a serem processadas na mesma área. Pode parecer um detalhe insignificante, mas, para manter os testes consistentes, é importante certificar-se de que o nível de zoom não atrapalhe seus cálculos. Tive que refazer todos os meus testes depois de descobrir isso, só para ter certeza de que eu não estou comparando laranjas com toranjas.

 

Falando de zoom, pode fazer sentido testar a diminuição de fonte e ver como ela afeta o desempenho geral de um aplicativo - ainda é utilizável?

 

10. No Opera, redimensionar a janela do navegador não afeta o desempenho de renderização. Parece que cálculos de layout/paint/style não é afetado pelo tamanho da janela.

 

11. No Chrome, redimensionar a janela do navegador afeta a performance. Talvez o Chrome seja mais esperto do que o Opera, e só renderiza áreas visíveis.

 

12. No Opera, recargas de página afetam negativamente o desempenho. A progressão é visivelmente linear. Você pode ver no gráfico como o tempo de renderização aumenta lentamente mais de 40 recargas de página (cada um desses retângulos vermelhos na parte inferior corresponde ao carregamento da página seguido pela espera de poucos segundos). O tempo de impressão torna-se quase três vezes mais lento no final. Parece quase que a página está vazando. Por precaução, usei sempre a média dos primeiros ~ 5 resultados para obter números ?frescos".

45866.png

Script usado para testar (recarregar a página):

window.onload = function() {

setTimeout(function() {

var match = location.href.match(/\?(\d+)$/);

var index = match ? parseInt(match[1]) : 0;

var numReloads = 10;

index++;

if (index < numReloads) {

location.href = location.href.replace(/\?\d+$/, '') + '?' + index;

}

}, 5000);

};

Eu não verifiquei se recargas de página afetam o desempenho no WebKit/Chrome.

 

13. Um padrão interessante com que me deparei foi um bloco SASS assim:

a.remove > * {

/* some styles */

.ie7 & {

margin-right: 0.25em;

}

}

...o que geraria um CSS como este:

a.remove > * { /* some styles */ }

.ie7 a.remove > * { margin-right: 0.25em }

Observe o seletor adicional do IE7 e como ele tem uma regra universal. Sabemos que regras universais são lentas devido à associação direita-esquerda e, assim, todos os navegadores, exceto o IE7 (no qual .ie7 - provavelmente no elemento <body> - é um suposto alvo) estão tendo um impacto no desempenho desnecessário. Esse é, obviamente, o pior caso de IE7-targeted selector.

 

Os outros eram mais inocentes:

.steps {

li {

/* some styles */

.ie7 & {

zoom: 1;

}

}

}

...que produz CSS tipo:

.steps li { /* some styles */ }

.ie7 .steps li { zoom: 1 }

Mas mesmo nesse caso o mecanismo precisa verificar cada elemento <li> (que está dentro do elemento com a classe "steps") até que ele "perceba" que não há nenhum elemento com a classe "ie7" mais acima na árvore.

 

No meu caso, houve perto de uma centena de tais seletores .Ie7 e .Ie8 baseados em uma folha de estilo final. Alguns deles eram universais. A correção foi simples - mover todos os estilos relacionados ao IE para um estilo separado, incluído via comentários condicionais. Como resultado havia muito menos seletores para analisar, combinar e aplicar.

 

Infelizmente, esse tipo de otimização vem com um preço. Descobri que colocar estilos relacionados ao IE próximos dos originais é realmente uma solução mais sustentável. Ao alterar/adicionar/remover algo no futuro, só há um lugar para mudar, e assim há menos chance de esquecer as correções relacionadas ao IE. Talvez, no futuro, ferramentas como SASS poderão otimizar declarações como essas fora do arquivo principal e para outros incluídos de maneira condicional.

 

14. No Chrome (e WebKit), você pode usar a aba "Timeline" em Developer Tools para obter informações semelhantes sobre recálculo de performance de repaint/reflow/style. A aba Timeline permite que você exporte dados como JSON. A primeira vez que vi isso ser feito foi por Marcel Duran no Performance Calendar deste ano. Marcel utilizou Node.js e um script para analisar e extrair dados.

 

Infelizmente, o script estava incluindo o tempo de recálculo de estilos no tempo do "layout" - algo que eu queria evitar. Também quis evitar recargas de página (e obtendo médio/mediano de tempo). Então eu o ajustei para uma versão muito mais simples. Ela interage todos os dados, filtrando entradas relacionadas a Repaint, Layout e Cálculo de Estilo; então resume o tempo total para cada uma dessas entradas:

 

var LOGS = './logs/',

fs = require('fs'),

files = fs.readdirSync(LOGS);

 

files.forEach(function (file, index) {

var content = fs.readFileSync(LOGS + file),

log,

times = {

Layout: 0,

RecalculateStyles: 0,

Paint: 0

};

 

try {

log = JSON.parse(content);

}

catch(err) {

console.log('Error parsing', file, ' ', err.message);

}

if (!log || !log.length) return;

 

log.forEach(function (item) {

if (item.type in times) {

times[item.type] += item.endTime - item.startTime;

}

});

 

console.log('\nStats for', file);

console.log('\n Layout\t\t', times.Layout.toFixed(2), 'ms');

console.log(' Recalculate Styles\t', times.RecalculateStyles.toFixed(2), 'ms');

console.log(' Paint\t\t\t', times.Paint.toFixed(2), 'ms\n');

console.log(' Total\t\t\t', (times.Layout + times.RecalculateStyles + times.Paint).toFixed(2), 'ms\n');

});

Depois de salvar dados da timeline e executar um script, você poderia obter informações como esta:

Layout                      6.64 ms

Recalculate Styles 0.00 ms

Paint 114.69 ms

 

Total 121.33 ms

Usando a Timeline do Chrome e esse script, acionei o botão de teste original que testei antes no Opera e consegui isto:

45869.png

 

Da mesma forma que no Opera, border-radius estava entre os de desempenho mais baixo. No entanto, linear-gradiente foi comparativamente mais dispendioso do que no Opera, e no box-shadow foi muito superior text-shadow.

 

Uma coisa para se observar sobre a Timeline é que ela só fornece informações de "Layout", enquanto o profiler do Opera tem "Reflow" e "Layout". Não tenho certeza se os dados de "reflow" análogos aos do Opera são incluído no "Layout" do WebKit, ou se ele é descartado. Uma coisa para se descobrir no futuro, a fim de se obter os resultados corretos dos testes.

 

15. Quando estava quase terminando minhas descobertas, o WebKit acrescentou o profiler seletor  semelhante ao do Opera.

45868.png

 

Não consegui fazer muitos testes com ele, mas notei uma coisa interessante. Selector Matching no WebKit foi ligeiramente mais rápido do que o do Opera. O mesmo documento - aquele aplicativo em uma página na qual eu estava trabalhando (antes de otimizações) - levou 1.144ms no selector matching no Opera, e apenas 18ms no WebKit. Essa é uma diferença de ~ 65x. Ou algo está fora nos cálculos de um dos mecanismos, ou o WebKit é realmente muito, muito mais rápido em selector matching. Pelo que vale, a timeline do Chrome foi mostrando ~ 37ms para recálculo total (muito mais perto do WebKit) e ~ 52ms para repaint (compare com "Paint" do Opera de 225ms total; diferente, mas muito mais próximo). Não consegui salvar os dados da "Timeline" no WebKit, por isso não pude verificar números de reflow e repaint lá.

 

Resumo

  • Reduza o número total de seletores (incluindo estilos relacionados ao IE: .ie7 .foo .bar)
  • Evite seletores universais (incluindo seletores de atributo não qualificados: [type = "url"])
  • Zoom da página afeta o desempenho do CSS em alguns browsers (por exemplo, Opera)
  • Iamanho da janela afeta o desempenho do CSS em alguns browsers (por exemplo, Chrome)
  • Recarregar a página pode afetar negativamente o desempenho do CSS em alguns browsers (por exemplo, Opera)
  • "Border-radius" e "transform" estão entre as propriedades mais dispendiosas (pelo menos em WebKit e Opera)
  • Aba "Timeline" em browsers baseados no WebKit pode esclarecer os tempos totais de recalc/reflow/repaint
  • Selector Matching é muito mais rápido no WebKit

Perguntas

Como terminei essas observações, tenho toneladas de outras questões relacionadas ao desempenho do CSS:

 

  • Os valores dos atributos citados vs. não citados (por exemplo, [type = search] vs [type = "search"]). Como isso afeta o desempenho do Selector Matching?
  • Quais são as características de desempenho de múltiplos box-shadows/text-shadows/backgrounds? 1 text-shadow vs 3 vs 5.
  • Desempenho de pseudo seletores (: before,: after).
  • Como os diferentes valores de border-radius afetam o desempenho? Radius mais altos são mais dispendiosos? Será que crescem linearmente?
  • A declaração !important influencia o desempenho? Como?
  • A aceleração do hardware influencia o desempenho? Como?
  • Os estilos são similarmente dispendiosos em combinações diferentes? (por exemplo, text-shadow com gradiente linear vs text-shadow em uma cor de fundo)

Futuro

À medida que nossas páginas/apps tornam-se mais interativas, a complexidade do CSS aumenta, e os navegadores começam a suportar cada vez mais funcionalidades ?avançadas? do CSS, o desempenho dele provavelmente se tornará ainda mais importante. As ferramentas existentes estão apenas analisando a superfície. Precisamos de ferramentas para testes móveis e algumas em mais browsers (IE, Firefox). Criei um ticket para a Mozilla, então talvez veremos algo surgir daí em breve. Adoraria ver os dados de desempenho do CSS expostos através de scripts, para que pudéssemos utilizá-lo em ferramentas como jsperf.com. Enquanto isso, há muitos testes para serem feitos com os profilers já existentes. Então o que você está esperando?

 

?

Texto original disponível em http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

 

 

 

 

 

 

 

 

http://imasters.com.br/artigo/24015/css/desenvolvendo-perfis-css-para-diversao-e-lucro-notas-de-otimizacao-parte-02

Compartilhar este post

Link para o post
Compartilhar em outros sites
Ir para a lista de tópicos Desenvolvimento frontend
×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.

  Aceito