Como adaptar aos usuários com dicas do cliente

Desenvolver sites rápidos em qualquer lugar pode ser complicado. A infinidade de recursos do dispositivo e a qualidade das redes às quais eles se conectam podem fazer parecer uma tarefa insuperável. Embora possamos aproveitar os recursos do navegador para melhorar o desempenho de carregamento, como sabemos do que o dispositivo do usuário é capaz ou a qualidade da conexão de rede? A solução são as dicas para o cliente.

As dicas do cliente são um conjunto de cabeçalhos de solicitação HTTP ativados que nos dão insights sobre esses aspectos do dispositivo do usuário e da rede a que ele está conectado. Ao acessar esse lado do servidor de informações, podemos mudar a forma de exibição de conteúdo com base nas condições do dispositivo e/ou da rede. Isso pode nos ajudar a criar experiências do usuário mais inclusivas.

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

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

Um exemplo de negociação de conteúdo envolve o cabeçalho de solicitação Accept. Ele descreve quais tipos de conteúdo o navegador entende e 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 ofereçam suporte a formatos de imagem como JPEG, PNG e GIF, Accept informa nesse caso que o navegador também oferece suporte a 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 em Accept, as dicas do cliente são outra forma de negociar conteúdo, mas no contexto dos recursos do dispositivo e das condições da rede. Com as dicas do cliente, podemos tomar decisões de desempenho no lado do servidor com base na experiência individual de um usuário, como decidir se recursos não críticos devem ser disponibilizados a usuários com más condições de rede. Neste guia, vamos descrever todas as dicas disponíveis e algumas maneiras de usá-las para tornar o envio de conteúdo mais adequado aos usuários.

Ativação

Ao contrário do cabeçalho Accept, as dicas do cliente não aparecem magicamente (com exceção de Save-Data, que vamos discutir mais tarde). Para manter o mínimo dos cabeçalhos das solicitações, escolha quais dicas de cliente receberá enviando um cabeçalho Accept-CH quando um usuário solicitar 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 para a próxima solicitação de recurso. Quando o cliente lê esse cabeçalho, ele é informado de que "este site quer as dicas do cliente Viewport-Width e Downlink". Não se preocupe com as dicas específicas. Vamos abordar isso daqui a pouco.

É possível definir esses cabeçalhos de permissão em qualquer idioma de back-end. Por exemplo, a função header do PHP pode ser usada. 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 do cliente!

As dicas do cliente descrevem duas coisas: o dispositivo que os usuários usam e a rede que eles usam para acessar seu site. Vamos abordar rapidamente todas as dicas disponíveis.

Dicas do dispositivo

Algumas dicas do cliente descrevem as características do dispositivo do usuário, geralmente características 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 na mídia.

Antes de entrarmos nessa lista, pode ser útil aprender alguns termos-chave 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 descrevem o tamanho intrínseco dela.

Tamanho intrínseco de densidade corrigida:as dimensões de um recurso de mídia após a correção para a densidade de pixels. É o tamanho intrínseco da imagem dividido pela proporção de pixels do dispositivo. Por exemplo, vamos pegar 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 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 dispositivo de tela de 2 (por exemplo, uma tela Retina), a imagem 2x será solicitada. O tamanho intrínseco de densidade corrigida 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) foram aplicados a ele. Digamos que você tem um elemento <img> que carrega uma imagem com um tamanho intrínseco de densidade corrigida de 320 x 240, mas que também tem propriedades CSS width e height com valores 256px e 192px aplicados, respectivamente. Neste exemplo, o tamanho externo desse elemento <img> passa a ser 256 x 192.

Agora que conhecemos alguns termos, vamos conferir a lista de dicas de cliente específicas do dispositivo 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 tratamentos diferentes (por exemplo, cortes) de uma imagem que sejam ideais para tamanhos de tela específicos (por exemplo, direção da arte) ou para omitir recursos desnecessários para a largura atual da tela.

RPDC

