Como adaptar aos usuários com dicas do cliente

Desenvolver sites rápidos em todos os lugares pode ser um cliente em potencial complicado. A multidão da capacidade dos dispositivos e da qualidade das redes conectadas pode fazer parecer uma tarefa insuperável. Embora possamos os recursos do navegador para melhorar o desempenho de carregamento, como saber do que o dispositivo do usuário é capaz de fazer ou a qualidade da rede a conexão? A solução é uma solução dicas.

As dicas do cliente são um conjunto de cabeçalhos de solicitação HTTP que nos fornecem informações sobre esses aspectos do dispositivo do usuário e da rede à qual estão conectados. De usando essas informações no lado do servidor, podemos mudar como entregamos com base nas condições do dispositivo e/ou da rede. Isso pode nos ajudar a criar experiências de usuário mais inclusivas.

É tudo uma questão de negociação de conteúdo

As dicas do cliente são outro método de negociação de conteúdo, o que significa mudar respostas de conteúdo com base nos cabeçalhos de solicitação do navegador.

Um exemplo de negociação de conteúdo envolve Accept cabeçalho da solicitação. Ela descreve quais tipos de conteúdo o navegador entende e quais que o servidor pode usar para negociar a resposta. Para solicitações de imagem, o conteúdo do cabeçalho Accept do Chrome é:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Embora todos os navegadores suportem formatos de imagem como JPEG, PNG e GIF, o Accept informa Nesse caso, o navegador também é compatível com WebP e APNG. Com essas informações, podemos negociar os melhores tipos de imagens para cada navegador:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

Assim como no Accept, as dicas de clientes são outra maneira de negociar conteúdo, mas as capacidades do dispositivo e as condições da rede. Com dicas de clientes, pode tomar decisões de desempenho no lado do servidor com base nas necessidades experiência do usuário, como decidir se recursos não críticos devem ser para usuários em más condições de rede. Neste guia, descreveremos todos os dicas disponíveis e algumas formas de usá-las para tornar o envio de conteúdo mais ser compatíveis com os usuários.

Ativação

Ao contrário do cabeçalho Accept, as dicas do cliente não aparecem mágica (com o exceto Save-Data, que vamos discutir mais adiante). A fim de manter no mínimo, será necessário escolher quais dicas de clientes quer receber enviando um cabeçalho Accept-CH quando um usuário solicita recurso:

Accept-CH: Viewport-Width, Downlink

O valor para Accept-CH é uma lista separada por vírgulas de dicas solicitadas que o site usará para determinar os resultados da solicitação de recurso subsequente. Quando o o cliente lê o cabeçalho e recebe a seguinte mensagem: "Este site quer que o Viewport-Width e Downlink dicas de cliente.” Não se preocupe com as dicas específicas. Veremos isso em breve.

É possível definir esses cabeçalhos em qualquer idioma de back-end. Por exemplo, PHP header poderia ser usada. É possível até mesmo definir esses cabeçalhos com o http-equiv atributo em uma tag <meta>:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

Todas as dicas do cliente!

As dicas do cliente descrevem uma das duas coisas: o dispositivo que seus usuários usam e a rede usada para acessar o site. Vamos conferir rapidamente dicas disponíveis.

Dicas do dispositivo

Algumas dicas do cliente descrevem as características do dispositivo do usuário, geralmente tela e as características determinantes. Algumas delas podem ajudar você a escolher o recurso de mídia ideal para de um determinado usuário, mas nem todos são necessariamente centrados na mídia.

Antes de entrarmos nesta lista, pode ser útil conhecer alguns termos-chave usados para descrever telas e a resolução de mídia:

Tamanho intrínseco:as dimensões reais de um recurso de mídia. Por exemplo, se você abre uma imagem no Photoshop, as dimensões mostradas na caixa de diálogo de tamanho da imagem descrever o tamanho intrínseco dele.

