Discussion :

[mga_geo]

Bonjour à tous,

Je suis impressionné par la vitesse de chargement de http://vtt.revermont.bike/randonnees...evermont-2014/
Contrairement aux autres utilisations que j'ai déjà vues, je n'ai pas vu de chargement de OpenLayers et autres Geoportal pour assurer la gestion des droits.
Le code http://vtt.revermont.bike/assets/code-0fca96a.js fait moins de 135 koctets, 36 koctets compressés !!!
Il y a un peu de magie dans ce site ...

[cmail]

Salut Marc,
De la "magie" due peut-être à leaflet...
Cela me rappelle cette discussion ou j'évoquais cette réflexion qui me semble très importante...

[mga_geo]

Bonjour Christian,

La magie est plutôt dans l'automatisation des différentes étapes de la production d'une page web : concaténation, validation, optimisation de l'ensemble des composants.
L'architecture de Leaflet permet effectivement de sélectionner plus facilement les composants nécessaires que celle d'OpenLayers mais OL a encore une richesse fonctionnelle supérieure (à mon sens).

Il ne reste plus qu'à se plonger dans Node.js et Grunt ...

[cmail]

De mon coté, je prends tes dernières remarques comme de futures réflexions à approfondir.
Mais si l'auteur, Damien (Tigr00), ouvre ce fil, ses réflexions sur le sujet seraient instructives...
De même pour celles de nos amis de l'ign.

[mga_geo]

Et pour découvrir Grunt sur Windows, j'ai trouvé un très bon tutoriel en vidéo sur grafikart.

[cmail]

Comme d'habitude le tuto de grafikart est très bien, mais si grunt peut aider à automatiser les phases de finalisation (concaténation, validation, minifi...) d'un site, je ne suis pas très sur que la rapidité des vitesses de chargement de revermont y trouve sa seule justification.

[gcebelieu]

Bonjour,

je vais dans le sens de Christian : grunt est un très bon outil pour gérer la fabrication et la publication d'un projet javascript, mais la légèreté du script final et donc la vitesse de chargement des pages est essentiellement due à la bibliothèque sous-jacente Leaflet dont c'est la raison d'être : des fonctionnalités minimales pour afficher et naviguer sur une carte avec des markers : http://leafletjs.com/features.html .

A côté, l'API Géoportail traîne derrière elle toutes les fonctionnalités et le formalisme d'Openlayers 2, et même en version minimale, elle est beaucoup plus grosse.

[tigr00]

Salut,

je découvre avec plaisir cette discussion (fallait me pinger, j'aurais répondu plus tôt) et je suis heureux de voir que certains apprécient la rapidité d'affichage car c'est pour moi une fonctionnalité hyper importante au même titre qu'un affichage agréable ou que certaines fonctionnalités du site pour les utilisateurs.

Donc pour revenir aux performances, il n'y a pas magie :-) mais des choix et des optimisations techniques qui permettent d'améliorer le temps de chargement générale. Grunt n'est là dedans qu'un outil qui a l'avantage d'être assez populaire et qui du coup bénéficie de nombreux plugins pour à peu près tout (dont l'optimisation) mais en fait ce qui compte c'est d'appliquer les bonnes pratiques et de faire quelques bons choix ou compromis peu importe les outils employés pour ça (d'ailleurs grunt fait assez peu de choses dans mon cas, la plupart des optimisations sont faites via l'outil que j'utilise pour construire le site et par de la configuration côté serveur). Des livres entiers sont consacrés à la performance web mais je peux expliquer tout de même certains points.

Leaflet vs. Geoportail

j'ai abordé ce point dans un billet sur mon blog perso. D'un point de vue purement performances, l'API Geoportail telle que servie par api.ign.fr est beaucoup trop lourde, 320Ko après minification et compression gzip, ce n'est pas ce que j'appelle minimale. En plus, toutes les optimisations de base ne sont pas en place telle qu'une entête d'expiration loin dans le futur (alors que l'URL contient le numéro de version donc ça ne poserait aucun problème!), la même chose pour les feuilles de styles qui en plus ne sont ni minifiées, ni même compressées. Ces points sont pour moi vraiment la base, en plus il est pas simple de construire sa version de l'API (maven m'a fait fuir, désolé ) pour l'héberger soit même et s'assurer que tout ça est en place...

