Quais são as características de um bom Progressive Web App?

Pete LePage
Sam Richard

Os Progressive Web Apps (PWA) são criados e aprimorados com APIs modernas, para oferecer recursos, confiabilidade e capacidade de instalação aprimorados, além de alcançar qualquer pessoa, em qualquer lugar, em qualquer dispositivo com uma única base de código. Para ajudar você a criar a melhor experiência possível, use as listas de verificação e as recomendações principais e ideais.

Lista de verificação principal do App Web Progressivo

A lista de verificação de Progressive Web App descreve o que torna um app instalável e utilizável para todos os usuários, independentemente do tamanho ou do tipo de entrada.

Começa rápido, continua rápido

A performance desempenha um papel significativo no sucesso de qualquer experiência on-line, porque os sites com alto desempenho engajam e retêm melhor os usuários do que os de baixo desempenho. Os sites devem se concentrar na otimização de métricas de desempenho centradas no usuário.

Por quê?

A velocidade é fundamental para que os usuários usem seu app. Na verdade, como os tempos de carregamento da página vão de um a dez segundos, a probabilidade de um usuário sair do app aumenta em 123%. A performance não para com o evento load. Os usuários nunca devem se perguntar se a interação, por exemplo, clicar em um botão, foi registrada ou não. A rolagem e a animação devem ser suaves. O desempenho afeta toda a experiência, desde a forma como os usuários percebem o aplicativo até o desempenho real dele.

Embora todos os aplicativos tenham necessidades diferentes, as auditorias de desempenho no Lighthouse são baseadas nas Core Web Vitals. Uma pontuação alta nessas auditorias aumenta as chances de os usuários terem uma experiência agradável. Também é possível usar o PageSpeed Insights ou o Chrome User Experience Report para ver dados reais do desempenho do seu app da Web.

Como?

Siga nosso guia sobre tempos de carregamento rápidos para saber como fazer com que o PWA seja iniciado e permaneça rápido.

Funciona em qualquer navegador

Os usuários podem usar qualquer navegador para acessar seu app da Web antes que ele seja instalado.

Por quê?

Progressive Web Apps são apps da Web primeiro, o que significa que eles precisam funcionar em vários navegadores, não apenas em um deles.

Uma maneira eficaz de fazer isso é, nas palavras de Jeremy Keith no Resilient Web Design, identificando a funcionalidade principal, disponibilizando essa funcionalidade usando a tecnologia mais simples possível. Em muitos casos, isso significa começar apenas com HTML para criar a funcionalidade principal e melhorar a experiência do usuário com CSS e JavaScript para criar uma experiência mais envolvente.

Por exemplo, considere o envio de formulários. A maneira mais simples de implementar isso é usando um formulário HTML que envia uma solicitação POST. Depois disso, é possível aprimorar a experiência com JavaScript para validar o formulário e enviar o formulário usando AJAX, melhorando a experiência dos usuários compatíveis.

Considere que os usuários vão interagir com seu site em diversos dispositivos e navegadores. Não é possível segmentar o nível máximo do espectro. Ao usar a detecção de recursos, você poderá oferecer uma experiência utilizável para a maior variedade de usuários em potencial, incluindo aqueles que usam navegadores e dispositivos que podem não existir hoje.

Como?

O Resilient Web Design (link em inglês) de Jeremy Keith é um excelente recurso que descreve como pensar sobre o Web design nessa metodologia progressiva e para vários navegadores.

Mais informações

Responsivo para qualquer tamanho de tela

Os usuários podem usar o PWA em qualquer tamanho de tela, e todo o conteúdo está disponível em qualquer tamanho de janela de visualização.

Por quê?

Existem dispositivos de vários tamanhos, e os usuários podem usar seu aplicativo em vários tamanhos, até mesmo no mesmo dispositivo. Portanto, é fundamental garantir que o conteúdo não se encaixe apenas na janela de visualização, mas que todos os recursos e conteúdos do seu site possam ser usados em todos os tamanhos de janela de visualização.

As tarefas que os usuários querem concluir e o conteúdo que eles querem acessar não mudam com o tamanho da janela de visualização. O conteúdo pode ser reorganizado em diferentes tamanhos de janela de visualização e precisa estar lá, de um jeito ou de outro. Na verdade, como Luke Wroblewski afirma em seu livro Mobile First, começar pequeno e ir grande em vez de o contrário pode realmente melhorar o design de um site:

Os dispositivos móveis exigem que as equipes de desenvolvimento de software se concentrem apenas nos dados e nas ações mais importantes de um aplicativo. Não há espaço em uma tela de 320 x 480 pixels para elementos irrelevantes e desnecessários. Você precisa priorizar.

Como?

