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

A performance tem um papel significativo no sucesso de qualquer experiência on-line, porque sites de alta performance engajam e retêm usuários melhor do que sites de baixo desempenho. Concentre-se em otimizar as métricas de performance centradas no usuário.

Por quê?

A velocidade é fundamental para que os usuários usem seu app. Na verdade, à medida que o tempo de carregamento da página aumenta de um segundo para dez segundos, a probabilidade de rejeição de um usuário aumenta em 123%. O desempenho também não para com o evento load. Os usuários nunca devem se perguntar se a interação deles, por exemplo, o clique em um botão, foi registrada ou não. A rolagem e a animação precisam ser suaves. O desempenho afeta toda a experiência, tanto no comportamento do app quanto na percepção dos usuários.

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

Como

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

Os usuários podem usar qualquer navegador para acessar o app da Web antes da instalação.

Por quê?

Os Progressive Web Apps são apps da Web em primeiro lugar, o que significa que eles precisam funcionar em todos os navegadores.

Uma maneira eficaz de fazer isso é, de acordo com Jeremy Keith em Resilient Web Design, identificar os recursos principais, disponibilizá-los usando a tecnologia mais simples possível e, em seguida, aprimorar a experiência sempre que possível. Em muitos casos, isso significa começar com apenas HTML para criar os recursos principais e aprimorar a experiência do usuário com CSS e JavaScript para criar uma experiência mais envolvente.

Por exemplo, o envio de formulários. A maneira mais simples de implementar isso é um formulário HTML que envia uma solicitação POST. Depois de criar isso, você pode melhorar a experiência com JavaScript para fazer a validação do formulário e enviar o formulário pelo AJAX, melhorando a experiência para os usuários que podem oferecer suporte a ele.

Seus usuários interagem com seu site em vários dispositivos e navegadores. Não é possível segmentar apenas o extremo superior desse espectro. Use a detecção de recursos para oferecer uma experiência utilizável para o maior número possível de usuários em potencial, incluindo aqueles que usam navegadores e dispositivos que ainda não existem.

Como

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

Mais informações

• O artigo Understanding Progressive Enhancement do A List Apart é uma boa introdução ao tema.
• Smashing Magazine's Progressive Enhancement: What It Is, And How To Use It? oferece uma introdução prática e links para tópicos mais avançados.
• O artigo Como implementar a detecção de recursos do MDN discute como detectar um recurso fazendo uma consulta direta.

Os usuários podem usar sua PWA em qualquer tamanho de tela, e todo o conteúdo dela está disponível em qualquer tamanho de viewport.

Por quê?

Os dispositivos têm vários tamanhos, e os usuários podem usar seu app em vários tamanhos, mesmo no mesmo dispositivo. Portanto, é fundamental garantir que o conteúdo se ajuste à janela de visualização e que todos os recursos e o conteúdo do site sejam utilizáveis 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. Você pode reorganizar o conteúdo para diferentes tamanhos de janela de visualização, e tudo deve estar lá, de uma forma ou outra. Na verdade, como Luke Wroblewski afirma em seu livro Mobile First, começar pequeno e ajustar o design para telas maiores pode melhorar o design de um site:

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

Como

Há muitos recursos sobre 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 esta discussão aos aspectos de conteúdo do design responsivo, consulte design com foco no conteúdo e layouts responsivos de conteúdo externo. Por fim, embora o foco seja em dispositivos móveis, as lições em Seven Deadly Mobile Myths (em inglês) de Josh Clark são tão relevantes para visualizações de tamanho pequeno de sites responsivos quanto para dispositivos móveis de modo geral.

Quando os usuários estão off-line, manter eles no PWA oferece uma experiência mais simples do que voltar à página off-line do navegador padrão.

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 uma PWA nunca deve 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 ele tenta usar um recurso que exige uma conexão, ajuda a experiência da Web a parecer parte do dispositivo em que está sendo executado.

Como

Durante o evento install de um worker de serviço, é possível pré-cachear uma página off-line personalizada para mostrar quando um usuário ficar off-line. Confira Criar uma página de substituição off-line para saber como implementar. O Chrome vai mostrar uma página off-line básica se nenhuma for fornecida.

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

Por quê?

A instalação de um app da Web progressivo 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 outros apps. Ele é executado na própria janela do app, separada do navegador, e aparece na lista de tarefas, assim como outros apps.

Assim como nos apps específicos para dispositivos, os usuários que instalam seus apps são o público mais engajado e, muitas vezes, têm métricas de engajamento equivalentes às dos usuários em dispositivos móveis. Essas métricas incluem mais visitas repetidas, mais tempo no seu site e taxas de conversão mais altas do que os visitantes típicos.

