Activer HTTP2 pour Zeste de Savoir

Bonjour
J’ai remarqué que Zeste de Savoir est sous HTTP 1/1, en soit ce n’est pas dérangeant. Cependant, sur la page d’accueil, vous faites 35 requêtes, 1 à Google (qui est en HTTP2), 13 à mathJax (qui est aussi en HTTP2). Le temps de chargement lié à ces CDN est donc relativement court parce que les scripts sont chargé en simultanée. Par contre vous faites 21 requêtes à Zeste de savoir (notamment pour les images), qui met donc du temps à charger. En somme, pour charger les images ont se retrouve avec plus de 2 secondes de chargement (j’ai une connexion en carton aussi). Pourquoi ne pas passer le site sous HTTP 2 ?

Je viens de remarquer autre chose aussi, le script javascript sortant du serveur n’est pas compressé tandis que les ressources html / css le sont en Gzip.

C’est possible avec l’hébergeur de ZDS ? Gandi je crois.

Je croyais que le Zds était sur un VPS, j’avais oublié une possible contrainte du prestataire technique :/

Je ne crois pas que ce soit une contrainte, ZdS est bien hébergé sur son propre serveur (virtuel ou pas, pour ça je ne sais pas) comme montré dans la doc.

Merci pour la doc, ça va m’être utile pour certaines conf sur mon serveur
Sinon c’est à ne rien y comprendre, nginx est bien en HTTP 2 :

1
2

listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;

mais la réponse est en HTTP 1/1

J’ai créé un ticket, avec l’explication de pourquoi on a pas d’HTTP/2: https://github.com/zestedesavoir/zds-site/issues/4220

Plus radicale que ma question, on a la réponse
Merci !

Au passage, je claque un article très intéressant au propos de HTTP2. https://calendar.perfplanet.com/2016/http2-push-the-details/

Ah et aussi, il ne suffit pas de configurer nginx pour passer à http2. C’est tout un système à revoir ! Basiquement HTTP2 avec une simple modification de la configuration nginx n’aura aucun inpact (ça pourrait même alourdir les transactions).

Super, du coup peux-tu détailler les choses à faire pour que ça fonctionne au mieux ? Toutes nos configs sont dans notre doc et je réponds volontiers à tes questions sur notre infra.

Bah le push de files n’est pas magique, y’a de la conf supplémentaire à faire. Ça dépend des infras et des frameworks etc… Perso j’m’y connais pas vraiment en http2 et je ne connais même pas votre infra ! J’pose juste mon warning.

Tu veux dire en gros que cela ne sert plus à rien de faire du one css file et du one javascript file n’est ce pas ?
Parce que oui, en HTTP 2 tout se charge en simultané, donc avoir un seul gros fichier CSS est beaucoup trop lourd qu’en avoir 5-6. En tout cas c’est ce que j’ai compris

Justement, je comprends pas le warning en question. Tout est en http2 ici non ? Du coup qu’est-ce qui n’est pas magique, qu’est-ce qui manque, qu’est-ce qui ne fonctionne pas, qu’est-ce qu’on peut améliorer ?

Et quel rapport avec les frameworks ? Là on a juste nginx et openssl avec la config minimale présente dans notre documentation.

J’apprécie que tu nous avertisses que c’est pas aussi simple que ce que j’ai fait (remplacer SPDY par http2 dans nginx), mais l’administration système et les réseaux c’est pas mon métier. Du coup je veux bien que tu m’expliques quels outils te font dire qu’on n’a pas bien configuré le truc, et comment le configurer mieux.

@victor : Vous êtes maintenant en HTTP/2 chez moi, Firefox 51 comme sur le premier test, mais j’étais sur W7, ça ne devrait rien changer pourtant. Une mise à jour de l’infra ?

