Definir a compatibilidade dos browsers é uma dificuldade para a maioria das empresas. As empresas mais novas dificilmente se preocupam com isso enquanto as mais maduras sofrem para garantir uma compatibilidade decente com os navegadores. Deixarei aqui o meu resumo sobre algumas das muitas conversas que tive com os meus amigos, com a comunidade (Opensanca e ReactBrasil) e com algumas empresas do grupo Monashees.
Antes de prosseguir na leitura eu gostaria de informar que a Arquivei é um SaaS B2B. Acredito que a abordagem adotada funciona bem para empresas nesse modelo. Para empresas B2C, sobretudo e-commerces, esta abordagem pode ser inadequada para o seu negócio.
Contexto
Javascript é a linguagem de programação que define as regras de negócio. CSS é a linguagem de marcação que descreve o layout. ECMA é a convenção que define as diretrizes da linguagem ECMAScript, outrora implementada com o nome Javascript. HTML, CSS e Javascript são as linguagens que o browser computa.
Tomem por conhecimento que Brendan Eich criou a maravilhosa linguagem de programação javascript em apenas 10 dias, durante a guerra dos browsers. Para melhorar a situação o javascript não teve atualizações relevantes de 2009 até 2015. <sarcasmo>
Depois de 2015, a ECMA se propôs a lançar anualmente uma versão da ECMAScript com novas funcionalidades. Essa definição é guiada por um comitê técnico (TC39) e é muito bem descrita em https://tc39.github.io/process-document/.
Além disso, durante a guerra dos browsers cada navegador implementou o javascript do seu jeito, adicionando regras e features próprias. Isso acontece tanto para o javascript quanto para as regras CSS.
Por que é importante definir a compatibilidade da sua aplicação com os browsers?
Definir bem a compatibilidade da sua aplicação com os navegadores permite que a sua equipe desenvolva novos produtos com elegância, qualidade e agilidade. Isso acontece porque uma comunidade ativa de desenvolvedores arquitetaram novas funcionalidades para resolver problemas complexos em aplicações de grande escala. Isso acontece tanto nas features do javascript (arrow-function, async, await, object spead) quanto nas features do CSS (css-grid ou flexbox).
Temos que admitir que um sentimento de preguiça e tristeza é manifestado pelo programador quando ele deve escrever um layout de forma tabular, com uso exagerado de float, ou ainda, preservar uma constante de forma gambiarrada, copiar objetos com Object.assign, etc.. Eu, particularmente, sinto muita preguiça quando é necessário usar técnicas antigas para desenhar layouts ou para programar uma lógica de negócio.
A comparação mais fácil que eu faço com essas features antigas é com uma Belina Del Rey. Quem teve uma Del Rey na época adorou, pode até dizer que foi um dos melhores carros que já teve, mas jamais compraria uma nos dias de hoje. Essas features resolveram problemas reais na época que elas surgiram mas hoje dificultam a vida do programador quando comparada com as novas funcionalidades.
O que deve ser feito?
O primeiro passo é entender o seu público. Quais são os browsers que eles usam? O Google Analytics pode te dar essa informação com facilidade.
Uma vez que você tenha entendido o seu público já é possível definir quais são as zonas de impacto ao se definir compatibilidade de browser a fim de esboçar o esforço para guiar os usuários para instalar browsers mais modernos.
Vamos começar a definir os impactos. Faça uma lista de impacto para cada nível de suporte da sua aplicação, três níveis é o suficiente.
1. Amplo suporte (impacto limitado)
Os browsers nesse nível devem ter amplo suporte. A sua equipe de desenvolvimento deve garantir que a aplicação funcione plenamente.
Neste primeiro nível é importante que você defina somente os browsers modernos e que realmente acompanhem a convenção ECMA. Com isso, você consegue garantir que o seu software se adeque perfeitamente ao browser onde ele será utilizado, sem se preocupar com efeitos colaterais.
Vimos que algumas empresas definem suporte amplo apenas para os navegadores nas últimas duas versões estáveis. Isso já é suficiente para abordar maioria dos usuários mas não a plataforma toda. Os demais usuários foram abordados nos níveis inferiores de suportes.
Caso algum problema aconteça dentro de um browser que está em amplo suporte, este deverá ter um tempo de resposta bem curto por parte dos desenvolvedores.
2. Suporte parcial (impacto limitado)
O seu software pode apresentar alguma funcionalidade com comportamento indesejado ou com layout mal formado.
Este é o nível que exige o maior esforço. Aqui você continua usando as mesmas features do nível anterior, mas dessa vez com ajuda de um polyfill e de um transpilador. O Babel existe para isso, simplificar esse processo. Caso você não conheça o Babel e esteja usando features recentes da ECMAScript o seu negócio corre sérios riscos. O webpack é a melhor ferramenta para te ajudar no processo de transformação do seu código. Não tem muito segredo, algumas horas de estudo na internet te farão entendedor do assunto.
Bom, aparentemente o problema é resolvido de uma forma bem simples né!? EROW!
- Primeiro que essa estratégia não funciona para todas as features. Tome como exemplo o Proxy. Não existe equivalente em polyfill ou transpilação;
- Segundo que polyfill e transpilador são estratégias para o javascript e não para o CSS, pois não existe polyfill ou transpilador para essa linguagem. Isso acontece porque ainda não é possível estender a engine do CSS e fazer algumas modificações. Estamos esperando o dia em que o Houdini CSS esteja concluído e faça parte da nossa vida.
Para resolver o problema do CSS é realmente importante conhecer as features e regras que você vai usar. Tomemos como exemplo o css-grid. Ele só funciona nos seguintes browsers.
Em alguns casos o suporte existe através de algum prefixo como -ms-, -webkit-, -moz- e com bugs e overflows em alguns cenários. Isso exige muita atenção do desenvolvedor. A vantagem que temos é que existem bibliotecas que adicionam os prefixos automaticamente, como é o caso da Autoprefixer, Styled-component e alguns plugins para Less e Sass.
Caso algum problema aconteça, uma análise mais clínica deve ser feita. O problema pode ser um bug ou uma falta de definição do babel e no polyfill, ou ainda um erro do programador. Esse suporte costuma ter um tempo de resposta maior.
3. Sem suporte (impacto ilimitado)
O seu software não deve dar suporte para estes browsers. Neste nível o seu software pode até funcionar mas não deve haver garantias. A sua equipe de desenvolvimento ou equipe de suporte não deve dar foco para esses navegadores.
Para garantir que usuário entenda o motivo de um browser não ter compatibilidade com a sua aplicação, você pode:
- Informá-lo através de uma notificação, banner, modal, popup ou qualquer meio que seja realmente invasivo na tela.
- Bloquear o usuário e forçá-lo a instalar um navegador dentro do amplo suporte. Esta última opção parece um absurdo, não!? Mas é a prática adotada pelos principais players de mercado, tais como: Netflix, Spotify, Slack e WhatsApp.
Tenha em mente que a maioria das pessoas que usam esse browsers antigos dificilmente tem uma limitação técnica ou burocrática. A maioria delas usam porque simplesmente não tem conhecimento sobre o assunto. Elas não sabem o que é um browser, elas sabem o que é internet, e o ícone do browser significa internet. Logo, browser e internet são a mesma coisa para esses usuários.
A equipe de suporte deve guiar e educar o usuário para o uso de um browser mais moderno dentro das suas definições de amplo suporte.
Efeitos colaterais
Como deixamos alguns usuários sem suporte é claro que teremos impactos negativos. Alguns deles podem ser fatais para o seu negócio. Vou citar alguns deles pra vocês.
Onboarding
O efeito colateral mais importante é no onboarding. O onboarding é definido como a trilha do usuário que vai desde o primeiro contato na sua aplicação até ele virar um MQL (marketing qualified lead). Como deixaremos uma parte dos atuais usuários da plataforma sem suporte, também deixaremos uma parte dos futuros usuários sem suporte. Esse efeito colateral impacta diretamente no seu funil de conversão.
Você tem basicamente duas abordagens sobre esse problema:
- Encare o problema e perder alguns novos usuários. Faça boas análises e preveja o impacto no seu funil. Não se esqueça de informar o usuário que a sua aplicação não dá suporte ao browser que ele usa. Tente guiá-lo a instalar um browser mais novo;
- Faça um onboarding que suporte browsers antigos. Esse é um processo custoso e doloroso mas garante que não haverá grandes impactos no seu funil de conversão. Este, de longe, é o método mais adotado pelos grandes players. Na maioria das empresas o onboarding é uma aplicação separada da sua aplicação real.
Performance
Essa é basicamente uma balança. Os usuários que estiverem dentro do amplo suporte não terão uma carga extra (polyfill e transpilação) nos assets. Isso fará a sua aplicação rodar sem problemas. Já os usuários que estão no nível de suporte parcial terão uma carga extra muito maior.
Para fazer um carregamento dos assets há um trabalho maior. Você precisa verificar qual o browser do cliente, no lado do servidor (através do user agent), e criar o cabeçalho (head do seu html) apontando para os assets corretos, além de definir duas regras de minificação de assets no seu processador (webpack).
Dependendo do tamanho da sua cobertura de suporte, os assets ficarão mais pesados. Por isso é muito importante definir bem a cobertura. Você ainda pode definir vários outros níveis de suporte, isso vai exigir um código ainda mais complexo.
Fator Brasil
O maior problema é que o Brasil ainda está um pouco atrás em tecnologia. Não consigo te dizer se é pela dificuldade no acesso a tecnologia/informação ou se é um problema cultural. Algumas empresas (e bancos) ainda usam sistemas legados da Microsoft como o Windows XP e Windows Vista. E com eles vem a carga mais pesada, o IE (Internet Explorer). Para piorar ainda mais a situação, o IE ainda vem com as últimas versões do Windows e foi o navegador padrão até a versão 10. E pra esquentar qualquer desenvolvedor web a Microsoft ainda dá suporte de segurança para esse navegador, eu acredito que ela faz isso para continuar vendendo o versões anteriores ao windows 10 para outras empresas.
É muito difícil dar suporte a este navegador pois ele não aceita muitas features da convenção ECMA. Na verdade não aceita a maioria delas. Por essas razões, a comunidade já está parando de dar suporte para esse peculiar navegador. Vale lembrar que a maioria dos sites que dão suporte para o IE só o fazem até a versão 11, ou seja, a web não funciona para versões anteriores a 11.
Em algum momento, você deverá ter uma boa justificativa para dar ou não suporte para esse browser. A maioria das empresas já abandonou esse navegador a fim de produzir novos produtos com mais qualidade. Algumas outras tem um polyfill e uma transpilação somente para esse navegador.
Resultado da Arquivei
Quero apresentar o nosso resultado final. Primeiro analisamos a nossa população de usuários:
Com uma análise super simples concluímos que ~83,62% de toda a nossa base usuários usa Chrome 71+ e é o principal candidato para o amplo suporte. Enfim, isso foi suficiente para definir os três últimos browsers dentro do amplo do suporte. Para o suporte parcial tomamos como requisito mínimo o ECMA2015 (ou ES6) e algumas regras CSS.
Com isso criamos a nossa definição de compatibilidade.
Nós optamos por informar os usuários que usam navegadores sem suporte através de uma notificação na plataforma. Alguns browser sem suporte realmente não funcionam na nossa plataforma, como é o caso do IE.
O preset-env tem integração com o browserlist e permite definir automaticamente a compatibilidade da nossa aplicação. Além disso, é possível definir o uso do polyfill com a regra useBuiltIns.
// babel.config.jsmodule.exports = {
"presets": [
["@babel/preset-env", {
"useBuiltIns": "entry",
"targets": { "node": "current" },
}],
...
],
...
}
Adicionamos um arquivo .browserslistrc na raiz da nossa aplicação para definir a compatibilidade com os navegadores do nosso interesse. Nesse primeiro momento fizemos de modo manual, mas a ideia é automatizar até darmos suporte apenas para as duas últimas versões dos navegadores ou de acordo com a nossa audiência.
# Browsers that we supportchrome 63
firefox 57
opera 50
edge 12
safari 10
Próximos passos:
- Separar os assets de amplo suporte dos assets de suporte ilimitado;
- Criar um onboarding que seja compatível com qualquer navegador;
Este post é o resultado de uma briga que eu venci…
Venci por que a Arquivei adotou a compatibilidade de browsers que criamos sem um impacto negativo, assim demos mais agilidade na criação de novos produtos. Por fim, eu gostaria de agradecer o empenho daqueles que me ajudaram nessa batalha aqui na firma, em especial o Adriano J Souza e o Vinicius Marchesin Araujo que fomentaram essa pesquisa.
