[TabNews] Otimizações e mais melhorias 🎉

E aí Turma, tudo certo? Após a última publicação de melhorias nós realizamos mais algumas otimizações que devem passar despercebidas para a maioria dos usuários, mas são cruciais para a saúde do sistema.

A página de login recebe a informação de qual era a página que o usuário estava antes de navegar para o login, pois assim ele pode ser enviado de volta para a mesma página após fornecer suas credenciais.

Acontece que nem sempre é interessante voltar para a página anterior, por exemplo, quando a página era relacionada com o processo de cadastro de uma nova conta, poderia ocorrer o que foi relatado pelo @Henrique-Gomes na issue #1386 💪, onde ele foi levado de volta para a página que pedia para verificar o email.

Um bug relacionado ocorria se o usuário já estando na página de login clicasse no link para a página de login, o que acrescentava um redirecionamento desnecessário para a mesma página.

Então agora o redirecionamento não vai mais ocorrer para as páginas relacionadas com login ou cadastro, e nesses casos o usuário será levado para a página inicial do TabNews.

A implementação foi realizada por mim, e os detalhes estão no PR #1387.

Para ocorrer o redirecionamento relatado na melhoria anterior, a página de login recebe como parâmetro o caminho da página que o usuário estava acessando antes de navegar para a página de login.

Exemplo quando o usuário estava na página inicial antes de ir para o login:

https://www.tabnews.com.br/login?redirect=/

Só que o Google entende que diferentes parâmetros na URL podem levar a diferentes páginas, e ao mesmo tempo existe um prejuízo no ranqueamento de sites que possuem diferentes páginas com conteúdos repetidos. Com isso o Google estava identificando diferentes URLs que levavam para página de login como se fossem diferentes páginas com conteúdos repetidos.

Para ajudar o Google a entender que, independentemente dos parâmetros, todas as URLs para a página de login levam para a mesma página (e não para páginas duplicadas), agora estamos fornecendo a URL canônica:

Essa implementação foi realizada por mim, e os detalhes estão no PR #1379.

LCP – Largest Content Paint

Uma métrica que também impacta na relevância que o Google dá para o TabNews é a LCP. E recentemente o Google começou a reclamar do nosso resultado para esse indicador em dispositivos móveis.

Basicamente é medido o tempo que leva para o principal conteúdo da página ser carregado. Onde até 2,5s é considerado bom, até 4s precisa de melhoria e acima disso está ruim.

Efetuando essa medida em diferentes páginas podemos ver resultados muito diferentes de acordo com o conteúdo em si, mas em geral o resultado realmente estava ruim para a maioria das páginas.

O mais estranho é que o Google começou a reclamar logo após a mudança da estratégia de cache, mas revertendo o código para antes dessa implementação não existe nenhuma diferença significante no resultado dos testes. Apenas quando o código era revertido para antes da implementação do modo escuro é que o teste apresentava um resultado bom.

Então no PR #1394 foi realizada uma otimização na implementação do modo escuro que levou o LCP em dispositivos móveis de 5,1s para 1,2s, voltando ao nível considerado bom. 🎉

Cache do saldo de TabCoins

Junto com a mudança do funcionamento do cache das páginas (e da API) foram introduzidos bugs no valor mostrado como saldo de TabCoins dos conteúdos.

Como já era esperado que o cache produzisse algumas inconsistências eventuais (e temporárias somente enquanto ocorria a revalidação em segundo plano), os bugs primeiramente foram assumidos como um efeito colateral do cache, mas foi somente a observação mais detalhada do @maniero, que nos relatou na issue #1383 💪, que deixou claro que não era apenas um comportamento de cache, mas que existiam bugs que poderiam ser solucionados.

O primeiro bug ocorria se o usuário qualificasse o conteúdo enquanto a revalidação estava ocorrendo, situação em que o dado revalidado poderia vir sem essa última qualificação, fazendo o saldo mostrado ficar correto no momento da qualificação, mas logo em seguida mudar para o valor anterior.

Um outro bug ocorria quando a navegação ocorria diretamente entre dois conteúdos sem passar pela lista de conteúdos, por exemplo ao clicar na data de publicação de um comentário. Nesses casos o saldo mostrado permanecia o do conteúdo anterior até ocorrer a revalidação em segundo plano.

A correção desses bugs (e a introdução também 😅) foi realizada por mim, e os detalhes estão nos PRs #1385 e #1389.

Conteúdos recentes nos relevantes

Uma pequena parte dos conteúdos que aparecem na página de relevantes é reservada para os últimos conteúdos postados, mesmo os que ainda não receberam nenhuma qualificação.

Acha isso estranho? Expanda aqui para entender...

Essa medida é necessária por enquanto, pois o tamanho atual do TabNews (usuários vs conteúdos) ainda não nos dá a relevância estatística necessária para usar algoritmos mais sofisticados para classificar esses conteúdos recém postados.

Então qualquer algoritmo que podemos utilizar precisa usar a idade do conteúdo, e isso faz com que os mais novos vão para a lista de relevantes.

Uma sugestão comum é colocar um limiar mínimo de qualificações positivas para os conteúdos irem para os relevantes, mas isso piora a questão estatística, pois seria menor o número de usuários que poderiam definir se um conteúdo está apto ou não a ser considerado relevante, já que essa decisão ficaria restrita aos que usam a aba de recentes, ou seja, teremos dados mais enviesados do que o atual.

Temos muito a melhorar na classificação de conteúdos, mas precisamos lidar com os vieses, então esse é um campo em que ainda precisamos de muita ajuda da Turma que tem boa base em estatística. 💪

Mas isso permitia que um único usuário monopolizasse essa faixa ao criar uma sequência de publicações em um curto período. Então agora essa faixa só permite um único conteúdo por usuário.

Esse filtro na consulta do ranqueamento foi adicionado por mim, e os detalhes estão no PR #1390.

Autenticação dos usuários

Fizemos algumas otimizações na autenticação dos usuários:

Cálculo de saldos de TabCoins e TabCash

Antes os saldos eram calculados sempre que buscávamos dados dos usuários no banco de dados, ou seja, sempre que o usuário era autenticado os saldos eram calculados sem nenhuma necessidade.

Agora os saldos só são calculados quando essa informação for necessária, como nos endpoints /user e /users.

Essa implementação foi realizada pelo @filipedeschamps no curso, e eu apenas fiz os ajustes para trazer o commit dele para o TabNews no PR #1396.

Renovar a sessão do usuário apenas no `/user`

Antes a sessão do usuário era renovada toda vez que a autenticação era necessária. Então o @filipedeschamps iniciou a modificação para que a renovação ocorresse apenas no endpoint /user. Isso foi feito no repositório do curso (que ainda está privado), mas eu complementei a modificação trazendo o PR #1395 no TabNews com os acréscimos relatados abaixo.

Mais otimizações na sessão

Agora a sessão só é renovada quando faltar menos de 3 semanas para o token expirar.
O método GET do endpoint /sessions foi extinto.
Foram adicionados alguns testes que faltavam sobre a expiração e renovação do token de sessão.

Conclusão

Estamos quase concluindo as etapas mais difíceis da milestone atual e logo chegaremos na milestone mais aguardada, onde será implementada alguma(s) maneira(s) da Turma que está criando os conteúdos mais massa aqui no TabNews poder usar seus TabCash. 🚀🚀🚀

Redirecionamento após login

URL canônica na página de login