Salut les zestes !
Je me balladais un peu, et j’ai remarqué que.. Darn ! Ma connexion rurale ne me permettait pas de charger certaines pages rapidement, même lorsque le contenu était au final assez… léger, pour ne pas dire presque vide (certains sujets etc).
J’ai donc rapidement pris mon tinfoil hat et commencé mon exploration de la timeline de la requête, montrée gracieusement par notre grand ami Firefox, et je me suis rendu compte que le principal élément bloqueur était mathjax (environ 60% du temps de charge).
Pour être honnête, je ne suis pas surpris, ayant déjà bricolé avec mathjax. Je savais à quoi m’attendre ! 
Je me suis vite rendu compte que plus de 15 API calls vers mathjax.org étaient effectués par mon navigateur pour charger l’intégralité du site, ne contenant que peu de formules. Ce qui est, disons-le nous.. beaucoup. Du moins, proportionnellement au contenu de la page en question (dont je n’ai, hélas, plus le lien sous la main), c’est beaucoup.
J’ai un peu fouiné sur le forum de communauté et j’ai trouvé ce post, qui semble bien résumer le problème, notamment avec l’intervention de Gabbro, qui expliquait le problème principal de lourdeur cité un peu au dessus.
Pour éviter un petit déterrage éventuellement inutile, je venais donc demander si:
- la solution envisagée et en cours de production lors du dernier message posté par Kje a été retenue ;
- la solution n’a pas été retenue, dans quel cas:
Pourquoi ne pas faire un API endpoint qui accepterait toutes les formules à convertir (et les requêtes "complémentaires"), et qui retournerait une série de réponses (éventuellement encodées en JSON), qui seraient alors réparties à travers la page ?
Dans le principe, cet API endpoint recevra alors une série de requêtes (sans doute une liste ou un tableau, par exemple), traitera individuellement chaque requête (éventuellement en stockant le résultat dans un cache, si disponible), et une fois fini, retournera la liste de réponses.
Note que je suis conscient que monter ça apporterait pas mal d’autres contraintes et soulèverait pas mal de problématiques, comme, par exemple, un flood d’insertions de formules mathématiques en LaTeX, qui soulèverait alors un très gros batch de requêtes à effectuer, donc un gros boulot côté serveur et une double charge côté réseau ; ce qui produirait alors l’effet inverse, même si un flux continu ininterrompu de données restera toujours techniquement plus performant qu’une série de requêtes/réponses courtes avec fermeture/réouverture de flux.
