Eu escrevi esse pedaço do guia.
Você definitivamente não quer viver compilado na produção.
Quando você compila, é o que acontece:
Toda solicitação de um arquivo em / assets é passada para os Sprockets. Na primeira solicitação de cada ativo, ele é compilado e armazenado em cache em qualquer Rails que esteja usando para cache (geralmente o sistema de arquivos).
Em solicitações subsequentes, o Sprockets recebe a solicitação e precisa procurar o nome do arquivo com impressão digital, verifique se o arquivo (imagem) ou os arquivos (css e js) que compõem o ativo não foram modificados e, se houver uma versão em cache, atenda.
Isso é tudo na pasta de ativos e em qualquer pasta de fornecedor / ativo usada pelos plug-ins.
Isso representa muita sobrecarga, pois, para ser honesto, o código não é otimizado para velocidade.
Isso afetará a rapidez com que os ativos serão transferidos para o cliente e afetará negativamente os tempos de carregamento da página do seu site.
Compare com o padrão:
Quando os ativos são pré-compilados e a compilação está desativada, os ativos são compilados e impressos digitais no public/assets
. O Sprockets retorna uma tabela de mapeamento dos nomes de arquivos simples para impressões digitais no Rails, e o Rails grava isso no sistema de arquivos. O arquivo de manifesto (YML no Rails 3 ou JSON com um nome aleatório no Rails 4) é carregado na Memória pelo Rails na inicialização e armazenado em cache para uso pelos métodos auxiliares de ativos.
Isso torna muito rápida a geração de páginas com os recursos corretos das impressões digitais, e a veiculação dos arquivos em si é rápida do servidor da web a partir do sistema de arquivos. Ambos muito mais rápidos que a compilação ao vivo.
Para obter a máxima vantagem do pipeline e das impressões digitais, é necessário definir cabeçalhos de futuro distante no servidor da web e ativar a compactação gzip para arquivos js e css. O Sprockets grava versões compactadas dos ativos que você pode configurar para o servidor, eliminando a necessidade de fazê-lo para cada solicitação.
Isso distribui ativos para o cliente o mais rápido possível e no menor tamanho possível, agilizando a exibição das páginas no lado do cliente e reduzindo as solicitações (com cabeçalho no futuro futuro).
Portanto, se você estiver compilando ao vivo, é:
- Muito devagar
- Falta compressão
- Irá afetar o tempo de renderização das páginas
Versus
- O mais rápido possível
- Comprimido
- Remova a compactação ouvida do servidor (opcional).
- Minimize o tempo de renderização das páginas.
Editar: (Resposta ao comentário seguinte)
O pipeline pode ser alterado para pré-compilar na primeira solicitação, mas existem alguns obstáculos importantes para isso. A primeira é que deve haver uma tabela de pesquisa para nomes de impressões digitais ou os métodos auxiliares são muito lentos. Sob um senario de compilação sob demanda, haveria uma maneira de anexar à tabela de pesquisa, à medida que cada novo ativo é compilado ou solicitado.
Além disso, alguém teria que pagar o preço da entrega lenta de ativos por um período desconhecido, até que todos os ativos sejam compilados e no local.
O padrão, onde o preço de compilar tudo é pago off-line de uma só vez, não afeta os visitantes públicos e garante que tudo funcione antes que as coisas sejam lançadas.
O ponto crítico é que ele adiciona muita complexidade aos sistemas de produção.
[Editar, junho de 2015] Se você estiver lendo isso porque está procurando uma solução para tempos de compilação lentos durante uma implantação, considere pré-compilar os ativos localmente. Informações sobre isso estão no guia de pipeline de ativos . Isso permite pré-compilar localmente apenas quando houver uma alteração, confirmar isso e, em seguida, implantar rapidamente, sem estágio de pré-compilação.