Recentemente, tenho me encontrado com muitos sites responsivos com muito de 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 responsividade como um conceito se destina a alcançar um mais largo público, isso parece bastante contraproducente.

O maior contribuidor para esse problema é o paradigma de design de desktop que ainda prevalece. Pensar na perspectiva do mobile-first parece resolver o problema, mas só isso não garante um desempenho satisfatório. Todos parecemos depender demais de uma degradação mais ou menos elegante. Contamos com shims e polyfills para ativar a funcionalidade ausente. Contamos com as bibliotecas para permitir um desenvolvimento rápido e nos ajudar quando a compatibilidade do navegador for um problema.

Assassinos de telefone à solta, disfarçados de sites responsivos. Tweet

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

Lamento o argumento do espantalho, mas acho que merece ser dito em voz alta que as pessoas que posso usar o seu site será a maioria de seus usuários. Se você não vê 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 novos até hoje. Você não deve descartá-lo como uma tecnologia do passado.

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

Paradigma do Design Brick-First

Uma parte significativa das vendas anuais de telefones ainda é feita por telefones convencionais. Uma parcela ainda maior da população não compra telefones todos os anos, mas, mesmo assim, possui algum dispositivo compatível com a web. Some-se a esses números os smartphones de última geração ainda em uso, acrescente os kindles e outros dispositivos semiacapazes da web (dispositivos WAP, TVs, torradeiras, camisetas e tijolos). Some todos eles e você pode chegar a uma soma impressionante.

Você não os verá em suas análises, a menos que funcione lá. Tweet

Considere os casos de uso para este 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 uma URL no teclado numérico e navegar na página usando as teclas direcionais para chegar a um número de telefone ou verificar um endereço na hora.

Quão difícil é para nós implementar um layout submóvel primeiro que fornecerá apenas essas informações para os dispositivos abaixo de um certo limite de recursos e desempenho?

Melhoria Graciosa

Com a degradação harmoniosa como prática recomendada mínima, criamos um princípio abrangente que (até certo ponto) impede o pensamento além dele. Uma vez que a degradação elegante está em vigor, podemos certamente dizer que nosso trabalho está feito, e bem feito. Cada vez com mais frequência, não precisamos nem mesmo pensar nisso, pois já é abordado pelas várias estruturas 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 disponível, a necessidade de pensar sobre ela (quanto mais além) torna-se cada vez mais remota.

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

Degradação ingrata: 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 uma forma proibitivamente impraticável.

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

Melhoria deselegante: Se o recurso não estiver disponível, ele é emulado por um polyfill ou calço.

Pronto, problema resolvido.

Bem, a menos que você considere o desempenho desses mesmos dispositivos de gama baixa.

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

E então você implementa modernizar e polyfill tudo para o caso. 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.

Shiv, shim e polyfill? Graças a Deus, a maioria dos smartphones não suporta Flash! Tweet

A ideia de uma melhoria elegante 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 lidar com eles.

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 é necessário?

Outra prática recomendada para o desenvolvimento da 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 atrás, e ele afirmará que pode ser executado Animações CSS , WebGL , efeitos de paralaxe de fundo e muitas outras funcionalidades. Mas realmente, realmente , não posso. Tanto que o navegador irá travar e todo o dispositivo ficará sem resposta a um ponto que terá de ser reiniciado para recuperar o controle.

Este problema começou recentemente a afetar Aplicativos Android em grande forma (do ponto de vista do usuário). Uma das degradações mais perceptíveis neste sentido afetou a atualização do aplicativo Google Talk / Hangouts, que transformou seu serviço do aplicativo de chat mais leve disponível para um aplicativo quase inutilizável devido a problemas de desempenho em dispositivos mais antigos. (Apenas para enfatizar este ponto mais uma vez: “mais velho” aqui significa que você ainda pode comprá-lo fora da prateleira, novo em quase qualquer loja). O mesmo problema afetou o aplicativo do YouTube e o app Twitter (na minha experiência) e aparentemente muitos outros.

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

Permitir que os usuários optem pela margem de sangramento

Você já tentou usar o Gmail em um dispositivo antigo ou com uma conexão ruim? que Link “carregar HTML básico” com certeza vem a calhar.

Por que sua loja online de ponta, responsiva, animada e voltada para o toque não tem essa funcionalidade?

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

Você realmente precisa da biblioteca inteira?

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 incluí-los apenas às vezes é entediante, mas manter seu conjunto de ferramentas inteiro em cada página é simplesmente desleixado.

Mentira comum do século 21: apenas alguns segundos restantes. Tweet

Recentemente, comecei a controlar quanta funcionalidade realmente uso depois de incluir uma biblioteca. E a ferramenta que uso com mais frequência é jQuery . Freqüentemente, descubro que usei apenas uma ou duas funcionalidades (como $ .extend ou $ .ready), ou ainda pior, que usei apenas para obter elementos por classe ou ID. Às vezes eu deixo assim, outras vezes eu volto no 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 eu continuo tendo a sensação de que não deveria estar muito fora de nosso alcance padronizar uma arquitetura de construção automatizada do tipo 'use ou perca' em nossas bibliotecas.

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

O que seria necessário é uma versão 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 de dependência mínima ou pelo menos escala de utilização (como perguntar se eu 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, envolver o problema . Pense sobre isso, discuta com seus colegas e tente localizar 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. Experimente usá-lo em seus próprios sites e verifique se o conteúdo pode ser usado remotamente. Visite 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 questões de acessibilidade.

Se você é um comprador encomendar um site, certifique-se de pedir (pelo menos) um suporte de baixo nível sobre este assunto. 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 seus dispositivos travarem.

Reserve recursos reais para isso: a solução mais simples para o problema não deve levar mais do que um ou dois dias e pensar no futuro. Lembre-se dos motivos mais básicos para criar o site (sem falar em criar um site responsivo).

Se você é um desenvolvedor de pacotes trabalhando em uma biblioteca, estrutura, pacote 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, você estará afetando todo o cenário do desenvolvimento web. Se você incorporar no design de sua embalagem, me avise e eu evangelizarei para você.

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

No final das contas, se você quiser ouvir alguém falar sobre isso por horas e se encontrar perto Zagreb , Avise-se me. Podemos ir tomar um café.