Webperf : boostez vos apps PHP avec le code de statut HTTP 103 Early Hints

Bonjour à tous ! Effectivement on va parler, une fois n'est pas coutume de webperf et des nouveautés du protocole HTTP parce que ça a beau être quelque chose d'assez ancien, ça évolue encore pas mal . Et parfois, on va le voir, ça revient même en arrière.

Je m'appelle Kévin.

Venant du Nord de la France, c'est assez commun.

Je suis le co-fondateur des Tilleuls et effectivement ça fait un moment que je travaille sur PHP et son écosystème, mais aussi sur d'autres technologies desquelles je pense, il y a pas mal de choses desquelles on peut s'inspirer, dont Go et le serveur web Caddy dont on va parler un petit peu à la fin de cette conférence.

Les Tilleuls, c'est une société coopérative qui appartient intégralement aux gens qui travaillent dedans et qui prend les décisions de manière démocratique, qui fait principalement du développement, du consulting, de l'audit.

En gros, qui peut vous aider pour faire des bons projets ou vous aider quand le projet est déjà en difficulté.

Et on est très présent dans l'écosystème PHP, avec API Platform.

On est aussi dans la PHP Foundation depuis un an, on travaille beaucoup sur Symfony.

Depuis cette semaine, on est partenaire officiel de Laravel.

Je sais qu'il n'y a pas que des fans mais c'est quand même assez efficace et on en fait depuis assez longtemps chez Les Tilleuls.

On fait aussi beaucoup de JavaScript, vraiment très éclectique.

Voilà pour les petites présentations.

Alors, de quoi va parler ce talk de 20 minutes ? Quel est le problème qu'essaie de régler ce nouveau code de statut ? Pourquoi dans ce protocole assez ancien qui est HTTP/2 On vient rajouter un élément aussi fondamental qu'un nouveau code de statut.

Déjà, peut être, pour voir à qui j'ai affaire, qui sait ce que c'est qu'un code de statut HTTP ? Ok, donc on n'est pas obligé de passer du temps là dessus.

Ça tombe bien, j'ai que 20 minutes.

Le fonctionnement du web de manière complètement classique, c'est à peu près résumé par ce schéma que j'ai honteusement copié sur le site de Google WebDev.

Un utilisateur va vouloir accéder à une ressource.

Une ressource, à la base, c'était des documents style thèse, documents universitaires, etc.

Le web a été conçu pour ça.

Maintenant, généralement, c'est des vidéos de chats.

Peu importe, une ressource, c'est n'importe quoi qui peut être nommé et affiché à l'utilisateur final.

L'utilisateur, pour ça, il va utiliser un agent utilisateur.

Dans 95 % des cas ou 90, c'est Google Chrome.

Dans les faits, ça peut être n'importe quel navigateur web ou client HTTP type curl, ce genre de chose.

Donc voilà, on a une requête GET qui permet de demander une ressource, et, en théorie, on obtient cette ressource, elle est affichée à l'utilisateur.

C'est vraiment le principe du web, le slogan de base : partager les connaissances, etc.

Ça, c'est la théorie. Et ça marchait bien dans les années 90, quand notre document c'était juste du texte.

Dans les faits, maintenant, les pages web sont composées de plusieurs ressources.

On a notre ressource principale, disons notre article de blog.

Mais, cet article de blog, quand on récupère la ressource principale index.html On obtient juste du HTML.

Et en fait, il faut aussi une feuille de style CSS, voire plusieurs feuilles de style CSS pour le mettre en page.

Il faut aussi 50000 Mo de JavaScript pour que ça s'affiche correctement parce que vous avez utilisé React ou Vue.js.

Il faut aussi des images pour que ce soit joli, il faut aussi des vidéos parce que pour monétiser votre blog, vous lancez des vidéos en autoplay et tout ça.

Bref, en plus de la ressource principale index.html ici là, dans mon exemple, j'ai aussi besoin de beaucoup de ressources liées.

Ça, c'est l'état actuel du web.

Et le problème qui se passe, c'est que c'est lent.

Vous allez demander l'article de blog, votre script PHP va exécuter 2000 requêtes SQL, des algorithmes mal foutus, etc.

Ça va prendre un moment.

Une fois que tout ça aura été effectué, vous aurez généré du HTML côté serveur, vous allez l'envoyer aux clients.

Il faut qu'il soit téléchargé, en tout cas commencé à être téléchargé.

