Caso você tenha perdido, eu estava no DotNetRocks de quarta-feira falando sobre otimização de desempenho na web . Foi uma ótima conversa com Carl e Richard e eu gostaria que pudéssemos ter conversado por um dia ou mais.
O episódio recebeu alguns bons comentários até agora. Gostaria de responder ao comentário de Tim Clark aqui no Blog porque minha resposta não será sucinta. Seu comentário ecoa pontos de recuo comuns que recebo de desenvolvedores corporativos o tempo todo. Interessante, os desenvolvedores da web (esses são desenvolvedores que não são desenvolvedores de back-end da Teade) abraçam minha posição, que se relaciona aos comentários completos que recebi na entrevista.
Meu ponto de vista principal é que nosso O objetivo principal das aplicações web é envolver os usuários e resolver seus problemas. Esta é a essência do primeiro desenvolvimento do usuário. Infelizmente, o desenvolvedor médio segue a abordagem do desenvolvedor primeiro, deixando o usuário sofrer.
Antes de entrar nos pontos e respostas, deixe-me apresentar um pouco de onde estou vindo. Eu amei jQuery , ainda amo, mas não uso nem tenho por cerca de quatro anos. Eu já estive em uma conferência jQuery e tive a sorte de promover uma amizade com Dave Metvin, presidente da fundação jQuery nos últimos anos.
jQuery nos deu exatamente o que precisávamos há uma década. Desde então, os navegadores corrigiram os problemas que o jQuery foi criado para resolver. Gosto de dizer que existem cerca de 3 dúzias de APIs que todo desenvolvedor web deve conhecer e que você pode fazer cerca de 99% do que já usou o jQuery para fazer.
Eu gosto do utilitário do jQuery, mas o tamanho é impressionante, maior do que a maioria dos aplicativos completos que construo atualmente. Então, numa tarde de sábado, construí um dólarbill, um substituto do jQuery. Existem outras bibliotecas semelhantes disponíveis, Zepto e ShoeString Vêm à mente. Então, existem sites como You Might Not Need jQuery , Você pode não precisar dos plug-ins jQuery e, claro, VanillaJS . Existem outras opções mais eficientes disponíveis que o jQuery.
Por que parei de usar jQuery? Tive que começar a construir aplicativos da web que carregassem rapidamente em dispositivos móveis. Carregar através de 3G e um dispositivo móvel pode ser doloroso se você carregar muito JavaScript, CSS e imagens. Esperar 10-20 segundos mata sua eficácia. Por exemplo, sabemos se sua página não foi renderizada por 3 segundos, quase os usuários saíram. Isso é verdade no celular, pois os usuários esperam que as páginas sejam renderizadas tão rápido, senão mais rápido, do que em seus desktops. Em outras palavras, há muita pressão sobre os desenvolvedores e arquitetos para fornecer experiências amigáveis ao usuário. Infelizmente, 99% da web falha e está piorando. Velocidade é uma vantagem competitiva, aproveite-a.
Se você reservar um tempo para visitar o HttpArchive, poderá ver como o peso da página e o tempo de carregamento têm aumentado constantemente. Hoje, a página inicial média dos 250.000 principais sites não caberia em um disquete de alta densidade de 3,5″. Se você se aprofundar, sem dúvida, descobrirá que a URL média na Internet é muito maior do que a média de 2 MB agora relatada pelo HttpArchive. Assim como nossos sites estão ficando mais gordos e menos saudáveis, também estão nossos sites.
Os comentários de Tim são de natureza egoísta e não pretendem ser mesquinhos, mas para definir uma perspectiva. Seus comentários são tudo focado no desenvolvedor, não no cliente. Aqui está o principal problema. Os desenvolvedores e arquitetos precisam perceber que não importa em que nível concentramos nossas habilidades de desenvolvimento, o objetivo é fornecer uma experiência de usuário de qualidade que constrói fidelidade à marca e, claro, receita.
Em uma apresentação da ThoughtWorks sobre princípios de UX , o ponto 2 afirma o seguinte:
Se você avaliar os pontos de Tim, eles são todos sobre o desenvolvedor e ser capaz de contratar o que eu classificaria como desenvolvedores não qualificados. Entrevisto candidatos a clientes e acho difícil encontrar alguém que conheça alguma das APIs principais. Eles geralmente respondem’você acabou de usar jQuery’.
Isso não se limita a jQuery, Angular, React, Ember, etc, todos encorajam os desenvolvedores a conhecer apenas o framework e não o que está realmente acontecendo. Depois de aprender o punhado de APIs e adotar algumas técnicas básicas de arquitetura modular, você verá como é fácil criar grandes aplicativos com muito pouco código. Você também começa a ver por que a proliferação de estruturas de fast food é ruim.
De volta ao motivo pelo qual parei de usar jQuery. As aplicações que recebi no período de 2010 me forçaram a descobrir uma maneira melhor. Usar ferramentas como WebPageTest me permitiu ver o inchaço das páginas estava me matando. Uma investigação mais aprofundada revelou que jQuery estava me matando e eu estava triste. Mas dentro de algumas semanas, fui capaz de substituir tudo, exceto AJAX. Eu logo mudei para Reqwest e nunca mais voltei para jQuery.
Mas havia mais. Eu senti a pressão sendo aplicada por aplicativos nativos móveis. Principalmente na experiência do usuário. Depois de avaliar o que a maioria dos aplicativos nativos estava fazendo, senti que quase todos os componentes UX e recursos de layout poderiam ser replicados usando HTML5 e CSS em todos os navegadores e plataformas. Em particular, foi a transição da página. Isso me levou a criar aplicativos de página única.
Na época, não havia nada para fazer referência como uma prática recomendada de SPA. Então criei minha própria arquitetura contando com bibliotecas pequenas e focadas em tarefas e boa organização. Isso me levou a criar SPAjs e agora um padrão e biblioteca do View Engine.
Eu experimentei diferentes mecanismos de renderização, vinculação e push. Depois de várias experiências, prefiro empurrar porque é super rápido. Além disso, 90% ou mais de suas necessidades de renderização são cenários somente leitura. Os% que requerem algum tipo de atualização em algum outro lugar da visualização são muito raros. Meu modelo de push de escolha é baseado na função de microtemplate de John Resig . Tem cerca de 20 linhas, não 120kb.
Usar microbibliotecas não significa que abandono uma boa arquitetura e padrões. Pelo contrário, me obriga a aproveitá-los e entender o que oferecem e por que estão sendo usados. Nada é implementado cegamente.
Por exemplo, eu gosto do modelo Flux, mas como tudo o mais no ecossistema React, é uma bagunça. Se eu tiver um UX moderadamente complexo para construir, uso uma biblioteca simples de 3kb chamada Callbacks. A biblioteca faz a mesma coisa que o Flux sem o overhead. Oh e React é lento e cheio de vazamentos de memória. Por favor, pare de usar, você está apenas poluindo a Internet e travando navegadores em todo o mundo. Mais naquele outro dia.
Depois daquela experiência’inicial’de SPA, posso criar SPAs grandes e complexos rotineiramente com JavaScript de 100kb ou menos. Este é o tamanho do arquivo reduzido, não compactado, que é o tamanho citado por Tim em seu comentário. Meu JavaScript é compactado em um tamanho semelhante, para todo o aplicativo. Isso inclui bibliotecas e controladores e serviços específicos de aplicativos. Não digo isso para me gabar, mas para lhe dar confiança, você pode realizar o mesmo. É sempre bom trabalhar em direção a uma meta sabendo que outra pessoa fez isso antes de você.
Portanto, com esse histórico e ponto de vista, citarei alguns pontos no comentário de Tim e responderei a eles.
Use o Google CDN
Eu ouço isso o tempo todo, use o Google CDN. O problema é que você está assumindo que o usuário final já fez referência e reteve uma versão local em cache do arquivo que você está usando. A realidade é que isso não é tão comum quanto você pensa.
Primeiro, os CDNs do Google e da Microsoft se fragmentaram. Novas versões de bibliotecas e estruturas populares são lançadas o tempo todo. Os desenvolvedores são preguiçosos e nunca revisam suas referências de versão, etc. Isso resultou em uma confusão de fragmentação. Onde os sites fazem referência a diferentes versões. Isso reduz a eficácia desses CDNs.
Outro equívoco são as características de cache do navegador. A realidade é que os navegadores limpam arquivos do cache o tempo todo. Não há NENHUMA GARANTIA de que um arquivo será retido, mesmo se o recurso de destino tiver um cabeçalho de expiração futuro distante. Enquanto desktops com grande quantidade de espaço em disco tendem a reter referências por um longo período, os dispositivos móveis de classe não retêm. Eles podem nem mesmo armazenar em cache o recurso localmente. Quando comecei a primeira abordagem móvel, o iOS não armazenava em cache um recurso maior que 25kb. Esse limite foi levantado, mas a estratégia ainda está em vigor. O navegador armazena seletivamente os recursos com base nos recursos disponíveis. À medida que os recursos se tornam escassos, o cache é a primeira coisa jogada ao mar.
Como exemplo, meu iPad costuma me dizer que estou sem espaço em disco e sim, o cache do meu navegador é relativamente pequeno. Pense em ter 10 versões do jQuery, 3 Embers, 4 Bootstraps, etc? Provavelmente, eles não serão mantidos.
Em alguns casos, o navegador do cliente nunca tem a opção de armazenar recursos em cache. Algumas empresas interceptam solicitações com servidores proxy e outros dispositivos de rede. Eles ajustam os cabeçalhos e possivelmente armazenam em cache os recursos da rede. Isso causa todos os tipos de problemas com a alteração de recursos, daí a prática de bloqueio de cache.
Você deve sempre adicionar um cabeçalho de expirações no futuro distante para que seu recurso possa ser armazenado em cache. Mas nunca presuma que o recurso está armazenado em cache no cliente. Sempre trabalhe supondo que o usuário está acessando seu site ou aplicativo com um cache não criado.
Por fim, usar outro nome de domínio apenas aumenta o tempo de carregamento, adicionando outra resolução DNS e outra conexão. Cada vez que o navegador encontra um recurso em um novo domínio, ele deve resolver o endereço IP do domínio, o que leva tempo e adiciona latência ao tempo de carregamento. Abrir uma conexão adicional também é caro e adiciona sobrecarga.
Os CDNs são uma boa ideia e você certamente deve usá-los para os ativos do seu aplicativo. Mas não aceite falsas premissas sobre seus benefícios. Entenda como o HTTP funciona e como os navegadores gerenciam as conexões. Pesquise quantas versões de bibliotecas diferentes são referenciadas e aceite o fato de que sua referência de biblioteca não pode ser armazenada em cache no dispositivo do seu cliente.
Tempo gasto sem envio
Outro argumento que ouço é o uso pequenas bibliotecas evitam que você envie o código. Besteira eu digo. Pergunte a si mesmo quanto tempo leva para aprender a última estrutura de fast food du jour? Um dia? Uma semana? Um mês ou mais? Minha experiência pessoal é de pelo menos um mês e mesmo assim a experiência média é apenas hackear amostras de código escolhidas em várias respostas do Stack Overflow até que algo’funcione’. O desenvolvedor típico não entende por que algo funciona ou mesmo se tem efeitos colaterais negativos.
Deixe-me dar outro exemplo do mundo real. É preciso mais para cozinhar em casa ou sair? Claro que você pode ir ao drive through e pedir algo, mas quanto tempo leva para dirigir até seu estabelecimento de fast food favorito? Que tal dirigir de volta? Que tal sentar na fila com o motor funcionando? Então, qual é a qualidade da comida entregue pela janela do motorista?
Minha preferência é ficar em casa e cozinhar um pouco de salmão, brócolis e talvez um pouco de arroz. Isso leva de 10 a 15 minutos. Custa quase o mesmo que uma refeição de fast food engorda, mas leva menos tempo. Claro que tive que ir até a loja e pegar os ingredientes, mas fiz várias refeições que valeram a pena na viagem.
Novamente, qual é o objetivo do aplicativo da web? Para envolver e resolver o problema do cliente ou usuário. O desempenho é importante de muitas maneiras. Estruturas de fast food só causam sites obesos. Eles parecem resolver problemas rapidamente, mas, em vez disso, demoram tanto, senão mais tempo para serem implementados. Os desenvolvedores que trabalham apenas com estruturas de fast food aprendem a estrutura, não a tecnologia. Leva tanto tempo para aprender as tecnologias básicas quanto para aprender a estrutura do dia. E a história das estruturas do lado do cliente nos diz que a estrutura favorita deste ano (como React) será substituída pela moda do próximo ano. Portanto, invista seus recursos no aprendizado das principais APIs e na compreensão de uma boa arquitetura. Conheça os comos e os porquês e você será capaz de construir seu código mais rápido, mantê-lo com menos esforço e seus aplicativos carregarão e rodarão mais rápido. Isso leva a um TCO mais baixo e um ROI mais alto.
Trazendo desenvolvedores a bordo
É mais fácil trazer novos desenvolvedores a bordo quando você constrói com base em uma estrutura de fast food. Eu classifico isso como uma alucinação coletiva. Existe uma diferença entre encontrar desenvolvedores Angular e desenvolvedores JavaScript? Com certeza, mas você pode encontrar qualquer um. No final, o que irá atendê-lo melhor. Eu defendo aquele que entende JavaScript e o navegador. Lembre-se de que o Angular era o fast food favorito do ano passado, hoje está esquecido e todos aderiram ao React. Isso só desperdiça ciclos de aprendizado e é caro para as empresas que tentam’acompanhar’.
Um compromisso que tive recentemente foi um aplicativo que tinha camadas como as camadas da Terra. Havia os ASP.NET WebForms e uma camada centrada no servidor de um tempo muito antigo. Logo acima disso estava a camada jQuery. Foi enterrado sob as camadas Backbone e Ember. No ano passado, a empresa adicionou Angular à cintura. Este ano React. O JavaScript básico tinha quase 2 MB antes que o código específico do aplicativo pudesse ser carregado. Eu construí um protótipo rápido e sujo de todo o aplicativo em cerca de 20 horas, menos de 100kb de JavaScript e cerca de 1/10 do CSS. Mais uma vez, um protótipo rápido, mas recriou a maior parte da experiência do usuário.
Agora, pergunte-se se é mais fácil encontrar um bom desenvolvedor front-end para seu aplicativo ou alguém vinculado a uma estrutura de fast food? É bom adotar cegamente uma estrutura popular porque é popular?
Não procure bundas para ocupar seus lugares. Encontre verdadeiros ativos para impulsionar seu aplicativo. Coloque seu cliente em primeiro lugar, não a falta de conhecimento técnico do departamento de recursos humanos. A contratação técnica não é fácil, mas você não precisa se acomodar. Contrate desenvolvedores da web, não clínicos gerais.
A tecnologia não é estática
Levei algumas vezes para entender o que Tim queria dizer com não estática. Seu ponto é que usando jQuery você pode encontrar um plugin rápido para adicionar um recurso. O problema aqui é que você está se enganando.
Primeiro, existem milhares de bibliotecas e componentes disponíveis no github, o gerenciador de pacotes de nó, bower, etc. Não consigo me lembrar da última vez que peguei um plugin jQuery para resolver qualquer coisa. A razão é que muitas vezes eles não são bem escritos. Eles foram escritos para uma época em que o Internet Explorer 8 era padrão. Isso significa animações JavaScript e outras opções que não são tão saudáveis.
Outro problema com correções prontas como plug-ins é que raramente atendem aos requisitos das partes interessadas. Você já expandiu um ícone de calendário e viu um pop-up de calendário do jQuery UI. Com que frequência seu estilo parece fora do lugar? Quase 100% do tempo. As empresas tendem a ter diretrizes de marca por um motivo. Mesmo que não o façam, tenho certeza de que o titular da participação tem outra coisa em mente, no que diz respeito à aparência e ao comportamento. Isso significa que agora você precisa gastar horas, senão dias, tentando hackear e bater contra o componente rápido e sujo para fazer com que tenha a aparência e o comportamento da maneira que o cliente exige. Quando terminar, você olha para trás e não consegue deixar de pensar que eu deveria ter escrito do zero, teria sido mais fácil.
Eu faço referência a bibliotecas, tutoriais, frameworks e talvez um plugin jQuery para ver como algo pode ser feito. Freqüentemente, incorporo o truque principal em meus aplicativos, geralmente de forma mais sucinta. Na semana passada, postei um tutorial sobre animações de quadro-chave em resposta a um vídeo do Polymer. Se você decidir usar o Polymer para animar seus aplicativos, estará se colocando em uma desvantagem demonstrável em termos de desempenho e problemas de codificação.
Então, para responder ao ponto de Tim, com certeza você pode encontrar um jQuery que parece funcionar, mas a realidade é que provavelmente não o fez. O código aberto é ótimo para descobrir como resolver problemas. Assuma a liderança e coloque-a na arquitetura do seu aplicativo para obter melhores resultados.
Resumo
Agradeço os argumentos de Tim, mas a experiência e a pesquisa me dizem que ele está errado. Basta pesquisar seus sites favoritos; se eles não forem renderizados em menos de 1 segundo para você, eles não estão funcionando direito.
Muitos compromissos corporativos e discussões com líderes do setor, combinados com minha experiência no mundo real, me dizem que uso rápido estruturas alimentares não são saudáveis. Os desenvolvedores e arquitetos foram enganados ao pensar que sua conveniência é boa. A contratação de desenvolvedores de front-end sólidos e a adoção de uma arquitetura modular sólida oferece ao seu aplicativo a melhor trajetória para o sucesso.
Os aplicativos são desenvolvidos para usuários finais. O front-end é especialmente focado na experiência do usuário. Nossos hábitos de desenvolvimento devem se concentrar no sucesso do usuário final, não apenas no sucesso do desenvolvedor. Claro, precisamos ter boas práticas e ferramentas para construir aplicativos sólidos. No entanto, as estruturas de fast food são projetadas para fazer os desenvolvedores focados em back-end sentirem sucesso em uma área na qual têm pouca ou nenhuma experiência real.
Eu não estou sozinho, se você seguir os líderes de pensamento do desenvolvimento web você encontrará muitos artigos, apresentações e outras mídias apoiando minha posição. Um dos meus artigos favoritos é o de Peter-Paul Koch comparando o front end e back end .
Obrigado pelos comentários Tim. Espero que minha resposta tenha sido esclarecedora. Você tem uma opinião contrária? Envie-me um ping no twitter ou comente na página DotNetRocks. Convido o diálogo porque só nos torna melhores.