DPR, abreviação de "Proporção de pixels do dispositivo", informa a proporção de pixels físicos para 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 disparadas por tags <img> ou <source> usando o atributo sizes. sizes informa ao navegador qual será o tamanho externo do recurso. Width usa esse tamanho externo 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 tela ampla CSS de 320 pixels e uma DPR de 2. O dispositivo carrega um documento com um elemento <img> que contém um valor de 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 para o src do <img>:

Width: 544

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

Essa dica é especialmente eficiente, porque não apenas considera a largura de densidade corrigida da tela, mas também reconcilia essa informação essencial com o tamanho externo da imagem no layout. Isso dá aos servidores a oportunidade de negociar respostas de imagem que são ideais para a tela e o layout.

Conteúdo-DPR

Embora você já saiba que as telas têm uma proporção de pixels do dispositivo, os recursos também têm a própria proporção de pixels. Nos casos de uso de seleção de recursos mais simples, a proporção de pixels entre dispositivos e recursos pode ser a mesma. Mas! Nos casos em que os cabeçalhos DPR e Width estão sendo executados, o tamanho externo de um recurso pode produzir cenários em que os dois são diferentes. É aqui que a dica Content-DPR entra em jogo.

Ao contrário de outras dicas de cliente, Content-DPR não é um cabeçalho de solicitação a ser usado pelos servidores. Na verdade, um cabeçalho de resposta precisa ser enviado sempre que 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 de solicitação Content-DPR é enviado, o navegador sabe como dimensionar a imagem especificada para a proporção de pixels do dispositivo e o layout. Sem ele, as imagens podem não ser dimensionadas corretamente.

Memória do dispositivo

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

Device-Memory: 2

Um possível caso de uso dessa dica seria reduzir a quantidade de JavaScript enviado para navegadores em dispositivos com memória limitada, já que o JavaScript é o tipo de conteúdo com maior consumo de recursos que os navegadores normalmente carregam. Ou você pode enviar imagens de DPR mais baixa, porque elas usam menos memória para decodificar.

Dicas de rede

A API Network Information fornece outra categoria de dicas do cliente que descrevem o desempenho da conexão de rede do usuário. Na minha opinião, são as dicas mais úteis. Com elas, podemos personalizar experiências para os usuários mudando a forma como entregamos recursos para clientes em conexões lentas.

RTT

A dica RTT fornece o tempo de retorno aproximado, em milissegundos, na camada do aplicativo. A dica RTT, diferente do RTT da camada de transporte, inclui o tempo de processamento do servidor.

RTT: 125

Essa dica é útil devido ao papel da latência no desempenho de carregamento. Com 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, na omissão de algumas solicitações).

Fazer o downlink

A latência é importante no desempenho do carregamento, mas 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

Com RTT, o 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 eficaz. O valor é um em uma lista enumerada de tipos de conexão, cada uma descrevendo uma conexão dentro de intervalos especificados de valores 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 a qual perfil de rede ele 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 é o valor mais próximo 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 com as dicas RTT e Downlink.

Salvar dados

Save-Data não é uma dica para descrever as condições de rede, mas é uma preferência do usuário que determina 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 ela são semelhantes a outras dicas de rede. Os usuários também podem ativá-la em ambientes de alta latência/baixa largura de banda. Essa dica, quando presente, sempre se parece com esta:

Save-Data: on

Aqui no Google, falamos sobre o que você pode fazer com o Save-Data. O impacto disso no desempenho pode ser profundo. É um sinal de que os usuários literalmente pedem que você envie menos coisas! Se você ouvir e agir de acordo com esse indicador, os usuários vão gostar disso.

Como tudo se junta

O que você faz com as dicas do cliente depende de você. Como eles oferecem muitas informações, você tem muitas opções. Para fazer as ideias fluírem, vamos ver o que as dicas dos clientes podem fazer para a Sconnie Timber, uma empresa fictícia de madeira que fica na parte rural do centro-oeste. Como geralmente acontece em áreas remotas, as conexões de rede podem ser frágeis. É aqui que uma tecnologia como dicas de cliente 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 ser complicados. E se você tiver vários tratamentos e variantes das mesmas imagens para diferentes tamanhos de tela e formatos? Essa marcação se torna muito complicada muito rapidamente. É fácil errar e facilmente esquecer ou entender conceitos importantes (como sizes).