Et à ce moment là uniquement, le navigateur web va pouvoir réclamer les ressources liées, les CSS, les JS, etc.

Et donc, seulement au moment où il aura le HTML, il va devoir lancer ces téléchargements et potentiellement ça va être en cascade.

Peut être que votre fichier JS référence à un autre fichier JS qui lui même référence une image.

Il va falloir attendre que le fichier HTML, puis le fichier JS, puis le fichier JS, puis l'image soit téléchargée pour que je puisse finalement afficher mon contenu intéressant à l'utilisateur.

Ça va faire ce qu'on appelle des latents, ça va augmenter les latences.

On arrive dans ce genre de situation.

Au niveau protocole, comment ça marche ? Là c'est du HTTP on va dire, abstrait.

C'est à dire que c'est ni du HTTP/1, ni du HTTP/2, ni du HTTP/3.

C'est un truc qui marche à peu près dans les trois et on va voir que ça a quand même son importance.

Ça ressemble très fort à du HTTP/1.

Donc voilà, on demande la ressource principale.

Notre serveur PHP exécute ses 2000 requêtes SQL.

Ça prend un moment, ce qu'on va appeler le temps de calcul, le temps de pensée du serveur et ça bloque l'affichage de la page pendant ce temps là.

Ensuite, le HTML est prêt, il est enfin généré, il est envoyé.

Finalement, la latence réseau etc, c'est récupéré par le navigateur.

Le navigateur voit qu'il y a un fichier CSS qui est demandé.

Boom.

Nouvelle requête effectuée par le navigateur vers common.css.

Une fois qu'il est téléchargé, il va faire le rendu, ce qui peut prendre un peu de temps aussi et c'est affiché.

Alors, qu'est ce que c'est que ce nouveau code 103 ? Ce nouveau code 103 va permettre d'essayer de diminuer la latence perçue par l'utilisateur pour l'affichage de ses données.

Déjà, on va quand même reparler un tout petit peu des codes de statut.

Vous savez tous ce que c'est, mais est ce que parmi vous certains ont déjà utilisé, manipulé directement des codes de statut qui commencent par la classe 1 ? Vous connaissez sûrement les 2 comme 200 qui sont OK.

On envoie quelque chose qui va bien.

La classe 3 ce sont les redirections, la classe 4 qui sont les erreurs côté client, les données utilisateur mal formatées, une erreur de validation, etc.

Et la classe 5 qui est un problème côté serveur, on a un bug dans notre code, etc.

Mais la classe 1 : qui parmi vous a déjà utilisé ces codes de statut ? Ça m'étonne pas. Assez peu de monde.

Et en fait, c'est assez logique parce que c'est utilisé, mais c'est utilisé généralement par des trucs assez bas niveau qui sont implémentés directement par les navigateurs et les serveurs web de l'autre côté.

En fait, la classe 1, c'est des réponses dites informatives qui vont être des réponses préliminaires, temporaires qui vont être envoyées avant les réponses finales.

Donc en fait, on va pouvoir, le serveur va pouvoir envoyer des informations au client en disant "Bon, c'est l'information que j'ai en ce moment sur une opération qui est en cours, effectuée, en progression, et à la fin, t'auras forcément une réponse suivante qui va être de la classe 2, 3, 4 ou 5".

C'est des réponses temporaires.

Le seul usage vraiment commun de ça, c'est l'upload de fichier.

En fait, quand vous uploadez un fichier via un navigateur web, généralement le navigateur envoie une requête pour dire voilà, je vais envoyer un fichier de 10Mo et le serveur a l'occasion de répondre avec une réponse 1 : ok, c'est bon, je vais l'accepter ou non, c'est trop gros, arrête toi là tout de suite.

Alors, pour améliorer les performances, les gens de chez Fastly à la base, si je ne dis pas de bêtises, ont décidé de proposer un nouveau code de statut qui va permettre de donner des indications très tôt dans le cycle de requêtes réponses HTTP au navigateur.

L'idée de base, c'est que nous, en tant que développeurs web, en tant que développeurs PHP, on sait que pour afficher la page, au final, en plus du HTML du blog, j'ai aussi besoin de ces deux feuilles de style CSS, de cette image-là et de ces 3000 JavaScript ici.

Donc, plutôt que d'attendre d'avoir fait toutes mes requêtes SQL etc et d'avoir envoyé tout le HTML, je pourrais notifier le navigateur tout de suite qu'il en a besoin pour que pendant cette attente, le navigateur télécharge ces éléments-là en parallèle.

