A variedade de recursos de dispositivos que podem se conectar à Web é maior do que nunca. O mesmo aplicativo da Web disponibilizado para um computador desktop de última geração também pode ser usado em um smartphone, relógio ou tablet de baixo consumo. Além disso, pode ser incrivelmente desafiador criar experiências atraentes que funcionam perfeitamente em qualquer dispositivo.
A API Device Memory é um novo recurso de plataforma
da Web criado para ajudar os desenvolvedores da Web a lidar com o cenário moderno dos
dispositivos. Ele adiciona uma propriedade somente leitura ao objeto navigator,
navigator.deviceMemory, que retorna a quantidade de RAM do dispositivo em
gigabytes, arredondada para a potência mais próxima de dois. A API também apresenta um
cabeçalho de dicas do cliente,
Device-Memory, que informa o mesmo valor.
A API Device Memory oferece aos desenvolvedores a capacidade de fazer duas coisas principais:
- Tome decisões no ambiente de execução sobre quais recursos veicular com base no valor retornado da memória do dispositivo (por exemplo, disponibilizar uma versão "lite" de um app para usuários em dispositivos com pouca memória).
- Informe esse valor a um serviço de análise para entender melhor como a memória do dispositivo se relaciona com o comportamento do usuário, as conversões ou outras métricas importantes para sua empresa.
Personalização dinâmica de conteúdo com base na memória do dispositivo
Se você estiver executando seu próprio servidor da Web e conseguir modificar a lógica que
disponibilize recursos, será possível responder condicionalmente a solicitações que contenham o
Device-Memory Cabeçalho de dicas do cliente.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
Com essa técnica, é possível criar uma ou mais versões dos scripts
do aplicativo e responder condicionalmente às solicitações do cliente com base no
valor definido no cabeçalho Device-Memory. Essas versões não precisam conter
códigos completamente diferentes, já que a manutenção é mais difícil. Na maioria das vezes, a versão "lite" exclui apenas recursos que podem ser caros e não essenciais para a experiência do usuário.
Como usar o cabeçalho "Dicas do cliente"
Para ativar o cabeçalho Device-Memory, adicione a tag <meta> das dicas do cliente
ao <head> do documento:
<meta http-equiv="Accept-CH" content="Device-Memory">
Ou inclua "Device-Memory" nos cabeçalhos de resposta do Accept-CH do servidor:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
Isso instrui o navegador a enviar o cabeçalho Device-Memory com todas as solicitações
de sub-recursos para a página atual.
Em outras palavras, depois de implementar uma das opções acima para seu
site, se um usuário acessar um dispositivo com 0, 5 GB de RAM, todas as solicitações de imagem, CSS e
JavaScript dessa página vão incluir o cabeçalho Device-Memory com
o valor definido como "0,5". Seu servidor poderá responder a essas solicitações da forma
que você achar melhor.
Por exemplo, a rota Express a seguir exibirá uma versão "lite" de um script se o cabeçalho Device-Memory estiver definido e o valor for menor que 1, ou ela exibirá uma versão "full" se o navegador não oferecer suporte ao cabeçalho Device-Memory ou o valor for 1 ou maior:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
Como usar a API JavaScript
Em alguns casos (como com um servidor de arquivos estáticos ou uma CDN), não é possível responder condicionalmente a solicitações com base em um cabeçalho HTTP. Nesses casos, você pode usar a API JavaScript para fazer solicitações condicionais no seu código JavaScript.
A lógica a seguir é semelhante à rota expressa acima, mas ela determina dinamicamente o URL do script na lógica do lado do cliente:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
Embora a exibição condicional de diferentes versões do mesmo componente com base nos recursos do dispositivo seja uma boa estratégia, às vezes pode ser ainda melhor não exibir um componente.
Em muitos casos, os componentes são puramente melhorias. Eles adicionam alguns toques úteis à experiência, mas não são necessários para a funcionalidade principal do app. Nesses casos, é recomendável não carregar esses componentes. Se um componente destinado a melhorar a experiência do usuário deixar o app lento ou sem resposta, ele não vai atingir o objetivo.
Ao tomar qualquer decisão que afete a experiência do usuário, é fundamental que você meça o impacto dela. Também é fundamental que você tenha uma imagem clara do desempenho do seu app hoje.
Entender como a memória do dispositivo se correlaciona com o comportamento do usuário para a versão atual do app informa melhor qual ação precisa ser realizada e fornece um valor de referência para você medir o sucesso de mudanças futuras.
Rastrear a memória do dispositivo com análises
A API Device Memory é nova, e a maioria dos provedores de análise não a rastreia por padrão. Felizmente, a maioria dos provedores de análise oferece uma maneira de rastrear dados personalizados (por exemplo, o Google Analytics tem um recurso chamado Dimensões personalizadas), que pode ser usado para rastrear a memória dos dispositivos dos seus usuários.
Como usar uma dimensão personalizada de memória do dispositivo
Usar dimensões personalizadas no Google Analytics é um processo de duas etapas.
- Configure a dimensão personalizada no Google Analytics.
- Atualize o código de acompanhamento para
seto valor da memória do dispositivo para a dimensão personalizada que você acabou de criar.
Ao criar a dimensão personalizada, dê a ela o nome "Memória do dispositivo" e escolha um escopo de "sessão", porque o valor não vai mudar durante a sessão de navegação de um usuário:
Em seguida, atualize o código de acompanhamento. Aqui está um exemplo de como pode ficar. Para navegadores que não oferecem suporte à API Device Memory, o valor da dimensão será "(not set)".
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
Como gerar relatórios sobre dados de memória do dispositivo
Quando a dimensão da memória do dispositivo for set no objeto do rastreador, todos os dados enviados ao Google Analytics incluirão esse valor.
Isso permite que você analise as métricas desejadas (por exemplo, tempos de carregamento de página, taxa de conclusão de metas etc.) por memória do dispositivo para ver se há correlações.
Como a memória do dispositivo é uma dimensão personalizada, não uma dimensão integrada, ela não é mostrada em nenhum dos relatórios padrão. Para acessar esses dados, você precisa criar um relatório personalizado. Por exemplo, a configuração de um relatório personalizado que compara os tempos de carregamento por memória do dispositivo pode ter esta aparência:
E o relatório gerado será semelhante a este:
Depois de coletar dados da memória do dispositivo e ter um valor de referência para a experiência dos usuários com seu aplicativo em todas as faixas do espectro da memória, é possível mostrar recursos diferentes para usuários distintos usando as técnicas descritas na seção acima. Depois, você poderá olhar para os resultados e ver se eles melhoraram.
Conclusão
Esta postagem descreve como usar a API Device Memory para adaptar seu aplicativo às funcionalidades dos dispositivos dos usuários e mostra como medir a experiência desses usuários com seu app.
Embora esta postagem se concentre na API Device Memory, a maioria das técnicas descritas aqui pode ser aplicada a qualquer API que informe os recursos do dispositivo ou as condições da rede.
À medida que o cenário de dispositivos continua a aumentar, é mais importante do que nunca que os desenvolvedores da Web considerem todo o espectro de usuários ao tomar decisões que afetam a experiência deles.