Alors oui Leaflet fait beaucoup moins de choses, mais surtout son architecture permet d'utiliser des plugins ce qui permet d'avoir du code "à la carte" et si je peux me permettre, c'est clairement quelque chose de manquant dans l'API Geoportail (en plus de ce que j'évoque dans le précédent paragraphe).

Et le reste alors ?

L'utilisation de Leaflet aide donc mais ça ne fait pas tout (je connais certains sites basés sur Leaflet pas spécialement rapides) et donc pour vraiment améliorer le temps d'affichage, il faut mettre en œuvre différentes bonnes pratiques qui sont parfois hyper simples et spectaculairement efficaces Pour savoir quoi faire, je conseille l'utilisation de PageSpeed Insight de Google ou WebPageTest ou de plein d'autres outils du même genre.

Dans mon cas, j'ai notamment mis en place les choses suivantes:

• Réduction du nombre de requêtes HTTP nécessaire pour la construction de la page, en d'autres termes, concaténation des JS, CSS, utilisation de police pour les icônes (ou de sprite d'images)
• Réduction de la taille des composants, ie minification (JS, CSS et même HTML) et configuration du serveur pour compresser les ressources "textuelles", optimisation des images (j'ai pas tout à fait terminer ce dernier point, et d'ailleurs chaque tuile envoyée par l'IGN pourrait aussi bénéficier de ça :-))
• Optimisation de la mise en cache par le navigateur : en gros positionnement d'une entête Expires assez loin dans le futur pour les éléments externes de la page (CSS, JS, image, police, ...) mais pour éviter tout problème de mise en page/d'exécution je fais en sorte que les URL (CSS et JS) principalement aient un numéro de version qui change pour forcer le téléchargement en cas de mise à jour. J'avoue que c'est un peu pénible à mettre en place, mais c'est hyper efficace, après une première page chargée, le navigateur ne télécharge quasiment que le code HTML!

Tout ça peut s'appliquer quasiment à n'importe quelle application web et est très efficace. Et évidemment, la performance se joue aussi dans son propre code par une factorisation suffisante, l'utilisation de chargement asynchrones, ...

Voila en gros mes recettes de cuisine :-) c'est un peu long et encore je me limite. Si vous avez des questions, je serais ravi d'y répondre.

--
Damien

[cmail]

Merci pour ce retour.
En ce qui concerne API IGN, je retiens:
1/

api.ign.fr est beaucoup trop lourde, 320Ko après minification et compression gzip,

mais Gilles me répondait à ce sujet

.... Cela dit proposer un service qui génère les fichiers de paramétrage à partir du choix d'un utilisateur, lance la compilation et propose le fichier résultat au téléchargement demande un certain investissement qui ne pourra pas forcément se faire dans l'immédiat, voire du tout si cela est trop important à mettre à œuvre.

2/

