Le MIT propose de cartographier les pages web pour les charger plus vite
Le temps de chargement des pages web est devenu un enjeu essentiel aujourd’hui. Non seulement parce que les sites deviennent de plus en plus lourds et donc lents à charger, mais aussi parce que le moindre retard peut avoir des conséquences très importantes. Amazon avait ainsi estimé qu’une attente supplémentaire de 100 millisecondes lui faisait perdre 1 % de son chiffre d’affaire…
Les navigateurs font tout leur possible pour accélérer ce chargement, notamment en essayant de télécharger des ressources compressées et ainsi réduire le temps nécessaire pour les récupérer. Mais leur approche reste au fond très simple, et pas toujours efficiente : charger une page HTML, puis l’analyser et ensuite charger toutes les ressources nécessaires est un processus relativement lent.
Et surtout, en agissant ainsi, on multiplie les allers et retours entre navigateur et serveur, ce qui provoque de nombreux ralentissements. Tout est relatif bien sûr, mais il faut parfois 100 millisecondes d’attente pour chaque connexion et à l’arrivée, l’attente peut se compter en secondes. C’est pourquoi le MIT propose une nouvelle solution, nommée « Polaris ». Grâce à elle, des doctorants de l’université ont réussi à réduire en moyenne le temps de chargement des pages web à hauteur de 34 %, sans toucher au code source et aux ressources chargées.
Pour parvenir à de tels résultats, Polaris commence par analyser chaque page web et à en établir un profil que ses concepteurs comparent à une carte. L’idée est de lister non seulement toutes les ressources nécessaires, mais aussi d’établir les interdépendances. Pour charger tel module, le navigateur va avoir besoin de tel fichier JavaScript. Ou bien pour afficher la galerie à tel endroit, il va falloir telles images. Toutes ces informations forment un itinéraire optimisé pour limiter au maximum le nombre d’échanges effectués avec le serveur.
Concrètement, voici comment Polaris va agir. Il faudra installer un module supplémentaire sur le serveur qui va établir des cartes pour toutes les pages. Les navigateurs devront être mis à jour pour charger en premier lieu cette carte et ensuite la suivre en téléchargeant les ressources dans l’ordre indiqué. Sur les pages web les plus complexes, celles qui contiennent le plus de ressources, la différence peut être significative, mais ce sera moins le cas sur celles qui sont plus légères.
Le MIT précise que les navigateurs essaient déjà d’optimiser le chargement des pages, par exemple en récupérant en priorité ce qui est visible quand on arrive sur le site. Néanmoins, Polaris est censé être bien meilleur, notamment en tenant compte des dépendances en JavaScript, beaucoup plus complexes à gérer. Par ailleurs, en générant la carte d’une page web à l’avance, ce nouveau dispositif n’ajoute aucun temps de chargement supplémentaire et le navigateur n’a plus à analyser quoi que ce soit.
À l’heure actuelle, Polaris est le résultat d’une thèse financée par le MIT, mais à terme, ce devrait être un outil open-source, proposé à tous les acteurs du web. Est-ce que cela veut dire qu’il sera adopté largement ? Il faudra pour cela que les navigateurs jouent le jeu, ce qui n’est pas forcément gagné d’avance.
Il y a déjà HTTP/2 (inspiré de SPDY) qui permet de multiplexer plusieurs requêtes sur une seule connexion TCP et est un standard, cela semble aller dans le même sens.
C'est vrai mais il faut le temps de le mettre en place et tout le net ne va pas basculer comme ça.
L'autre solution c'est des bloqueurs de pub au niveau des serveurs et relais, car il faut se rendre compte que la charge des publicités inclusent dans des pages peut representer plus de 100% du poids d'une page (100% car une page WEB peut etre mise en cache, compressée,...)
Donc si on nettoie les sites WEB des publicités, ont accélère le chargement de près de 100%!
Cela veut dire aussi faire baisser la consommation des serveurs et des machines clientes, ce qui en terme de consommation électrique au niveau du Net est énorme: faut penser aussi a la charge que la pub représente pour les datacenter.
Ne négligeons pas non plus que plus une page contient de pub plus elle demande de ressource pour être indexée.
D'autant que nombre du pub abuse de video, qui ne sont pas compressibles...
Bref on cherche des solutions qui ne concernent pas le problème, et LA solution la plus simple est la plus efficace dans ce cas.
Excellente idée :-D
Une fois adopté, les développeurs utiliseront la marge gagnée pour alourdir leurs pages…
@Madalvée :
Oui c'est assez désespérant !
J'ai énormément de pages/onglets ouverts sur safari et je vois bien avec le moniteur d'activité que certains sites se permettent de jouer avec des gigas de mémoire vive et mes nerfs au passages. D'autres parfois, sans aucune raison apparente, font tourner un cœur de mon processeur au maximum pendant qqs minutes... Et donc les ventilateurs par la même occasion.
sans raison ? la raison est un script javascript asynchrone pour par exemple faire dire à votre ordi si vous êtes encore sur la page, faire calculer on ne sait quoi, et autres idées perverse.
bon ok, y a aussi le script tout pourri qui n'a pas de condition de fin..
mais oui, plus on optimise, plus y a des parasites pour exploiter le gain dans LEUR intérêt.
suffit de supprimer les pubs, trackers et autre scripts javascript. Accélération +90%
@reborn :
Le Javascript n'a plus les mêmes usages qu'il y a 10-15 ans. Il ne sert plus (majoritairement) à afficher des effets ringards et ouvrir des popups. Le désactiver risque vite de devenir un problème avec l'émergence des webapps modernes. ;-)
bof.
quand on veut lire du texte, ça passe très bien sur la quasi totalité des sites webs.
@oomu :
Pour l'heure, il est vrai que désactiver JS ne pose pas de problèmes particuliers pour consulter dès contenus textuels.
Toutefois, les usages du navigateur semblent être amenés à évoluer à moyen terme. Aujourd'hui déjà, on ne s'en sert plus uniquement pour consulter des sites webs basiques.
Et le Javascript prend une importance que l'on n'aurait pas soupçonnée il y a quelques années encore. On voit émerger de plus en plus d'applications web très abouties (la suite iWork d'Apple en est un bon exemple à mon sens).
À voir comment évoluera le web ces 10 prochaines années ? :-)
"Pour l'heure, il est vrai que désactiver JS ne pose pas de problèmes particuliers pour consulter dès contenus textuels."
c'est tout ce qui compte.
"Toutefois, les usages du navigateur semblent être amenés à évoluer à moyen terme. "
surement, mais je ne suis pas convaincu par le "tout web". Cela me parait être la énième répétition du mirage aux alouettes des terminaux textes, de X11, de java, de flash et de tout ce qui promet aux ingénieurs "soyez feignants, ça marchera partouuuuuut, et po cher"
"Et le Javascript prend une importance que l'on n'aurait pas soupçonnée il y a quelques années encore"
je suis la prétention même, non je ne suis pas surpris. Bien sur qu'on pouvait soupçonner l'usage que permet un langage de programmation objet aussi puissant que Javascript au sein d'une machine virtuelle presque universelle.
Je dirais même, je redoutais ce qui arrive. Exécuter du code arbitraire venant de la Jungle (internet) est une mauvaise idée.
" On voit émerger de plus en plus d'applications web très abouties"
ha mais c'est pas un problème.
On va évoluer vers deux sortes de web: celui où je laisse javascript actif (iWork, pour quand je suis malheureux et sans la version native pour Os X) et celui où je laisse le navigateur tuer, bloquer, filtrer, supprimer les scripts, pubs, trackers, gif invisibles, etc.
On a appris à faire ça avec flash (le tuer partout SAUF quand un artiste coréen me fait une comédie musicale avec des chats et des lapins). On fera de même avec javascript.
Y a du second degré absurde dans mon propos, mais mon point est simple : JS n'est pas inéluctable. On a déjà vécu tout ça.
Et d'ailleurs, quand je fais (volontairement) planter les myriades de scripts des gros sites de médias et que je veux commenter (je bloque les plateformes de commentaires qu'imbriquent les sites), et bien je désactive temporairement les filtres (Ghostery par exemple), et zou.
Y a aucun problème.
+1
Le javascript est un moyen d'améliorer la consultation d'un site WEB, en aucun cas ce doit etre un gestionnaire d'information. Le contenu d'une page WEB c'est du HTML, ensuite le formatage c'est du CSS. Le Javascript arrive en 3eme couche qui doit rester optionnelle.
Apres on peut parler des WebApp dans lesquelles JS devient le gestionnaire d'information et qui se charge de l'automatisation de l'application. On va mettre dans cette categorie les jeux et applications graphiques interactives.
Ce sont des cas particuliers facilement identifiables.
De plus une WebApp a souvent avantage a etre realiser sous la forme d'une application native qui va si c'est vraiment necessaire communiquer avec un serveur, mais va mettre en cache - au pire - l'information pour l'utiliser en local uniquement. La majorité des WebApp n'ont d'ailleurs nulle justification de leurs aspect "Web" si ce n'est l'exposition a de la pub!
L'idee est alors d'utiliser des "bloqueurs" de JS qui autorisent seulement certaines WebApp a fonctionner, le reste est desactivé par defaut.
@reborn :
C'est sur qu'un bloqueur de pub ca accélère la navigation ! C'est meme assez impressionnant.
En plus de ca j'ai désinstallé le flash, on gagne vite quelques secondes. Surtout pour ceux qui ont une mauvaise connexion comme la mienne
Quelle est la source permettant d'affirmer qu'Amazon perd 1% de CA s'il perde 100 ms ???? Cela paraît pas crédible. Amazon n'est pas un site de trading et le client n'arrête pas sa commande pour un ralentissement de 100 mS.... Il ne s'en rend même pas compte !
@Patrick75 :
http://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/
@tekikou :
Merci !
Quand j'ai commencé à tâter du web, il y a longtemps, le but du jeu était de créer des pages les plus optimisées possible (rapide parce que légères, avec des images pas trop nombreuses et utiles). Moins une page pesait, mieux c'était.
> il faut dire qu'une connexion en 56k théoriques, plus souvent (chez mes parents, quand j'y passais, à ce moment-là) autour du Mo/30 minutes, on cherchait du light.
Maintenant, surtout depuis qu'on peut compter sur des définitions d'écran démentielles et des connexions "rapides" (sauf... chez mes parents : oubliés du web de 2016), c'est la fête du slip : à qui fera la page la plus lourde.
Et si, parce que c'est maintenant relative simple, excepté pour une catégorie non négligeable de la population "oubliée", nos chers webdesigners passaient leurs pages au régime, histoire de se souvenir que leur boulot c'est AUSSI de faire pour les plus faibles connexions.
@tbr
Je ne pourrais être plus d'accord avec toi. Le poids des pages internet est devenu totalement délirant, et la plupart du temps pour des données parasites.
Exactement … ghost in the shell (|>1)
- Jo :
et inversement, des pages web portables,
où qu'on trouve l'information qu'on chercheu,
ou qu'on cherche l'information qu'on trouveu?
– π :
beaucoup traînent encore les pieds dans leurs bottes en peau de lézard sur leur clavier en dansant sans aucune notion de chorégraphieu, tactiles
Non !!! sérieux ?
Sauf a répété encore les même erreurs on peut vraiment faire une page web avec une ligne temporelle interactive sans programmation séquentielle en se privant de Javascript ?
Sinon côté serveur un bon ordonnanceur NGIИX ?
Personne ne soulève le coté fou de cette affirmation : 100 millisecondes de retard dans l'ouverture d'une page web fait perdre 1% de chiffre d'affaire. Déjà, en soi, la remarque frise le ridicule, mais surtout elle nous fait bien comprendre jusqu'où va l'obsession, la folie furieuse de la surconsommation.
Je pense que le MIT ferait bien, au contraire, d'étudier la possibilité d'allonger le délai d'ouverture des pages web pour les sites marchands : ce serait un grand pas pour l'humanité, la planète en particulier !
100 ms... un temps imperceptible au quotidien
Une affirmation fantaisiste d'Amazon
Ils font de la vente en ligne pas du RTB
Ce qui ralentit le plus le chargement des sites, ce sont la pub et tout ces trackers qui chargent du code depuis ces "serveurs distants" !
Quant aux code JavaScript pour les Frameworks, mieux vaut recopier les fichiers requis sur son propre serveur et ne charger que ce qui est nécessaire.
Mais encore faudrait-il que le mot "optimisation" existe dans le vocabulaire des décideurs et même de bcp de devs...