Table des matières de l'article :
Introduction
Dans le paysage actuel de l'optimisation des performances Web, je Google Vitaux Web de base ils sont devenus un élément fondamental dans la définition d'une expérience utilisateur de qualité. Parmi les nombreux facteurs qui influencent ces paramètres, l'un des plus significatifs est la gestion des feuilles de style CSS. Les techniques classiques comme le chargement asynchrone de CSS, bien qu'utiles, peuvent entraîner des problèmes de décalage de mise en page, pénalisés par le décalage de mise en page cumulé (CLS).
Une solution prometteuse à ce problème est la technique del Supprimer le CSS inutilisé (RUCSS), qui prévoit l'élimination des codes CSS inutilisés dans une page Web spécifique.
Fonctionnement de RUCSS et implémentation de WP Rocket
L'approche RUCSS est basée sur la réduction du poids du code CSS envoyé au navigateur en identifiant et en éliminant les sélecteurs CSS inutiles pour afficher une page Web spécifique. Ce processus passe par une analyse approfondie du contenu HTML de la page, une analyse approfondie des règles CSS définies dans les feuilles de style qui lui sont liées, et enfin la création d'un CSS "propre" qui ne contient que les styles utilisés dans le page actuelle. Ce processus permet d'améliorer l'efficacité du chargement des pages et de réduire le temps de blocage du rendu.
Prenons un exemple plus concret : si un site Web a une feuille de style de 200 kilo-octets, mais n'en utilise en réalité que 20 % pour une page donnée, RUCSS supprimera les 80 % de CSS inutilisés. Le résultat sera une feuille de style de seulement 40 kilo-octets, améliorant considérablement le temps de téléchargement du CSS et la vitesse de chargement des pages.
WP Rocket, l'un des plugins de performance WordPress les plus connus, implémente la technique RUCSS en enregistrant le CSS "propre" dans la table "wp_rocket_css". Cependant, cette pratique peut entraîner une augmentation spectaculaire de l'utilisation du stockage, en particulier sur les sites Web comportant un grand nombre de pages. En fait, la table 'wp_rocket_css' peut atteindre plusieurs gigaoctets de taille, en particulier dans les environnements à haute disponibilité de pages.
En effet, il n'est pas rare lors de l'exécution d'opérations d'administration et de maintenance sur les sites des clients, tant au niveau applicatif que système, de rencontrer des situations dans lesquelles une base de données de quelques dizaines de mégaoctets a littéralement explosé à plusieurs dizaines de gigaoctets, produisant également ralentissements importants au niveau du SGBD MySQL.
Par exemple un utilisateur sur Github pointe son expérience et ses doléances :
Pour un site avec 10 50 produits (sur 5 attributs), la table est de XNUMX Go.
Je ne pense pas que la création de CSS pour chaque page/produit soit la solution, quelle que soit la méthode de stockage. Bien sûr, lorsque vous utilisez un système de fichiers, vous n'aurez pas les besoins accrus en mémoire auxquels nous avons affaire actuellement. Notre site consomme 15 Go de RAM même lorsqu'il est «inactif» - grâce à votre table massive qui fait huit fois la taille du reste de votre contenu.
Ce que vous devez faire, les amis, est de suivre l'exemple de TagDiv et de créer UN SEUL CSS optimal pour chaque modèle de page, PAS UN POUR CHAQUE PAGE INDIVIDUELLE. Par exemple, UN fichier CSS pour la page produit, un pour la page catégorie, UN pour la page d'accueil, etc. En supposant bien sûr le "pire des cas", par exemple une page qui comprend des produits connexes, des ventes croisées, des ventes incitatives, etc. et appliquez ce modèle UNIQUE à toutes les pages de produits.
Si vous n'êtes pas sûr, autorisez les utilisateurs finaux à exécuter manuellement l'optimiseur sur leur page de produit plus complexe, comme le fait TagDiv pour chaque modèle. J'aimerais vraiment utiliser votre excellent travail d'optimisation CSS dans un autre projet. Malheureusement, il compte plus de 150 XNUMX produits et votre architecture le rend prohibitif.
Comme on peut le voir dans le commentaire ci-dessus, qui traite d'un cas concret réel, donc le problème n'est pas tant dans la technique utilisée (c'est-à-dire celle de supprimer les css inutilisés), mais dans la mauvaise implémentation d'un plugin très célèbre comme WP Rocket.
Évaluations sur la sagesse de l'utilisation du RUCSS
L'utilisation du RUCSS, bien qu'elle puisse sembler intéressante d'un point de vue théorique, nécessite une évaluation réfléchie. La principale raison réside dans le coût de calcul associé à la génération de feuilles de style "propres". L'analyse nécessaire pour trouver des sélecteurs CSS inutilisés sur chaque page de votre site nécessite des ressources CPU et mémoire importantes.
Un autre aspect à prendre en compte est la gestion du stockage : le CSS "propre" généré doit être enregistré quelque part, ce qui a un impact conséquent sur l'utilisation du stockage.
Comme déjà mentionné, dans le cas de WP Rocket, ceux-ci sont stockés dans la table 'wp_rocket_css' de la base de données MySQL, qui peut atteindre plusieurs gigaoctets. Cette circonstance, en plus de nécessiter un espace disque considérable, implique également un coût de calcul élevé pour l'exécution des requêtes SQL, à la fois dans la phase d'insertion et de sélection des données.
Dans des contextes tels que le commerce électronique, l'adoption de RUCSS pourrait entraîner la nécessité de télécharger de nombreux fichiers CSS, bien que petits, à chaque visite sur une nouvelle page. En termes d'expérience utilisateur, un léger retard lors du chargement initial du site peut être plus acceptable que de subir des retards répétés sur chaque page.
RUCSS dans différents contextes : sites de produits et commerce électronique
Les sites Web axés sur les produits, tels que les cosmétiques, les lunettes ou les vêtements, nécessitent une attention particulière. Dans de tels cas, l'utilisateur a tendance à visiter de nombreuses pages de produits et une navigation fluide est cruciale. L'approche la plus sensée pourrait être de servir initialement un fichier CSS plus volumineux, qui sera ensuite réutilisé par les pages HTML suivantes.
Prenons par exemple un e-commerce comme ceux de la cosmétique, de la lunetterie ou de l'habillement, où l'utilisateur a tendance à visiter de nombreuses pages produits, il serait préférable d'avoir une navigation la plus fluide possible. Vous pouvez finir par télécharger de nombreux petits fichiers CSS à chaque nouvelle visite de page. Cela peut avoir peu de sens si l'on considère l'expérience utilisateur : il est probablement plus acceptable d'attendre une seconde supplémentaire lors du chargement initial du site, plutôt que de subir de petits retards répétés sur chaque page.
Recommandations pour l'utilisation du RUCSS
Bien que Google note l'optimisation Vitaux Web de base peut sembler tentant, un e-commerce qui reçoit principalement du trafic de campagnes sponsorisées sur Facebook ou Google Adsense peut ne pas bénéficier de manière significative de cette approche. Ceci est particulièrement vrai en présence de plugins tels que WP Rocket, Autoptimize ou RapidLoad, qui peuvent provoquer des délais de chargement de page importants notamment là où le CSS n'est pas encore présent et doit être généré au moment de l'exécution, créant un paradoxe en présence de systèmes avec des caches qui cache évidemment le HTML et non les fichiers statiques comme JS et CSS.
Dans certains cas, nous nous sommes retrouvés avec un chargement HTML en 40 millisecondes et une attente CSS en 9 secondes, générant une expérience utilisateur pour le moins terrifiante, alors qu'elle aurait dû être pratiquement immédiate.
Bien que par conséquent, l'approche RUCSS puisse être efficace dans certains contextes, ce n'est pas une solution universelle. Avant d'implémenter cette technique, il est essentiel de considérer l'ensemble de l'écosystème du site Web, y compris les caractéristiques d'audience, la structure du site, les priorités en matière de référencement et d'expérience utilisateur, ainsi que les ressources disponibles pour la gestion de la base de données et du stockage.