Embora <picture> e srcset sejam ferramentas incríveis, elas podem levar muito tempo para serem desenvolvidas e mantidas para casos de uso complexos. É possível automatizar a geração de marcações, mas isso também é difícil porque a funcionalidade que <picture> e srcset fornece é complexa o suficiente para que a automação precise ser feita de uma maneira que mantenha a flexibilidade fornecida.

Dicas de cliente podem simplificar isso. A negociação de respostas de imagem com dicas do cliente pode ser semelhante à seguinte:

1. Se aplicável ao seu fluxo de trabalho, primeiro selecione um tratamento de imagem (ou seja, imagens direcionadas à arte) marcando a dica Viewport-Width.
2. Para selecionar uma resolução de imagem, verifique as dicas Width e DPR e escolha uma fonte que se ajuste ao tamanho do layout e à densidade da tela da imagem (semelhante à forma 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).

Quando estava preocupado com meu cliente fictício de madeira, desenvolvi uma rotina simples de seleção de imagem responsiva em PHP que usa dicas de cliente. Isso significava 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 reduzi-la 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 regravados por mod_rewrite. Ele usa um nome de arquivo de imagem e outros parâmetros para ajudar um script de back-end a escolher a melhor imagem nas condições fornecidas.

Eu sinto que "Mas isso não está apenas implementando <picture> e srcset no back-end?" é a primeira pergunta.

De certa forma, sim, mas com uma diferença importante: quando um aplicativo usa dicas do cliente 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 para você. Assim como nas soluções HTML, é necessário escrever novas marcações para fornecer a todos os casos de uso. Claro, você pode automatizar a geração de marcações. No entanto, se o design ou os requisitos mudarem, há uma boa chance de que você precise revisitar sua estratégia de automação no futuro.

As dicas do cliente 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ê enumera uma lista fixa de possíveis imagens candidatas para o navegador escolher, essa abordagem pode ser mais flexível. Enquanto srcset força você a oferecer aos navegadores um conjunto mais amplo de variantes, por exemplo, 256w, 512w, 768w e 1024w, uma solução com dicas de cliente pode exibir todas as larguras, sem uma enorme pilha de marcações.

É claro que você não precisa criar a lógica de seleção de imagens por conta própria. O Cloudinary usa dicas de cliente para criar respostas de imagem quando você usa o parâmetro w_auto e observou que os usuários médios fizeram o download de 42% menos bytes ao usar navegadores compatíveis com dicas de cliente.

Mas cuidado. As alterações na versão para computador do Chrome 67 removeram o suporte a dicas de cliente de origem cruzada. Felizmente, essas restrições não afetam as versões do Chrome para dispositivos móveis e serão totalmente suspensas em todas as plataformas quando o trabalho na Política de recursos for concluído.

Como ajudar usuários em redes lentas

O desempenho adaptável é a ideia de que podemos ajustar a forma como oferecemos recursos com base nas informações disponibilizadas pelas dicas do cliente, especificamente informações sobre o estado atual da conexão de rede do usuário.

Em relação ao site da Sconnie Timber, tomamos medidas para aliviar a carga quando as redes estão lentas, com os cabeçalhos Save-Data, ECT, RTT e Downlink sendo examinados em nosso código de back-end. Quando isso é feito, geramos um índice de qualidade de rede que pode ser usado para determinar se precisamos intervir para melhorar a experiência do usuário. Essa pontuação de rede está entre 0 e 1, em que 0 é a pior qualidade de rede possível e 1 é a melhor.

Inicialmente, verificamos se Save-Data está presente. Se estiver, a pontuação será definida como 0, já que estamos supondo 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, prosseguiremos e ponderaremos os valores das dicas ECT, RTT e Downlink para calcular uma pontuação que descreva 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 maneira, poderemos melhorar as experiências para quem usa redes lentas.