Comme ça, une fois que tout est prêt, une fois que tout est téléchargé, je peux afficher tout de suite les éléments G+ et Cascade.

Je peux diminuer cette latence perçue.

C'est vraiment l'idée des codes 103.

C'est de pouvoir permettre au navigateur de télécharger en parallèle toutes les ressources liées qui seront au final nécessaires pour afficher les données à l'utilisateur.

Ça utilise des standards préexistants qu'on va couvrir très rapidement après, ils n'ont pas réinventé la roue.

Et attention, ça ne fonctionne qu'avec HTTP/2 et HTTP/3, donc avec HTTP/S.

En tout cas dans les navigateurs web de manière programmatique, ça peut aussi marcher avec HTTP/1.

Mais dans la vraie vie avec des vrais utilisateurs, il faut du HTTP/2 ou 3 pour que ce soit activé.

À la base, c'était une RFC qui a été proposée par Fastly en 2017, qui a toujours le statut expérimental, qui définit comment fonctionne ce nouveau code de statut.

Et, depuis quelques temps, ça a été déplacé dans le standard HTML.

Et donc maintenant ça fait partie du standard HTML qui est fait par le WHATWG et normalisé une fois de temps en temps par le W3C.

Donc, ça fait partie du corpus des standards du web.

Voyons comment ça marche.

Toujours le même exemple, un fichier index.html potentiellement généré par un script PHP qui a besoin, pour être affiché par le navigateur, d'une feuille de style common.css.

Le navigateur fait la requête tout de suite, immédiatement avant d'exécuter mes requêtes SQL, etc.

Le serveur va envoyer une réponse informative de code 103 qui indique qu'il y aura besoin de common.css.

Tout de suite en parallèle, en attendant le HTML généré par mon script PHP, le navigateur télécharge cette feuille de style.

Finalement, le HTML est généré, envoyé.

Il arrive au moment où le navigateur voit que en fait il faut utiliser la feuille de style common.css pour faire le rendu elle est déjà téléchargée et je peux le faire immédiatement, donc je réduis mes latences.

Typiquement, les 25 millisecondes qui, avant, venaient après la génération, elles ont été faites en parallèle, donc j'ai gagné 25 millisecondes en temps d'affichage.

Au niveau HTTP, comment ça fonctionne ? Là j'ai ma requête très similaire à celle d'avant, j'ai ma requête, j'ai ma réponse.

Sauf que vous voyez maintenant, j'ai une autre réponse entre les deux : requête, réponse temporaire qui est envoyée le plus tôt possible avec le code 103 Early Hints et un entête spécial Link qui référence quel est le fichier que je veux télécharger.

Bien sûr, je peux télécharger autant de fichiers que nécessaire et je peux envoyer plusieurs fois des requêtes 103 quand je détecte au fil de la progression, qu'en fait, je vais avoir besoin de truc en plus, je peux le faire au fil de l'eau.

La relation qui dit à quoi ça sert, il faut que je le préload et ça c'est pour les contraintes de security policy, c'est pour que le navigateur sache ce qu'il y a dedans et commence dans quel contexte ça doit être utilisé.

Donc là, c'est une feuille de style.

Dès que c'est reçu, le navigateur peut émettre la deuxième requête en parallèle.

Et puis ensuite, bon ben voilà, parallélisme.

Dès que j'ai le HTML, ça, ça va être soit en cours de téléchargement ou au mieux déjà téléchargé.

Je vais pouvoir l'utiliser. C'est clair jusque là ? Concrètement, il y a eu pas mal d'études qui ont été menées par Google, Cloudflare, Fastly qui ont fait ça ensemble et grosso modo, suivant les cas, pour ce qu'on appelle le largest content full paint, c'est à dire en gros le bloc principal de votre page.

Disons que sur un site e-commerce ici, c'est pas les menus etc, c'est mon produit avec sa description, son prix et sa photo.

Du coup, ça inclut vraiment, c'est du dessin dans le navigateur.

Donc s'il faut trois feuilles de style, une image et un JavaScript, il faut que tout ça soit téléchargé et que ce soit affiché.

Cette métrique, elle est très très utilisée pour le référencement.

En gros, Google va classer plus haut les sites dont le contenu principal est affiché le plus vite possible à l'utilisateur parce que bien sûr, ça améliore l'expérience utilisateur.

