Analyse en surface du nouveau site Météo France

HTTPS not everywhere

Premier contact : pas de HTTPS. D'un autre côté on confie rarement des données personnelles à un site météo, mais en lui indiquant des lieux, on lui donne quand même des informations sur sa position ou ses intentions (voyages, etc.). Et n'importe quel SEO guru vous le dira, mettez du HTTPS : ça ne coûte pas plus cher, et ça peut rapporter gros.

Si vous regardez rapidement la situation avec SSLLabs vous verrez que le setup HTTPS n'est pas fonctionnel : le serveur ne fournit pas sa chaîne de certification. On peut le tester ainsi :

$ curl --resolve meteofrance.com:443:185.86.168.138 https://meteofrance.com/ curl: (60) SSL certificate problem: unable to get local issuer certificate 

Si on force l'accès, on se voit gentiment redirigé vers la version HTTP-sans-s (notez aussi qu'une redirection 301 aurait été préférable) :

$ curl -kv --resolve meteofrance.com:443:185.86.168.138 https://meteofrance.com/ ... < HTTP/1.0 302 Moved Temporarily < Location: http://meteofrance.com/ < Server: BigIP 

Au passage, il semble qu'on parle à un loadbalancer "BigIP"de chez F5 - matériel très populaire sauf chez les libristes comme Bearstech - et non directement à un équipement terminal. Les protocoles et algos TLS proposés sont acceptables (TLS 1.2 et ECDHE) mais visiblement, par souci de compatibilité, de nombreuses versions obsolètes sont aussi présentes : si HTTPS était utilisé, sa sécurité dépendrait surtout du client.

DNS round batman

Si on creuse un peu, le problème est plus subtil : l'entrée DNS meteofrance.com résout 4 adresses IPv4 :

C'est donc la technique du DNS round robin qui est utilisée : une forme de répartition de charge, mais assurée côté client. Avec la généralisation des CDNs, cette technique tombe en désuétude, et si elle a l'avantage de la simplicité, elle a aussi ses inconvénients :

• la structure de vos backends est révélée, et un attaquant peut se concentrer sur une seule machine ;
• si une machine tombe, un quart de vos clients ne peut plus joindre le site ;
• vous ne pouvez pas vous assurer qu'un même client touche toujours le même backend, ce que certaines applications (mal conçues) requièrent.

Dans ce cas, la résilience est également limitée, car les adresses appartiennent au même sous-réseau et sont donc derrière le même routeur sur le même réseau. Ceux qui utilisent encore le DNS round robin prennent normalement soin d'utiliser des adresses sur des sous-réseaux distincts (essayez apple.com ).

