E continuando meu pequeno artigo sobre performance web, quero falar sobre mais alguns aspectos que considero importantes.  Comportamentos e situações que acabam comprometendo o uso e fazendo com que muitas vezes o projeto fracasse ou não tenha o impacto esperado no público alvo.

Desenvolvedor não faz milagre, desenvolvedor faz software

O que eu quero dizer com isso? Não importa se você é Front-End, Back-End, Fullstack ou Jedi, todos nós precisamos de uma estrutura razoavelmente boa para criar o que precisa ser criado.

Nesse aspecto, sou muito privilegiado, trabalho em uma empresa onde tenho a liberdade de me fechar em uma sala quando necessário para pensar em como vou desenvolver o que preciso. Tenho uma boa estrutura, tenho liberdade e sou incentivado a trazer coisas novas sempre que possível, mas sei que esse cenário não existe em todos os lugares.

E por outro lado, temos clientes acostumados com um ritmo veloz, com entregas rápidas. E é este o ponto. Prazos insensatos geram produtos instáveis e manutenção, então, nem se fala. Estresse não combina muito com produtos bem desenvolvidos e quando a estrutura de trabalho é falha, então, aí é que o caldo engrossa.

Talvez isso não tenha a ver diretamente com o quesito performance web, mas acho que de certo modo, tem muito a ver, sim. Criar algo performático exige muitos e muitos e muitos testes, e para que estes testes sejam possíveis, precisamos minimamente de uma estrutura que seja boa o suficiente para cria-los, e quantos testes forem necessários, automatizados ou não, em dispositivos diferentes, nem que seja de forma simulada.

De novo, parece obvio? E é bastante obvio, mas nem sempre a empresa oferece uma estrutura de trabalho que compartilhe dessa ideia. É aquela história do “Ah, depois a gente vê o que faz” e nessa vai ficando de qualquer jeito.

Conheça o nível técnico do seu time

Esse ponto aqui nem deveria ser lembrado. Qualquer um que deseja desenvolver um produto, seja ele qual for, precisa saber o nível técnico do seu time para montar um cronograma plausível com a realidade. Mas nem sempre é assim, nem sempre funciona dessa forma. Por N fatores, simplesmente vende-se a ideia, e a partir disso começa o desenvolvimento.

Isso é perigoso, já vi isso acontecer e não foi uma unica vez, não! Por conta desse comportamento que se repete em diversos ambientes e empresas, decidi abordar este aspecto.

Talvez, neste momento, pra você isso nem faça muito sentido, talvez você tenha a oportunidade de trabalhar em uma empresa com ótimos desenvolvedores, gente fera que sabe o que faz. Talvez você trabalhe em um ambiente que respeite e incentive a evolução daqueles que tem menos conhecimento, talvez seja uma empresa que trabalhe até com prazos sensatos e metodologias que realmente trazem resultados.

Mas nem todo lugar é assim, nem todo ambiente de trabalho tem esse nível de maturidade, e se não levarmos em conta o nível técnico do time, nada vai sair como o planejado, se é que há algum planejamento.

Como resolver isso? O que pode ser feito para diminuir esse buraco entre nível técnico x produtividade? Bom, ao meu ver precisamos levar em consideração dois pontos principais:

• Avalie bem o nível técnico do seu time. Saiba até onde a sua equipe pode ir e quais são suas limitações. Se você faz toda a gestão, converse com cada um para entender melhor até onde ele pode ir e o que precisa para evoluir.
• Facilite o desenvolvimento da sua equipe. O que isso significa? Incentive eles a aprenderem! Você pode até se perguntar “mas isso não é obrigação deles?”. Sim, também, mas o investimento no seu time vai gerar retorno para o seu próprio negócio. Melhor uma equipe evoluindo e desenvolvendo produtos cada vez melhores, do que uma equipe estagnada e talvez até desmotivada.

De novo, isso tudo que eu disse pode parecer meio “básico”, mas já vi erros crassos em relação a montagem de cronogramas, exatamente por conta desse fator ser desconsiderado.

Desafios são importantes e fazem parte da carreira de qualquer pessoa que trabalhe com tecnologia, mas jogar o seu time na cova dos leões e falar “se vira” também não é justo. Equilíbrio é sempre o melhor caminho. Empatia gera um ambiente de trabalho mais colaborativo, evolutivo e isso reflete em produtos melhores.

Todo time tem que trabalhar de maneira próxima

Se o pessoal do design monta layouts absurdos (isso é mais comum do que parece), o pessoal do front vai ter mais dificuldade para implementar o que foi pensado, se isso já não estiver inserido no cronograma, pode acabar gerando atrasos.

Se o pessoal do front faz código sem padrão, o pessoal do back vai ter dificuldade de fazer qualquer tipo de integração e vice versa.

Se cada um trabalha de uma maneira, no final vai ser impossível juntar as peças e montar o produto final. Isso é um quesito que impacta diretamente na performance de qualquer produto web, obviamente. E quando eu falo sobre o time trabalhar de maneira mais próxima, é PENSAR EM CONJUNTO!

Incluir a galera do Front e do Back na hora de fazer o layout, desenvolver um padrão de código ou alguma metodologia que ajude a criar códigos mais fáceis de se entender.

E principalmente, tentar montar um fluxo de trabalho onde toda a equipe tenha pelo menos um minimo de sinergia. Não estou falando aqui para todo mundo ser amigo de todo mundo, mas sim para haver uma forma de trabalho onde todos entendam pelo menos o mínimo do processo do outro.

Por exemplo, o designer entender um pouco do que o back está programando, o front mostrar pro pessoal que cuida da gestão um pouco da sua forma de trabalho, enfim, ter um ambiente onde todo mundo entende pelo menos um pouco da dificuldade do outro.

