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.
width: 256px;.
e height: 192px; transforma uma imagem de 320 x 240 de tamanho intrínseco
para um de 256 x 192 de tamanho extrínseco.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:
- 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. - Selecione uma resolução de imagem verificando a dica
WidtheDPR. escolher uma fonte que se ajuste ao tamanho do layout da imagem e à densidade da tela (semelhantes de como os descritoresxewfuncionam emsrcset). - 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:
| 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 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.