Bref, en utilisant ce code 103, Google, Shopify, etc, ont vu qu'en moyenne, on arrivait à améliorer la latence perçue à améliorer le LCP de 30 %.

Donc c'est quand même énorme.

Juste en ajoutant une petite réponse temporaire qui dit "tu vas avoir besoin de cette image de t-shirt, commence à la télécharger tout de suite plutôt que d'attendre que tout le HTML soit prêt".

Et donc, juste avec ça, on arrive à améliorer vraiment beaucoup les performances et à rendre les sites un peu plus rapides.

Alors bien sûr, si vous n'aviez pas 10 000 images et 100 000 feuilles de fichiers JavaScript, ça irait plus vite sans avoir besoin de tout ça.

Mais le fait est que c'est pas l'état du web actuel.

Alors, vous allez me dire est ce que tu n'avais pas déjà parlé d'un truc comme ça ? Une vieille version, une vieille édition du Forum PHP ? Il n'y avait pas un truc dans HTTP/2, c'était pas censé servir à ça, HTTP/2 ? Si, effectivement c'était censé servir à ça.

Google avait promu énormément une fonctionnalité qui s'appelait Serveur Push qu'ils ont fini par supprimer de Chrome en disant en fait c'est complexe, c'est pas très utilisé, ça peut être mal utilisé en fait, dégrader les performances.

Du coup, on va le supprimer et on va exhumer la vieille RFC de Fastly qui en fait est beaucoup plus simple et règle la plupart des problèmes.

Et voilà, utilisez ça, de toute façon, vous n'avez pas le choix.

Donc, j'avais fait un talk sur ce sujet que vous pouvez retrouver en ligne à l'AFUP Day, mais donc en gros, c'est un peu le remplacement moderne et plus simple de HTTP/2 server push, qui de toute façon, ne marche plus dans Google Chrome.

Alors, comment on fait pour utiliser ça dans nos applications PHP ? Déjà, il faut que l'utilisateur ait un navigateur compatible.

Actuellement les navigateurs compatibles, c'est les dérivés de Chromium qui ont tous activé ça au cours des derniers mois.

Ça date de cette année.

C'est quand même assez récent que ce soit présent dans les navigateurs.

Il y a aussi le support expérimental de ce code de statut dans Firefox et dans Safari, et ça devrait être mis dans les versions non expérimentales relativement prochainement.

De toute façon, les réponses 103 étant temporaires, les navigateurs les ignorent s'il ne connaissent pas le code de statut qui est renvoyé.

Donc, Chrome c'est malheureusement une grosse part de marché, donc ça va permettre d'accélérer les sites web chez pas mal de monde en attendant que Firefox et Safari rattraper leur retard là-dessus.

Et de toute façon, les envoyer, ça peut améliorer les performances sur Chrome et les envoyer, ça va être juste aussi lent qu'avant, mais pas plus lent qu'avant sur les navigateurs qui le supportent pas donc il y a vraiment tout intérêt à toujours envoyer ces codes de statut parce qu'il n'y a que des avantages, pas d'inconvénients.

Alors ensuite, si on veut faire marcher ça dans nos pages web, le plus simple pour le moment, c'est de le faire dans la config du serveur web directement.

C'est pas très pratique, mais c'est le plus simple.

Alors ça marche que vous soyez en PHP, en JavaScript, en Rails ou peu importe, ça fonctionne.

Avec Caddy, mon serveur web préféré, on peut le faire depuis un peu moins d'un an je crois.

On va définir un matcher qui dit "ok, toutes les requêtes qui sont HTTP/2 et dont le pass c'est ça".

Je veux que tu m'envoies le fichier CSS en Early Hints.

Et donc là c'est vraiment le serveur web qui va se charger de générer cette réponse temporaire.

Ça, ça marche.

Avec Apache, on peut aussi le faire.

C'est un peu une bidouille leur config, mais ceci dit, ça fonctionne.

Eux ils ont dit bon, on avait HTTP/2 server push.

En fait, c'est un peu la même chose.

Du coup, on va proposer une nouvelle directive qui permet de désactiver server push mais d'activer les Early Hints à la place et, on va juste surcharger le comportement de ce qu'on avait déjà.

Bon là du coup pareil, on met le nom du pass et le fichier qu'on veut pusher et grâce à ça, ça va envoyer un Early Hints plutôt qu'un serveur push.

