He revisado vários sites Tainacan (i.e. Acervo - Instituto Ziraldo ) e comprovei que em todos eles, na visualização individual da coleção, embora a coleção mostre o skeleton inicial corretamente, assim que os filtros e o conteúdo carregam, esse skeleton é substituído por outro, e o scroll de toda a página fica bloqueado até que os conteúdos terminem de carregar, sendo disruptivo para a navegacão. Alguém mais está tendo esse problema?
Em um carregamento de página inicial na listagem de itens por exemplo, são sempre três requisições: a pelos metadados da coleção, pelos filtros e por fim pelo itens em si. Nenhuma destas deveria repetir a menos que filtros, ordenação ou paginação sejam aplicados.
O “efeito dos dois skeletons” que você aponta estar sentindo provavelmente vem de um comportamento padrão que temos. Logo que a página é montada, ainda não sabemos quais itens serão carregados. A interface monta então um uma sequência de 12 (ou mais, a depender do atributo items_per_page) caixas cinzas pulsantes de dimensões aleatórias, representando possíveis futuros itens.
Quando a requisição pelo filtros é completa, a barra de filtros aparece, o que causa um pequeno ajuste no layout, movendo as mesmas caixas para baixo, entretanto ainda são as mesmas.
Quando a requisição pelos itens termina, sabemos por fim quais são os itens, e montamos a lista de itens com novos “skeletons coloridos”. Isto é, temos agora caixas que já terão as proporções aproximadas dos itens desejados, porém ainda não temos as imagens. Imagens são em geral a coisa mais pesada em uma consulta dessa. Por isso usamos uma biblioteca (blurhash) para gerar uma versão colorida borrada da futura imagem a ser carregada. Ou seja, este novo skeleton é mais próximo do resultado final, mas de fato não é o mesmo e só pode existir após esta informação dos itens existir.
Por conta desta chegada “parcial” dos dados em etapas, acredito que você pode estar com esta impressão de re-renderização, quando na verdade são informações novas acumuladas mesmo.