Quando os sites se adaptam às informações fornecidas pelo cliente, não precisamos adotar uma abordagem de "tudo ou nada". Podemos decidir quais recursos enviar. Podemos modificar nossa lógica de seleção de imagem responsiva para enviar imagens de qualidade mais baixa a uma determinada tela para acelerar o carregamento quando a qualidade da rede for baixa.

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

Agora, uma hierarquia para o mesmo site na mesma conexão lenta, exceto pelo fato de o site usar dicas do cliente para eliminar recursos de página não críticos:

As dicas do cliente 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 nesse cenário não podem ser enfatizados o suficiente e podem ser um grande benefício para os usuários que buscam informações críticas em redes lentas.

Além disso, é possível usar dicas de cliente sem prejudicar a experiência em navegadores que não têm suporte a 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 usar 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 mais alta qualidade descrita pelo cabeçalho ECT. Se inicializarmos $ect como "4g", os navegadores que não oferecem suporte às dicas de cliente não serão afetados. Ativar agora!

Cuidado com os caches!

Sempre que você alterar uma resposta com base em um cabeçalho HTTP, precisará estar ciente de como os caches processarão as buscas futuras desse recurso. O cabeçalho Vary é indispensável aqui porque chave para entradas de cache para o valor dos cabeçalhos de solicitação fornecidos a ele. Simplificando, se você modificar qualquer resposta com base em um determinado cabeçalho de solicitação HTTP, quase sempre precisará incluir esse cabeçalho em Vary da seguinte maneira:

Vary: DPR, Width

No entanto, há uma grande ressalva: nunca faça Vary as 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, convém evitar Vary em cabeçalhos de dicas do cliente, 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 digitar apenas o cabeçalho ECT, o que minimizará as ausências no cache.

Obviamente, 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 isso pode prejudicar a experiência do usuário em visitas repetidas. Nesses casos, você pode modificar essas respostas conforme achar necessário e não se preocupe com Vary.

Dicas de cliente 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ê controla como os recursos são entregues via JavaScript. Isso inclui dicas do cliente. No evento fetch do service worker, é possível usar o método request.headers.get do objeto event para ler os cabeçalhos de solicitação de um recurso da seguinte maneira:

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. Essa não é a única maneira de conseguir algumas dessas informações. Dicas específicas da rede podem ser lidas nestas propriedades JavaScript equivalentes no objeto navigator:

Plug-ins da Imagemin para tipos de arquivo.

Dica para o 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 em que você precisa da verificação de 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 você usaria no servidor, exceto que não precisa de um servidor para negociar conteúdo com dicas do cliente. Somente os service workers têm o poder de tornar as experiências mais rápidas e resilientes devido à capacidade extra de veicular conteúdo quando o usuário está off-line.

Conclusão

Com as dicas do cliente, podemos tornar as experiências dos usuários mais rápidas de uma maneira totalmente progressiva. Podemos exibir mídia com base nos recursos do dispositivo do usuário de uma forma que facilite a veiculação de imagens responsivas do que 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 seja mais eficiente para as telas do usuário do que e o srcset.

Talvez o mais importante seja identificar conexões de rede ruins e preencher a lacuna para os usuários modificando o que enviamos e como fazemos isso. Isso pode ser um longo caminho para facilitar o acesso a sites para usuários em redes frágeis. Com os service workers, podemos criar sites incrivelmente rápidos que estão disponíveis off-line.

Embora as dicas do cliente estejam disponíveis apenas no Chrome e em navegadores baseados no Chromium, é possível usá-las de uma forma que não sobrecarregue navegadores que não têm suporte a elas. Use as dicas do cliente para criar experiências realmente inclusivas e adaptáveis, cientes dos recursos do dispositivo de cada usuário e das redes a que eles se conectam. Esperamos que outros fornecedores de navegador enfrentem o valor delas e mostrem a intenção de implementar.

Recursos

• Imagens responsivas automáticas com dicas do cliente
• Dicas de cliente e imagens responsivas: mudanças no Chrome 67
• Uma dica (cliente)! (Apresentações)
• Como entregar 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 edições valiosos neste artigo.