Como

Siga nosso guia de instalação para saber como tornar seu PWA instalável.

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

Por quê?

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

Como

Depois de determinar quais recursos os usuários esperam que funcionem off-line, você precisa disponibilizar e adaptar seu conteúdo a contextos off-line. Você pode usar o IndexedDB, um sistema de armazenamento NoSQL no navegador, para armazenar e recuperar dados e sincronização em segundo plano para permitir que os usuários realizem ações off-line e adiem as comunicações do servidor até que o usuário tenha uma conexão estável novamente. Também é possível usar workers de serviço para armazenar outros tipos de conteúdo, como imagens, arquivos de vídeo e áudio, para uso off-line e implementar sessões seguras e de longa duração para manter os usuários autenticados. Do ponto de vista da experiência do usuário, é possível usar telas de esqueleto que dão aos usuários uma percepção de velocidade e conteúdo durante o carregamento, que podem ser substituídos por conteúdo armazenado em cache ou um indicador off-line, conforme necessário.

Todas as interações do usuário atendem aos requisitos de acessibilidade WCAG 2.0.

Por quê?

A maioria dos usuários, em algum momento, quer usar seu PWA de uma forma coberta pelos requisitos de acessibilidade do WCAG 2.0. A capacidade das pessoas de interagir e entender sua PWA existe em um espectro, e as necessidades podem ser temporárias ou permanentes. Ao tornar o PWA acessível, você o torna utilizável por 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 Accessibility Insights podem ajudar a automatizar alguns testes de acessibilidade. Também é importante usar elementos semanticamente corretos em vez de recriar esses elementos por conta própria, por exemplo, elementos a e button. Isso garante que, quando você precisar criar recursos mais avançados, as expectativas de acessibilidade sejam atendidas, como quando usar setas em vez de guias. O A11Y Nutrition Cards tem excelentes conselhos sobre isso para alguns componentes comuns.

Seu PWA pode ser detectado facilmente pela pesquisa.

Por quê?

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

Como

Comece verificando se cada URL tem um título descritivo e uma metadescrição exclusivos. Em seguida, use o Google Search Console e as auditorias de Otimização para mecanismos de pesquisa no Lighthouse para depurar e corrigir problemas de visibilidade com sua PWA. Você também pode usar as ferramentas de proprietário do site do Bing ou do Yandex e considerar incluir dados estruturados usando esquemas do Schema.org no seu PWA.

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

Por quê?

Os dispositivos oferecem vários métodos de entrada, e os usuários precisam poder alternar entre eles sem problemas ao usar seu aplicativo. Da mesma forma, os métodos de entrada não podem depender do tamanho da tela, ou seja, as viewports grandes precisam oferecer suporte ao toque, e as pequenas precisam oferecer suporte a teclados e mouses. Faça o possível para garantir que o aplicativo e todos os recursos dele ofereçam suporte ao uso de qualquer método de entrada que o usuário possa escolher. Quando apropriado, melhore as experiências para permitir controles específicos de entrada (como a puxar para atualizar).

Como

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

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

Por quê?

As APIs que acionam uma solicitação de permissão, como notificações, geolocalização e credenciais, são projetadas intencionalmente para interromper o usuário porque tendem a estar relacionadas a recursos avançados que exigem a ativação. Acionar essas solicitações sem contexto adicional, como no carregamento da página, faz com que os usuários tenham menos probabilidade de aceitar essas permissões e mais probabilidade de desconfiar delas no futuro. Em vez disso, acione essas solicitações somente depois de fornecer um motivo para o usuário entender por que você precisa dessa permissão.

Como

O artigo UX de permissões e o artigo do UX Planet As maneiras certas de pedir permissões aos usuários são bons recursos para entender como projetar solicitações de permissões que, embora se concentrem em dispositivos móveis, se aplicam a todos os PWAs.

Manter a base de código saudável facilita o cumprimento das metas e a entrega de novos recursos.

Por quê?

Há muitos fatores envolvidos na criação de um aplicativo da Web moderno. Manter seu aplicativo atualizado e a base de código saudável facilita a entrega de novos recursos que atendam à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:

• Evite usar bibliotecas com vulnerabilidades conhecidas.
• Verifique se você não está usando APIs descontinuadas.
• Remova práticas de programação inseguras da sua base de código, como o uso de document.write() ou a presença de listeners de eventos de rolagem não passivos.
• Você pode até mesmo programar defensivamente para garantir que o PWA não falhe se a análise ou outras bibliotecas de terceiros não forem carregadas.
• Considere exigir a análise estática do código, como linting, e 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.