Escribí esa parte de la guía.
Definitivamente no quieres vivir compilar en producción.
Cuando ha compilado, esto es lo que sucede:
Cada solicitud de un archivo en / assets se pasa a Sprockets. En la primera solicitud para todos y cada uno de los activos, se compila y almacena en caché en lo que sea que Rails esté usando para caché (generalmente el sistema de archivos).
En solicitudes posteriores, Sprockets recibe la solicitud y tiene que buscar el nombre de archivo con huellas digitales, verificar que el archivo (imagen) o los archivos (css y js) que componen el activo no se modificaron, y luego, si hay una versión en caché, sirva eso.
Eso es todo en la carpeta de activos y en cualquier proveedor / carpeta de activos utilizada por los complementos.
Eso es una gran carga, ya que, para ser sincero, el código no está optimizado para la velocidad.
Esto tendrá un impacto en la rapidez con la que los activos se transfieren al cliente y afectará negativamente los tiempos de carga de la página de su sitio.
Comparar con el valor predeterminado:
Cuando los activos están precompilados y la compilación está desactivada, los activos se compilan y se toman las huellas digitales en el public/assets
. Sprockets devuelve una tabla de mapeo de los nombres de archivo sin formato a huellas digitales a Rails, y Rails escribe esto en el sistema de archivos. El archivo de manifiesto (YML en Rails 3 o JSON con un nombre aleatorio en Rails 4) se carga en la memoria Rails al inicio y se almacena en caché para su uso por los métodos de ayuda de activos.
Esto hace que la generación de páginas con los activos de huellas dactilares correctas sea muy rápida, y el servicio de los archivos en sí mismos es un servidor web del sistema de archivos rápido. Ambos dramáticamente más rápido que la compilación en vivo.
Para obtener la máxima ventaja de la canalización y las huellas digitales, debe configurar encabezados en el futuro en su servidor web y habilitar la compresión gzip para archivos js y css. Sprockets escribe versiones comprimidas de activos que puede configurar su servidor para usar, eliminando la necesidad de que lo haga para cada solicitud.
Esto permite que los activos lleguen al cliente lo más rápido posible y en el menor tamaño posible, acelerando la visualización de las páginas en el lado del cliente y reduciendo las solicitudes (con encabezado en el futuro).
Entonces, si estás compilando en vivo es:
- Muy lento
- Carece de compresión
- Afectará el tiempo de renderizado de las páginas
Versus
- Tan rápido como sea posible
- Comprimido
- Elimine la compresión escuchada del servidor (opcionalmente).
- Minimice el tiempo de renderizado de las páginas.
Editar: (respuesta al comentario de seguimiento)
La tubería podría cambiarse para precompilar en la primera solicitud, pero existen algunos obstáculos importantes para hacerlo. La primera es que tiene que haber una tabla de búsqueda de nombres de huellas digitales o los métodos auxiliares son demasiado lentos. En virtud de un senario de compilación a pedido, debería haber alguna forma de agregar a la tabla de búsqueda a medida que se compila o solicita cada nuevo activo.
Además, alguien tendría que pagar el precio de la entrega lenta de activos por un período de tiempo desconocido hasta que todos los activos estén compilados y en su lugar.
El valor predeterminado, donde el precio de compilar todo se paga fuera de línea al mismo tiempo, no afecta a los visitantes públicos y garantiza que todo funcione antes de que las cosas se activen.
El factor decisivo es que agrega mucha complejidad a los sistemas de producción.
[Edición, junio de 2015] Si está leyendo esto porque está buscando una solución para tiempos de compilación lentos durante una implementación, entonces podría considerar precompilar los activos localmente. La información sobre esto se encuentra en la guía de canalización de activos . Esto le permite precompilar localmente solo cuando hay un cambio, confirmarlo y luego tener una implementación rápida sin etapa de precompilación.