Tamanho intrínseco corrigido por densidade: as dimensões de um recurso de mídia após a densidade de pixels foi corrigida. É o tamanho intrínseco da imagem. dividido por um pixel do dispositivo proporção. Por exemplo, vejamos esta marcação:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Digamos que o tamanho intrínseco da imagem 1x, neste caso, seja 320 x 240, e o O tamanho intrínseco da imagem 2x é de 640 x 480. Se essa marcação for analisada por um cliente instalado em um dispositivo com uma proporção de pixels de 2 (por exemplo, uma tela Retina) tela), a imagem 2x será solicitada. O tamanho intrínseco com correção da densidade de a imagem 2x é 320 x 240, já que 640 x 480 dividido por 2 é 320 x 240.

Tamanho extrínseco: o tamanho de um recurso de mídia após CSS e outro layout fatores (como os atributos width e height) foram aplicados a ela. Vamos Digamos que você tenha um elemento <img> que carregue uma imagem com densidade corrigida tamanho intrínseco de 320 x 240, mas também tem as propriedades CSS width e height com valores de 256px e 192px aplicados a ela, respectivamente. Neste exemplo, o tamanho externo desse elemento <img> se torna 256 x 192.

Agora que já conhecemos alguns termos, vamos entrar na lista de configurações dicas de clientes disponíveis para você.

Largura da janela de visualização

Viewport-Width é a largura da janela de visualização do usuário em pixels CSS:

Viewport-Width: 320

Essa dica pode ser usada com outras dicas específicas da tela para oferecer diferentes tratamentos (por exemplo, cortes) de uma imagem que são ideais para tamanhos de tela específicos (por exemplo, arte direção), ou omitir recursos desnecessários para a largura atual da tela.

DPR

DPR, abreviação de "Proporção de pixels do dispositivo", informa a proporção de pixels físicos para CSS. pixels da tela do usuário:

DPR: 2

Essa dica é útil ao selecionar origens de imagem que correspondem ao tamanho a densidade de pixel, como descritores x no srcset ).

Largura

A dica Width aparece em solicitações de recursos de imagem acionadas por <img> ou Tags <source> usando sizes atributo. sizes informa ao navegador qual será o tamanho externo do recurso. O Width usa esse tamanho extrínseco para solicitar uma imagem com um tamanho intrínseco que é ideal para o layout atual.

Por exemplo, digamos que um usuário solicite uma página com uma largura de banda de 320 pixels CSS com uma DPR de 2. O dispositivo carrega um documento com um elemento <img> contendo um valor de atributo sizes de 85vw (ou seja, 85% da largura da janela de visualização para todos tamanhos de tela). Se a dica Width tiver sido ativada, o cliente enviará esta dica de Width para o servidor com a solicitação para o src do <img>:

Width: 544

Nesse caso, o cliente está insinuando ao servidor que uma solução intrínseca ideal a largura da imagem solicitada seria de 85% da largura da janela de visualização (272 pixels) multiplicado pelo DPR da tela (2), o que equivale a 544 pixels.

Essa dica é especialmente útil porque não só leva em conta os largura da tela com a densidade corrigida, mas também reconcilia essa parte crítica de informações com o tamanho externo da imagem dentro do layout. Isso dá dos servidores a oportunidade de negociar respostas de imagem ideais para ambos da tela e do layout.

Conteúdo-RPD

Embora você já saiba que as telas têm uma proporção de pixels do dispositivo, os recursos também têm suas próprias proporções de pixels. Nos casos de uso mais simples de seleção de recursos, as proporções entre dispositivos e recursos podem ser as mesmas. Mas! Nos casos em que os cabeçalhos DPR e Width estiverem funcionando, o tamanho externo de um recurso poderá criar cenários em que os dois são diferentes. É aqui que a dica Content-DPR aparece. entra em jogo.

Ao contrário de outras dicas de cliente, Content-DPR não é um cabeçalho de solicitação a ser usado por servidores, mas em vez disso, os servidores de cabeçalho de resposta devem enviar sempre que DPR e Dicas Width são usadas para selecionar um recurso. O valor de Content-DPR deve será o resultado desta equação:

