Desenvolver sites que sejam rápidos em todos os lugares pode ser uma tarefa difícil. A infinidade de recursos de dispositivos e a qualidade das redes às quais eles se conectam podem fazer com que isso pareça uma tarefa impossível. Embora possamos aproveitar os recursos do navegador para melhorar o desempenho de carregamento, como saber do que o dispositivo do usuário é capaz ou a qualidade da conexão de rede dele? A solução são as dicas de cliente HTTP.
As dicas de cliente HTTP são um conjunto de cabeçalhos de solicitação HTTP que dão insights sobre esses aspectos do dispositivo do usuário e da rede em que ele está conectado. Ao acessar essas informações no lado do servidor, podemos mudar como entregamos o conteúdo 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 gira em torno da negociação de conteúdo
As dicas de cliente HTTP são outro método de negociação de conteúdo, o que significa mudar as respostas de conteúdo com base nos cabeçalhos da solicitação do navegador.
Um exemplo de negociação de conteúdo envolve o cabeçalho da solicitação Accept. Ele descreve quais tipos de conteúdo o navegador entende, 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 sejam compatíveis com formatos de imagem como JPEG, PNG e GIF, o Accept informa, neste caso, que o navegador também é compatível com WebP e APNG. Com essas informações, podemos negociar os melhores tipos de imagem 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 Accept, as dicas de cliente HTTP são outra forma de negociar conteúdo, mas no
contexto dos recursos do dispositivo e das condições da rede. Com as dicas de cliente HTTP, podemos
tomar decisões de desempenho do lado do servidor com base na experiência individual
do usuário, como decidir se recursos não críticos devem ser disponibilizados para
usuários com condições de rede ruins. Neste guia, vamos descrever todas as
dicas disponíveis e algumas maneiras de usá-las para tornar a entrega de conteúdo mais
adequada aos usuários.
Ativação
Ao contrário do cabeçalho Accept, as dicas de cliente HTTP não aparecem magicamente, com exceção de Save-Data, que vamos discutir mais adiante. Para manter os cabeçalhos da solicitação no mínimo, você precisa escolher quais dicas de cliente HTTP quer receber enviando um cabeçalho Accept-CH quando um usuário solicita um recurso:
Accept-CH: Viewport-Width, Downlink
O valor de Accept-CH é uma lista separada por vírgulas de dicas solicitadas que o site
vai usar para determinar os resultados da solicitação de recurso subsequente. Quando o
cliente lê esse cabeçalho, ele recebe a mensagem "este site quer as dicas de cliente HTTP Viewport-Width
e Downlink". Não se preocupe com as dicas específicas.
Vamos falar sobre isso em breve.
É possível definir esses cabeçalhos de ativação em qualquer linguagem de back-end. Por exemplo, é possível usar a função header do PHP.
Você pode até mesmo definir esses cabeçalhos de ativação com o atributo http-equiv em uma tag <meta>:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Todas as dicas de cliente HTTP!
As dicas de cliente HTTP descrevem uma de duas coisas: o dispositivo que os usuários usam e a rede que eles estão usando para acessar seu site. Vamos falar brevemente sobre todas as dicas disponíveis.
Dicas do dispositivo
Algumas dicas de cliente HTTP descrevem características do dispositivo do usuário, geralmente da tela. Alguns deles podem ajudar você a escolher o recurso de mídia ideal para a tela de um determinado usuário, mas nem todos são necessariamente centrados em mídia.
Antes de entrarmos nessa lista, pode ser útil aprender alguns termos importantes usados para descrever telas e resolução de mídia:
Tamanho intrínseco: as dimensões reais de um recurso de mídia. Por exemplo, se você abrir uma imagem no Photoshop, as dimensões mostradas na caixa de diálogo de tamanho da imagem vão descrever o tamanho intrínseco dela.
Tamanho intrínseco corrigido por densidade: as dimensões de um recurso de mídia após a correção da densidade de pixels. É o tamanho intrínseco da imagem dividido por uma proporção de pixels do dispositivo. Por exemplo, considere 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 nesse caso seja 320 x 240, e o
tamanho intrínseco da imagem 2x seja 640 x 480. Se essa marcação for analisada por um cliente
instalado em um dispositivo com uma proporção de pixels de tela de 2 (por exemplo, uma tela
Retina), a imagem 2x será solicitada. O tamanho intrínseco com correção de densidade da
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 depois que o CSS e outros fatores de layout (como os atributos width e height) são aplicados a ele. Digamos
que você tenha um elemento <img> que carrega uma imagem com um tamanho intrínseco
corrigido por densidade de 320 x 240, mas que também tenha propriedades CSS width e height
com valores de 256px e 192px aplicados a ele, respectivamente. Neste exemplo,
o tamanho extrínseco do elemento <img> se torna 256x192.
width: 256px;
e height: 192px; transforma uma imagem de tamanho intrínseco de 320 x 240
em uma de tamanho extrínseco de 256 x 192.Agora que você já conhece a terminologia, vamos conferir a lista de dicas de cliente HTTP específicas do dispositivo disponíveis para você.
Viewport-Width
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 de tela para oferecer diferentes tratamentos (ou seja, cortes) de uma imagem que são ideais para tamanhos de tela específicos (ou seja, direção de arte) ou para omitir recursos desnecessários para a largura da tela atual.
DPR
DPR, abreviação de proporção de pixels do dispositivo, informa a proporção de pixels físicos em relação aos pixels CSS
da tela do usuário:
DPR: 2
Essa dica é útil ao selecionar fontes de imagem que correspondem à densidade de pixels de uma tela, como os descritores x fazem no atributo srcset.
Largura
A dica Width aparece em solicitações de recursos de imagem acionadas por tags <img> ou
<source> que usam o atributo
sizes.
sizes informa ao navegador qual será o tamanho extrínseco do recurso.
Width usa esse tamanho extrínseco para solicitar uma imagem com um tamanho intrínseco
ideal para o layout atual.
Por exemplo, digamos que um usuário solicite uma página com uma tela de 320 pixels CSS de largura
com um DPR de 2. O dispositivo carrega um documento com um elemento <img> que contém
um valor do atributo sizes de 85vw (ou seja, 85% da largura da janela de visualização para todos
os tamanhos de tela). Se a dica Width tiver sido ativada, o cliente vai enviar
essa dica Width ao servidor com a solicitação do src do <img>:
Width: 544
Nesse caso, o cliente está sugerindo ao servidor que uma largura intrínseca ideal para a imagem solicitada seria 85% da largura da janela de visualização (272 pixels) multiplicada pela DPR da tela (2), o que equivale a 544 pixels.
Essa dica é especialmente poderosa porque não apenas considera a largura da tela corrigida pela densidade, mas também reconcilia essa informação crítica com o tamanho extrínseco da imagem no layout. Isso dá aos servidores a oportunidade de negociar respostas de imagem ideais para a tela e o layout.
Content-DPR
Embora você já saiba que as telas têm uma proporção de pixels do dispositivo, os recursos também
têm as próprias proporções de pixels. Nos casos de uso mais simples de seleção de recursos, as proporções de pixels
entre dispositivos e recursos podem ser as mesmas. Mas! Nos casos em que os cabeçalhos DPR e Width estão em jogo, o tamanho extrínseco de um recurso pode produzir cenários em que os dois diferem. É aí que entra a dica
Content-DPR.
Ao contrário de outras dicas de cliente, Content-DPR não é um cabeçalho de solicitação a ser usado por
servidores, mas sim um cabeçalho de resposta que os servidores precisam enviar sempre que as dicas DPR e
Width são usadas para selecionar um recurso. O valor de Content-DPR precisa
ser o resultado desta equação:
Content-DPR = [Tamanho do recurso de imagem selecionado] / ([Width] / [DPR])
Quando um cabeçalho da solicitação Content-DPR é enviado, o navegador sabe como dimensionar
a imagem para a proporção de pixels do dispositivo da tela e o layout. Sem ele,
as imagens podem não ser dimensionadas corretamente.
Device-Memory
Tecnicamente, como parte da API Device Memory, Device-Memory revela a quantidade aproximada de memória que o dispositivo atual tem em GiB:
Device-Memory: 2
Um possível caso de uso para essa dica seria reduzir a quantidade de JavaScript enviada aos navegadores em dispositivos com memória limitada, já que o JavaScript é o tipo de conteúdo que mais consome recursos que os navegadores costumam carregar. Ou você pode enviar imagens com DPR menor, já que elas usam menos memória para decodificação.
Dicas de rede
A API Network Information fornece outra categoria de dicas de cliente HTTP que descrevem o desempenho da conexão de rede do usuário. Na minha opinião, esse é o conjunto de dicas mais útil. Com elas, podemos personalizar as experiências dos usuários mudando a forma como entregamos recursos aos clientes em conexões lentas.
RTT
A dica RTT fornece 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 devido ao papel que a latência desempenha 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, omitindo
algumas solicitações).
Downlink
Embora a latência seja importante no desempenho de carregamento, a largura de banda também é
influente. 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 é
entregue aos usuários com base na qualidade de uma conexão de rede.
ECT
A dica ECT significa Tipo de conexão efetiva. O valor dele é uma
lista enumerada de tipos de conexão, cada um descrevendo uma conexão
dentro de intervalos especificados de valores de RTT e Downlink.
Esse cabeçalho não explica qual é o tipo de conexão real. Por exemplo, ele não informa se o gateway é uma torre de celular ou um ponto de acesso Wi-Fi. Em vez disso, ele analisa a latência e a largura de banda da conexão atual e
determina com qual perfil de rede ela se parece mais. Por exemplo, se você se conectar
por Wi-Fi a uma rede lenta, ECT poderá ser preenchido com um valor de 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
usada como ponto de partida para avaliar a qualidade da conexão e, em seguida,
refinada usando as dicas RTT e Downlink.
Save-Data
Save-Data não é tanto uma dica que descreve as condições da rede, mas sim uma preferência do usuário
que indica que as páginas precisam 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
ativá-lo em ambientes de alta latência/baixa largura de banda. Essa dica, quando
presente, sempre tem esta aparência:
Save-Data: on
Aqui no Google, já falamos sobre o que você pode fazer com o
Save-Data.
O impacto que isso pode ter no desempenho é profundo. É um sinal de que os usuários
estão literalmente pedindo para você enviar menos conteúdo. Se você ouvir e agir de acordo com esse
sinal, os usuários vão gostar.
Como tudo se junta
O que você faz com as dicas de cliente HTTP depende de você. Como eles oferecem muitas informações, você tem muitas opções. Para ter algumas ideias, vamos ver o que as dicas de cliente HTTP podem fazer pela Sconnie Timber, uma empresa madeireira fictícia localizada na zona rural do Meio-Oeste dos EUA. Como costuma acontecer em áreas remotas, as conexões de rede podem ser instáveis. É aí que uma tecnologia como as dicas de cliente HTTP pode realmente fazer a diferença para os usuários.
Imagens responsivas
Todos os casos de uso de imagens responsivas, exceto os mais simples, podem ser complicados. E se você
tiver vários tratamentos e variantes das mesmas imagens para diferentes tamanhos de tela
e formatos diferentes? Essa marcação fica muito complicada muito
rapidamente.
É fácil errar e esquecer ou entender mal conceitos importantes (como sizes).
Embora o <picture> e o srcset sejam ferramentas incríveis, o desenvolvimento e a manutenção deles podem ser demorados para casos de uso complexos. Podemos automatizar
a geração de marcação, mas isso também é difícil porque a funcionalidade
oferecida por <picture> e srcset é complexa o suficiente para que a automação precise
ser feita de uma forma que mantenha a flexibilidade que eles oferecem.
As dicas de cliente HTTP podem simplificar isso. A negociação de respostas de imagem com dicas de cliente HTTP pode ser assim:
- Se aplicável ao seu fluxo de trabalho, primeiro selecione um tratamento de imagem (ou seja,
imagens com direção de arte) marcando a dica
Viewport-Width. - Selecione uma resolução de imagem verificando as dicas
WidtheDPRe escolhendo uma origem que se ajuste ao tamanho do layout e à densidade da tela da imagem (semelhante ao funcionamento dos descritoresxewemsrcset). - Selecione o formato do arquivo mais adequado para o navegador (algo que o
Acceptnos ajuda a fazer na maioria dos navegadores).
No caso do meu cliente fictício, uma empresa de madeira, desenvolvi uma rotina simples de seleção de imagens responsivas em PHP que usa dicas de cliente HTTP. Isso significa que, 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 de 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
reescritos por
mod_rewrite. Ele
usa um nome de arquivo de imagem e parâmetros adicionais para ajudar um script de back-end
a escolher a melhor imagem nas condições fornecidas.
Imagino que sua primeira pergunta seja: "Mas isso não é apenas reimplementar <picture> e srcset no
back-end?".
De certa forma, sim, mas com uma distinção importante: quando um aplicativo usa dicas de cliente HTTP para criar respostas de mídia, a maior parte (se não todo) do trabalho é muito mais fácil de automatizar, o que pode incluir um serviço (como uma CDN) que pode fazer isso em seu nome. Já com as soluções HTML, é preciso escrever uma nova marcação para cada caso de uso. Sim, você pode automatizar a geração de marcação. No entanto, se o design ou os requisitos mudarem, é provável que você precise revisar sua estratégia de automação no futuro.
As dicas de cliente HTTP permitem começar com uma imagem de alta resolução sem perdas, 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 uma lista fixa
de possíveis candidatos de imagem para o navegador escolher, essa abordagem
pode ser mais flexível. Enquanto o srcset força você a oferecer aos navegadores um conjunto aproximado
de variantes, como 256w, 512w, 768w e 1024w, uma solução
com tecnologia de dicas de cliente pode atender a todas as larguras, sem uma pilha gigante de marcação.
Claro que você não precisa escrever a lógica de seleção de imagens por conta própria. O Cloudinary
usa dicas de cliente HTTP para criar respostas de imagem quando você usa o parâmetro
w_auto
e observou que os usuários medianos baixaram 42% menos bytes ao usar navegadores
compatíveis com dicas de cliente HTTP.
Mas cuidado! As mudanças na versão para computador do Chrome 67 removeram o suporte para dicas de cliente HTTP entre origens. Felizmente, essas restrições não afetam as versões para dispositivos móveis do Chrome e serão totalmente suspensas para todas as plataformas quando o trabalho na política de recursos for concluído.
Como ajudar usuários em redes lentas
Desempenho adaptável é a ideia de que podemos ajustar como entregamos recursos com base nas informações que as dicas de cliente HTTP disponibilizam, especificamente informações sobre o estado atual da conexão de rede do usuário.
No site da Sconnie Timber, tomamos medidas para reduzir a carga quando as redes estão lentas, com os cabeçalhos Save-Data, ECT, RTT e Downlink sendo examinados no código de back-end. Quando isso é feito, geramos uma pontuação de qualidade de rede que podemos usar para determinar se devemos intervir para melhorar a experiência do usuário. Essa pontuação de rede fica entre 0 e 1, em que 0 é a pior
qualidade de rede possível e 1 é a melhor.
Primeiro, verificamos se Save-Data está presente. Se for, a pontuação será definida como
0, porque presumimos que o usuário quer que façamos o que for necessário para tornar a
experiência mais leve e rápida.
No entanto, se Save-Data estiver ausente, vamos analisar os valores das dicas ECT,
RTT e Downlink para calcular uma pontuação que descreve a qualidade da conexão
de rede. O código-fonte de geração de pontuação de rede está disponível no GitHub. A conclusão é que, se usarmos as dicas relacionadas à rede de
alguma forma, poderemos melhorar as experiências de quem está em redes
lentas.
Quando os sites se adaptam às informações fornecidas pelas dicas de cliente HTTP, 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 imagens responsivas para enviar imagens de qualidade inferior para uma determinada tela, acelerando o desempenho de carregamento quando a qualidade da rede for ruim.
Neste exemplo, podemos ver o impacto que as dicas de cliente HTTP têm quando se trata de melhorar o desempenho de sites em redes mais lentas. Veja abaixo um gráfico em cascata do WebPagetest de um site em uma rede lenta que não se adapta às dicas de cliente HTTP:
Agora, uma cascata para o mesmo site na mesma conexão lenta, mas, desta vez, o site usa dicas de cliente HTTP para eliminar recursos de página não críticos:
As dicas de cliente HTTP reduziram o tempo de carregamento da página de mais de 45 segundos para menos de um décimo desse tempo. Os benefícios das dicas de cliente HTTP nesse cenário são inestimáveis e podem ser uma grande vantagem para usuários que buscam informações importantes em redes lentas.
Além disso, é possível usar as dicas de cliente HTTP sem prejudicar a experiência em navegadores que não são compatíveis com elas. Por exemplo, se quisermos ajustar a entrega de recursos
usando o valor da dica ECT e, ao mesmo tempo, oferecer a experiência
completa para navegadores sem suporte, podemos definir um valor padrão
como este:
// 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 descrita pelo cabeçalho
ECT. Se inicializarmos $ect como "4g", os navegadores que não são compatíveis com as dicas de cliente HTTP não serão afetados. Ative o FTW!
Cuidado com os caches!
Sempre que você mudar uma resposta com base em um cabeçalho HTTP, é preciso estar ciente de
como os caches vão processar as buscas futuras desse recurso. O cabeçalho Vary é indispensável aqui, porque ele associa as entradas de cache ao valor dos cabeçalhos da solicitação fornecidos. Em resumo, se você modificar qualquer resposta com base em um determinado cabeçalho da solicitação HTTP, quase sempre será necessário incluir esse cabeçalho da solicitação em Vary, desta forma:
Vary: DPR, Width
No entanto, há uma grande ressalva: nunca Vary respostas armazenáveis em cache
em um cabeçalho que muda com frequência (como Cookie), porque esses
recursos se tornam efetivamente não armazenáveis em cache. Sabendo disso, evite usar Vary em cabeçalhos de dicas de cliente HTTP, como RTT ou Downlink, porque esses são fatores de conexão que podem mudar com frequência. Se você quiser modificar
as respostas nesses cabeçalhos, considere usar apenas o cabeçalho ECT, o que vai
minimizar as ausências no cache.
Claro, isso só se aplica se você estiver armazenando uma resposta em cache.
Por exemplo, não armazene em cache recursos HTML se o conteúdo deles for dinâmico, porque
isso pode prejudicar a experiência do usuário em visitas repetidas. Nesses casos, fique à vontade para modificar as respostas com base no que achar necessário, sem se preocupar com Vary.
Dicas de cliente HTTP em service workers
A negociação de conteúdo não é mais apenas para servidores. Como os service workers atuam
como proxies entre clientes e servidores, você tem controle sobre como os recursos
são entregues via JavaScript. Isso inclui dicas de cliente HTTP. No evento fetch do service worker, use o método request.headers.get do objeto event para ler os cabeçalhos da solicitação de um recurso, desta 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 de cliente HTTP que você ativar pode ser lido dessa maneira. Mas essa não é a única maneira de conseguir algumas dessas informações. As dicas específicas de rede
podem ser lidas nestas propriedades JavaScript equivalentes no objeto navigator:
| Dica de cliente HTTP | Equivalente em JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Como essas APIs não estão disponíveis em todos os lugares, é necessário verificar os recursos com o
operador
in:
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 não precisa de um servidor para negociar conteúdo com dicas de cliente HTTP. Os service workers têm o poder de tornar as experiências mais rápidas e resilientes devido à capacidade de veicular conteúdo quando o usuário está off-line.
Conclusão
Com as dicas de cliente HTTP, podemos tornar as experiências mais rápidas para os usuários de uma
maneira totalmente progressiva. Podemos veicular mídia com base nos recursos do dispositivo do usuário de uma forma que facilite a veiculação de imagens responsivas em vez de depender de <picture> e srcset, especialmente para casos de uso complexos. Isso nos permite
não apenas reduzir o tempo e o esforço no desenvolvimento, mas também otimizar
recursos, principalmente imagens, de uma forma que segmente as telas do usuário
com mais precisão do que
Talvez o mais importante seja que podemos detectar conexões de rede ruins e preencher a lacuna para os usuários modificando o que enviamos e como enviamos. Isso pode ajudar muito a facilitar o acesso aos sites para usuários em redes instáveis. Combinado com service workers, podemos criar sites incrivelmente rápidos que estão disponíveis off-line.
Embora as dicas de cliente HTTP estejam disponíveis apenas no Chrome e em navegadores baseados no Chromium, é possível usá-las de uma forma que não sobrecarregue os navegadores que não são compatíveis com elas. Considere usar as dicas de cliente HTTP para criar experiências verdadeiramente inclusivas e adaptáveis que estejam cientes dos recursos do dispositivo de cada usuário e das redes às quais eles se conectam. Esperamos que outros fornecedores de navegadores percebam o valor deles e mostrem intenção de implementar.
Recursos
- Imagens responsivas automáticas com dicas de cliente HTTP
- Dicas de cliente HTTP e imagens responsivas: o que mudou no Chrome 67
- Dicas de cliente HTTP (Slides)
- Como criar aplicativos rápidos e leves com o
Save-Data
Agradecemos a Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss e Estelle Weyl pelo feedback e pelas edições valiosas neste artigo.