J’ai l’impression que les ETag auraient un impact positif important sur les performances de chargement des pages, car la plupart des pages HTML ne sont pas mises en cache. Cela éviterait au serveur de devoir servir la page si le client l’a déjà téléchargée.
Cela a-t-il été envisagé ?
Je peux me tromper, mais Discourse dépend déjà fortement du JavaScript côté client, donc ce que le client télécharge est minimal. Presque tout est chargé lors de la première visite, puis mis en cache. Je ne sais pas vraiment dans quelle mesure les ETags pourraient améliorer ce processus de mise en cache.
Par exemple, le premier chargement de ma page fait environ 800 Ko, le deuxième environ 40 Ko.
Discourse est déjà très bien conçu et configuré pour la mise en cache.
La plupart des ressources du site (JS, CSS) disposent d’URL uniques générées à chaque mise à jour du site avec un hachage de la ressource, ce qui permet de définir des durées de cache longues.
Je pense que les fichiers téléchargés sur le site (images, avatars, etc.) utilisent également des URL uniques.
La plupart des pages complètes que vous pouvez voir sont dynamiques et ne devraient pas être mises en cache de manière agressive. Il serait possible, je suppose, d’implémenter un type de mise en cache par ETag qui vérifierait à chaque chargement de page s’il n’y a pas de nouveaux ou de nouveaux posts modifiés. Je ne sais pas pourquoi l’équipe a décidé de ne pas le faire.
J’aurais dû préciser : les assets sont bien mis en cache — ce dont je parle, c’est du document HTML (première requête).
La plupart des pages complètes que vous pouvez voir sont dynamiques et ne devraient pas être mises en cache de manière agressive. Je suppose qu’il serait possible d’implémenter un système de cache de type ETag qui vérifierait à chaque chargement de page s’il n’y a pas de nouveaux ou de posts modifiés. Je ne sais pas pourquoi l’équipe a décidé de ne pas le faire.
Oui, c’est essentiellement ce dont je parle, mais je ne pense pas que les ETag soient générés manuellement de cette façon. Ils peuvent être basés sur le code HTML brut servi et peuvent indiquer au client : « hé, c’est exactement ce que tu as vu précédemment, utilise-le simplement ».
Le problème, c’est que, à ma connaissance, cela se produit déjà avec le JS côté client. Donc, vous n’avez pas d’échange de HTML.
Le HTML charge le JSON depuis le serveur, et cette requête JSON pourrait utiliser des ETags. Pour l’instant, ce n’est pas le cas, bien que je ne sois pas certain de l’argument de l’équipe pour justifier cela.
La première requête vers une page affiche bien du contenu avant de charger le JSON depuis le serveur via XHR, ce qui, vous avez raison, se produit également.
Vous pouvez le vérifier en examinant la requête réseau de type « Document » dans l’outil de débogage de Chrome ; elle devrait contenir (du moins dans mon cas) les catégories déjà rendues.
Voici un exemple de ce qui est rendu par la requête de document :
Votre demande est incompréhensible car Discourse est une application JavaScript qui ne récupère pas de HTML ; toutes les « pages » sont construites en temps réel via du code JavaScript exécutable.
Votre demande est incompréhensible car Discourse est une application JavaScript qui ne récupère pas de HTML.
Je respecte tout à fait votre expérience et votre expertise en la matière, mais j’ai fait fonctionner des dizaines d’applications web rendues en JavaScript qui utilisent des ETags dans la réponse racine (si le contenu peut être réutilisé).
toutes les « pages » sont construites en temps réel via du code JavaScript exécutable.
La capture d’écran que j’ai publiée ci-dessus correspond au HTML renvoyé avant l’exécution de tout code côté client. Il y a donc assurément quelque chose côté serveur (je suppose Rails) qui gère cette route.
Chaque communauté Discourse que j’ai examinée (sauf celle-ci) renvoie initialement une version du site sans JavaScript, avec tout le contenu déjà rendu, vraisemblablement pour les robots d’indexation.
Je m’excuse si je me trompe complètement, mais je ne pense pas être « incompréhensible » ; je peux simplement avoir tort.
Uniquement pour les agents utilisateurs de robots d’exploration, donc ce n’est pas une observation utile.
Uniquement pour les agents utilisateur de robots d’exploration
Ce n’est pas ce que je constate lorsque j’exécute ceci :
curl -H "User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" https://community.midi.city/
Ce n’est pas un agent utilisateur de robot d’exploration et il renvoie bien la charge utile ci-dessus.
Quoi qu’il en soit, je pense que la réponse à ma demande d’ETag est « non ». Merci donc pour votre retour, et peut-être sera-t-elle reconsidérée à un moment donné.
Exact, la réponse est un non catégorique et ferme pour des raisons à la fois philosophiques et techniques.
(les assets constituent un problème différent, mais l’utilisation de noms de fichiers uniques avec un GUID est une approche bien supérieure, de sorte que les ETags sont en général quelque peu obsolètes.)
Même pour l’API ? Je comprendrais que pour les petites requêtes, cela ne vaille probablement pas la peine, mais les vues de sujets peuvent atteindre 20 Ko, ce qui s’accumulerait. Mais ensuite, peu de gens consultent les sujets à plusieurs reprises, sauf s’il y a de nouveaux messages…
C’est exactement le point. Pour les consultations répétées du même contenu, si vous êtes hors ligne, nous rendons déjà tout le contenu à partir du cache du navigateur sans toucher au serveur.
Mettre à niveau cela pour charger même si vous êtes en ligne implique une invalidation du cache, ce qui, naturellement, est difficile.
Ah, c’est bien de savoir que cela fonctionne. J’aurais pensé que l’en-tête cache-control: no-cache, no-store signifiait que les réponses de l’API ne seraient jamais mises en cache par le navigateur.
Ils ne le font pas. Enfin, c’est compliqué. Il y a plusieurs caches en jeu 
Il n’entre pas dans le cache navigateur conventionnel que tout le monde connaît et aime. Mais il existe une API Web Cache Web API exposée aux navigateurs en JS, qui est utilisée pour mettre en cache les réponses afin de permettre la navigation hors ligne du contenu déjà lu.