En plus, toutes les optimisations de base ne sont pas en place telle qu'une entête d'expiration loin dans le futur (alors que l'URL contient le numéro de version donc ça ne poserait aucun problème!), la même chose pour les feuilles de styles qui en plus ne sont ni minifiées, ni même compressées.

>> Ok pour la date d'expiration que je ne retrouve pas, mais pour la compression je ne suis pas très sûr de ton affirmation. Quant à la minification elle reste à la charge du concepteur lors de l'appropriation des styles de l'API.
3/

chaque tuile envoyée par l'IGN pourrait aussi bénéficier de ça

Cela doit être fait, non ? Que souhaiter de plus?

Et pour tes conseils généraux, ce sont des sujets que j'essaye de travailler même si je suis pas sûr de tout maîtriser à la perfection. Mais je vais me replonger sur l'optimisation de la mise en cache que je connais le moins bien... En espérant améliorer mes performances....


Parce que, quand même, je trouve le fonctionnement de obs43.fr problématique par rapport à revermont.bike/leaflet:
Au lancement, j'ai environ 185 requêtes http dont environ 150 (une paille!!!) en chargement de tuiles wmts. Certes, l'application est en plein écran, mais quelles que soient les tailles de l'écran (même si je prends par exemple une largeur = 768px par Hauteur = 839px comme dans le cas de revermont.bike...) , il charge toujours environ 150 tuiles. Et donc des tuiles que je n'affiche jamais car dans un zoom que je n'utilise pas! Est-ce normal? Mon codage est-il correct????

Sur http://vtt.revermont.bike/randonnees...evermont-2014/ la div de l'api leaflet fait largeur = 768px par Hauteur = 839px, et elle ne charge que 16 tuiles quelles que soient les zooms ou la nature des cartes (scan express, topo ou orthophoto) .... 10 fois moins! Je ne comprends pas.

[jrenard]

Bonjour, et merci pour ce point de vue très détaillé et fort intéressant en matière de conception !

En complément de la réponse de Christian, et avant les éventuelles précisions que pourra apporter Gilles, j'apporte à mon tour et à mon niveau quelques éléments de réponse.

l'API Geoportail telle que servie par api.ign.fr est beaucoup trop lourde, 320Ko après minification et compression gzip, ce n'est pas ce que j'appelle minimale

La citation de Gilles rapportée par Christian ci-dessus répond à la question en ciblant la difficulté de réalisation de la question. Aussi intéressant dans l'absolu que puisse être l'idée de faire une API à la carte, ce n'est pas chose facile à réaliser en pratique.

une entête d'expiration loin dans le futur (alors que l'URL contient le numéro de version donc ça ne poserait aucun problème!)

C'est effectivement une chose que l'on devrait mettre en place, à peu de frais. A mettre dans la TODO list de notre coté.

les feuilles de styles qui en plus ne sont ni minifiées, ni même compressées

C'est vrai, mais comme le dit Christian c'est quelque chose qui peut être fait du coté utilisateur. Qui plus est, toutes les feuilles de style de l'API ne sont pas nécessairement utilisée : par exemple et de façon assez triviale, une carte basée sur l'API n'utilise qu'un seul des trois styles par défaut proposés. Il n'est pas interdit à l'utilisateur de récupérer les librairies API en relatif dans son site Web, de supprimer les éléments inutiles, et de ne garder de l'API que le code js minifié et compressé + les élément de style (images et css) du style API qu'il utilise en faisant du ménage dans les fichiers récupérés.

