Un seul paquet avec minification contre plusieurs fichiers sur http/2

Question

Quelle est la recommandation générale en matière de regroupement des CSS et JS ? Est-il préférable de tout regrouper dans un seul fichier ou d'utiliser plusieurs fichiers ?

Personnellement, je dis que les fichiers multiples sont meilleurs, surtout avec http/2, mais il y a de bonnes raisons pour les paquets : La minimisation et le gzip ont de meilleurs résultats lorsque tout est dans un seul fichier, à cause de toutes les récurrences que l'on a généralement lorsqu'on écrit beaucoup de code. Servir plusieurs fichiers de l'autre côté améliore la mise en cache et permet des téléchargements parallèles, mais inclut un code égal à travers les fichiers qui auraient pu être minifiés.

Existe-t-il de bonnes statistiques permettant de comparer la taille des fichiers, la taille de la compression et les temps de téléchargement pour des fichiers multiples et groupés ?

Il y a déjà plusieurs sujets sur Stack Overflow concernant cette question, mais je n'ai pas pu en trouver un qui prenne en compte http/2 et la minification/gzip autant que je le voudrais.

Answer 1

Voici quelques-unes des caractéristiques de http/2 qui atténuent les avantages de la concaténation (extrait de Mise en réseau de navigateurs à haute performance ) :

Le regroupement de plusieurs ressources en une seule réponse était une optimisation essentielle pour HTTP/1.x, où le parallélisme limité et la surcharge élevée du protocole l'emportaient généralement sur toutes les autres préoccupations (voir Concaténation et Spriting). Cependant, avec HTTP/2, le multiplexage n'est plus un problème et la compression des en-têtes réduit considérablement la surcharge de métadonnées de chaque requête HTTP. Par conséquent, nous devons reconsidérer l'utilisation de la concaténation et du spriting à la lumière de ses nouveaux avantages et inconvénients :

• Les ressources groupées peuvent entraîner des transferts de données inutiles : l'utilisateur peut ne pas avoir besoin de toutes les ressources d'une page particulière, voire pas du tout.

• Les ressources groupées peuvent entraîner des invalidations de cache coûteuses : un seul octet mis à jour dans un composant oblige à récupérer l'ensemble du paquet.

• Les ressources groupées peuvent retarder l'exécution : de nombreux types de contenu ne peuvent être traités et appliqués avant que la réponse entière ne soit transférée.

• Les ressources regroupées peuvent nécessiter une infrastructure supplémentaire au moment de la construction ou de la livraison pour générer le regroupement associé. Les ressources groupées peuvent fournir une meilleure compression si les ressources contiennent un contenu similaire.

...

HTTP/2 supprime ce compromis malheureux en prenant en charge le multiplexage des demandes et des réponses, ce qui signifie que nous pouvons désormais optimiser nos applications en fournissant des ressources plus granulaires : chaque ressource peut avoir une politique de mise en cache optimisée (durée d'expiration et jeton de revalidation) et être mise à jour individuellement sans invalider les autres ressources du paquet. En bref, HTTP/2 permet à nos applications de mieux utiliser le cache HTTP.

Je ne pense pas que les récurrences diminuent beaucoup la taille des fichiers. De plus, la taille du fichier n'est qu'un aspect de la latence et de la vitesse perçue. Par exemple, même si le chargement initial est plus rapide, que se passe-t-il lorsque l'utilisateur effectue une deuxième visite ? Que se passe-t-il si un fichier doit être invalidé ?

Bien que je n'aie pas vu de données spécifiques concernant votre question, voici les résultats de Google pour http/1.1 par rapport à SPDY, un prédécesseur de http/2 :

En fin de compte, la réponse à votre question ne sera qu'une opinion, à moins que quelqu'un ne fasse des tests pour le savoir.

Answer 2

De la Liste de contrôle des performances du front-end 2017 :

Une fois de plus, la mise à disposition des ressources sur HTTP/2 nécessite une révision majeure de la manière dont vous avez mis à disposition les ressources jusqu'à présent. Vous devrez trouver un juste équilibre entre le regroupement des modules et le chargement de nombreux petits modules en parallèle.

D'une part, vous pouvez éviter de concaténer les ressources, mais plutôt décomposer l'ensemble de votre interface en de nombreux petits modules, les compresser dans le cadre du processus de construction, les référencer via l'approche "scout" et les charger en parallèle. La modification d'un fichier ne nécessitera pas le rechargement de l'ensemble de la feuille de style ou du JavaScript.

Vous pouvez néanmoins essayer de charger les CSS progressivement. Évidemment, en procédant de la sorte, vous pénalisez activement les utilisateurs de HTTP/1.1. Il se peut donc que vous deviez générer et servir différentes constructions à différents navigateurs dans le cadre de votre processus de déploiement, et c'est là que les choses se compliquent légèrement. Vous pourriez vous en sortir avec la coalescence des connexions HTTP/2, qui vous permet d'utiliser le partage de domaine tout en bénéficiant de HTTP/2, mais il est difficile d'y parvenir en pratique.

Que faire ? Si vous utilisez HTTP/2, l'envoi d'environ 10 paquets semble être un bon compromis (et n'est pas trop mauvais pour les anciens navigateurs). Expérimentez et mesurez pour trouver le bon équilibre pour votre site web.