Levei muito tempo otimizando meu CSS, removendo plugins, removendo redirecionamentos e fazendo tudo o que pude para melhorar os tempos de carregamento, mas aparentemente os principais culpados são:
mobile_4-randomcharacters-.css, que contém o normalize.css e o Pikaday e carrega em 1,5 segundos no mobile
e /assets/ember_jquery-randomcharacter-.js, que carrega em 3,6 segundos no mobile
Não faço ideia do que fazer com esses arquivos, que apresentam os maiores tempos de carregamento.
O carregamento no desktop é mais rápido, mas ainda não é bom.
O servidor tem 1 CPU, 2 GB de RAM, 50 GB de SSD e 2 TB de banda em um servidor profissional baseado nos EUA.
São 2 workers do Unicorn; nem a CPU nem a RAM estão sob carga pesada, e não tenho muitos usuários ou plugins.
Alguma ideia? Obrigado.
Obrigado. https://developers.google.com/speed/pagespeed/insights/ indica que o tempo de CPU (não o tempo de entrega) especificamente para o segundo recurso foi de quase 4 segundos. Um CDN como o Fastly ainda ajudaria nisso? Atualmente, uso o Cloudflare com cache. Devo fazer algum ajuste no Cloudflare ou apenas adicionar algo como o Fastly em cima dele?!
Isso é de fato um grande ativo que levará tempo para ser analisado e avaliado. Como o Discourse é uma “Aplicação de Página Única”, esse custo é pago integralmente no momento em que o usuário chega pela primeira vez, e essa é uma compensação da nossa abordagem, que se concentra em tornar todas as interações subsequentes, típicas do uso de fóruns, leves.
Existem planos para o EmberJS remover a dependência obrigatória do JQuery, o que reduzirá consideravelmente esse payload, mas ainda levaremos anos para fazer essa transição no Discourse.
Bem, os padrões do PageSpeed forçam um Nexus 5X e uma conexão 3G, o que, mesmo para o Brasil (um país em desenvolvimento), está na faixa baixa para os padrões de hoje, então o desempenho no mundo real dependerá disso.
Praticamente não há carga aparecendo nas estatísticas de desempenho do servidor, mas o URL leva uma eternidade para carregar. Registrei 1,2 minutos para um visitante não logado em uma janela anônima, mesmo com vários componentes já em cache. Os mais lentos foram os arquivos de fonte OpenSans TTF, com mais de um minuto; depois, vários componentes .js levaram de 30 a 45 segundos.
Vou investigar opções de cache, mas, analisando esses componentes, não acho que todos sejam passíveis de cache. No total, apenas 730 KB de transferência de dados. Se as 3 vCPUs estivessem operando na capacidade máxima, eu consideraria migrar para um servidor mais rápido, mas como até mesmo isso mostra pouca ou nenhuma carga, estou simplesmente confuso.
Há algo que esteja aguardando outra coisa antes de prosseguir? Existe alguma maneira de executar testes no servidor para verificar a saúde dos componentes, como o banco de dados?
O Docker poderia estar deixando as coisas mais lentas?