Pour ce qui est des fichiers CSS / JS, compression à environs 65% pour le CSS, donc c’est bon (on pourrait faire mieux m’enfin, aucun intérêt Les images sont priorisé, les sprites arrivent avant les autres images et juste après le CSS. J’ai envie de dire que le site est 97% compatible HTTP/2 (selon le site Dareboost) est que le seul moyen d’atteindre les 100% serait de quitter les CDN (car une connexion TCP c’est lourd), mais par conséquence augmenter le trafic sur Zds et donc perdre des perfs inutilement.

EDIT: Petit lien https://blog.dareboost.com/fr/2016/11/http2-changements-bonnes-pratiques-http1-front-end/

J’ai un peu la flemme de faire les tests (surtout qu’apparemment ma console chrome a un bug chelou ). Mais il semblerait que vous n’exploitiez pas du tout HTTP/2. Le but quand on y passe c’est de justement ne pas avoir plusieurs requête et d’envoyer les fichiers « en parallèle ».

Bref du coup cela implique bien des changements. Comme l’a soligné Dryusdan ça signifie qu’on ne compile plus les fichiers dans un seul… Et je présume qu’à l’avenir beaucoup de tools devront se développer là dessus. Notamment des tools front, peut être que des options existent même déjà dans des trucs genre requirejs… Je ne suis pas dev front et ne me suis encore intéressé que trop peu à HTTP/2.

Mais j’ai linké un lien très intéressant qui parle de tout cela mieux que moi.

Mais il semblerait que vous n’exploitiez pas du tout HTTP/2

Bah faux :

• nous chargeons un minimum de 10 PNG par page, à chaque fois avec des tailles et des niveaux de compression différents
• nous avons en plus de ça une sprite + un js + un css

En fait le fait de ne pas charger plusieurs fichier JS ensemble c’est pas trop grave en soit, tout au plus on perd 5ms. Au pire on pourrait utiliser le sytème qui existait précédemment : on a un fichier pour les dépendances et un autre pour le code du site lui-même.

Aussi on pourrait charger les polices nous-même.

Mais en soit on tire déjà bien partie de http/2.

T’as linké un article qui parle du push, et nginx ne supporte pas le push.

J’ai farfouillé un peu plus la console Firefox. Outre le fait qu’on est de nouveau en HTTP/2, on utilise l’HTTP/2 très bien (si ce n’est que le push de fichier, mais je vais me renseigner dessus).
Dans un premier temps, on charge l’HTML de la page (logique)
Dans un second temps, on charge le CSS via zestedesavoir.com et googleapi. On charge aussi le javascript venant de zestedesavoir.com (tout ça en simultané)
Puis on charge toutes les images et les polices de caractères en même temps (sauf à partir de mathjax).

Si je me souviens bien, HTTP/2 c’est du simultané et de la priorisation. C’est le cas ici non ?

EDIT :
J’ai fais le test sans cache.

Le rouge c’est quand la connexion est bloqué (connexion simultané par firefox)
Le rose la résolution DNS
Le orange le temps de connexion Le bleu le temps d’envois (sur un GET on est tranquille)
Le gris le temps d’attente du serveur Le vert le temps de réception.

EDIT 2 : je pose ce lien la, il s’agit d’un livre parlant d’HTTP/2, s’il ne vous ai pas utile dans cette discutions, il pourrait l’être dans d’autre cas https://bagder.gitbooks.io/http2-explained/fr/

EDIT 3 : Et Nginx supporte le push, il semblerait qu’il s’en charge déjà https://www.nginx.com/blog/http2-r7/

Regarde le titre de l’article en question. C’est pour Nginx Plus, pas Nginx.

Oups ^^’ Je croyais que quand c’était disponible pour nginx plus cela l’était pour nginx classique :/

Pourtant y a un module https://www.nginx.com/resources/wiki/modules/push_stream/ (je confonds peut-être )

Oui, c’est très différent ça.

Un document avec des benchmarks concernant le HTTP/2 Push rédigé par des membres de l’équipe de Chromium ici.