utilisation de police pour les icônes (ou de sprite d'images)

C'est quelque chose de déjà en place dans l'API Géoportail, même si certains cas ne sont peut-être pas totalement couverts.

optimisation des images

Il y a effectivement du travail à fournir de notre coté sur ce point sur un certain nombre d'images. C'est déjà dans la TODO list.

chaque tuile envoyée par l'IGN pourrait aussi bénéficier de ça

On sort là du cadre de l'API pour entrer dans celui des services sous-jacents au Géoportail, mais une chose est sûre : un gros travail d'optimisation est déjà réalisé en amont pour produire des tuiles légères tout en étant détaillées. Il serait inenvisageable de notre coté de dégrader de façon clairement visible la qualité des données pour gagner quelques millisecondes, cette qualité/précision dans les données étant justement un de nos atouts.

je conseille l'utilisation de PageSpeed Insight de Google ou WebPageTest ou de plein d'autres outils du même genre.

Petite appréciation personnelle, j'aime bien le site GTMetrix qui propose des diagnostics clairs et détaillés ainsi que des propositions d'optimisation.

[gcebelieu]

Bonjour,

l'API Géoportail peut sans doute être encore optimisée sur certains points et la question d'un packaging plus modulaire est intéressante. Cela dit, il est peu probable que l'API dans sa version actuelle (je parle de la version 2) fasse l'objet de ces améliorations car comme vous le savez OpenLayers 2 sur laquelle elle s'appuie est arrivé en bout de course.

Tout en assurant la maintenance et des évolutions mineures de l'API v2, nos efforts de développement vont devoir désormais se tourner vers la définition et l'élaboration d'une API v3 qui bénéficiera, elle, des réflexions évoquées notamment dans cette discussion.

@Christian, pour le nombre de tuiles, OpenLayers 2 charge plus de tuiles que la page peut en afficher pour optimiser la navigation ensuite. Je ne connais pas la stratégie de Leaflet par rapport à ça. A titre de comparaison, pour une taille de visu identique :

l'exemple utilisant Leaflet charge une douzaine de tuiles WMTS
l'exemple utilisant OpenLayers2 charge une cinquantaine de tuiles WMTS
l'exemple utilisant OpenLayers 3 en charge une quinzaine

Sur le site de Damien, en plus, les tuiles affichées sont plus grande que 256x256 (avec à priori un zoom client ?), donc, à priori, encore moins de tuiles à requêter.

Sinon au niveau de ta page, obs43, le temps de chargement de ta page semble être d'abord du au temps d'interrogation du service d'autoconfiguration. Une piste d'amélioration pourrait déjà être d'héberger localement sur ton site la réponse du service, comme cela a déjà été discuté sur le forum (je ne retrouve pas les références) et est expliqué ici sur le site api.ign.fr.

[cmail]

Gilles,
Je retravaille la question de l'autoconf.js (voir cette discussion de 2013) mis sur son hébergeur...

Le problème est de comparer les deux formules, toutes choses égales par ailleurs, avec des outils performants...

obs43.fr est pour l'instant toujours avec votre autoconf sur le serveur ign.
Et http://new.obs43.fr/index7-08.php est avec un autoconf.js hébergé sur mon serveur comme conseillé.
Voyez-vous une différence?

Et avec ces 150 interrogations de tuiles wmts, ce n'est pas la joie, dans les aléas de communications.

Vivement la version 3 de l'api!!!!

Pour quand déjà?

[gcebelieu]

Christian,

ta page fait maintenant les deux : elle charge l'autoconf en local ET aussi l'autoconf avec un appel au service !

En regardant ton code, je vois que tu utilises deux viewers : un pour la carte principale et l'autre (à priori) pour la loupe. Il faudrait aussi brancher ce dernier sur une autoconf locale.

Cela est aussi une raison de la multiplication de tes tuiles : 2 viewers => + de tuiles.

Gilles

[cmail]

Gilles,
Bien vu pour les 2 viewers: j'avais oublié la loupe!!!!!
Tout en ne sachant pas très bien comment tu l'as vu? Parce qu'avec firebug ce n'est pas évident!!!
Bon , maintenant sur ma page http://new.obs43.fr/index7-08.php je dois avoir qu'un seul et identique autoconfIndex.js appelé par mes deux viewers...
Qu'en penses-tu?

Cela est aussi une raison de la multiplication de tes tuiles : 2 viewers => + de tuiles.

Ce qui est vrai quand j'appelle la "loupe cartographique". Non?
C'est vrai que dans l'absolu, 2 viewers => + de tuiles. Mais ici ce n'est pas la multiplication des tuiles qui me chagrine, mais c'est que ce sont des tuiles qui sont hors de ma zone géographique...

Et puis, je suis presque certain, qu'avant d'avoir cette loupe carto (donc ce second viewer), j'avais déjà constaté cette profusion de tuiles....

[gcebelieu]

Et puis, je suis presque certain, qu'avant d'avoir cette loupe carto (donc ce second viewer), j'avais déjà constaté cette profusion de tuiles....

Il y a quand même profusion de tuiles avec OL2 (cf. la comparaison avec Leaflet et OL3 ci dessus), mais le fait d'avoir deux viewers en rajoute encore plus...

[cmail]

Gilles,
Peux-tu me préciser une chose:
Quelles sont vos modifications qui influent sur l'autoconf?
A chaque changement de version de l'API, devrai-je modifier mon autoconf?
Ou mon autoconf est valable tant que je ne change pas ma clé?

Par ailleurs, sur http://new.obs43.fr/index7-08.php où j'essaye d'appliquer tes conseils j'ai maintenant une erreur TypeError: OpenLayers.Protocol.Script.registry.regId1 is not a function dans mon autoconfIndex.js

[gcebelieu]

Gilles,
Peux-tu me préciser une chose:
Quelles sont vos modifications qui influent sur l'autoconf?
A chaque changement de version de l'API, devrai-je modifier mon autoconf?
Ou mon autoconf est valable tant que je ne change pas ma clé?

On touche rarement très l'autoconf au niveau de sa strucuture car c'est très sensible. Un changement de version d'API n'influera pas sur la façon de parser ton fichier d'autoconf ( sauf si on a fait une connerie - ce qui n'est pas impossible - ou si on fait une évolution concernant spécifiquement l'autoconf, mais dans ce cas là on l'indiquera dans le changelog et comme c'est sensible, on préviendra).

Par contre, le contenu va évoluer essentiellement en fonction des droits associés à ta clef. Si tu rajoutes une couche à laquelle tu veux accéder, il faudra régénérer ton fichier d'autoconf local.

Par ailleurs, sur http://new.obs43.fr/index7-08.php où j'essaye d'appliquer tes conseils j'ai maintenant une erreur TypeError: OpenLayers.Protocol.Script.registry.regId1 is not a function dans mon autoconfIndex.js

Visiblement au moment de l'erreur, il fait l'appel suivant :

http://new.obs43.fr/js/autoconfIndex...registry.regId2

Du coup, on s'attend à exécuter une fonction OpenLayers.Protocol.Script.registry.regId2 et non OpenLayers.Protocol.Script.registry.regId1, comme indiqué dans le fichier autoconfIndex.js.

En fait, comme tu appelles 2 fois l'autoconf (une fois pour la carte, l'autre pour la loupe), il y a un système de conteur qui fait qu'OpenLayers crée 2 identifiants de fonctions de callback à utiliser (la première fois, ça se termine en 1, la deuxième fois en 2). Du coup, la première fois ça marche car il appelle la fonction OpenLayers.Protocol.Script.registry.regId1 qui est bien celle qui est dans le fichier autoconfIndex.js ; la deuxième fois non car il ne connait que la fonction OpenLayers.Protocol.Script.registry.regId2 qu'il s'attend à appeler...

