Dans le préchargement l’idée est de faire travailler le navigateur avant que l’utilisateur ne demande les documents pour que ce soit quasiment instantané ensuite. On attend la fin de chargement de la page, et on lance par avance le téléchargement de plusieurs liens dont on pense qu’ils serviront plus tard. C’est très intéressant pour quelques logos, css ou javascript. Imaginez une page d’accueil avec un style bien différent du reste du site : il peut être avantageux de précharger la feuille de style ou le javascript qui seront utilisés sur les autres pages.
C’est Marc Hertzog qui se colle à l’exercice avec JQuery. Il a amélioré un module de Scott Jehl qui lit une feuille de style et tente de précharger toutes les images qui y sont référencées. L’idée est séduisante. On supprime alors les temps d’attente pour les images qui s’affichent au survol de la souris ou sur les pages suivantes.
L’idée est séduisante mais je n’accroche pas tout à fait. Tout d’abord parce que c’est au navigateur de faire ça. J’ai souvent dit que sur les performances on compensait les manques des navigateurs et qu’il fallait être pragmatiques (le faire quand même même si dans l’idéal c’est le boulot du navigateur) mais là il s’agit de quelque chose de simple, très simple. Quand un « quick win » n’est pas réalisé par des gens intelligents – et les développeurs de navigateur le sont – c’est qu’il y a anguille sous roche.
Le plus gros défaut que je vois est celui inhérent à tout préchargement : on fait travailler le navigateur. Sur un poste personnel avec une navigation très linéaire ça n’a d’effet négatif quasi que sur les prestataires réseau. Mais sur une ligne partagée (entreprise, wifi), avec des gens très connectés (vidéo en streaming parallèle, deezer ou spotify en tâche de fond), ou simplement sur une navigation avec beaucoup d’onglets (vous faites une recherche, vous ouvrez beaucoup de pages en parallèle), vous pénalisez l’utilisateur ou ses voisins. Même chose pour un utilisateur en itinérance : utiliser son réseau et son processeur pour ça aura une influence forte sur sa batterie.
Le préchargement reste une bonne idée, mais à petite dose, pour des choses ciblées, prévues. Ici on télécharge tout sans discernement. C’est certain, on va aussi télécharger des éléments qui ont une faible probabilité d’être utile. Dans les commentaires de la version originale du script on propose de faire un tri sur l’url de chaque image, suivant son répertoire on décide si c’est une image qui doit être préchargée ou pas. On résout ainsi l’occupation réseau (mais pas l’occupation processeur), mais ça commence à faire usine à gaz. Sans compter que une même image peut avoir du sens pour un préchargement sur certaines pages mais pas sur d’autres.
À ce compte là autant lister les images à précharger dans un tableau javascript au lieu de lire toute la feuille de style. Ou mieux, des <link rel= »prefetch »> parce que c’est fait pour ça.
Enfin, c’est surtout utile pour les changement d’image au survol de la souris, ou sur une action utilisateur. Dans ce cas on modifie l’image en cours, ou on affiche des icônes. Bref, on se retrouve très généralement dans des cas où les images concernées sont de toutes façons dans des sprites, soit avec une liste d’icône, soit avec l’image qu’on remplace – l’image contient alors et la version sans survol et la version avec survol.
Bref, l’idée est bonne mais je reste septique sur la pertinence de mettre en place une solution générique de ce type.
Le mot pertinence en conclusion résume l’idée si tu veux mon avis. Le pré-chargement est bien fondé si et seulement si une étude statistique des visiteurs met en évidence une grande probabilité que les éléments pré-chargés soient demandés ensuite.
Le pré-chargement générique revient à léser tout le monde pour afficher les meilleurs performances sur son propre site. C’est un mal plus ou moins grand selon la quantité de données mises en jeu.
Effectivement, quand on arrive à vouloir précharger les images d’une css, c’est qu’on a vraiment envie d’améliorer les perfs de son site. Or, dans ce cas, on tendrait plutot vers l’utilisation d’une seule image de sprites pour l’ensemble des images de l’UI.
Ceci fait, il n’y aurait alors plus vraiment d’intérêt à utiliser la technique de préchargement évoquée et seul un coup de prefetch sur la sprite unique devient intéressant.
Ouais, rel=”prefetch” c’est vraiment cool, je connaissais pas mais après une petite recherche il me semble que ça fait partie des specs HTML5 et que ça n’est pas encore implémenté partout.
En attendant il faut ruser avec des sprites ou du javascript et à ce sujet je suis entièrement d’accord sur le fait que tel quel c’est une arme à double tranchant qui risque même d’avoir l’effet inverse de celui recherché dans le cas d’un grand nombre d’images. On peut améliorer le script avec un tableau comme tu le suggères, ou avec une regexp etc.
Dans tous les cas, écrire ou lire ce script est très instructif sur les façons d’accéder aux feuilles de style via javascript dans les différents navigateurs 🙂
Pour allogarage, je me sers de la première page pour charger les images qui auront le plus de chances d’être chargées :
logo petit format, icones et logos constructeur des marques les plus représentées et qui ont donc la plus grande probabilité d’être chargés sur la page « carte interactive ».
Il faurait que je prenne le temps de créer une image sprite…
Je suis quant à moi contre tous système de préchargements car ça nous fait perdre du temps à nous les utilisateurs que le site précharge, particulièrement quand il met en prime une barre de progression et n’affiche le site qu’une fois entièrement chargé.
En outre, ça ne me dérange pas du tout qu’une image ne soit pas chargée lors du passage de la souris sur un bouton et d’attendre une demi-seconde de plus, néamoins ! Il suffit de créer une grande image regroupant tous les éléments de l’interface qu’on veux créer (Avec et sans hover) puis de sélectionner les parties qu’on veux afficher via les CSS (Background-image & background-position): pas de préchargements et toutes les images sont pourtant téléchargées pour un effet instantané lors du survol.
ah non Trent, la base d’un bon système de préchargement orienté html/css/js (par opposition aux flash) c’est de précharger la page suivante seulement *après* que les éléments de la page courante soient chargés.
Ca ne te fait pas attendre plus, ça ne délaie pas l’arrivée de la première page, et ça ne t’affiche certainement pas de barre de progression. On ne parle pas du tout de ça. On ne parle pas non plus forcément des images de survol (qui elles doivent vraiment être préchargés quand c’est possible) mais bien de précharger la page suivante elle-même (et pas des éléments de la page en cours)
Pour les sprites CSS c’est effectivement une partie de la solution, mais une partie seulement. Ca ne concerne pas toutes les images (certaines vont dans le contenu, d’autres ont un montage qui les empêche d’être mises en sprite, et certaines apparaissent dans des contextes trop différents pour qu’il soit bénéfique de les regrouper)
Avec le sprite on ne résoud pas le temps de téléchargement (qui sera d’autant plus long que le sprite contient d’éléments). Pire, on va justement délayer l’affichage de la première page si on met vraiment tout dedans (justement ce que tu voulais éviter). Les sprites sont indispensables pour les performances, mais ils ne sont pas « la » solution au préchargement entre deux pages différentes. Leur but est plus de mutualiser les téléchargements sur une même page.