Réglages de performance

La section Performance dans /settings/general contrôle comment l'admin interroge la collection posts dans le backend. Il y a un toggle et il a des implications réelles pour les sites avec des milliers de posts.

Mode de pagination

Deux modes :

global (par défaut)

Une souscription live unique sur toute la collection posts. L'admin garde chaque post en mémoire dans CmsDataContext et fait les filtres / pagination / comptages côté client. Pas d'index composite requis — fonctionne sur une base fraîche.

Avantages :

• Mises à jour temps réel — chaque liste de posts reflète instantanément les changements d'autres admins
• Pas de configuration d'index — fonctionne dès la création de la base
• Comptages in-memory — les comptages de sélection bulk-action sont gratuits
• Recherche rapide — la recherche tourne sur le corpus en mémoire, pas de lectures supplémentaires

Inconvénients :

• Le coût mémoire scale avec le nombre de posts — à 5 000+ posts, la liste en mémoire ralentit l'admin
• Le chargement initial lit tous les posts — le premier login admin paye le coût round-trip (~5-10 s pour 5 000 posts sur une connexion typique)

paginated

Souscriptions paginées par curseur, une page à la fois. L'admin fetche uniquement les posts visibles sur la page courante. Les comptages passent par des requêtes d'agrégation backend (single-read chacune).

Avantages :

• Faible empreinte mémoire — quelle que soit la taille du site
• Chargement initial rapide — peu importe que vous ayez 100 ou 100 000 posts

Inconvénients :

• Pas de mises à jour temps réel sur les autres pages — vous voyez les changements de la page courante, mais une autre page peut être stale
• Index composites requis — (type, createdAt) et (type, status, createdAt) pour Firestore
• Comptages plus coûteux — chaque comptage est une requête backend
• Recherche plus lente — bascule sur un fetch one-shot du corpus complet en mode recherche, puis filtre client-side

Quand basculer

Restez en global si :

• Votre site a moins de 5000 posts
• Vous voulez la simplicité (zéro setup d'index)
• Vous voulez des mises à jour temps réel

Passez à paginated si :

• Vous avez ou prévoyez 5000+ posts
• L'admin commence à ramer au chargement initial
• Vous acceptez l'overhead de gestion des index composites

Index Firestore composites

En mode paginated (mode Firebase uniquement — SQLite ne demande pas d'index), vous devez créer manuellement deux index composites :

Collection: posts
Field 1: type, Ascending
Field 2: createdAt, Descending

Collection: posts
Field 1: type, Ascending
Field 2: status, Ascending
Field 3: createdAt, Descending

Trois façons de les créer :

• Manuellement : Firebase Console → Firestore → Indexes → Add index
• Via firestore.indexes.json + firebase deploy : pour les workflows développeur
• Via le FirestoreSetupGate in-admin : l'admin détecte les index manquants au premier login et propose un lien direct vers la Firebase Console pour les créer

Une fois créés, les index prennent quelques secondes à se construire. Pendant la construction, les requêtes paginées renvoient un failed-precondition — l'admin attend et retente automatiquement.

Search en mode paginated

En mode paginated, taper dans la barre de recherche déclenche un fetch one-shot de tous les posts (mise en cache 30 s pour éviter de re-fetcher entre keystrokes). La recherche filtre ensuite côté client sur titre + slug + extrait.

Donc la recherche reste fonctionnelle mais coûte une lecture complète au premier query. C'est acceptable pour un usage occasionnel ; pas pour un workflow où vous cherchez à chaque édition.

Pagination size

Indépendant du mode de pagination, ce réglage contrôle le nombre de posts par page dans les listes (Posts, Pages). Par défaut : 25. Augmenter ralentit le rendu de chaque page ; diminuer multiplie les clics de pagination.

Pour un site avec moins de 100 posts, mettre 100 vous donne tout en une seule page. Pour un site avec 10 000 posts, gardez 25-50.

Cache de recherche

La recherche garde un cache 30 s du corpus fetché. Si vous éditez un post puis re-cherchez dans les 30 s, vous voyez la version pré-édit. C'est volontaire — sinon chaque keystroke coûterait une lecture complète.

Pour invalider le cache, cliquez ailleurs et revenez à la recherche (le composant recompute le useEffect qui invalide le cache à la prochaine entrée dans la recherche). Ou attendez 30 s.