Un jour, par curiosité, vous passez votre site Odoo dans PageSpeed Insights. Le score s’affiche en rouge. 45. 38. Sur le forum officiel d’Odoo, certains rapportent 19 sur 100. Le réflexe est immédiat : on s’est fait avoir, ou l’intégrateur a bâclé le travail.
Ni l’un ni l’autre. Nous avons mesuré, chiffres à l’appui, ce qu’une page Odoo envoie réellement à votre visiteur. La cause est structurelle, elle est parfaitement logique — et il n’existe qu’une seule façon d’y échapper vraiment : coder la page soi-même.
1. Non, votre intégrateur n’a pas bâclé le travail
Le sujet revient en boucle sur le forum d’Odoo, et presque toujours sans réponse claire : « existe-t-il un site Odoo au-dessus de 60 sur mobile ? », « mon site a un mauvais score PageSpeed ». Les réponses tournent en rond — activez un CDN, compressez vos images — sans jamais nommer la cause réelle.
Cette cause n’a rien à voir avec votre thème, votre hébergeur ou la qualité de votre intégration. Elle est inscrite dans le fonctionnement même du module Website d’Odoo. Tant qu’on ne l’a pas comprise, on s’épuise à optimiser des détails qui ne déplaceront jamais l’aiguille de plus de quelques points.
💡 Ce qu’il faut retenir d’emblée
Un score PageSpeed bas sur Odoo n’est pas un défaut de fabrication ni une négligence. C’est le prix d’une fonctionnalité que vous avez sans doute exigée : pouvoir modifier votre site vous-même, en glisser-déposer, sans développeur.
2. Ce qu’une page Odoo envoie réellement
Assez de théorie. Nous avons mesuré notre propre serveur : Odoo 19, une seule instance, un seul nom de domaine, le même cache et le même CDN pour tout le monde. D’un côté une page Website standard (un simple formulaire de contact), de l’autre une page de services que nous servons différemment. Le protocole est trivial à reproduire : on récupère le HTML, on liste les <script src> et les feuilles de style, on pèse chaque fichier.
Voici ce que le navigateur doit télécharger, avant de pouvoir afficher quoi que ce soit :
📊 Page Odoo standard — le détail
web.assets_frontend_lazy.min.js — 2 318 Ko
web.assets_frontend.min.css — 809 Ko
web.assets_frontend_minimal.min.js — 30 Ko
Total imposé par Odoo : 3 157 Ko, répartis en 7 requêtes bloquantes.
À titre de comparaison, la page de services que vous lisez sur ce même serveur charge 25 Ko de CSS et zéro kilo-octet de JavaScript applicatif.
3. Pourquoi 3,1 Mo pour afficher un formulaire de contact ?
Parce qu’Odoo ne sait pas à l’avance ce que vous allez faire de cette page. Le bundle assets_frontend ne contient pas « le nécessaire pour afficher un formulaire ». Il contient tout ce dont un site Odoo pourrait avoir besoin : l’éditeur de contenu en direct, la bibliothèque complète de snippets, le panier et le tunnel de commande e-commerce, le portail client, les widgets de blog, les animations, les galeries d’images.
Ce paquet est assemblé une fois pour l’ensemble du site, puis servi sur chaque page publique, identiquement. Votre page « Mentions légales », qui ne contient que du texte, télécharge le moteur de e-commerce. Votre formulaire de contact télécharge l’éditeur de site. Le visiteur paie pour des fonctionnalités qu’il ne verra jamais.
Ce n’est pas absurde : c’est le contrat. Ce bundle est exactement ce qui vous permet de cliquer sur « Modifier », de déplacer un bloc à la souris et de publier sans appeler personne. La lourdeur n’est pas un bug, c’est la facture de l’autonomie.
💡 La conséquence directe
Aucun réglage, aucune option de configuration Odoo ne vous permettra de descendre significativement sous ces 3 Mo tant que la page passe par le gabarit standard du module Website. Le plafond est structurel.
4. Ce que Google mesure vraiment (et ce qu’il ignore)
Avant de paniquer, une mise au point qui vaut de l’argent : le score PageSpeed n’est pas une note attribuée par Google à votre référencement. C’est le résultat d’un test de laboratoire, exécuté sur un mobile volontairement bridé et une connexion volontairement lente. Il sert à diagnostiquer, pas à sanctionner.
Ce que Google utilise réellement dans son classement, ce sont les Core Web Vitals mesurés sur vos vrais visiteurs — leurs vrais téléphones, leur vraie connexion, souvent avec vos fichiers déjà en cache. Ces chiffres-là sont systématiquement meilleurs que le score de laboratoire. Et même eux ne pèsent qu’au titre de départage entre deux résultats de qualité équivalente : un contenu médiocre et rapide ne passera jamais devant un contenu excellent et lent.
Autrement dit : un score rouge ne vous fait pas disparaître de Google. En revanche, il coûte cher là où c’est mesurable — le taux de rebond et la conversion. Sur une landing page qui reçoit du trafic publicitaire payant, chaque seconde d’attente se paie en visiteurs perdus. C’est là, et pas dans le classement, que se situe le vrai enjeu.
⚔️ Le Match : page Odoo standard vs page codée sur-mesure
| Critère | Page Website standard | Page codée sur-mesure |
|---|---|---|
| Poids JS + CSS | 3 157 Ko | 25 Ko |
| Requêtes bloquantes | 7 | 3 |
| JavaScript inutilisé | L’essentiel du bundle | Aucun |
| Modification par le client | Glisser-déposer, autonome | Passe par un développeur |
| Cas d’usage idéal | Pages internes, contenu vivant | Landing pages, pages stratégiques |
Mesures relevées sur une même instance Odoo 19, même domaine, même CDN. Le total réel de la page standard atteint 3 654 Ko une fois les outils de mesure d’audience ajoutés.
5. Les demi-mesures, et où elles s’arrêtent
Les conseils habituels ne sont pas faux, ils sont simplement plafonnés. Il faut les appliquer — ils sont peu coûteux — mais en sachant ce qu’ils rapportent :
Un CDN et un cache correct : le gain le plus rentable. Vos 3 Mo voyagent moins loin et sont réutilisés d’une page à l’autre. Le premier affichage reste lourd, les suivants deviennent confortables.
Désinstaller les modules Website inutiles : chaque module actif ajoute sa part au bundle. Un site vitrine qui traîne le e-commerce sans l’utiliser peut alléger réellement. Gain typique : quelques centaines de kilo-octets.
Compresser les images et activer le chargement différé : indispensable, et souvent le premier vrai coupable du Largest Contentful Paint. Mais cela ne touche pas d’un gramme aux 3 157 Ko de code.
Additionnez tout : vous gagnez dix à vingt points. Vous passez du rouge à l’orange. Vous ne passerez pas au vert, parce que le socle ne bouge pas.
💡 Méfiez-vous des promesses d’« optimisation Odoo »
De nombreuses offres promettent 90/100 sur un site Odoo standard sans jamais expliquer comment. Demandez toujours quelle est la stratégie sur le bundle assets_frontend. Si la réponse ne mentionne ni son contenu ni la façon de s’en passer, il n’y a pas de stratégie.
6. La seule vraie solution : coder la page
Si le poids vient du gabarit standard, alors la seule sortie consiste à ne pas passer par ce gabarit. Concrètement : un module Odoo qui déclare ses propres routes et renvoie directement le HTML de la page, sans jamais invoquer le layout du module Website. Aucun bundle n’est injecté, parce qu’aucun bundle n’est demandé.
C’est exactement ce que nous avons développé pour nos propres pages de services, après avoir constaté qu’aucun réglage ne nous ferait descendre sous les 3 Mo. Le résultat est la colonne de droite du tableau ci-dessus : 25 Ko de CSS écrit à la main, servi sur sa propre route avec son propre cache, et strictement rien d’autre.
Le point important, et c’est ce qui distingue une vraie solution d’un bricolage : on ne sort pas d’Odoo pour autant. La page reste servie par Odoo, sur le même domaine, avec le routage natif. Elle apparaît dans le sitemap.xml. Elle conserve le suivi de visiteurs intégré, donc les statistiques continuent d’alimenter le CRM. Le contenu vit dans un modèle Odoo, administrable depuis le back-office comme n’importe quelle donnée. On garde l’ERP, on choisit simplement ce qui part chez le visiteur.
💡 Le principe technique en une phrase
Une route qui retourne une réponse HTML construite par le module, plutôt qu’un rendu passant par le gabarit du module Website : c’est ce seul choix d’architecture qui fait passer une page de 3 157 Ko à 25 Ko.
7. Ce que vous perdez — parce qu’il faut le dire
Une page servie hors du gabarit standard n’est plus modifiable en glisser-déposer. Plus de bouton « Modifier », plus de snippets à déplacer à la souris. Chaque évolution passe par un développeur. C’est un vrai coût, et quiconque vous vend cette approche sans le mentionner vous vend mal.
D’où la seule règle qui vaille : ne codez pas tout, codez ce qui compte. Vos pages internes, vos actualités, tout ce qui change souvent et se pilote au fil de l’eau : gardez l’éditeur Odoo, c’est précisément son intérêt. Vos pages stratégiques — celles qui reçoivent la publicité, celles qui portent la conversion, celles qu’on partage — méritent d’être codées.
C’est un arbitrage page par page, pas une religion. Sur notre propre site, les deux approches cohabitent sur la même instance.
Le Verdict : le score bas n’est pas une fatalité, c’est un arbitrage
Un site Odoo lent n’est pas un site raté : c’est un site qui a payé en performance le confort de l’édition autonome. Sur la majorité de vos pages, c’est un excellent marché. Sur celles qui portent votre chiffre d’affaires, c’en est un mauvais — et la seule façon de renverser la table, c’est de reprendre la main sur ce que la page envoie.
Vous voulez savoir ce que vos pages pèsent réellement, et lesquelles justifient d’être reprises ? C’est le point de départ de notre audit, et le terrain quotidien de notre travail de développement sur-mesure.
Un jour, par curiosité, vous passez votre site Odoo dans PageSpeed Insights. Le score s’affiche en rouge. 45. 38. Sur le forum officiel d’Odoo, certains rapportent 19 sur 100. Le réflexe est immédiat : on s’est fait avoir, ou l’intégrateur a bâclé le travail.
Ni l’un ni l’autre. Nous avons mesuré, chiffres à l’appui, ce qu’une page Odoo envoie réellement à votre visiteur. La cause est structurelle, elle est parfaitement logique — et il n’existe qu’une seule façon d’y échapper vraiment : coder la page soi-même.
1. Non, votre intégrateur n’a pas bâclé le travail
Le sujet revient en boucle sur le forum d’Odoo, et presque toujours sans réponse claire : « existe-t-il un site Odoo au-dessus de 60 sur mobile ? », « mon site a un mauvais score PageSpeed ». Les réponses tournent en rond — activez un CDN, compressez vos images — sans jamais nommer la cause réelle.
Cette cause n’a rien à voir avec votre thème, votre hébergeur ou la qualité de votre intégration. Elle est inscrite dans le fonctionnement même du module Website d’Odoo. Tant qu’on ne l’a pas comprise, on s’épuise à optimiser des détails qui ne déplaceront jamais l’aiguille de plus de quelques points.
💡 Ce qu’il faut retenir d’emblée
Un score PageSpeed bas sur Odoo n’est pas un défaut de fabrication ni une négligence. C’est le prix d’une fonctionnalité que vous avez sans doute exigée : pouvoir modifier votre site vous-même, en glisser-déposer, sans développeur.
2. Ce qu’une page Odoo envoie réellement
Assez de théorie. Nous avons mesuré notre propre serveur : Odoo 19, une seule instance, un seul nom de domaine, le même cache et le même CDN pour tout le monde. D’un côté une page Website standard (un simple formulaire de contact), de l’autre une page de services que nous servons différemment. Le protocole est trivial à reproduire : on récupère le HTML, on liste les <script src> et les feuilles de style, on pèse chaque fichier.
Voici ce que le navigateur doit télécharger, avant de pouvoir afficher quoi que ce soit :
📊 Page Odoo standard — le détail
web.assets_frontend_lazy.min.js — 2 318 Ko
web.assets_frontend.min.css — 809 Ko
web.assets_frontend_minimal.min.js — 30 Ko
Total imposé par Odoo : 3 157 Ko, répartis en 7 requêtes bloquantes.
À titre de comparaison, la page de services que vous lisez sur ce même serveur charge 25 Ko de CSS et zéro kilo-octet de JavaScript applicatif.
3. Pourquoi 3,1 Mo pour afficher un formulaire de contact ?
Parce qu’Odoo ne sait pas à l’avance ce que vous allez faire de cette page. Le bundle assets_frontend ne contient pas « le nécessaire pour afficher un formulaire ». Il contient tout ce dont un site Odoo pourrait avoir besoin : l’éditeur de contenu en direct, la bibliothèque complète de snippets, le panier et le tunnel de commande e-commerce, le portail client, les widgets de blog, les animations, les galeries d’images.
Ce paquet est assemblé une fois pour l’ensemble du site, puis servi sur chaque page publique, identiquement. Votre page « Mentions légales », qui ne contient que du texte, télécharge le moteur de e-commerce. Votre formulaire de contact télécharge l’éditeur de site. Le visiteur paie pour des fonctionnalités qu’il ne verra jamais.
Ce n’est pas absurde : c’est le contrat. Ce bundle est exactement ce qui vous permet de cliquer sur « Modifier », de déplacer un bloc à la souris et de publier sans appeler personne. La lourdeur n’est pas un bug, c’est la facture de l’autonomie.
💡 La conséquence directe
Aucun réglage, aucune option de configuration Odoo ne vous permettra de descendre significativement sous ces 3 Mo tant que la page passe par le gabarit standard du module Website. Le plafond est structurel.
4. Ce que Google mesure vraiment (et ce qu’il ignore)
Avant de paniquer, une mise au point qui vaut de l’argent : le score PageSpeed n’est pas une note attribuée par Google à votre référencement. C’est le résultat d’un test de laboratoire, exécuté sur un mobile volontairement bridé et une connexion volontairement lente. Il sert à diagnostiquer, pas à sanctionner.
Ce que Google utilise réellement dans son classement, ce sont les Core Web Vitals mesurés sur vos vrais visiteurs — leurs vrais téléphones, leur vraie connexion, souvent avec vos fichiers déjà en cache. Ces chiffres-là sont systématiquement meilleurs que le score de laboratoire. Et même eux ne pèsent qu’au titre de départage entre deux résultats de qualité équivalente : un contenu médiocre et rapide ne passera jamais devant un contenu excellent et lent.
Autrement dit : un score rouge ne vous fait pas disparaître de Google. En revanche, il coûte cher là où c’est mesurable — le taux de rebond et la conversion. Sur une landing page qui reçoit du trafic publicitaire payant, chaque seconde d’attente se paie en visiteurs perdus. C’est là, et pas dans le classement, que se situe le vrai enjeu.
⚔️ Le Match : page Odoo standard vs page codée sur-mesure
| Critère | Page Website standard | Page codée sur-mesure |
|---|---|---|
| Poids JS + CSS | 3 157 Ko | 25 Ko |
| Requêtes bloquantes | 7 | 3 |
| JavaScript inutilisé | L’essentiel du bundle | Aucun |
| Modification par le client | Glisser-déposer, autonome | Passe par un développeur |
| Cas d’usage idéal | Pages internes, contenu vivant | Landing pages, pages stratégiques |
Mesures relevées sur une même instance Odoo 19, même domaine, même CDN. Le total réel de la page standard atteint 3 654 Ko une fois les outils de mesure d’audience ajoutés.
5. Les demi-mesures, et où elles s’arrêtent
Les conseils habituels ne sont pas faux, ils sont simplement plafonnés. Il faut les appliquer — ils sont peu coûteux — mais en sachant ce qu’ils rapportent :
Un CDN et un cache correct : le gain le plus rentable. Vos 3 Mo voyagent moins loin et sont réutilisés d’une page à l’autre. Le premier affichage reste lourd, les suivants deviennent confortables.
Désinstaller les modules Website inutiles : chaque module actif ajoute sa part au bundle. Un site vitrine qui traîne le e-commerce sans l’utiliser peut alléger réellement. Gain typique : quelques centaines de kilo-octets.
Compresser les images et activer le chargement différé : indispensable, et souvent le premier vrai coupable du Largest Contentful Paint. Mais cela ne touche pas d’un gramme aux 3 157 Ko de code.
Additionnez tout : vous gagnez dix à vingt points. Vous passez du rouge à l’orange. Vous ne passerez pas au vert, parce que le socle ne bouge pas.
💡 Méfiez-vous des promesses d’« optimisation Odoo »
De nombreuses offres promettent 90/100 sur un site Odoo standard sans jamais expliquer comment. Demandez toujours quelle est la stratégie sur le bundle assets_frontend. Si la réponse ne mentionne ni son contenu ni la façon de s’en passer, il n’y a pas de stratégie.
6. La seule vraie solution : coder la page
Si le poids vient du gabarit standard, alors la seule sortie consiste à ne pas passer par ce gabarit. Concrètement : un module Odoo qui déclare ses propres routes et renvoie directement le HTML de la page, sans jamais invoquer le layout du module Website. Aucun bundle n’est injecté, parce qu’aucun bundle n’est demandé.
C’est exactement ce que nous avons développé pour nos propres pages de services, après avoir constaté qu’aucun réglage ne nous ferait descendre sous les 3 Mo. Le résultat est la colonne de droite du tableau ci-dessus : 25 Ko de CSS écrit à la main, servi sur sa propre route avec son propre cache, et strictement rien d’autre.
Le point important, et c’est ce qui distingue une vraie solution d’un bricolage : on ne sort pas d’Odoo pour autant. La page reste servie par Odoo, sur le même domaine, avec le routage natif. Elle apparaît dans le sitemap.xml. Elle conserve le suivi de visiteurs intégré, donc les statistiques continuent d’alimenter le CRM. Le contenu vit dans un modèle Odoo, administrable depuis le back-office comme n’importe quelle donnée. On garde l’ERP, on choisit simplement ce qui part chez le visiteur.
💡 Le principe technique en une phrase
Une route qui retourne une réponse HTML construite par le module, plutôt qu’un rendu passant par le gabarit du module Website : c’est ce seul choix d’architecture qui fait passer une page de 3 157 Ko à 25 Ko.
7. Ce que vous perdez — parce qu’il faut le dire
Une page servie hors du gabarit standard n’est plus modifiable en glisser-déposer. Plus de bouton « Modifier », plus de snippets à déplacer à la souris. Chaque évolution passe par un développeur. C’est un vrai coût, et quiconque vous vend cette approche sans le mentionner vous vend mal.
D’où la seule règle qui vaille : ne codez pas tout, codez ce qui compte. Vos pages internes, vos actualités, tout ce qui change souvent et se pilote au fil de l’eau : gardez l’éditeur Odoo, c’est précisément son intérêt. Vos pages stratégiques — celles qui reçoivent la publicité, celles qui portent la conversion, celles qu’on partage — méritent d’être codées.
C’est un arbitrage page par page, pas une religion. Sur notre propre site, les deux approches cohabitent sur la même instance.
Le Verdict : le score bas n’est pas une fatalité, c’est un arbitrage
Un site Odoo lent n’est pas un site raté : c’est un site qui a payé en performance le confort de l’édition autonome. Sur la majorité de vos pages, c’est un excellent marché. Sur celles qui portent votre chiffre d’affaires, c’en est un mauvais — et la seule façon de renverser la table, c’est de reprendre la main sur ce que la page envoie.
Vous voulez savoir ce que vos pages pèsent réellement, et lesquelles justifient d’être reprises ? C’est le point de départ de notre audit, et le terrain quotidien de notre travail de développement sur-mesure.