Existem muitos recursos sobre o design responsivo, incluindo o artigo original de Ethan Marcotte, uma coleção de conceitos importantes relacionados a ele, além de muitos livros e palestras. Para restringir essa discussão aos aspectos de conteúdo do design responsivo, você pode se aprofundar no design que prioriza o conteúdo e nos layouts responsivos de saída de conteúdo. Por fim, embora se concentrem em dispositivos móveis, as lições em Seven Deadly Mobile Myths, de Josh Clark, são tão relevantes para visualizações pequenas de sites responsivos quanto para dispositivos móveis.

Fornece uma página off-line personalizada

Quando os usuários estão off-line, mantê-los no PWA proporciona uma experiência mais integrada do que voltar à página off-line padrão do navegador.

Por quê?

Os usuários esperam que os apps instalados funcionem independentemente do status da conexão. Um app específico da plataforma nunca mostra uma página em branco quando está off-line, e um Progressive Web App nunca pode mostrar a página off-line padrão do navegador. Oferecer uma experiência off-line personalizada, tanto quando um usuário navega para um URL que não foi armazenado em cache quanto quando um usuário tenta usar um recurso que requer uma conexão, ajuda sua experiência da Web a parecer parte do dispositivo em que está sendo executada.

Como?

Durante o evento install de um service worker, é possível pré-armazenar em cache uma página off-line personalizada para uso posterior. Se um usuário ficar off-line, você poderá responder com a página off-line personalizada armazenada em cache. Siga nosso exemplo personalizado de página off-line para conferir um exemplo disso em ação e aprender a implementá-lo por conta própria.

Pode ser instalado

Os usuários que instalam ou adicionam apps ao dispositivo tendem a se interagir mais com eles.

Por quê?

A instalação de um Progressive Web App permite que ele tenha a aparência e o comportamento de todos os outros apps instalados. Ele é iniciado no mesmo lugar em que os usuários iniciam os outros apps. Ele é executado na própria janela do app, separada do navegador, e aparece na lista de tarefas, assim como outros apps.

Por que você gostaria que um usuário instalasse seu PWA? Esse é o mesmo motivo pelo qual você gostaria que um usuário instalasse seu app de uma app store. Os usuários que instalam seus apps são seu público-alvo mais engajado e têm métricas de engajamento melhores do que os visitantes comuns, geralmente em paridade com os usuários do app em dispositivos móveis. Essas métricas incluem mais visitas repetidas, tempos mais longos no seu site e taxas de conversão mais altas.

Como?

Siga nosso guia de instalação para saber como tornar seu PWA instalável, como testar se ele pode ser instalado e tente fazer isso por conta própria.

Lista de verificação ideal para Progressive Web App

Para criar um App Web Progressivo verdadeiramente incrível, que pareça o melhor app da categoria, você precisa de mais do que apenas a lista de verificação principal. A lista de verificação ideal para Progressive Web App consiste em fazer com que o PWA pareça parte do dispositivo em que está sendo executado, aproveitando o que torna a Web eficaz.

Proporciona uma experiência off-line

Quando a conectividade não é estritamente necessária, o app funciona off-line da mesma forma que on-line.

Por quê?

Além de oferecer uma página off-line personalizada, os usuários esperam que os Progressive Web Apps possam ser usados off-line. Por exemplo, apps de viagens e voos precisam ter detalhes da viagem e cartões de embarque disponíveis off-line. Apps de música, vídeo e podcast precisam permitir a reprodução off-line. Os apps sociais e de notícias precisam armazenar em cache o conteúdo recente para que os usuários possam lê-lo off-line. Os usuários também esperam permanecer autenticados quando off-line, então, projete para autenticação off-line. Um PWA off-line oferece uma verdadeira experiência semelhante a um app para os usuários.

Como?

Depois de determinar quais recursos os usuários esperam que funcionem off-line, será necessário disponibilizar seu conteúdo e adaptá-lo aos contextos off-line. Além disso, é possível usar o IndexedDB, um sistema de armazenamento NoSQL no navegador, para armazenar e recuperar dados, e a sincronização em segundo plano para permitir que os usuários realizem ações off-line e adiar as comunicações do servidor até que o usuário tenha uma conexão estável novamente. Você também pode usar service workers para armazenar outros tipos de conteúdo, como imagens, arquivos de vídeo e arquivos de áudio para uso off-line. Da perspectiva da experiência do usuário, é possível usar telas esqueleto que dão aos usuários uma percepção de velocidade e conteúdo durante o carregamento, que podem recorrer ao conteúdo armazenado em cache ou a um indicador off-line, conforme necessário.

É totalmente acessível.

Todas as interações do usuário atendem aos requisitos de acessibilidade das WCAG 2.0 (link em inglês).

Por quê?

A maioria das pessoas em algum momento da vida vai querer aproveitar seu PWA de uma forma que seja coberta pelos requisitos de acessibilidade WCAG 2.0. A capacidade dos humanos de interagir e entender seu PWA existe em todo o espectro e as necessidades podem ser temporárias ou permanentes. Ao tornar o PWA acessível, você garante que ele possa ser usado para todos.

