Rapide par défaut

La vitesse ici n'est pas ajustée par projet ; c'est une propriété de l'architecture. Le site public est de simples fichiers statiques servis depuis le disque sans rendu par requête, avec un cache agressif et des charges utiles petites par construction. Cette page résume d'où vient la vitesse et quels réglages vous contrôlez.

Pas de rendu par requête

Vos visiteurs reçoivent les fichiers statiques publiés directement depuis le disque. L'application de rédaction ne rend jamais de pages publiques à la demande ; en production, elle est liée à une adresse loopback privée, si bien que les visiteurs ne peuvent tout simplement pas l'atteindre.

Un cache qui se livre avec la configuration d'origine

La configuration serveur d'exemple définit des durées de cache pour que votre déploiement soit rapide par défaut :

• Pages HTML: un court cache de 5 minutes avec must-revalidate, pour que le contenu fraîchement construit atteigne les lecteurs dans les minutes qui suivent un build.
• Polices: fichiers à contenu haché, mis en cache un an et marqués immutable.
• Autres assets statiques (CSS, JS, images, icônes), mis en cache un jour.
• Le service worker: explicitement pas mis en cache, pour qu'une copie périmée ne puisse jamais bloquer les mises à jour.
• Assets du dashboard d'admin : mis en cache un jour.

La compression (zstd et gzip) est activée côté serveur dans la configuration d'origine.

Des petites pages, générées à bon escient

L'étape de build fait au moment de la publication le travail que d'autres systèmes paient à l'exécution :

• Le HTML est minifié par défaut. Les espaces se replient dans chaque page construite (il y a un réglage si vous avez besoin d'une sortie non minifiée pour déboguer).
• Les images se chargent en différé automatiquement. Chaque image dépourvue d'indication de chargement reçoit loading="lazy" pendant le build.
• Les images se livrent avec des dérivés responsives. Quand vous téléversez une image, des copies redimensionnées à 320, 640 et 1280 px sont générées à la fois dans le format d'origine (JPEG ou PNG) et en WebP, et les templates reçoivent des attributs srcset tout faits pour que les visiteurs ne téléchargent que la taille dont ils ont besoin.

De la vitesse à la rédaction aussi

• Builds incrémentaux par défaut : les fichiers inchangés sont sautés par hachage de contenu, si bien que les rebuilds du quotidien sont rapides ; un rebuild complet reste disponible pour les jours où vous en voulez un.
• La base de données ne bloque jamais l'admin. SQLite tourne en mode WAL (les lectures concurrentes ne bloquent pas les écritures), ajusté avec un cache confortable pour la charge de travail attendue d'une session d'admin active plus des builds périodiques.
• Les builds restent bornés, et une sortie périmée vaut mieux qu'une sortie cassée : un build est plafonné en volume d'écriture et en temps (cinq minutes), et un build qui s'effondre (chute du nombre de pages, pic de liens, timeout) n'est pas promu ; le bon site précédent continue de servir.

Ce qui ne vous ralentit pas

Il n'y a pas de JavaScript à l'exécution sur la sortie publique : rien à récupérer, rien à exécuter, rien à différer, et aucun beacon à charger. Les pages de contenu ne sont que du balisage avec des optimisations enfournées au moment du build.