Notons toutefois que dans meteofrance.com il y a "france" et que le fait que 1/ il n'y ait pas de CDN, 2/ pas de multi-site indique qu'un choix stratégique (et financier) a été fait. Si, par exemple, 95% des utilisateurs sont en France et qu'on a déjà sa propre infra de cache, a-t-on besoin d'un CDN tiers ? Si le réseau en question (185.86.168.0/22 / AS201085 / https://www.antemeta.fr/ ) a une disponibilité globale de 99,99%, est-il nécessaire d'investir dans du multi-site si l'objectif voulu est déjà atteint ? (Note : nous ignorons si c'est le cas). Nous nous garderons donc bien de reprocher à Meteofrance qu'elle n'ait pas investi dans un marteau-pilon pour enfoncer un clou.

Chargez !

La suite logique de l'analyse consiste à observer la "cascade de chargement" de la page d'accueil. Cela nous donne à la fois des informations sur l'architecture de l'application et sur ses performances côté serveur et client. L'inspecteur de votre navigateur le fait très bien (trouvez-le dans le menu contextuel), pensez à nettoyer les "app data" (cache, cookies, etc) avant :

• 128 requests
• 324 kB transferred
• 5.9 MB resources
• Finish: 5.89 s
• DOMContentLoaded: 450 ms
• Load: 1.41 s

Ce n'est pas ce qu'on appelle léger... Sur une page d'accueil, l'objectif est en général 20 à 50 requêtes avec un temps de chargement de 1 seconde max. Cela dit, pour une telle quantité de ressources, le poids total de 6MB et le temps de chargement de 1,41 seconde est une très bonne performance. C'est donc d'autant plus dommage : les performances des serveurs sont là, mais le maquettage est contre-productif.

Si vous observez le contenu de la page, vous constaterez que l'objectif visé par l'utilisateur (la carte météo) représente environ 10% max de ces ressources. Le reste c'est : la publicité et les images des news qu'on ne voit pas sans scroller (du moins sur un écran HD).

Ne pas envoyer les ressources non consommées : ce serait une bonne idée, non ? Il y a foule de techniques à ce sujet, que ce soit nativement dans le code HTML (tag "loading" sur les images ou les iframes), grâce à l' Intersection Observer API (supportée par tous les browsers modernes), ou via une des nombreuses librairies JS le proposant ( Lozad.js , progressive-image.js , Yall.js , ...).

API à demi

La majorité des ressources (images, CSS, JS) sont chargées depuis le même domaine ( https://meteofrance.com/ ), mais on constate que les informations météo elles-mêmes sont sourcées sur une URL distincte du type : https://rpcache-aa.meteofrance.com/internet2018client/2.0/report? ...

C'est désormais une tradition : pour faire converger les sites webs et les apps mobiles, on expose les données via des "APIs" et on laisse les "frontends" les consulter. Le bonus, c'est qu'on peut construire des sites à chargement progressif où seule la partie pertinente à charger et à afficher est utilisée : c'est plus économique en bande passante et plus réactif vu de l'utilisateur.

Par contre cela peut être contre-productif, et à au moins deux égards.

D'une part, le chargement initial d'une page complète va devoir requêter frénétiquement son API pour construire l'intégralité de son contenu. Ce qui se faisait historiquement côté serveur se déplace donc côté client : ce n'est pas sans conséquence, car très souvent ces appels sont synchrones . Dit vernaculairement, effectués à la queue leu-leu, et chaque appel fait un aller-retour. Ici, http://meteofrance.com effectue 9 appels API : si vous avez la fibre, cela vous coûtera peut-être 9 x 10 = 90 ms, si vous avez une 3G des mauvais jours peut-être 9 x 100 = 900 ms. Chez Bearstech, on vous dira dans ce cas que "vous avez amplifié votre sensibilité à la météo du net" (poum tchi !), vos performances vont plus facilement se dégrader, être irrégulières et disparates selon les clients.

D'autre part, vous avez désormais 10 fois plus de requêtes dynamiques à traiter : côté infrastructure serveur, si vous n'avez pas une application 10 fois plus rapide que celle qui sert vos pages HTML (c'est rarement le cas), cela va vous demander de l'expertise et/ou plus d'infrastructure pour tenir cette nouvelle charge.

Certes, une partie des requêtes dynamiques est explicitement cachée par un proxy (reconnaissable avec le header X-Cache-Status: HIT ), et vu le type de traitement il y a de fortes chances qu'il y ait un cache applicatif. En utilisant OpenResty (fork de Nginx avec du Lua pour avoir du routage compliqué) plutôt que simplement du Nginx indique qu'il y a du tuning à ce niveau-là.

Techniquement, pour gérer cette multitude de requêtes sans trop brimer les accès itinérants, il existe simplement la version 2 du protocole HTTP, aka HTTP/2. Il est possible de limiter le nombre d'aller-retour des requêtes d'API distantes avec Graphql qui laisse aux développeurs frontends la responsabilité de composer les appels aux services du backends, mais en regroupant les appels. C'est plus intrusif que de déployer de l'HTTP/2, mais le gain en performance est largement plus grand.

Enfin, on sent bien que cette architecture orientée API n'a pas été complètement entérinée : si vous voulez afficher la météo d'un autre lieu, au lieu de ne faire que les requêtes APIs strictement nécessaires et ne rafraîchir que la carte, c'est une nouvelle page entière qui est chargée ( http://meteofrance.com/previsions-meteo-france/lyon/69000 ). Cerise sur le gâteau : celle-ci bien que très similaire à la page d'accueil est encore plus lourde (220 requêtes minimum) ! Personne n'y gagne : ni l'hébergeur, ni l'utilisateur.

Le parcours type sur ce genre de site implique une navigation, soit pour préciser un lieu, ou pour avancer dans le temps, un peu de cache local pourrait drastiquement limiter le nombre de requêtes.

Sur le côté positif, une API permet d'exposer des données qui peuvent être utilisées par d'autres services - donc de potentiels nouveaux services ou des services intégrés. Mais apprêtez-vous à déchanter : si dans https://donneespubliques.meteofrance.fr/ il y a "publique", c'est quand même un peu privé. Si vous voulez l'accès aux mêmes informations qui permettent d'afficher la carte météo du site (données "horaires"), prévoyez un petit ticket d'entrée : "Accès annuel aux données climatologiques de base, redevance annuelle : 200 000 Euros, disponible hors ligne" .

La publicité coûte plus que ce que l'on croit

Du point de vue de Meteofrance la publicité semble nécessaire, ce qui pose question pour un établissement public administratif . L'affichage de cette publicité est même pré-pondérant, affichée en bandeau supérieur avant la carte météo, parfois en encart global autour de la page météo, et sur le côté. Le mélange visuel avec le logo "République Française" est pour le moins détonnant : sur France TV il y a de la pub mais lors du jingle on ne vous affiche pas un logo "Ministère de la Culture"...

Il suffit d'activer l'incontournable uBlock Origin ( https://fr.wikipedia.org/wiki/UBlock_Origin ) et recharger sa page pour comparer : la météo lyonnaise ci-dessus passe de 220 à 72 requêtes. La pub représente trois fois plus de travail pour votre navigateur !

C'est un constat que l'on fait souvent. D'une part, les régies de publicités sont souvent intégrées au dernier moment, et souvent empilées : on rajoute des couches qui ne coopèrent pas et ne partagent aucunes ressources. D'autre part, elles sont pour la plupart très mal programmées et peu soucieuses d'économies de ressources. En d'autres termes, les seigneurs du SEO-land ne s'appliquent pas leurs propres critères. Vous en tirerez la leçon que vous souhaitez en tirer.

Conclusion

http://meteofrance.com est une étude de cas intéressante : on y trouve une bonne distribution, de bons et de mauvais points.

Il y a toujours plusieurs grilles de lecture :

• Développeur (engagé) : ne supporte pas les mauvais points, optimisera en boucle jusqu'à ce qu'on lui dise d'arrêter (et encore) ;
• Chef de projet : si ça remplit le cahier des charges, on arrête. Faire mieux peut vouloir dire faire plus long, plus compliqué, plus cher.
• Exploitation : tant que le site "rapporte plus", qu'il ne coûte pas plus cher et fonctionne dans les critères impartis, pourquoi faire mieux ?

Tous ces points de vue sont défendables, mais sont aussi défendus par peur de l'inconnu : a-t-on les compétences pour optimiser ? Combien ça va coûter ? Combien ça va rapporter ? Si on a les réponses à ces questions on peut éventuellement revoir sa position sur l'optimisation.

Et si jamais vous souhaitez vous poser ces questions, demandez à un expert dans le domaine ( https://bearstech.com ) : architecture, infrastructure, test de charge, audit de performance et de sécurité, etc. sont dans le catalogue !

Source Image : Wikimedia Commons