On a installé GetSimple CMS sur un serveur mutualisé poussif un lundi matin. Temps de réponse mesuré sur la page d’accueil : 42 millisecondes. Aucun plugin de cache, aucun CDN, aucune optimisation. Juste PHP qui lit trois fichiers texte, assemble un template, et répond. Le même gabarit sur un WordPress par défaut dépassait les 200 ms sur la même machine. La différence ne tient pas à « la qualité du code », mais à l’absence totale de connexion à une base de données. C’est le sujet de GetSimple : un CMS flat-file qui stocke les pages et les données en XML sur disque, sans jamais solliciter MySQL, MariaDB, ni SQLite. Pour les profils qui passent leur journée à pourchasser le LCP, ce simple choix d’architecture peut faire basculer un rapport PageSpeed de « médiocre » à « bon » avant même d’avoir minifié un seul fichier CSS.
GetSimple n’a pas de base de données : ce que ça change pour le TTFB
Le Time to First Byte (TTFB) est un indicateur qu’on analyse souvent mal. On accuse la bande passante, le PHP lent, le serveur mutualisé. Pourtant, dans une stack LAMP classique, le principal goulot n’est pas PHP lui-même, c’est le temps passé à établir la connexion, exécuter vingt ou quarante requêtes SQL, hydrater le modèle de données de WordPress, puis seulement assembler la page. Sur un site modeste, cette routine prend entre 80 et 200 ms. GetSimple la court-circuite entièrement.
À chaque requête d’une page, GetSimple ouvre quelques fichiers XML plats : les paramètres du site, la page demandée, le menu, la configuration du thème. La lecture est quasi-instantanée sur un disque SSD, et même sur un vieux disque mécanique, l’absence de round-trip réseau interne vers un socket SQL change la donne. On a mesuré un TTFB stable sous 50 ms sur un hébergement OVH mutualisé à 3 euros par mois, sans opcache activé. Activez l’opcache PHP, et le TTFB descend régulièrement sous 30 ms.
Ce n’est pas une astuce. C’est une conséquence mécanique de la suppression d’une couche entière de la pile logicielle. Moins de couches, moins de latence. Dans notre métier, on parle beaucoup de rendu côté client, de lazy-loading, de priorité de fetch, mais la base de la base reste le temps que le serveur met à sortir le premier octet. Si vous cherchez une piste pour réduire un TTFB supérieur à 200 ms sur un petit site, et que vous tournez encore sur un CMS base de données, GetSimple est une réponse plus immédiate que le tuning de innodb_buffer_pool_size.
Le revers, c’est que l’administration se fait par de simples opérations sur fichiers. Pas de JOIN, pas de tri complexe, pas de requête paramétrée. Tout ce qui ressemble à une recherche dynamique dépend de la taille des fichiers XML à scanner. Sur 50 pages, c’est imperceptible. Sur 2000, l’admin commence à grincer. Mais pour le visiteur, la page finale reste du HTML pur mis en cache interne, sans latence ajoutée.
Un LCP à moins de 2 secondes sans cache compliqué
On voit passer des checklist Core Web Vitals qui commencent par recommander un plugin de cache, puis un CDN, puis du fetchpriority="high" sur l’image d’en-tête. Tout ça part d’un postulat : le CMS est une usine à gaz qui régénère le HTML à chaque hit. Avec GetSimple, le HTML complet est assemblé et stocké en fichier cache dès la première visite, ou pré-chauffé via une tâche CRON. Le Largest Contentful Paint (LCP) tombe souvent sous la barre des 2,5 secondes sur des hébergements modestes, sans toucher à une seule ligne de configuration réseau.
Le phénomène est amplifié par le format des templates : des fichiers PHP légers, sans surcouche de template engine lourd. Les thèmes sont écrits en PHP procédural simple, avec des appels directs aux fonctions de l’API. Résultat : le serveur peut renvoyer le contenu principal et l’image LCP dans les premiers cycles, sans attendre la résolution de dépendances complexes. C’est là que le lien avec les principes généraux des Core Web Vitals devient concret : on mesure moins qu’on ne vérifie une architecture qui rend le LCP presque difficile à rater.
Bien sûr, le flat-file a ses limites. Dès que vous ajoutez une couche de cache externe comme Varnish ou un CDN, les différences entre CMS se tassent. Mais pour un site de 20 à 80 pages, la promesse de GetSimple tient : des performances excellentes sans jamais avoir à débugguer un cache qui ne s’invalide pas correctement, ni à expliquer au client pourquoi son panier reste vide à cause d’un fragment HTML périmé.
Le sitemap dynamique qui craque à 500 pages
GetSimple génère son sitemap XML à la volée en scannant tous les fichiers de contenu. Sur 50 pages, c’est instantané. Sur un site de test de 600 pages, le temps de génération est passé de 2 ms à plus de 400 ms. Googlebot télécharge un blob qui s’alourdit, et le timeout peut se déclencher avant la fin. La parade : segmenter le sitemap avec un script externe. Soit exactement le bricolage qu’on voulait fuir en quittant un CMS base de données.
L’extension qui détruit l’INP sans une ligne de JS
L’Interaction to Next Paint ne concerne pas que les frameworks JavaScript et les sliders. Un site GetSimple bien construit peut tenir un INP excellent, et une extension mal codée le tue, même en l’absence de JS lourd. Beaucoup de plugins injectent du contenu via des hooks PHP qui s’exécutent avant le rendu final. Si le hook ouvre un fichier XML par image, le DOM final devient plus lourd que prévu, et le thread principal galère côté client.
Cas réel : un plugin de formulaire qui générait du markup avec une quinzaine de <div> imbriquées et attachait des événements via un script non minifié. Délai de réponse de 320 ms au premier clic sur un champ texte. INP passé de 80 ms à plus de 300 ms. En désactivant le plugin et en remplaçant le formulaire par une include PHP écrite à la main, l’INP est redescendu sous 100 ms. Chaque extension GetSimple est à lire ligne par ligne avant déploiement.
Pour ce repérage, certains outils d’analyse statique intégrés dans un IDE moderne accélèrent la détection des hooks mal maîtrisés, dans le même esprit qu’un comparatif Claude Code vs Cursor IDE sur les environnements de développement.
Migration depuis WordPress : ce qu’on a gagné, ce qu’on a perdu
On a accompagné une TPE qui tenait son site de 35 pages sous WordPress avec un template acheté il y a six ans. Chaque mise à jour de plugin déclenchait une journée d’angoisse. Les Core Web Vitals étaient « à améliorer » depuis deux ans. Le TTFB moyen dépassait 300 ms même avec un cache lourd. On a migré vers GetSimple en une dizaine d’heures.
Ce qu’on a gagné :
- Un TTFB sous 40 ms immédiatement après la migration.
- La suppression définitive des soucis de compatibilité de plugins.
- Un fichier
robots.txtpropre, sans les traces de paramètres d’URL dynamiques. - Une courbe d’apprentissage administrative quasi nulle pour la cliente.
Ce qu’on a perdu :
- La gestion des utilisateurs avancée. GetSimple a un système de rôles basique.
- La génération automatique de miniatures configurables. Il faut le faire à la main ou via une extension choisie avec soin.
- L’écosystème de SEO plugins. Le SEO de base est bon, mais le contrôle granulaire des balises nécessite un minimum de code maison.
La perte la plus sensible reste la flexibilité du state management dès qu’on touche à du fonctionnel. On ne fait pas une SPA avec un CMS flat-file PHP. Pour un front-end interactif au-delà du formulaire, on bascule sur des stacks comme celles qu’on compare dans un guide sur le state management React avec Zustand, et GetSimple n’y a plus sa place.
GetSimple ne joue pas en Champions League
GetSimple ne concurrence ni Drupal ni un headless, et ne le revendique pas. Le bon usage : un site institutionnel de 30 pages, un portfolio, une landing de service. Les Core Web Vitals passent en « Bon » sans tuning, sans danse de la pluie sur un plugin de minification qui casse le CSS. Sous 200 pages, le flat-file est un choix d’architecture rationnel.
Questions fréquentes
GetSimple peut-il gérer un site multilingue ?
Pas nativement. Le flat-file ne propose pas de mécanisme standard de correspondance entre traductions. Il faut dupliquer les pages manuellement et gérer la navigation par menus distincts. Certains plugins communautaires ajoutent un semblant de multilinguisme, mais ils alourdissent l’administration et introduisent des fichiers XML supplémentaires. Pour une poignée de langues, ça passe. Pour un site international de plus de 5 langues, on sort du cadre.
Est-ce que le flat-file pose un problème pour les backups ?
L’avantage, c’est que l’intégralité du site tient dans un dossier. Un rsync ou une copie FTP suffit à sauvegarder le contenu, les templates et les settings. Pas de dump SQL séparé, pas d’incohérence entre fichiers et base de données. Le revers vient de l’absence de versioning natif. Si vous écrasez un fichier, le contenu précédent est perdu, sauf si vous couplez le dossier avec un dépôt Git. On recommande un git init dès la création du site, ce qui transforme le backup en historique de version complet.
Comment gérer les commentaires sans base de données ?
GetSimple ne propose pas de moteur de commentaires intégré. La solution la plus propre est d’intégrer un service tiers comme Isso ou un script externe qui écrit dans des fichiers plats séparés. Cela évite de charger le CMS principal avec une logique applicative pour laquelle il n’a pas été conçu. Si les commentaires sont un élément critique du projet, GetSimple n’est probablement pas le bon choix de départ.
