Carregamento e skeleton: informe a espera com honestidade

Uma animação em movimento mostra atividade, mas não explica necessariamente se uma operação está avançando. Estados de carregamento precisam responder a perguntas diferentes: o que está sendo preparado, se existe uma estimativa confiável e o que fazer quando a espera ultrapassa o esperado. A escolha visual deve acompanhar essas respostas.

Escolha o indicador pelo tipo de operação

O skeleton sugere a estrutura do conteúdo que chegará, como linhas de uma lista ou espaços de cartões. Ele ajuda quando essa estrutura é relativamente previsível. Um indicador localizado pode servir melhor a uma atualização curta dentro de um componente. Uma barra de progresso faz sentido quando o sistema consegue representar uma parcela real do trabalho.

Evite percentuais fabricados para tranquilizar. Se uma barra chega rapidamente perto do fim e fica parada sem explicação, o número perde credibilidade. Em operações com etapas de duração incerta, mostrar a etapa atual pode comunicar melhor do que uma estimativa que a implementação não consegue sustentar.

Reserve espaço sem fingir que o dado já existe

Em um catálogo hipotético de equipamentos, os cartões têm imagem, nome e condição de disponibilidade. O skeleton pode reservar essa disposição enquanto a consulta acontece. A dimensão deve aproximar a estrutura final para reduzir deslocamentos, sem apresentar valores fictícios como se já fossem resultados.

Cuide de imagens e conteúdo tardio

A orientação do web.dev sobre estabilidade de layout destaca a reserva de espaço para conteúdo que chega depois. Considere imagens, banners e fontes além da lista principal. Corrigir apenas o skeleton não elimina saltos provocados por um aviso inserido acima do título quando a página já está em uso.

Mantenha o que continua útil durante atualizações

Ao alterar um filtro, apagar todo o painel e substituir tudo por blocos cinzentos pode remover referências necessárias à comparação. Avalie manter o resultado anterior com uma indicação clara de atualização. A decisão depende do risco de confundir dados antigos com atuais e da possibilidade de interagir com informações em transição.

Se um botão inicia uma operação, preserve sua posição e deixe explícito que o acionamento foi recebido. Bloqueie repetições quando elas puderem causar duplicidade, com comportamento consistente. Um botão que muda de largura durante o carregamento pode deslocar outros controles e tornar a confirmação visual mais difícil.

Planeje espera prolongada, falha e interrupção

Defina com a equipe quais sinais indicam atraso e quais confirmam erro. Um carregamento infinito esconde a diferença entre serviço lento e requisição encerrada. Quando houver falha, substitua o indicador por uma explicação e uma ação pertinente. Se a pessoa puder cancelar, informe o que será interrompido e se parte do trabalho permanecerá.

Em tarefas que continuam em segundo plano, permita sair sem sugerir perda quando isso for verdadeiro. Para um relatório extenso, uma área de trabalhos em andamento pode ser mais adequada que prender toda a interface. Essa solução depende de suporte real da aplicação, incluindo consulta posterior do resultado.

Verifique a espera para diferentes formas de acesso

Não dependa do brilho pulsante para informar o estado. A descrição da MDN para aria-busy apresenta uma propriedade que indica atualização em andamento de uma região, mas sua aplicação exige cuidado com os anúncios e com o término do estado. Uma marcação esquecida pode deixar a informação incoerente.

Teste conexão lenta, falha de rede e preferência por movimento reduzido. Confira se o indicador termina, se a pessoa percebe a chegada do conteúdo e se consegue continuar a tarefa. Comece documentando um carregamento completo, do acionamento ao sucesso ou erro, antes de padronizar a mesma animação por todo o produto.