Bref, dans ton cas précis qui utilises 2 appels à l'autoconf, il faudrait créer 2 fichiers autoconfIndex.js contenant ton autoconf, l'un contenant un appel à OpenLayers.Protocol.Script.registry.regId1 et l'autre un appel à OpenLayers.Protocol.Script.registry.regId2, le contenu restant inchangé. Chaque appel à Geoportal.load utilisant l'un ou l'autre des fichiers.

C'est un peu tordu, mais ça devrait marcher... et rester quand même plus rapide qu'un appel dynamique au service d'autoconf

[cmail]

Je comprends très bien ce que tu me dis.

J'ai créé deux fichiers identiques autoconfIndex1.js (pour le viewer principal) et autoconfIndex2.js (pour la loupe)
Ma page http://new.obs43.fr/index7-08.php a été actualisée avec ces modifs

Mais l'erreur se maintient...

[gcebelieu]

Il faut que tu mettes à jour aussi ton code pour que le paramètre geormUrl pointe vers ces nouveaux fichiers. Ce qui ne semble pas être le cas (ta page récupère toujours le fichier autoconfIndex.js)

Oups... PB de cache de mon côté ; tu as bien mis à jour ta page. Il faut que je regarde plus en détail...

=> autoconfIndex2.js contient toujours l'appel à OpenLayers.Protocol.Script.registry.regId1. Il faut que tu mettes OpenLayers.Protocol.Script.registry.regId2 à la place.

[cmail]

Il y avait un point de Damien qui m'interrogeait:

.......... optimisation des images (j'ai pas tout à fait terminer ce dernier point, et d'ailleurs chaque tuile envoyée par l'IGN pourrait aussi bénéficier de ça :-)).......

J'ai fait des tests sur les tuiles transmises par exemple celle-là et je l'ai soumise à http://www.smushit.com/ysmush.it/ pour obtenir ceci . J'ai ressorti mes outils d'infographiste et la seule différence qui apparaît est en terme d’algorithme de traitement des bits de l'image sans aucune conséquence sur la qualité du rendu (pas de perte due à une plus grande compression , pas de modification sur l'histogramme....).
Et pourtant un gain de 7 % (dans ce cas, mais cela dépend du contenu de la tuile) sur la taille de la tuile. Négligeable ? Pas sûr quand on a plusieurs viewers en attente....
A méditer....