Como?

A Introdução à acessibilidade na Web do W3C é um bom ponto de partida. A maioria dos testes de acessibilidade precisa ser feita manualmente. Ferramentas como as auditorias de Acessibilidade no Lighthouse, axe e Insights de acessibilidade podem ajudar você a automatizar alguns testes de acessibilidade. Também é importante usar elementos semanticamente corretos em vez de recriá-los por conta própria, como, por exemplo, elementos a e button. Isso garante que, quando você precisar criar funcionalidades mais avançadas, as expectativas de acessibilidade sejam atendidas (como quando usar setas ou guias). Os cartões de nutrição A11Y têm excelentes conselhos sobre isso para alguns componentes comuns.

Seu PWA pode ser encontrado na pesquisa.

Por quê?

Uma das maiores vantagens da Web é a capacidade de descobrir sites e apps pela pesquisa. Na verdade, mais da metade de todo o tráfego do site vem da pesquisa orgânica. Garantir que os URLs canônicos existam para o conteúdo e que os mecanismos de pesquisa possam indexar seu site é fundamental para que os usuários possam encontrar seu PWA. Isso é especialmente verdadeiro ao adotar a renderização do lado do cliente.

Como?

Comece garantindo que cada URL tenha um título descritivo e uma meta descrição exclusivos. Em seguida, use o Google Search Console e as auditorias de otimização de mecanismos de pesquisa no Lighthouse para depurar e corrigir problemas de descoberta com seu PWA. Também é possível usar as ferramentas para webmasters do Bing ou da Yandex e considerar incluir dados estruturados usando esquemas do Schema.org no seu PWA.

Funciona com qualquer tipo de entrada

O PWA também pode ser usado com mouse, teclado, stylus ou toque.

Por quê?

Os dispositivos oferecem uma variedade de métodos de entrada, e os usuários podem alternar facilmente entre eles ao usar o aplicativo. Tão importante quanto isso, os métodos de entrada não podem depender do tamanho da tela, o que significa que janelas de visualização grandes precisam oferecer suporte a toque e janelas pequenas precisam oferecer suporte a teclados e mouses. Verifique se o aplicativo e todos os recursos dele oferecem suporte ao uso de qualquer método de entrada que o usuário possa usar. Quando apropriado, aprimore as experiências para permitir controles específicos de entrada também (como deslizar para baixo para atualizar).

Como?

A API Pointer Events fornece uma interface unificada para trabalhar com várias opções de entrada e é especialmente boa para adicionar suporte à stylus. Para oferecer suporte a toque e teclado, confira se você está usando os elementos semânticos corretos (fixos, botões, controles de formulário etc.) e não os recrie com HTML não semântico, o que é bom para acessibilidade. Ao incluir interações que são ativadas ao passar o cursor, verifique se elas também podem ser ativadas ao clicar ou tocar.

Fornece contexto para solicitações de permissão

Ao pedir permissão para usar APIs avançadas, forneça contexto e pergunte apenas quando a API é necessária.

Por quê?

As APIs que acionam uma solicitação de permissão, como notificações, geolocalização e credenciais, são intencionalmente projetadas para serem prejudiciais ao usuário, porque tendem a estar relacionadas a funcionalidades poderosas que exigem ativação. Acionar essas solicitações sem mais contexto, como no carregamento de página, diminui a probabilidade de os usuários aceitarem essas permissões e aumenta a probabilidade de desconfiar que elas deve ter no futuro. Em vez disso, só acione essas solicitações depois de fornecer uma justificativa contextualizada ao usuário para saber por que você precisa dessa permissão.

Como?

O artigo Permissão UX e o artigo The Right Ways to Ask Users for Permissions (em inglês) da UX Planet são bons recursos para entender como criar solicitações de permissão que, embora focadas em dispositivos móveis, se aplicam a todos os PWAs.

Segue as práticas recomendadas para um código íntegro

Manter sua base de código íntegra facilita o cumprimento das metas e a entrega de novos recursos.

Por quê?

Criar um aplicativo da Web moderno envolve muitos fatores. Manter o aplicativo atualizado e a base de código íntegra facilita o envio de novos recursos que atendem às outras metas estabelecidas nesta lista de verificação.

Como?

Há várias verificações de alta prioridade para garantir uma base de código saudável: evitar o uso de bibliotecas com vulnerabilidades conhecidas, garantir que você não esteja usando APIs descontinuadas, remover antipadrões da Web da base de código (como usar document.write() ou listeners de eventos de rolagem não passivas) e até mesmo programar de maneira defensiva para garantir que o PWA não falhe se a análise ou outras bibliotecas de terceiros falharem ao carregar. Considere exigir análise de código estático, como inspeção, bem como testes automatizados, em vários navegadores e canais de lançamento. Essas técnicas podem ajudar a detectar erros antes que eles cheguem à produção.