Qui utilise Nginx ici ? C'est mort.

Pour l'instant, ce n'est pas supporté, en tout cas via la configuration comme ça par Nginx.

Alors, si on veut le faire en PHP, c'est quand même plus pratique de pouvoir gérer ça, de centraliser ça dans notre code PHP.

Ça peut être aussi pratique de pouvoir le faire de manière programmatique dans certains cas.

Pour tel article, je preload telle image par exemple, ça je ne vais pas pouvoir le hardcoder dans ma configuration de mon serveur web.

Alors Nikita a fait une pull request comme d'habitude, pour essayer d'ajouter ça dans PHP.

Voilà, comme d'habitude il contribuait l'essentiel des fonctionnalités de PHP.

Sauf que, en discutant de ça, on s'est rendu compte que de par le fonctionnement interne de PHP, ça n'allait pas fonctionner.

Malheureusement, le moteur d'exécution le plus populaire de PHP, c'est PHP FPM et, PHP FPM ne parle pas directement le HTTP.

En fait le navigateur web va faire une requête à un serveur web type Apache, Caddy, Nginx, etc qui va lui même la convertir dans un protocole un peu ancien qui s'appelle Fast CGI, qui va être envoyé à PHP FPM. PHP FPM va traiter la requête, envoyer une réponse Fast CGI qui va être elle-même passée au serveur web, qui va la convertir en réponse HTTP.

Là où on est embêté, c'est que dans la spécification Fast CGI, on dit une requête égale une réponse, pas plusieurs réponses.

Sauf que nous, là, on veut envoyer plusieurs réponses et ça ne fonctionne pas.

Il n'y a pas de solution, sauf patcher la spécification.

Bon courage, un truc de l'IETF, etc.

Et ensuite patcher toutes les implémentations pour pouvoir être en mesure de gérer ce code de statut avec PHP FPM.

On pourrait imaginer ce genre de hacks.

J'envoie ma première requête 103 Early Hints comme d'habitude, puis ensuite directement dans la connexion TCP.

Je fais à la main ma seconde réponse finale où je mets le texte de mon HTTP.

Effectivement, on pourrait l'imaginer.

Attention, par contre là c'est du HTTP/1.1 écrit en dur, mais HTTP/2, HTTP/3 c'est plus un protocole texte, c'est un protocole binaire.

Donc ça, ça ne veut rien dire en HTTP/2, en HTTP/3, ça va être envoyé directement dans le corps de la requête et du coup mon utilisateur final va voir ça s'afficher au lieu de son t-shirt qu'il veut acheter, ça va peut être pas être terrible.

Donc ça c'est un souci, d'autant plus que les Early Hints ne marchent qu'avec HTTP/2 ou 3 pas avec le 1.

Alors on pourrait penser à faire des trucs encore plus compliqués du genre, je configure mon serveur web pour ne mettre que du HTTP/2 et je mets un reverse proxy qui va convertir le HTTP/1 en HTTP/2 au dessus.

Ça, ça fonctionne, mais c'est un peu compliqué.

Bref.

Peut être qu'on peut faire mieux.

C'est l'une des raisons pour lesquelles on a bossé pas mal sur FrankenPHP.

FrankenPHP, lui est écrit en Go, il embarque l'exécuteur PHP, il est écrit en Go, il parle directement HTTP.

Et comme Go supporte ce code 103 Early hints, FrankenPHP est capable d'envoyer plusieurs réponses à une seule requête et peut envoyer sans problème du coup du code 103. Il n'y a plus le Fast CGI entre les deux qui nous embête.

Du coup, si votre moteur d'exécution est FrankenPHP vous pouvez juste créer votre première réponse, envoyer une réponse informative avec cette fonction qui est en fait celle qui a été proposée en termes d'API par Nikita tout à l'heure, qu'on a réimplémenté.

Et puis ensuite faire votre PHP comme d'habitude et à la fin PHP de manière transparente va générer la seconde réponse qui va réinclure ces entêtes parce que c'est nécessaire et faire tout le travail pour vous.

Donc ça, vous pouvez le faire dès aujourd'hui si vous utilisez FrankenPHP.

Si vous utilisez les composants Symfony type HTTP Foundation, ce qui est le cas de Laravel, Drupal et plein d'autres machins et que le moteur d'exécution est FrankenPHP, vous pouvez aussi depuis la version 6.3, envoyer des réponses temporaires avec la méthode sendHeaders et en passant 103 en paramètre, puis votre réponse finale, comme d'habitude c'est pareil, c'est complètement transparent.

