Rendre les sites Web réactifs performants
Il fut un temps où vous pouviez faire la différence en toute confiance entre une page Web de bureau et une page Web mobile. À tel point, en fait, que toute une industrie s’est développée autour de la réorientation des sites de bureau pour les mobiles.
Pendant un certain temps, vous n’étiez personne si vous n’aviez pas de site mobile distinct sur un domaine distinct. Puis les choses ont commencé à changer.
Les écrans mobiles se sont améliorés au-delà de toute reconnaissance. Les navigateurs mobiles aussi. Les tablettes ont ajouté un autre élément à l’équation. La 4G est arrivée. Les écrans Retina offraient de nouveaux niveaux de clarté aux utilisateurs finaux.
Soudain, la frontière entre ordinateur de bureau et mobile était devenue floue.
Dans le même temps, il y avait une diversité croissante dans la taille et la résolution des écrans de bureau.
Et un casse-tête croissant pour les concepteurs de sites Web.
L’époque où vous n’aviez qu’à prendre en charge une poignée de tailles de fenêtres était révolue. Les choses se compliquaient.
Heureusement, l’aide était à portée de main sous la forme de requêtes médiatiques et du concept de conception réactive.
Grâce aux requêtes multimédias, il est devenu possible de varier les styles et la mise en page – voire le contenu – en fonction de la largeur de la fenêtre d’affichage et de la résolution de l’écran de l’utilisateur. Bien sûr, les requêtes médias ne sont en aucun cas le seul outil dans le sac à malice du concepteur réactif, mais il est juste de dire qu’elles constituent la base de la technique.
C’était une excellente nouvelle pour le mobile. La conception réactive signifiait que vous pouviez diffuser efficacement différentes versions du même site sur différents appareils. Le tout sans développer un site mobile distinct sur un domaine différent.
Qu’en est-il des performances ?
Les propriétaires de sites commencent à réaliser que les utilisateurs finaux se soucient des performances. Les détaillants en particulier commencent à comprendre que la réduction de millisecondes de temps de chargement peut se traduire par des millions sur le bilan.
Heureusement, les sites réactifs offrent un avantage clair en termes de performances par rapport à leurs cousins mobiles dédiés : la redirection vers un domaine mobile est supprimée.
Cependant, malgré cela, la conception réactive a réussi à acquérir une certaine réputation de performances médiocres.
À certains égards, c’est plutôt injuste, mais cela vaut la peine d’examiner les défis de performances supplémentaires que la conception réactive pose aux imprudents…
Images
Les fichiers image sont volumineux. Et parce qu’ils sont gros, ils sont souvent responsables des temps de chargement lents. Ils sont donc un bon point de départ pour quiconque essaie d’optimiser les performances d’un site.
Malheureusement, l’une des premières solutions pour fournir des images réactives n’était pas excellente pour les performances.
La technique est magnifiquement simple. Utilisez simplement max-width: 100% pour vous assurer que les images s’adaptent à la largeur de l’élément contenant :
img
{
max-width: 100%;
}Au fur et à mesure que le conteneur se rétrécit pour s’adapter à des fenêtres plus petites, toutes les images à l’intérieur rétréciront avec lui. Facile!
Mais il y a un problème. La taille de l’image peut diminuer à l’écran, mais la taille du fichier reste la même. C’est loin d’être idéal d’un point de vue performance. Vous pourriez envoyer une image de 800 x 800 pixels sur le fil, uniquement pour qu’elle soit affichée à 80 x 80 pixels: en d’autres termes, vous pourriez transmettre des centaines (ou des milliers) d’octets inutiles. Non seulement l’image prendra beaucoup de temps à charger, mais tous ces octets redondants pourraient épuiser la précieuse allocation de données de l’utilisateur final.
Cependant, ce n’est pas le seul – ni même le meilleur – moyen de fournir des images réactives. D’une part, une image qui fonctionne à 800 pixels de large ne fonctionnera pas nécessairement aussi bien à diverses fractions de cette taille.
Pour résoudre ce problème, vous pouvez utiliser une requête multimédia pour afficher différentes versions de l’image en fonction de la taille de la fenêtre d’affichage en utilisant une requête multimédia et afficher : aucune.
CSS :
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML :
<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">Cela vous permet d’afficher différentes versions d’une image, plutôt que la même image à différentes tailles. Cependant, cela ne réduit pas le nombre d’octets. En effet, la taille globale de la page sera plus importante puisque toutes les images seront chargées, qu’elles soient affichées ou non.
Une meilleure alternative – si c’est pratique – consiste à utiliser des images d’arrière-plan <divs>à la place <img>des éléments. Ceci est préférable car les images référencées dans CSS ne sont chargées que si elles sont utilisées (tant qu’il ne s’agit pas d’URI de données) :
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Cela fonctionne bien: les visiteurs ne téléchargent que les images dont ils ont besoin, au fur et à mesure qu’ils en ont besoin. Le problème est qu’il est désordonné, traitant efficacement le contenu comme un style. En tant que tel, cela crée potentiellement un problème de maintenabilité et pourrait également entraîner l’ignorance d’images importantes par les moteurs de recherche.
Au lieu de cela, pourquoi ne pas utiliser SVG (graphiques vectoriels évolutifs): un format d’image qui s’adapte de par sa nature même? Les images SVG ont également l’avantage d’être facilement stylisées avec CSS (voir cet excellent tutoriel sur la façon de rendre les SVG réactifs avec CSS). C’est parfait pour les icônes et les logos, mais malheureusement, vous ne pourrez pas utiliser de SVG pour les photos – pour celles-ci, vous devrez recourir à des formats raster, tels que JPEG.
Une autre option consiste à utiliser l’une des nombreuses solutions JavaScript pour fournir des images réactives. C’est une façon populaire de le faire, mais cela ajoute une autre couche de complexité. De plus, étant donné que JavaScript bloque la construction du DOM, toute solution impliquant JavaScript a le potentiel de retarder le rendu. Ainsi, bien qu’il existe des plugins très intelligents, simplement en introduisant JavaScript dans l’équation, vous vous résignez, dans une certaine mesure, au moindre de deux maux.
Jusqu’à récemment, c’étaient les seules options.
Maintenant, cependant, les éléments <picture>et <source>, ainsi que les attributs srcset et tailles, apportent enfin des images vraiment réactives sur le Web. La nouvelle spécification commence également à être prise en charge par les navigateurs, avec une prise en charge complète dans Chrome et Opera, et une prise en charge du changement de résolution dans Safari. Jusqu’à ce que d’autres navigateurs rattrapent leur retard, il existe un excellent polyfill JavaScript .
Dans ce nouveau monde courageux, vous pouvez utiliser srcset pour établir une liste d’images candidates parmi lesquelles le navigateur peut choisir. Vous pouvez ensuite utiliser une requête multimédia dans l’attribut tailles pour dicter la taille à laquelle l’image sera affichée. En utilisant l’ <picture>élément avec des requêtes multimédias à l’intérieur d’un ou plusieurs éléments, vous pouvez spécifier une gamme différente d’images pour différentes conditions (par exemple, pour les fenêtres jusqu’à une certaine largeur, utilisez l’image a, b ou c, et pour les fenêtres plus grandes, utilisez l’image x, y ou z). Ceci est utile si vous avez besoin de fournir une version recadrée d’une image pour les utilisateurs avec de petits écrans.
Le détail précis de l’utilisation de la nouvelle syntaxe sort du cadre de cet article, mais vous pouvez trouver un excellent tutoriel sur alistapart.
Peut-être que le seul inconvénient de cette nouvelle spécification est qu’elle est assez longue, ce qui pourrait signifier un HTML gonflé sur des pages avec beaucoup d’images. Cependant, les avantages l’emportent largement sur les inconvénients.
Bien que les requêtes multimédias vous permettent d’appliquer différentes règles CSS en fonction des critères que vous avez définis, il est indéniable que les utilisateurs finaux devront télécharger tous les CSS qui pourraient s’appliquer. Cela est vrai même si vous mettez votre CSS dans des fichiers séparés et placez votre requête multimédia dans l’ <link>élément.
Par exemple, les deux feuilles de style suivantes seront chargées, quelle que soit la largeur de la fenêtre :
<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">Ce n’est pas un bug du navigateur. Les critères utilisés dans les requêtes médias concernent souvent des éléments qui changent lors d’une visite sur une page. Par exemple, un visiteur peut décider de redimensionner la fenêtre du navigateur ou de faire pivoter sa tablette/appareil mobile. Le changement d’affichage qui en résulte devrait être transparent et lancer une demande pour un autre fichier CSS serait loin d’être idéal. Cela est particulièrement vrai pour les appareils mobiles, qui cherchent à fermer les liaisons radio le plus tôt possible afin de préserver la puissance de la batterie. Le fait de devoir potentiellement rétablir ce lien lorsque la taille de la fenêtre d’affichage change pourrait être une mauvaise nouvelle pour la durée de vie de la batterie.
Cependant, Chrome fait l’effort de traiter ces différents fichiers de manière intelligente. Alors que tous les fichiers seront téléchargés, seul celui avec la requête multimédia correspondante bloquera le rendu. Tous les autres seront chargés avec une priorité inférieure.
Malheureusement, les autres navigateurs ne sont pas aussi obligeants. Dans Firefox, par exemple, les fichiers CSS inutilisés ne bloquent pas seulement le rendu, ils bloquent également le chargement d’autres objets sur la page.
Le graphique en cascade ci-dessous illustre ce point. Les images de cette page ne commencent pas à se charger tant que le fichier CSS inutilisé n’est pas entièrement téléchargé :
Vous pouvez contourner ce problème en utilisant JavaScript pour charger CSS de manière conditionnelle, mais, comme nous l’avons déjà vu, JavaScript a ses propres coûts de performances.
Qu’est-ce que tout cela signifie pour les performances d’un site réactif par rapport à un site mobile ?
Eh bien, les utilisateurs mobiles et les utilisateurs de bureau sur un site réactif devront télécharger le même CSS.
Et il y en aura plus qu’il n’y en aurait sur un site conçu uniquement pour les ordinateurs de bureau ou mobiles.
De plus, un site mobile dédié est plus susceptible d’utiliser une version plus légère et simplifiée du CSS de bureau (bien que cela soit peut-être moins vrai maintenant, car les utilisateurs s’attendent à une expérience plus riche sur des écrans mobiles de plus en plus sophistiqués).
Donc, toutes choses étant égales par ailleurs, il semble qu’il y ait quelque chose dans l’argument selon lequel un responsive est susceptible d’être plus lent qu’un site mobile en raison du CSS supplémentaire requis. Cependant, tant que les concepteurs sont conscients des pièges potentiels, ils devraient être en mesure de créer des feuilles de style à chargement rapide pour un site réactif. En particulier, il est bon de :
- évitez d’utiliser des URI de données pour les images – les images d’arrière-plan binaires ne seront (normalement) chargées que si/quand elles sont nécessaires, mais toutes les URI de données seront chargées malgré tout.
- restez léger – puisque tous les CSS doivent être téléchargés, il est important d’être efficace. Cela signifie éviter la duplication et s’assurer que les règles globales sont définies en dehors du CSS basé sur les requêtes multimédias.
RESS (Responsive Web Design + Composants côté serveur)
RESS est un hybride entre la conception réactive et adaptative, qui implique que l’agent utilisateur renifle sur le serveur pour examiner les caractéristiques de l’appareil client et fournir le contenu qui lui convient.
Si l’une des objections à la conception réactive est qu’elle implique de diffuser tout le contenu sur tous les appareils, pourquoi ne pas atténuer cela en supprimant une partie de ce contenu là où vous le pouvez ?
Cela peut avoir beaucoup de sens. S’il y a une image que vous savez que vous ne voudrez jamais afficher sur des appareils dont l’écran est inférieur à une certaine taille, vous pouvez aussi bien ne pas l’envoyer à ces appareils, ce qui économise de la bande passante et réduit le temps de chargement.
De plus, si vous utilisez des requêtes multimédias dont vous savez qu’elles ne peuvent pas être satisfaites sur certains appareils, il existe au moins un argument pour séparer votre CSS en différents fichiers et les charger de manière conditionnelle.
Il convient de garder à l’esprit que tout ce processus n’est pas "gratuit" en termes de performances. Certains travaux doivent évidemment être effectués sur le serveur, ce qui prend du temps – probablement pas assez pour compenser les avantages, mais c’est quelque chose dont il faut être conscient.
Le verdict
Les sites réactifs sont-ils lents ?
Cela dépend de ce que vous entendez par lent.
Le site réactif le plus rapide que vous pourriez créer est-il susceptible d’être plus lent que le site mobile dédié le plus rapide que vous pourriez créer ?
Probablement.
Nous avons également vu qu’il y a quelques pièges. Si vous ne faites pas attention, il est facile de forcer les utilisateurs à télécharger de nombreuses images et CSS redondantes, ce qui rend votre site réactif beaucoup plus lent que nécessaire.
Cependant, il n’a pas à être de cette façon. Il est parfaitement possible de créer un site réactif qui soit aussi rapide que nécessaire et offre une excellente expérience utilisateur. Et à mesure que les normes et les navigateurs commencent à rattraper ce que les développeurs veulent offrir, cela devrait commencer à devenir plus facile.