Design responsivo não é suficiente, precisamos de desempenho responsivo

Recentemente, encontrei muitos sites responsivos com muitos problemas de desempenho. Na maioria deles, os problemas são tão evidentes que são quase inúteis em qualquer coisa além da última geração de smartphones. Considerando o fato de que a responsividade como conceito se destina a atingir um público mais amplo , isso parece bastante contraproducente.

O maior contribuinte para esse problema é o paradigma de design de desktop em primeiro lugar ainda predominante. Pensar na perspectiva do mobile-first parece resolver o problema, mas isso por si só não garante um desempenho satisfatório. Todos nós parecemos confiar demais na degradação mais ou menos graciosa. Contamos com calços e polyfills para habilitar a funcionalidade ausente. Contamos com bibliotecas para permitir um desenvolvimento rápido e para nos proteger quando a compatibilidade do navegador for um problema.

"Por que se preocupar?" você pode perguntar. “A maioria dos nossos visitantes tem smartphones de alto desempenho com as versões mais recentes do sistema operacional. Eles podem lidar com nossos sites. A análise nos diz isso.”

Sinto muito pelo argumento do espantalho, mas acho que merece ser dito em voz alta que as pessoas que podem usar seu site serão a maioria de seus usuários. Se você não vir o Android 2.3 em suas análises, isso significa que não há usuários com esses dispositivos? Ou significa que seu site não tem nada a oferecer a esses usuários? Considere que muitos aparelhos dessa geração ainda estão nas prateleiras, sendo comprados novinhos até hoje. Você não deve descartá-la como uma tecnologia do passado.

Por isso, gostaria de falar sobre os casos ideais e os objetivos reais do desenvolvimento web. E sobre práticas e paradigmas que nos aproximam desses objetivos.

Paradigma de design de tijolos em primeiro lugar

Uma parcela significativa das vendas anuais de telefones ainda é realizada por telefones comuns. Uma parcela ainda maior da população não está comprando telefones todos os anos, mas, no entanto, possui algum dispositivo compatível com a web. Adicione a esses números os smartphones de última geração ainda em uso, adicione os kindles e outros dispositivos semi-capazes da web (dispositivos WAP, TVs, torradeiras, camisetas e tijolos). Adicione todos eles e você pode chegar a uma soma impressionante.

Considere os casos de uso para esse público. Eles não vão ler artigos longos, navegar e pesquisar em seus dispositivos. Mas eles podem passar pelos horrores de tentar digitar um URL no teclado numérico e navegar na página usando as teclas direcionais para obter um número de telefone ou verificar um endereço rapidamente.

Quão difícil é para nós implementar um layout sub-móvel que forneça apenas essas informações para os dispositivos abaixo de um certo limite de recursos e desempenho?

Melhoria Graciosa

Com a degradação graciosa como uma prática mínima recomendada, criamos um princípio abrangente que (até certo ponto) obstrui o pensamento além dele. Uma vez que a degradação graciosa está em vigor, podemos dizer que nosso trabalho está feito, e bem feito. Cada vez mais, nem precisamos pensar nisso, pois já é coberto pelos vários frameworks e bibliotecas em uso. E, finalmente, polyfills e calços eliminam completamente a necessidade de degradação da funcionalidade em alguns casos.

À medida que essa funcionalidade se torna cada vez mais prontamente disponível, a necessidade de pensar sobre ela (e muito menos além dela) torna-se cada vez mais remota.

Do ponto de vista deste artigo, ele pode ser dividido assim:

Degradação sem graça: Se um recurso não estiver prontamente disponível, a implementação falha de tal forma que se torna inutilizável ou utilizável de maneira proibitivamente impraticável.

Degradação graciosa: se um recurso não estiver prontamente disponível, ele falha de uma maneira que ainda permite uma usabilidade aceitável.

Melhoria sem graça: se o recurso não estiver prontamente disponível, ele será emulado por um polyfill ou shim.

Pronto, problema resolvido.

Bem, a menos que você considere o desempenho desses mesmos dispositivos de baixo custo.

Sem o poder de processamento e os recursos de dados de seus irmãos mais novos, eles são solicitados a carregar uma carga muito maior. Tomar polyfills como solução cria uma ilusão de que todas as funcionalidades modernas estão agora disponíveis em todos os dispositivos e podem ser usadas sem preocupação.

E então você implementa modernizr e polyfill tudo por precaução. O dispositivo menos competente acaba carregando a maior quantidade de dados e realizando a maior quantidade de processamento. Garantindo assim a “melhor” experiência do usuário final.

A ideia de melhoria graciosa reverteria o conceito, começando com os requisitos de recursos mais baixos e carregando atualizações até que o equilíbrio entre desempenho e usabilidade seja ideal com base nos recursos do dispositivo. Assim, o tráfego de dados e os requisitos de processamento seriam movidos para os dispositivos mais adequados para tratá-los.

Claro, no momento o conceito é proibitivamente complexo: não é suportado pela maioria dos frameworks e bibliotecas, não é discutido, e as referências a tais práticas são poucas, distantes e localizadas em microfuncionalidades. Mas em algum momento foi assim com todos os conceitos e funcionalidades.

Pode, mas precisa?

Outra prática recomendada com desenvolvimento web é verificar se um recurso está disponível em um dispositivo antes de ativá-lo.

No entanto, leve em consideração que você pode instalar a versão mais recente do Google Chrome em seu telefone Android de anos e ele alegará que pode executar animações CSS, WebGL, efeitos de paralaxe de fundo e muitas outras funcionalidades. Mas realmente, realmente , não pode. Tanto que o navegador travará e todo o dispositivo ficará sem resposta a ponto de ter que ser reiniciado para recuperar o controle.

