? Le temps avant la première bouchée de confiture (archive) Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.

Source originale du contenu

Mon billet (vite fait et pas très sérieux) sur « Une page blanche performante » a été pris un peu trop au sérieux. Donc revenons dessus un peu plus en détail. En se concentrant sur la définition des mots, il sera plus facile de cirsconcrire ma position sur le sujet.
http://www.la-grange.net/2018/02/27/statique-vide

Time To First Byte (TTFB)

Time To First Byte (TTFB) (pointé par le billet de Boris Schapira) donne la définition.

Time elapsed between the sending of the request requiring the web page and the reception of the first data by the user. The TTFB is particularly impacted by the latency.

D’ailleurs ironie de notre situation, la page glossaire en question n’affiche pas les définitions sans JavaScript et CSS. Le temps avant la première bouchée (byte → bite → bouchée) est également définie sur Wikipedia.

Requête et réponse HTTP

Pour les néophytes, lorsque vous cliquez un lien, le navigateur Web crée une requête HTTP à un temps t0 vers un URL sous la forme GET /miammiam. Le message passe dans l’ordinateur, le réseau comprenant de nombreux routeurs, hubs, etc afin d’atteindre une autre machine physique située quelque part dans le monde. L’instruction GET /miammiam est reçue par la machine distante. Elle le transmet au serveur Web, qui analyse la requête et donne toutes les commandes nécessaires pour composer une réponse (un autre message). Ce message de réponse refait le voyage inverse jusqu’à votre ordinateur qui finalement le transmet au navigateur Web. Le premier « byte » (ou multiplet en français) arrive à un temps t1 dans le navigateur Web. Ainsi TTFB = t1 - t0.

En fait, si nous analysons bien ce que nous venons d’écrire, nous pouvons dégager trois phases.

• Phase 1 : Du click jusqu'au serveur (temps réseau)
• Phase 2 : De l'analyse à la composition du message (temps serveur)
• Phase 3 : Le voyage de retour (temps réseau)

Site statique

Les phases 1 et 3 sont plus ou moins incontrôlables. Elles dépendent des infrastructures réseaux et de la configuration des serveurs de non de domaines. De quelques millisecondes à parfois quelques centaines de millisecondes. Nous entrons donc dans la phase 2 : la composition de la réponse et tout le débat sur les sites Web statiques ou dynamiques. Un site statique est un site où l’on minimise le temps de composition de la réponse.

Nous appellons message tout ce qui est relatif au code HTTP et HTML envoyé par le serveur Web. Et nous appelons information tout ce qui est la notion de contenu présente dans le message. La réponse d’un serveur Web à une requête HTTP s’accompagne de la résolution de l’URL pour envoyer le message. Dans cette phase 2, le serveur peut simplement associer GET /miammiam à un fichier sur le disque de l’ordinateur ou bien à l’extraction du message déjà prêt en mémoire ou bien à la fabrication du message par nombre de scripts et requêtes à des bases de données. Quand les personnes mentionnent le mot statique, ils entendent souvent la pré-génération des pages qui seront directement livrées depuis le disque de l’ordinateur plutôt que générées à la volée. En évitant le temps des requêtes à la base de données, le temps de CPU des scripts, on permet au serveur Web de renvoyer le message plus rapidement.

Cela s’accompagne d’une contrainte essentielle, toute information dynamique et vivante devient dépendante d’un message statique. Si vous désirez par exemple avoir la température de la ville de Rouen, si le message contenant l’information a été générée le jour précédent l’information n’est pas à jour bien que le serveur soit très performant dans sa réponse.

Après la réponse, le rendu de la page

Ensuite il faudra pour le navigateur Web traiter le message, l’interpréter afin de l’afficher à l’utilisateur. Le navigateur téléchargera d’autres ressources images, CSS et JavaScript, la plupart du temps. Et puis il devra calculer l’affichage de la page, plus ou moins complexe en fonction du CSS et du JavaScript. C’est une fois cette affichage réalisée que les personnes peuvent interagir avec l’information contenue dans la réponse. Ainsi « le temps avant la première bouchée » n’est qu’une partie du processus et ne définit pas vraiment l’interaction.

Le cache et la fraîcheur

Les systèmes de cache accompagnent ces processus : cache au niveau applicatif, au niveau DB, au niveau du réseau et au niveau du navigateur lui-même. Ces caches évitent de répéter une opération déjà réalisée précédemment et où l’information n’aurait pas changé. Nous remplaçons dans ce cas le temps de fabrication de la page par le temps de vérification de fraîcheur du cache.