Content-DPR = [tamanho do recurso de imagem selecionado] / ([Width] / [DPR])

Quando um cabeçalho de solicitação Content-DPR for enviado, o navegador saberá como escalonar a imagem fornecida para a proporção de pixels do dispositivo da tela e o layout. Sem isso, as imagens podem não ser dimensionadas corretamente.

Memória do dispositivo

Tecnicamente, parte da Memória do dispositivo API, Device-Memory revela a quantidade aproximada de memória O dispositivo atual tem em GiB:

Device-Memory: 2

Um possível caso de uso para essa dica seria reduzir a quantidade de enviadas para navegadores em dispositivos com memória limitada, pois o JavaScript é a os navegadores de tipos de conteúdo que consomem muitos recursos carregar. Ou você pode enviar imagens com DPR menor, porque elas usam menos memória para decodificar.

Dicas de rede

A API Network Information oferece outra categoria de dicas de clientes que descrevem o desempenho da rede do usuário uma conexão com a Internet. Na minha opinião, essas são as dicas mais úteis. Com eles, conseguem adaptar as experiências aos usuários, mudando a forma como oferecemos recursos a clientes em conexões lentas.

RTT

A dica RTT informa o tempo de retorno aproximado, em milissegundos, na camada do aplicativo. A dica RTT, ao contrário do RTT da camada de transporte, inclui o tempo de processamento do servidor.

RTT: 125

Essa dica é útil por causa do papel da latência no desempenho de carregamento. Usando a dica RTT, podemos tomar decisões com base na capacidade de resposta da rede, o que pode ajudar a acelerar a entrega de uma experiência inteira (por exemplo, por meio do omitindo algumas solicitações).

Downlink

A latência é importante no desempenho do carregamento, mas a largura de banda também é influente, também. A dica Downlink, expressa em megabits por segundo (Mbps), revela a Velocidade de downstream aproximada da conexão do usuário:

Downlink: 2.5

Em conjunto com RTT, Downlink pode ser útil para mudar a forma como o conteúdo é entregues aos usuários com base na qualidade de uma conexão de rede.

ECT

A dica ECT significa Tipo de conexão efetiva. Seu valor é um dos lista enumerada de tipos de conexão, cada um descrevendo uma conexão nos intervalos especificados de RTT e Downlink de classificação.

Esse cabeçalho não explica qual é o tipo de conexão real, por exemplo, por exemplo, ele não informa se o gateway é uma torre de celular ou um acesso Wi-Fi ponto Em vez disso, ele analisa a latência e a largura de banda da conexão atual e determina o perfil de rede mais parecido. Por exemplo, se você conectar por Wi-Fi em uma rede lenta, ECT pode ser preenchido com o valor 2g, que é a aproximação mais próxima da conexão efetiva:

ECT: 2g

Os valores válidos para ECT são 4g, 3g, 2g e slow-2g. Essa dica pode ser usado como ponto de partida para avaliar a qualidade da conexão e, posteriormente, refinado usando as dicas RTT e Downlink.

Salvar dados

Save-Data não é tanto uma dica que descreve as condições de rede, mas um usuário preferência indicando que as páginas devem enviar menos dados.

Prefiro classificar Save-Data como uma dica de rede porque muitas das coisas que você faria com ele são semelhantes a outras dicas de rede. Os usuários também podem ser em ambientes de alta latência/baixa largura de banda. Essa dica, quando presente, sempre fica assim:

Save-Data: on

Aqui no Google, falamos sobre o que você pode fazer com Save-Data. O impacto que isso pode ter no desempenho pode ser profundo. É um indicador de onde os usuários estão literalmente pedindo que você envie menos coisas. Se você ouvir e agir com base nisso, sinal, os usuários vão gostar.

Como tudo se junta

