Prepare um site para conexões lentas e interrompidas

Tempo estimado de leitura: 3 min. · Publicado em 1º de outubro de 2026

Defina um escopo útil

Classifique tarefas como ler informações estáveis, preparar um rascunho, verificar a disponibilidade ou pagar. Estes últimos dependem de dados e confirmações que não devem ser assumidos atualmente offline. Explique as ações indisponíveis de maneira útil.

Um site simples pode permanecer útil por meio de páginas leves e links confiáveis sem adicionar um aplicativo offline. Avalie primeiro as interrupções reais e o conteúdo essencial. Mecanismos adicionais precisam de proprietários e testes em vez de nomes meramente técnicos.

Descreva os estados sem ambiguidade

Separe o rascunho local, aguardando transmissão, recebimento do servidor e processamento concluído. Escreva uma mensagem e uma ação de recuperação para cada um. Um ícone de conexão ou um botão desabilitado sozinho não explica o que aconteceu com a solicitação.

MDN documenta os trabalhadores do serviço e a operação offline ou em segundo plano. Avalie a disponibilidade e o ciclo de vida nos navegadores de destino do projeto. Os navegadores podem interromper o trabalho, portanto, a jornada deve permanecer compreensível sem depender da execução contínua.

Teste a interrupção em um momento inconveniente

Em um ambiente de teste, desconecte-se antes de enviar, durante a transferência e após o recebimento do servidor. Restaure a rede e recarregue. Verifique o que é retido, perdido, repetido ou mostrado como completo. O caso difícil geralmente é a incerteza sobre uma solicitação já recebida.

Use uma nova sessão e outro dispositivo se a continuidade de um dispositivo cruzado for prometida. Peça a alguém que não esteja familiarizado com a arquitetura para testar as mensagens. Eles devem entender a ação restante e como evitar fazer uma segunda ordem.

Verifique a frescura e a privacidade

Para informações retidas, data de exibição e uso permitido. A disponibilidade antiga pode orientar um visitante sem autorizar uma reserva. Defina o que resta no dispositivo após o logout e quem analisa os riscos do dispositivo compartilhado.

Após uma nova versão, verifique a substituição de recursos e a compatibilidade de dados locais. Forneça uma maneira de recuperar rascunhos permitidos ou restaurar a operação simples. Entregue estados, testes de interrupção, regras de retenção e limitações de modo degradado.

Documentação principal: MDN — Operação offline e em segundo plano.

Documentos de referência

MDN — Operação offline e em segundo plano

Conteúdo atualizado em 1º de outubro de 2026

Registe as verificações e os resultados no registo de testes web

Matriz de validação funcional para se adaptar ao projeto

Esses controles propostos usam casos fictícios. Decida qual comportamento é esperado com a equipe, anote o resultado e atribua discrepâncias não resolvidas antes da publicação.

Casos de teste, resultados esperados e evidências úteis
Caso	Resultado esperado	Prova para guardar
Primeira visita sem rede	Um estado claro aparece mesmo quando nenhuma versão anterior foi armazenada.	Tela obtida em um navegador sem dados ou caches anteriores do site.
Página visitada anteriormente offline	Os visitantes entendem a data e os limites do conteúdo retido.	Versão exibida e informações de frescura visíveis ao lado das informações armazenadas em cache.
formulário interrompido	Um rascunho local nunca é apresentado como uma submissão recebida.	Exibido redação, armazenamento local e ausência confirmada de recibo do servidor.
Sessão mais antiga após o lançamento	Os dados e recursos permanecem compatíveis ou oferecem uma reinicialização clara.	Versões de cache e interface observadas na mesma sessão existente do navegador.

Perguntas frequentes

A operação offline significa que um pedido é aceito?

Não. Um rascunho ou solicitação pendente deve ser distinto da confirmação do servidor. Mostre o estado real e forneça a recuperação que evita operações repetidas.

Todo site precisa de um trabalhador de serviço?

Não. Comece com usos, peso da página e interrupções observadas. A operação offline específica é justificada quando suporta uma jornada útil que a equipe pode manter e testar.