La combinaison / concaténation des techniques CSS et JS est-elle considérée comme obsolète?
Google recommandait aux webmasters de combiner des fichiers externes CSS et JS pour améliorer la vitesse de la page. Une de ces pages se trouvait ici: https://developers.google.com/speed/docs/best-practices/rtt#CombineExternalCSS Entre-temps, il a été redirigé et je n'arrive pas à trouver une version en cache. de cette page.
Cette recommandation semble maintenant avoir disparu des directives de Google et des plates-formes telles que GTMetrix ("PageSpeed: Combine CSS externe (obsolète)") et des fournisseurs de solutions comme Kinsta ("Comment combiner des CSS externes dans WordPress") indiquent que cette technique est obsolète.
Est-ce vraiment obsolète et devrions-nous cesser de nous en préoccuper (à condition que les meilleures pratiques soient respectées)?
C'est toujours une bonne chose à faire. La requête de fichiers un par un ajoute des délais supplémentaires, tels que le délai d’envoi de la requête et le délai au premier octet (pour chaque requête différente), qui, une fois additionnés, peuvent entraîner une seconde (ou plus) de délai supplémentaire. Cela étant dit, séparer vos fichiers en fichiers critiques et non critiques est également une bonne idée, télécharger les fichiers critiques en premier et le reste après le chargement de la page.
À la vitesse où HTTP/2 est en train d'adopter un nombre croissant (près de 30% des 10 millions de sites Web les plus importants en juillet 2018), je ne ferais pas beaucoup d'efforts. HTTP/2 vous évite d'avoir à gérer ce type de détail d'implémentation. Vous devez vous assurer que votre hôte est capable de servir du contenu via HTTP/2 pour en tirer le meilleur parti.
De Wikipedia:
Les sites Web efficaces minimisent le nombre de demandes nécessaires au rendu d'une page entière en réduisant (réduisant la quantité de code et en regroupant des morceaux de code plus petits dans des ensembles, sans réduire sa capacité de fonctionnement) des ressources telles que des images et des scripts. Toutefois, la minification n’est pas nécessairement pratique ni efficace et peut nécessiter des connexions HTTP distinctes pour obtenir la page et les ressources réduites. HTTP/2 permet au serveur de "pousser" le contenu, c'est-à-dire de répondre avec des données pour plus de requêtes que le client n'a demandé. Cela permet au serveur de fournir des données, sachant qu'un navigateur Web aura besoin de générer une page Web, sans attendre que le navigateur examine la première réponse et sans la surcharge d'un cycle de demande supplémentaire.
Les améliorations de performances supplémentaires dans la première version de HTTP/2 (qui était une copie de SPDY) proviennent du multiplexage des demandes et des réponses afin d'éviter le problème de blocage en tête de ligne dans HTTP 1 (même lorsque le traitement en pipeline HTTP est utilisé), la compression d'en-tête et la priorisation des demandes. HTTP/2 ne prend plus en charge le mécanisme de codage de transfert en bloc de HTTP 1.1, car il fournit ses propres mécanismes, plus efficaces, pour la transmission en continu des données.