O que você faz com dicas de clientes depende de você. Porque eles oferecem muito informações, você tem muitas opções. Para fazer algumas ideias fluírem, vamos ver o que dicas de cliente podem fazer para Sconnie Madeira, uma madeira fictícia localizada no Meio-oeste rural. Como geralmente acontece no trabalho remoto, áreas, as conexões de rede podem ser frágeis. É aqui que uma tecnologia, como dicas de clientes, pode realmente fazer a diferença para os usuários.

Imagens responsivas

Todos os casos de uso de imagem responsiva, exceto os mais simples, podem se complicar. E se você têm vários tratamentos e variantes das mesmas imagens para diferentes telas; tamanhos e diferentes formatos? Essa marcação fica muito complicada muito rapidamente. É fácil errar, e é fácil esquecer ou entender as coisas importantes (como sizes).

Embora <picture> e srcset sejam ferramentas inegavelmente incríveis, elas podem ser levar muito tempo para desenvolver e manter para casos de uso complexos. Podemos automatizar a geração de marcações, mas isso também é difícil porque a funcionalidade <picture> e srcset fornecem é complexa o suficiente para que a automação precise seja feito de uma forma que mantenha a flexibilidade que eles fornecem.

As dicas do cliente podem simplificar isso. Como negociar respostas de imagem com o cliente dicas podem ser semelhantes a:

1. Se aplicável ao seu fluxo de trabalho, primeiro selecione um tratamento de imagem (por exemplo, imagens com direção de arte) verificando a dica Viewport-Width.
2. Selecione uma resolução de imagem verificando a dica Width e DPR. escolher uma fonte que se ajuste ao tamanho do layout da imagem e à densidade da tela (semelhantes de como os descritores x e w funcionam em srcset).
3. Selecione o formato de arquivo ideal para o navegador (algo Accept) nos ajuda a fazer na maioria dos navegadores).

No que diz respeito a meu cliente fictício, uma empresa de madeira, eu desenvolvi uma linguagem simples rotina de seleção de imagem responsiva em PHP que usa dicas do cliente. Isso significou em vez de enviar essa marcação para todos os usuários:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

Consegui reduzir para o seguinte com base no suporte a cada navegador:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

Neste exemplo, o URL /image é um script PHP seguido por parâmetros reescrito por mod_rewrite. Ela usa um nome de arquivo de imagem e parâmetros adicionais para ajudar um script de back-end escolher a melhor imagem nas condições fornecidas.

Percebo que "Mas isso não está apenas reimplementando <picture> e srcset nos back-end?” é a sua primeira pergunta.

De certa forma, sim, mas com uma diferença importante: quando um aplicativo usa dicas de clientes para elaborar respostas de mídia, a maior parte (se não todo) do trabalho é muito mais fáceis de automatizar, o que pode incluir um serviço (como uma CDN) que possa fazer isso em seu nome. Enquanto nas soluções HTML, a nova marcação precisa ser gravada para todos os casos de uso. Claro que é possível automatizar a geração de marcações. Se as no design ou nos requisitos, há uma boa chance de você precisar revisar sua estratégia de automação no futuro.

As dicas do cliente permitem começar com um protótipo de alta resolução imagem que pode ser redimensionada dinamicamente para ser ideal para qualquer combinação de tela e layout. Ao contrário de srcset, que exige que você enumere um valor fixo lista de possíveis imagens candidatas para o navegador escolher, essa abordagem podem ser mais flexíveis. Por outro lado, a srcset força você a oferecer aos navegadores um conjunto de variantes, como 256w, 512w, 768w e 1024w, uma dica do cliente pode atender a todas as larguras, sem uma pilha enorme de marcações.

Obviamente, você não precisa escrever a lógica de seleção de imagens por conta própria. Cloudinary usa dicas do cliente para criar respostas de imagem ao usar o w_auto. parâmetro, e observou que os usuários medianos baixavam 42% menos bytes ao usar navegadores suporte a dicas do cliente.