Un site statique (dont les pages ont été générées à l’avance) est en quelque sorte un système de cache qui s’appuie sur le système de fichiers. Dans une période donnée, nous pourrions calculer :

Nb(générations) / Nb(requêtes) = Ratio(dynamique/statique)

Plus le ratio tends vers la valeur 0 et plus le site est statique. À noter que la plupart des générateurs de sites statiques sont aussi des négations d’un véritable site statique en régénérant toutes les pages à chaque mise à jour (pour la majorité des systèmes) sans aucun changement du contenu de la page.

Tas de confiture (JAMStack)

Boris présente dans son billet la JAMStack, qui a un site Web dédié, où on peut lire :

The JAMstack is not about specific technologies. It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

le « better developer experience » est pour moi un petit grincement de dents. Les bonnes pratiques pour réaliser un site JAMStack sont plus intéressantes que les verbiages du début. Voyons comment La Grange, ce site même, se place dans leurs contraintes.

• ✅ « Entire Project on a CDN. » La Grange ne dépend pas de code serveur et peut-être hébergé partout. (à part bien sûr la négotiation de contenu qui dépend de HTTP.)
• ✅ « Everything Lives in Git. » La Grange pourrait être entièrement sous git, mais sincèrement, je n’en ai pas l’utilité puisque je suis tout seul et installer un serveur git pour moi tout seul semble disproportionné.
• 💣 « Modern Build Tools. (And that currently means Babel, PostCSS, Webpack, and friends.) » J’ai ri. Comme si le fait d’utiliser les technologies modernes aient un sens quelconque dans le déploiement d’un site. La Grange est en ce moment généré en utilisant un script python et déployé en utilisant… rsync + ssh
• ✅ Automated Builds. Je ne suis pas sûr ce que cela signifie mais comme dit au point d’avant. Le build est automatiquement lancé à la main par un script en python. Moderne ! Une ligne de code : ymir billet-blog.html
• ✅ Atomic Deploys. Là aussi, j’ai ri. rsync + ssh fait exactement ce qui est décrit comme un déploiement atomique. Les fichiers uniquement modifiés sont chargés sur le serveur. Ah oui… une seule ligne de bash.
• ✅ Instant Cache Invalidation. Pas nécessaire dans mon cas, mais fourni par défaut dans un site Web bien configuré.

Tout cela me fait penser que bien souvent les développeurs ajoutent des couches complexes pour une meilleure « expérience de développeurs » mais en perdant de vue la simplicité initiale. Plus l’abstraction est grande et plus la complexité des outils viennent au final résoudre des problèmes inexistants au départ.

Bien sûr, La Grange est un site très simple mais le sont également les sites donnés en example dans le site JAMStack.

Avant déploiement - Après déploiement

L’ambiguité du billet de Boris tient en partie dans la non-séparation de l’après et l’avant déploiement. Et le site JAMStack semble en quelque sorte passer à côté également. Les bonnes pratiques sont pour la plupart trop proches d’une forme de mode plutôt que de principes généraux Web. Elles ne tiennent pas vraiment compte de l’utilisateur. D’ailleurs l’utilisateur n’est pas mentionné dans le site à l’exception d’une seule fois dans la page des bonnes pratiques : « The more of your app you can push to the edge, the better the user experience. » D’ailleurs poussé l’application à sa limite ne permet en rien de donner une meilleure ergonomie du site.

Insérer par exemple un script vers Disqus afin de créer un système de commentaires qui doit injecter un nœud dans le DOM et donc affecter le rendu, télécharger ses propres images et CSS et avec une dépendance à une latence propre qui dépend de ses propres requêtes n’améliore pas le rendu complet de la page en un temps record.

Il y a probablement une bonne volonté derrière les acteurs de ce site/méthode. Si je compris bien l’analogie de la confiture. On mets les fruits et tous les ingrédients nécessaire dans sa gamelle, on cuisine, on met dans un pot et on range le pot sur l’étagère (le avant-déploiement) jusqu’à sa consommation potentielle (le après déploiement). Tous ces appels à des APIs sont utiles, s’ils sont réalisés en amont du déploiement, générant tout le code nécessaire aux pages statiques, figées pour un instant t. La JAMStack est une mise en cache en fichier de tous les éléments d’un site Web.