Esse problema começou recentemente a afetar os aplicativos Android em grande escala (do ponto de vista do usuário). Uma das degradações mais visíveis nesse sentido afetou a atualização do aplicativo Google Talk/Hangouts, que transformou seu serviço do aplicativo de bate-papo mais leve disponível em um aplicativo quase inutilizável devido a problemas de desempenho em dispositivos mais antigos. (Só para enfatizar este ponto mais uma vez: “mais velho” aqui significa que você ainda pode comprá-lo na prateleira, novinho em folha em quase qualquer loja). O mesmo problema afetou o aplicativo do YouTube e o aplicativo do Twitter (na minha experiência) e aparentemente muitos outros.

Portanto, reserve um momento em algum momento durante sua fase de planejamento para avaliar o valor de um recurso principal de alto desempenho em relação à composição de ponta. Ou pelo menos deixe a última geração do seu aplicativo/serviço/conteúdo disponível de alguma forma para os usuários legados. Falando nisso…

Permita que os usuários optem por não participar do Bleeding Edge

Você já se pegou tentando usar o Gmail em um dispositivo antigo ou em uma conexão ruim? Esse link “carregar HTML básico” certamente é útil.

Por que sua vitrine on-line de ponta, responsiva, animada e orientada ao toque não tem essa funcionalidade?

Pense nisso: você solicitou que ele fosse responsivo para alcançar mais clientes em potencial. Você fez isso de ponta para deixar a melhor primeira impressão. E, como resultado, menos clientes em potencial podem acessar até mesmo as informações básicas sobre você e seus serviços. Se a melhoria graciosa é um conceito muito caro para você, por que você não oferece a seus visitantes a opção de acessar uma versão apenas em texto do seu conteúdo se a versão “WOW” for demais para seus dispositivos.

Você realmente precisa de toda a biblioteca?

Finalmente, a última prática recomendada que eu gostaria de ver um pouco além do padrão é “use ou perca”. Manter o controle de quais bibliotecas e módulos estão realmente em uso e incluir apenas eles às vezes é tedioso, mas manter todo o seu conjunto de ferramentas em cada página é simplesmente desleixado.

Recentemente, comecei a acompanhar quanta funcionalidade realmente uso quando incluo uma biblioteca. E a ferramenta que uso com mais frequência é jQuery. Muitas vezes acho que usei apenas uma ou duas funcionalidades (como $.extend ou $.ready), ou pior ainda, que usei apenas para obter elementos por classe ou ID. Às vezes deixo assim, outras vezes volto pelo código para remover ou desacoplar a dependência.

Não seria legal se você pudesse analisar automaticamente o que e quanto de uma biblioteca acabou sendo usada e perdendo peso com base nos resultados?

Muitas bibliotecas e aplicativos oferecem a opção de personalizar o carregamento antes de começar a usá-lo. Mas continuo tendo a sensação de que não deve estar muito fora de nosso alcance padronizar uma arquitetura de compilação automatizada do tipo “use ou perca” em nossas bibliotecas.

Eu tenho uma alergia pela abordagem “incluir tudo”. Mas usá-lo em conjunto com essa funcionalidade pode transformar a abordagem em algo semelhante a uma placa de prototipagem: uma ferramenta de desenvolvimento excessivamente flexível que é minificada não apenas na sintaxe, mas na própria funcionalidade real.

O que seria necessário é uma versão apenas de desenvolvimento da biblioteca que, por meio de um teste de unidade de funcionalidade dependente, permitiria o rastreamento de recursos usados ​​e a saída da dependência mínima ou pelo menos escala de utilização (como perguntar se incluí jQuery para 8% de sua funcionalidade ou 80%). A saída de dependência pode então ser usada para selecionar, agregar e minimizar a saída para produção.

Mas o que posso fazer sobre isso?

Em primeiro lugar, engaje a questão . Pense nisso, discuta com seus colegas e tente identificar o problema em cenários do mundo real.

Experimente. Desenterre aquele telefone de última geração que você guardou em uma gaveta em algum lugar. Tente usá-lo em seus próprios sites e verifique se o conteúdo pode ser usado remotamente. Vá visitar alguns parentes atrasados ​​no país e tente ser um evangelista de tecnologia para eles. Veja se o atraso na adoção de tecnologia é realmente facilitado por problemas de acessibilidade.

Se você é um comprador que está comissionando um site, certifique-se de solicitar (pelo menos) um suporte de baixo nível sobre esse problema. Lembre-se: o objetivo não é criar uma porta completa de todos os seus recursos para dispositivos de baixo nível. Tudo o que está sendo solicitado é que esses usuários obtenham suas informações de contato em vez de o dispositivo travar.

Separe recursos reais para isso: a solução mais simples para o problema não deve levar mais de um ou dois dias e um pouco de visão de futuro. Tenha em mente as razões mais básicas para fazer o site em primeiro lugar (quanto mais fazer um site responsivo).

Se você é um desenvolvedor de pacotes trabalhando em uma biblioteca, framework, bundle ou qualquer outro software incorporável: você é quem pode fazer a maior diferença aqui. Se você puder facilitar ou incorporar esses conceitos em sua plataforma, estará afetando todo o cenário do desenvolvimento web. Se você incorporá-lo em seu design de embalagem, me avise e eu vou evangelizar para você.

E, finalmente, **se você for um desenvolvedor ou designer**, não se limite apenas às práticas recomendadas. Sempre tente olhar um pouco além desse horizonte. O trabalho duro está em você para empurrar esses conceitos que ninguém ainda pediu, que não são suportados e não documentados para o benefício de seus clientes e usuários.

Em última análise, se você quiser ouvir alguém falar sobre isso por horas e se encontrar perto de Zagreb, me avise. Podemos ir tomar um café.