Mas cuidado! As mudanças na versão para computador do Chrome 67 removeram o suporte para clientes de origem cruzada dicas. Felizmente, essas restrições não afetam as versões do Chrome para dispositivos móveis. elas serão removidas completamente para todas as plataformas quando trabalharem no Recurso a política esteja concluída.

Como ajudar usuários em redes lentas

Performance adaptável é a ideia de que podemos ajustar a forma como oferecemos recursos com base nas informações que o cliente Hints nos disponibiliza; especificamente informações sobre o estado atual da conexão de rede do usuário.

Com relação ao site de Sconnie Timber, tomamos medidas para reduzir a carga quando As redes são lentas, com os cabeçalhos Save-Data, ECT, RTT e Downlink sendo examinadas em nosso código de back-end. Quando isso é feito, geramos uma configuração de qualidade de rede que podemos usar para determinar se devemos intervir para melhorar a qualidade do usuário. Esta pontuação de rede está entre 0 e 1, em que 0 é a pior a qualidade de rede possível, e 1 é a melhor.

Inicialmente, verificamos se Save-Data está presente. Se sim, a pontuação é definida como 0, já que estamos supondo que o usuário quer que façamos o que for necessário para tornar a tenha uma experiência mais leve e rápida.

No entanto, se Save-Data estiver ausente, vamos seguir em frente e ponderar os valores de ECT, dicas RTT e Downlink para calcular uma pontuação que descreve a rede a qualidade da conexão. A fonte de geração da pontuação de rede código está disponível no GitHub. A conclusão é que, se usarmos as dicas relacionadas à rede de alguma maneira, podemos melhorar as experiências para quem está lento redes VPC.

Quando os sites se adaptam às informações que as dicas do cliente fornecem, não precisamos adotar uma abordagem de “tudo ou nada”. Podemos decidir de forma inteligente quais recursos enviar. Podemos modificar nossa lógica de seleção de imagem responsiva para enviar imagens com qualidade imagens de uma determinada tela para acelerar o desempenho de carregamento quando a qualidade da rede é ruim.

Neste exemplo, podemos ver o impacto que as dicas do cliente têm quando se trata de melhorando o desempenho de sites em redes mais lentas. Abaixo está um WebPagetest hierarquia de um site em uma rede lenta que não se adapta às dicas do cliente:

E agora uma cascata para o mesmo site na mesma conexão lenta, exceto que esta tempo, o site usa dicas de clientes para eliminar recursos não críticos da página:

As dicas do cliente reduziram o tempo de carregamento da página de mais de 45 segundos para menos do que um décimo desse tempo. Os benefícios das dicas do cliente neste cenário não podem ser enfatizadas o suficiente e pode ser um grande benefício para usuários que buscam informações em redes lentas.

Além disso, é possível usar dicas de clientes sem prejudicar a experiência. para navegadores que não são compatíveis com elas. Por exemplo, se quisermos ajustar recursos entrega após o valor da dica ECT, sem deixar de entregar experiência em navegadores não compatíveis, podemos voltar para o valor padrão assim:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

Aqui, "4g" representa a conexão de rede de maior qualidade do cabeçalho ECT. descreve. Se inicializarmos $ect como "4g", os navegadores incompatíveis com o cliente as dicas não serão afetadas. Aceite!

Cuidado com os caches!

Sempre que você alterar uma resposta com base em um cabeçalho HTTP, precisará conhecer como os caches vão lidar com as buscas futuras desse recurso. O Vary cabeçalho é é indispensável aqui, já que ele faz com que as entradas do cache sejam chaves para o valor dos cabeçalhos da solicitação fornecidas a ele. Simplificando, se você modificar uma resposta com base em um determinado HTTP cabeçalho de solicitação, inclua quase sempre esse cabeçalho em Vary assim:

Vary: DPR, Width

