Compression des fichiers statiques
Depuis Lagoon 4.0, la compression des fichiers statiques est déléguée au pipeline static web assets du SDK .NET, et le toolkit remplace les réglages par défaut de celui-ci :
| Étape | Formats par défaut du SDK | Formats retenus par Lagoon |
|---|---|---|
| Build | gzip | aucun |
| Publication | gzip + brotli | brotli uniquement |
Ne produire que du Brotli allège sensiblement le livrable, mais ce format n'est négocié par les navigateurs que sur une origine sécurisée : en HTTPS, ou sur http://localhost. Sur une origine http:// distante, le navigateur n'annonce que gzip, deflate et ne peut donc recevoir aucune des variantes publiées.
Application fonctionnant en HTTP
Si l'application doit pouvoir être exécutée en HTTP, ajoutez LagoonDefaultCompression au fichier Directory.Build.props de la solution.
<Project>
<PropertyGroup>
<LagoonDefaultCompression>false</LagoonDefaultCompression>
</PropertyGroup>
</Project>
Cette propriété rend la main au SDK, qui rétablit alors ses formats par défaut : gzip au build, gzip et brotli à la publication. Le navigateur reçoit ainsi la variante gzip en HTTP et la variante Brotli en HTTPS.
Créez le fichier Directory.Build.props à la racine de la solution s'il n'existe pas encore.
C'est la seule propriété à poser, mais elle est indispensable. Par défaut, Lagoon ne publie que la variante .br de chaque fichier compressé : l'original est supprimé et MapStaticAssets le restitue par négociation de contenu — sur l'application de démonstration Draft, le dossier wwwroot publié passe ainsi de 23,8 Mo à 10,4 Mo. Un client qui n'accepte pas Brotli n'a alors rien à recevoir : le serveur renvoie 404 Not Found ou un corps vide, sans erreur explicite, et l'application ne démarre pas. LagoonDefaultCompression à false rétablit les variantes gzip et conserve les fichiers non compressés.
Les fichiers que le runtime Lagoon lit directement sur le disque ne sont jamais compressés et restent donc toujours présents, quelle que soit la configuration : les gabarits _vroot/index*.html et _content/Lagoon.UI/login-callback.html, les favicon*.ico, service-worker-assets.js et service-worker.js.
Pourquoi dans Directory.Build.props et pas dans un .csproj
Chaque projet possédant des fichiers statiques compresse son propre dossier wwwroot pendant son propre build, et une propriété définie dans un .csproj ne se propage pas aux projets référencés. Placée dans un seul .csproj, la propriété laisserait donc les autres projets de la solution produire des variantes incohérentes. Directory.Build.props est hérité par tous les projets de la solution : c'est le seul emplacement qui garantit un réglage homogène.
Le fichier compte autant que la propriété : les fichiers de compilation du toolkit sont importés avant Directory.Build.targets, où la valeur arriverait trop tard pour être lue.
Vérifier le résultat
Après publication, interrogez un fichier statique en faisant varier l'en-tête Accept-Encoding :
# Client acceptant Brotli
curl -s -D - -o /dev/null -H "Accept-Encoding: br" http://localhost:5000/_content/Lagoon.UI/js/app-init.js
# Client ne l'acceptant pas
curl -s -D - -o /dev/null -H "Accept-Encoding: identity" http://localhost:5000/_content/Lagoon.UI/js/app-init.js
La première requête doit renvoyer 200 OK avec l'en-tête Content-Encoding: br. La seconde doit renvoyer 200 OK sans en-tête Content-Encoding et avec un corps non vide : si elle renvoie 404 Not Found ou Content-Length: 0, la variante non compressée a été supprimée à la publication, et l'application ne fonctionnera pas en HTTP. Vérifiez alors que LagoonDefaultCompression figure bien dans le Directory.Build.props de la solution.