Et si vous utilisez la version full stack de Symfony, là c'est encore mieux.

Le contrôleur par défaut de Symfony fournit un petit helper qui permet d'envoyer des requêtes 103 et donc vous pouvez utiliser cette nouvelle fonction send EarlyHints et le composant weblink pour référencer quel est le fichier que vous voulez envoyer.

Et ça va marcher dans le cas où vous utilisez PHP.

Attention à un truc avec ça.

Bien sûr, utilisez ça le plus tôt possible.

Si ici, là, avant d'appeler sendEarlyHints, je fais 2000 requêtes à Doctrine, ça ne va plus avoir beaucoup d'intérêt.

Faut vraiment que je le fasse assez tôt.

Et finalement, le mettre dans le serveur web, c'est pas si mal parce que ça permet de le faire même avant que je déclenche l'exécuteur PHP.

Voilà, suivant les cas, pour l'image, c'est bien là.

Pour le fichier CSS, c'est peut être pas plus mal de le faire dans le serveur web parce que je sais que pour cette URL j'aurais toujours ce fichier CSS, donc autant l'envoyer le plus tôt possible.

J'espère que ça vous a donné envie d'essayer en quelques lignes de config dans votre serveur web ou en utilisant FrankenPHP.

Vous pouvez aussi faire les deux.

Vous pouvez donc essayer de gagner énormément en temps d'affichage.

Et ça marche actuellement sur Chrome.

Merci à tous.

Merci.

On est court en temps malheureusement, on n'aura pas le temps de faire des questions, sauf si on a une question très précise et très rapide.

Et on partira en pause directement après.

Parce qu'il se fait faim quand même.

Merci.

Merci pour la conf.

On parlait de server push pour pré loader, pour pusher des ressources autres que du CSS et des images.

Est ce que c'est viable et pertinent d'envisager de pousser du JSON avec les Early Hints ? Il me semble que tu connais la réponse parce qu'il me semble que tu as une Pull Request sur Vulcain en cours d'attente pour permettre de faire ça.

Mais oui, complètement en fait.

On a discuté pas mal avec les équipes de Google au moment où serveur push a été supprimé parce que c'était pratique pour ce cas très front qu'on a vu là, mais aussi pour les API web, surtout les API hypermédia, avec des relations liées comme celles exposées par API Platform.

Et donc, quand ça a été implémenté dans Chrome, ça a été fait en collaboration avec les équipes de Google pour être en mesure de rendre ça aussi utilisable pour le cas des API Web.

Et il y a du boulot encore en cours, entre autre par Robin qui a déjà fait des patches qui restent plus qu'à finaliser et merger pour que Vulcain qui permet d'ajouter un reverse proxy qui permet d'utiliser ce genre de trucs au dessus d'une API web plutôt que pour du front, soit en mesure d'utiliser ça.

Donc oui, oui, complètement.

Là j'ai vraiment montré le cas front-end qui est le cas typique pour lequel c'est fait, mais ça pourra aussi où ça peut être aussi utilisé pour pour les API web et j'ai pas eu le temps d'en parler pendant la conférence, mais vu qu'on laisse encore un peu de temps, j'en profite.

Il y a quand même un gros avantage au code 103 par rapport aux serveurs push, c'est qu'il y a un échange de plus.

Avec server push qui était bien, c'est qu'on pouvait envoyer sans échange.

Voilà de quoi tu vas avoir besoin, alors que là il faut envoyer.

Ok, voilà la liste des choses dont tu vas avoir besoin et ensuite le navigateur doit faire une requête vers le fichier CSS, JS, etc.

Mais l'avantage par rapport à server push, c'est que dans server push on envoyait directement le contenu du CSS.

Et s'il était déjà en cache dans le navigateur parce que l'utilisateur revenait sur le site, on avait quand même envoyé pour rien les données, alors que là le navigateur va dire ok, tu as besoin de recevoir, tu as besoin de common.css, s'il a déjà dans le cache, il va juste rien faire parce qu'il l'a déjà.

Et ça même pour les API, ça va pouvoir être assez pratique parce que ça évite de consommer du temps de serveur pour rien, pour des choses qui sont déjà disponibles côté client.

Merci. On va passer à la pause.