Existe uma ressalva grande para isso: não convém usar Vary para armazená-la em cache. respostas em um cabeçalho que muda com frequência (como Cookie) porque essas esses recursos se tornam efetivamente não armazenáveis em cache. Sabendo disso, convém evitar Use Vary em cabeçalhos de dicas do cliente, como RTT ou Downlink, porque eles são de conexão que podem mudar com frequência. Se você quiser modificar de entrada nesses cabeçalhos, considere codificar apenas o cabeçalho ECT, que para minimizar as ausências no cache.

Isso só se aplica se você estiver armazenando uma resposta em cache. Por exemplo, você não armazenará recursos HTML em cache se o conteúdo deles for dinâmico, porque que podem prejudicar a experiência do usuário em visitas repetidas. Em casos como esses, sinta livre para modificar essas respostas da forma que você achar necessária e não Preocupação com Vary.

Dicas do cliente em service workers

A negociação de conteúdo não é mais apenas para servidores. Como os service workers agem como proxies entre clientes e servidores, você tem controle sobre como os recursos são entregues via JavaScript. Isso inclui dicas de clientes. No service worker fetch, é possível usar o evento event request.headers.get para ler os cabeçalhos da solicitação de um recurso da seguinte forma:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

Qualquer cabeçalho de dica do cliente que você ativar pode ser lido dessa maneira. Embora isso seja é a única maneira de conseguir algumas dessas informações. Dicas específicas de rede podem ser lidas nestas propriedades JavaScript equivalentes no objeto navigator:

.

Plug-ins do Imagemin para tipos de arquivos.

Dica do cliente	Equivalente em JS
"ECT"	`navigator.connection.effectiveType`
RTT	`navigator.connection.rtt`
"Salvar dados"	`navigator.connection.saveData`
"Downlink"	`navigator.connection.downlink`
"Memória do dispositivo"	`navigator.deviceMemory`

Como essas APIs não estão disponíveis em todos os lugares onde você precisa da verificação de recursos com o in operador:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

A partir daqui, você pode usar uma lógica semelhante à que usaria no servidor, mas você não precisa de um servidor para negociar conteúdo com dicas de clientes. Serviço por si só, o poder de tornar as experiências mais rápidas e resilientes além da capacidade extra de veicular conteúdo quando o usuário está off-line.

Conclusão

Com dicas de clientes, podemos deixar as experiências mais rápidas para os usuários em um totalmente progressiva. Podemos veicular mídia com base no dispositivo do usuário de uma forma que torne a exibição de imagens responsivas mais fácil do que no <picture> e no srcset, principalmente para casos de uso complexos. Isso nos permite não apenas para reduzir o tempo e o esforço de desenvolvimento, mas também para otimizar recursos, principalmente imagens, de modo a segmentar as telas do usuário de forma mais detalhada do que e srcset.

E talvez o mais importante: podemos detectar conexões de rede ruins e a lacuna para os usuários, modificando o que enviamos e como enviamos. Isso pode ajudam muito a facilitar o acesso de usuários em redes frágeis a sites. Combinados com service workers, podemos criar sites incrivelmente rápidos que são disponível off-line.

Embora as dicas de cliente só estejam disponíveis no Chrome (e com base no Chromium) navegadores. É possível usá-los de forma que não complique que não são compatíveis com elas. Considere o uso de dicas de clientes para criar anúncios experiências inclusivas e adaptáveis que conheçam o dispositivo de cada usuário recursos e as redes às quais se conectam. Espero que outros fornecedores de navegadores vão ver o valor delas e mostrar a intenção de implementar.

Recursos

• Imagens responsivas automáticas com o cliente Dicas
• Dicas de cliente e imagens responsivas: o que mudou no Chrome 67
• Receba uma dica (cliente) (Apresentações)
• Como entregar aplicativos rápidos e leves com Save-Data

Obrigado a Ilya Grigorik, Érico Portis, Jeff Posnick e Yoav Weiss e Estelle Weyl para feedbacks e edições valiosos neste artigo.