Discussion :

[cmail]

Histoire d'améliorer les performances des pages contenant l'api, n'y aurait-il pas quelques modifs à faire sur le server de l'api?

Par exemple, j'ai testé le premier exemple de l'api: http://api.ign.fr/tech-docs-js/examp...p_simple1.html avec http://gtmetrix.com

Résultat: Page Speed Grade : 89% et Page Yslow : 87% avec des carences sur le type "server" (voire "JS") qui ne peuvent être améliorées que par vos soins (me semble-t-il?).

[mga_geo]

Ton constat est dur pour l'IGN !
Le gros javascript de l'API est le principal responsable du temps de chargement. Et pour diminuer sa taille, il faudrait s'orienter vers d'autres bibliothèques ...

[cmail]

Ton constat est dur pour l'IGN !

Non, mon constat a simplement pour ambition d'améliorer l'api, si possible coté IGN. Nullement un jugement de valeur.

[Zébulon-21]

Non, mon constat a simplement pour ambition d'améliorer l'api, si possible coté IGN. Nullement un jugement de valeur.

J’adhère tout à fait à la démarche de cmail et le félicite pour la suite de ses idées qui vont toujours dans un sens constructif.

Ce n’est pas toujours évident si l’on considère que la contrepartie des aides obtenues sur les forums est parfois dépendante d’une certaine docilité.

Sans la liberté de blâmer, il n'est point d'éloge flatteur.

[jrenard]

Bonjour à tous,

Christian, tu as raison de nous pousser dans nos retranchements, cela ne peut que nous inciter à nous améliorer GTMetrix est un outil indispensable que nous utilisons déjà, mais comme tous les outils il doit se prendre avec le recul et la réflexion nécessaire. Quand tu évoques "L'API passée au crible", c'est bien un exemple basé sur l'API et non l'API elle-même qu tu testes (tu l'as très bien compris, mais je préfère le rappeler pour éviter toute confusion). Dans cet exemple, il y a quatre postes principaux qui influent sur le temps de chargement et les notes de GTMetrix :
1) le code de base de l'API
2) l'appel à l'autoconf de la clé API
3) le code de la page appelant l'API pour construire la carte
4) l'outil de stats de visites des sites IGN (Piwik)

Les points 3 et 4 expliquent à eux seuls pas mal de points négatifs relevés par l'analyse GTMetrix. D'une part pour le point 3 parce que le code de la page n'est pas optimisé, étant entendu que c'est une page d'exemple à visée didactique qui par essence n'a pas vocation à être optimisée ou minifiée (cela n'aurait pas de sens). D'autre pour le point 4 parce que notre outil de stats n'est lui aussi pas optimisé et peut être responsable d'une bonne latence au chargement. Ces deux points sont responsables notamment des mauvaises notes sur la minification, sur l'encodage, sur les parsings non différés, et sur le temps de chargement global, mais ils ne relèvent pas de l'API en elle-même.

Là où un effort pourrait être fourni, c'est comme tu le soulignes coté serveur en ajoutant des en-têtes d'expiration, une meilleure gestion du cache (ce qui va avec) et en utilisant un Content Delivery Network. Ce sont des points sur lesquels on travaille, en particulier sur l'ajout d'en-têtes d'expiration qui a récemment fait l'objet d'un effort particulier même si cela ne se voit pas encore sur les fichiers de l'API issus de la dernière version 2.1.1. Donc on travaille là-dessus, mais tu as raison de signaler l'effort qui pourrait être fourni.

Pour être parfaitement complet, un dernier point important : si vraiment un utilisateur de l'API chercher à faire de l'optimisation sur sa page, il a aussi la possibilité de charger le code-source de l'API dans sa propre arborescence de déploiement, ce qui lui évitera des appels sur le serveur api.ign.fr. En ajoutant à ça un appel à une autoconf locale (pour diminuer le nombre de requêtes http et éviter là aussi d'appeler les serveurs IGN), il y a moyen de faire des choses qui plairont beaucoup à GTMetrix. Je peux par exemple te montrer l'analyse faite pour une appli maison pas encore livrée au public, basée sur la version étendue de l'API (la plus lourde), construite de la façon que je viens de te décrire :



Tu vois donc qu'avec l'API on peut faire des choses très optimisées, avec de bonnes notes et un temps de chargement raisonnable (la mauvaise note du CDN étant due au fait que l'on n'a pas encore déployé sur un réseau optimisé). Le principal poste du temps de chargement de l'appli reste le code-source de l'API (1.4s sur 2.26s), mais là-dessus, comme l'a fait remarquer Marc, on ne peut pas faire grand chose sauf à se baser sur une bibliothèque plus légère mais fatalement moins complète.

[cmail]

Salut Jeremy.
Ta réponse est excellente, constructive et clarifie beaucoup de mes interrogations.

Là où un effort pourrait être fourni, c'est comme tu le soulignes coté serveur en ajoutant des en-têtes d'expiration, une meilleure gestion du cache (ce qui va avec) et en utilisant un Content Delivery Network. Ce sont des points sur lesquels on travaille, en particulier sur l'ajout d'en-têtes d'expiration qui a récemment fait l'objet d'un effort particulier même si cela ne se voit pas encore sur les fichiers de l'API issus de la dernière version 2.1.1. Donc on travaille là-dessus, mais tu as raison de signaler l'effort qui pourrait être fourni.

Très bien, on va patienter

Pour être parfaitement complet, un dernier point important : si vraiment un utilisateur de l'API chercher à faire de l'optimisation sur sa page, il a aussi la possibilité de charger le code-source de l'API dans sa propre arborescence de déploiement, ce qui lui évitera des appels sur le serveur api.ign.fr. En ajoutant à ça un appel à une autoconf locale (pour diminuer le nombre de requêtes http et éviter là aussi d'appeler les serveurs IGN), il y a moyen de faire des choses qui plairont beaucoup à GTMetrix.

OK, je vais de voir ce que cela donne en déplaçant le code source de l'api sur mon serveur et en le minifiant avec mes js.... Par contre pour l'autoconf locale, j'ai abandonné voir cette discussion http://www.developpez.net/forums/d14...f-sous-chrome/ Mais la question reviendra!

Je peux par exemple te montrer l'analyse faite pour une appli maison pas encore livrée au public, basée sur la version étendue de l'API (la plus lourde), construite de la façon que je viens de te décrire :

Super ces performances! Cela m'incite à peaufiner les miennes! Et dans un premier temps à comprendre mes erreurs, et là, il y a du boulot !