Isso ajuda a desenvolver algo mais viável e com padrão. Até que todo esse fluxo de trabalho seja criado, leva tempo, até criar um padrão confiável e entendível por todos na escrita do código é necessário um tempo. É necessário desde o inicio de qualquer projeto ou nova implementação ter uma forma de trabalho muito bem definida.

Por exemplo, o pessoal de desenvolvimento se reunir com o pessoal de design logo nos primeiros estágios do projeto ajuda a elucidar quais são as dificuldades, o que deve ou não ser levado em conta e qual a melhor forma de implementar o que foi pensado.

Muito embora eu saiba que a obrigação do desenvolvedor é entregar código funcional, entendo também que este tipo de comportamento que eu exemplifiquei acima ajuda muito a criar algo mais coerente e em muito menos tempo. Todo mundo ajudando todo mundo, no final, quem vai ficar feliz é o usuário, pois com certeza o produto será um reflexo desse cenário.

Design Performático

Esse é um ponto que pode gerar muita polêmica. Por que? Porque estamos sempre buscando inovação, buscando uma nova forma de interagir com os nossos usuários, estamos sempre pensando (ou pelo menos deveríamos pensar) no usuário e na forma como ele se sente usando algo. E para um design mais rico, inclusivo e para uma experiência mais agradável, buscamos usar e abusar da criatividade, cores, imagens, animações, efeitos e etc.

Mas calma lá! Quanto mais abusamos da criatividade, mais precisamos de um dispositivo potente o suficiente para rodar esse tipo de coisa. Se você cria um site rico em animações CSS, ele provavelmente vai rodar muito bem em um Macbook Pro lançamento. Mas e aquele PC do milhão com processador Celeron? Será que vai aguentar?

Sem contar a velocidade da internet. É muito fácil acessar um site rico em elementos e animações e ter uma experiencia incrível em uma conexão de 100mb/s, mas e naquele 3G meia boca da VIVO? Pois é, quando eu falo em design performático, eu abordo o velho clichê “menos é mais”.

É pra isso que existe o conceito de Progressive Enhancement. Mas, calma! Nem todo mundo sabe o que é isso e nem todo mundo leva em consideração os dispositivos menos potentes ou ainda aquelas conexões mais lentas.

#gifAcessivel: Um gif de uma mulher falando em inglês, o que isso deveria significar?

Por isso eu abordo aqui essa ideia de um design mais limpo, seguindo a linha do design minimalista mesmo. É possível, sim, aliar um belíssimo design com um produto performático sem que você precise sacrificar o seu time de desenvolvimento em um ritual hindu para que isso ocorra. Nesse ponto, entra aquilo que eu citei acima, times trabalhando juntos, bem mais próximos! Dessa forma todo mundo pode opinar e acabar chegando em um denominador comum.

Não estou dizendo aqui que não devem existir desafios. Eles devem, sim, existir e as vezes montar um quebra cabeças desses pode ajudar o time a evoluir e encontrar novas formas de desenvolver alguma coisa. Mas isso não significa que abusar de imagens, efeitos, animações e fontes seja algo coerente.

#imagemAcessivel: Uma imagem com vários exemplos de sites que adotaram o design minimalista.

Então, além do time mais próximo, acredito que a empatia seja um fator fundamental para criar algo performático. Afinal de contas, performance é, sim, UX.

Na verdade, eu vou até além, acredito fortemente que a performance é um ponto chave que define o sucesso ou não de um produto. E não estou aqui falando de uma performance razoável, me refiro a um produto que seja performático o suficiente pra rodar bem em um Moto G1 e em um Macbook Pro ultima geração com todos os recursos mais modernos. E isso por si só já é algo bem desafiador.

Técnicas de Performance

Este é um ponto óbvio e eu vou explorar em um artigo mais técnico para quem não conhece, ou ainda para quem é novo com Performance Web, mas de qualquer modo vale o registro.

Use e abuse de todas as técnicas que ajude a melhorar a performance do seu produto. Gaste mais tempo se for necessário. Aliás, reserve um tempo só para executar testes de performance e as melhorias necessárias. Das técnicas básicas às avançadas. Das automatizações de tarefas às análises dos gráficos gerados pelas ferramentas de teste.

Teste muito, analise muito e tire tudo que for possível. Ou, ao menos crie a sensação de rapidez. O que deve ser priorizado? O que vale a pena renderizar primeiro? É possível implementar HTTP 2? Não? Então quais truques usar para melhorar a performance no HTTP 1? Enfim, vá a fundo, leve realmente em consideração a questão de performance, entenda a necessidade, analise o que pode ou não ser priorizado e como priorizar isso.

Te garanto que você só terá ganhos no final das contas. Um produto melhor deixa o usuário feliz, um usuário feliz recomenda o seu produto ou, caso seja um site somente, ele vai sair com uma boa sensação. Nossas tecnologias melhoraram, mas nossos usuários estão cada vez mais impacientes. Ter de esperar, alguns segundos que seja, é algo muitas vezes absurdo em termos de Web hoje em dia. Performance Web é muito mais do que importante, é fundamental, é um ponto chave. É obrigação.

Concluindo

Bom, é isso minha gente. Minha intenção aqui é apenas compartilhar cenários que eu vi e vivi ao longo do meu pouco tempo como desenvolvedor. Nada do que eu disse aqui é verdade absoluta, até porque existem milhares de cenários diferentes.

Meu objetivo foi apenas incentivar a reflexão, o debate, e levantar a bandeira de que a Performance Web não deve ser tão negligenciada assim (pelo menos é o que eu vejo que é por aí).

Enfim, espero que tenha te ajudado de alguma forma, e se achar válido, por favor, comente o que pensa.

Valeu!