J'ai écrit cette partie du guide.
Vous ne voulez certainement pas vivre la compilation en production.
Lorsque vous avez compilé, voici ce qui se passe:
Chaque demande de fichier dans / assets est transmise à Sprockets. Lors de la première requête pour chaque actif, il est compilé et mis en cache dans tout ce que Rails utilise pour le cache (généralement le système de fichiers).
Lors des demandes suivantes, Sprockets reçoit la demande et doit rechercher le nom du fichier d'empreintes digitales, vérifier que le fichier (image) ou les fichiers (css et js) qui composent l'actif n'ont pas été modifiés, puis s'il existe une version mise en cache.
C'est tout ce qui se trouve dans le dossier des actifs et dans tous les dossiers de fournisseur / actifs utilisés par les plugins.
C'est beaucoup de frais généraux car, pour être honnête, le code n'est pas optimisé pour la vitesse.
Cela aura un impact sur la rapidité avec laquelle l'actif sera transmis au client et aura un impact négatif sur les temps de chargement des pages de votre site.
Comparez avec la valeur par défaut:
Lorsque les ressources sont précompilées et que la compilation est désactivée, les ressources sont compilées et empreintes dans le fichier public/assets
. Sprockets renvoie une table de mappage des noms de fichiers simples aux empreintes digitales vers Rails, et Rails l'écrit dans le système de fichiers. Le fichier manifeste (YML dans Rails 3 ou JSON avec un nom aléatoire dans Rails 4) est chargé dans la mémoire par Rails au démarrage et mis en cache pour être utilisé par les méthodes d'assistance des ressources.
Cela rend la génération de pages avec les actifs d'empreintes digitales correctes très rapide, et le service des fichiers eux-mêmes est rapide du serveur Web à partir du système de fichiers. Les deux sont considérablement plus rapides que la compilation en direct.
Pour tirer le meilleur parti du pipeline et de l'empreinte digitale, vous devez définir des en-têtes pour l'avenir lointain sur votre serveur Web et activer la compression gzip pour les fichiers js et css. Sprockets écrit des versions gzippées d'actifs que vous pouvez configurer votre serveur pour qu'il utilise, ce qui lui évite d'avoir à le faire pour chaque requête.
Cela permet de transmettre les actifs au client le plus rapidement possible et dans la plus petite taille possible, ce qui accélère l'affichage des pages côté client et réduit les demandes (avec un en-tête pour un futur lointain).
Donc, si vous compilez en direct, c'est:
- Très lent
- Manque de compression
- Cela aura un impact sur le temps de rendu des pages
Contre
- Aussi vite que possible
- Comprimé
- Supprimez la compression entendue du serveur (facultatif).
- Réduisez le temps de rendu des pages.
Edit: (Réponse au commentaire de suivi)
Le pipeline pourrait être modifié pour être précompilé à la première demande, mais il existe des obstacles majeurs à le faire. La première est qu'il doit y avoir une table de recherche pour les noms d'empreintes digitales ou les méthodes d'aide sont trop lentes. Dans le cadre d'un sénario de compilation à la demande, il devrait y avoir un moyen d'ajouter à la table de recherche à mesure que chaque nouvel actif est compilé ou demandé.
En outre, quelqu'un devrait payer le prix d'une livraison lente des actifs pendant une période de temps inconnue jusqu'à ce que tous les actifs soient compilés et en place.
La valeur par défaut, où le prix de la compilation de tout est payé hors ligne en une seule fois, n'a pas d'impact sur les visiteurs publics et garantit que tout fonctionne avant la mise en ligne.
Le problème, c'est que cela ajoute beaucoup de complexité aux systèmes de production.
[Edit, juin 2015] Si vous lisez ceci parce que vous recherchez une solution pour les temps de compilation lents pendant un déploiement, vous pouvez envisager de précompiler les actifs localement. Des informations à ce sujet se trouvent dans le guide du pipeline d'actifs . Cela vous permet de précompiler localement uniquement lorsqu'il y a un changement, de le valider, puis d'avoir un déploiement rapide sans étape de précompilation.