Des performances web réelles, pour de vrai
Dans les moindres détails.

Non. Nous visons le meilleur résultat durable pour votre site, en conservant ses contenus et ses fonctionnalités. Le score de laboratoire dépend aussi des conditions du test et des ressources tierces : viser 100 à tout prix peut conduire à des compromis qui n’apportent pas grand-chose à ceux qui utilisent le site.

Nous partons des goulots d’étranglement, fixons les priorités et vérifions l’effet de nos modifications sur les pages et les parcours les plus importants. Nous évaluons le chargement, la stabilité et la réactivité avec les données de terrain, pour apporter des bénéfices concrets même quand l’appareil est moins puissant ou que la connexion ralentit.

Oui. Nous travaillons sur WordPress, WooCommerce, PrestaShop, Magento, Joomla, Drupal et des applications sur mesure. Nous adaptons le travail à l’architecture du projet, en tenant compte des thèmes, des plugins, des modules, des intégrations et de la façon dont les pages sont générées.

L’analyse porte sur les parcours qui comptent pour votre activité : navigation dans le catalogue, recherche, filtres, panier, tunnel de commande et envoi de formulaires. Sur les systèmes sur mesure, nous examinons aussi la relation entre le code applicatif, la base de données et l’infrastructure. Nous identifions ainsi les modifications les plus utiles et vérifions leur effet sur les fonctionnalités concernées, au lieu de nous arrêter au seul résultat de la page d’accueil.

Nous en décidons après l’analyse. Nous partons de votre infrastructure actuelle pour comprendre ce qui freine le site et ce qui peut être amélioré par une configuration plus efficace. Les caches et les CDN peuvent faire partie de la solution lorsqu’ils accélèrent réellement la distribution des contenus et répondent aux besoins de l’application.

Nous examinons les temps de réponse, les ressources disponibles, le comportement du cache et les pages dynamiques. Si nous trouvons des limites qui empêchent d’atteindre les objectifs, nous expliquons quels changements nous recommandons et pourquoi. Une éventuelle décision de changer d’hébergement repose donc sur des éléments techniques, avec une attention particulière à la continuité du service.

Les premiers effets peuvent être vérifiés par des tests contrôlés dès que les modifications sont appliquées. Nous comparons les pages avant et après, dans des conditions comparables, et vérifions aussi que les menus, les formulaires et les parcours de commande continuent de fonctionner correctement.

Les données CrUX de PageSpeed Insights, en revanche, reflètent une fenêtre glissante de 28 jours : les anciens résultats sont progressivement remplacés par de nouvelles expériences utilisateur. C’est pourquoi l’amélioration sur le terrain n’apparaît pas forcément d’un seul coup. Les délais et les priorités dépendent de la complexité du projet, des intégrations en place et de la présence de données suffisantes pour évaluer la tendance.

Les données CrUX décrivent l’expérience d’utilisateurs réels de Chrome, sur différents appareils et connexions. Dans PageSpeed Insights, elles couvrent les 28 derniers jours et sont disponibles lorsque l’échantillon est suffisamment large. Les données LABS, à l’inverse, proviennent d’un test Lighthouse dans des conditions contrôlées : elles aident à identifier les causes des ralentissements et à vérifier immédiatement les modifications.

Nous les analysons ensemble : CrUX montre ce qui se passe sur le terrain, tandis que les tests de laboratoire aident à comprendre où intervenir. Un bon résultat dans l’un ne rend pas l’autre inutile. Comment Google distingue données de terrain et de laboratoire ↗

Un cache web est un excellent point de départ : il peut réduire le travail du serveur et le temps nécessaire pour renvoyer une page déjà générée. Le navigateur doit cependant toujours télécharger les ressources, exécuter le JavaScript et construire l’interface. Des images lourdes, des scripts tiers et une mise en page instable peuvent ralentir l’expérience même avec une réponse serveur très rapide.

De plus, le panier, le tunnel de commande, les espaces privés et les contenus personnalisés peuvent nécessiter des traitements que le cache de page ne couvre pas. Nous vérifions donc à la fois les réponses servies par le cache et celles générées par l’application, et nous intervenons aussi sur ce qui reste à faire au navigateur.

Un score supérieur à 90 est un bon signe, mais il ne décrit pas toute l’expérience de navigation. WP Rocket, FlyingPress, LiteSpeed Cache et WP-Optimize proposent des options pour retarder le JavaScript jusqu’à l’interaction de l’utilisateur. Le test initial peut alors mesurer une page plus légère, tandis qu’une partie du travail est effectuée au premier toucher ou au premier défilement. Retarder peut être utile, mais il faut aussi vérifier ce qui se passe après le clic.

La documentation de LiteSpeed sur la Guest Optimization décrit aussi des optimisations sélectives pour certaines requêtes, notamment celles de PageSpeed Insights, des bots et des premières visites, et avertit qu’elles peuvent masquer de vrais problèmes. Exclure des ressources uniquement pour un outil de test peut produire des résultats non représentatifs : c’est différent du simple report des scripts et cela doit être vérifié sur la configuration réelle.

Nous comparons donc les ressources, les fonctionnalités et les temps avant et après l’interaction, avec les données CrUX. L’objectif est de réduire le travail que le site effectue réellement, sans cacher les ralentissements derrière un chiffre vert.

Les interventions commencent à environ 600 € HT, selon le CMS, la complexité du site et les activités nécessaires. Un site vitrine, une boutique e-commerce et un portail d’information peuvent demander des analyses et des modifications très différentes : templates, intégrations, code sur mesure et état de l’infrastructure, tout compte.

Le travail est toujours défini sur la base d’un devis, avec un périmètre convenu et des priorités claires. Nous évaluons le projet avant de confirmer le coût, en précisant les interventions prévues et les vérifications incluses. Le prix de départ est donc une référence indicative, pas un forfait valable pour n’importe quel site.

Nous ne nous arrêtons pas à la page d’accueil. Nous sélectionnons des pages représentatives des différents types de pages du site : articles, catégories, fiches produit, recherche et parcours de commande. De nombreux ralentissements dépendent de templates, de composants ou de ressources partagés : les corriger à la source peut étendre le bénéfice à toutes les pages qui les utilisent.

Le périmètre est défini pendant l’analyse, en distinguant les modifications communes des problèmes propres à certaines sections. Sur une archive très volumineuse, inutile de traiter chaque URL à la main : nous vérifions les templates partagés, les exceptions et les fonctionnalités dynamiques. Le résultat est évalué sur un échantillon significatif, sans considérer la seule page d’accueil comme représentative de tout le projet.

L’objectif est de maintenir le site en fonctionnement et de planifier les modifications en fonction de son activité. Lorsqu’un environnement de staging est disponible et adapté aux tests, nous l’utilisons pour essayer les modifications avant de les publier. Les modifications les plus délicates sont planifiées en tenant compte du trafic, des commandes et des mises à jour éditoriales.

Avant la mise en production, nous définissons les vérifications et les procédures de retour arrière nécessaires. Si une activité exige une fenêtre de maintenance, nous le signalons et la planifions avec vous. Après la publication, nous vérifions le comportement en production, y compris le cache, les intégrations et les principaux parcours : la continuité de l’activité compte autant que de meilleures performances.

Oui. Travailler avec ceux qui connaissent déjà le site nous aide à comprendre les choix applicatifs, les personnalisations et les contraintes du projet. Nous partageons les problèmes constatés et convenons des priorités, des responsabilités et de la manière de procéder, en reliant le travail sur le code aux besoins de l’infrastructure.

Nous convenons de qui applique les modifications et de la façon de les vérifier, en respectant le flux de développement et de mise en production déjà en place. Nous pouvons accompagner l’équipe dans le diagnostic et la validation des modifications, en documentant les choix techniques. L’objectif : un site plus efficace, avec des indications utiles pour ceux qui continueront à le développer et à le maintenir.

Nous concevons des modifications maintenables, en privilégiant les approches cohérentes avec l’architecture du CMS et en limitant les changements que les mises à jour pourraient écraser. Cela ne signifie pas que les performances restent identiques pour toujours : de nouvelles versions de thèmes, de plugins ou de modules peuvent introduire des ressources, des dépendances et des comportements différents.

C’est pourquoi nous documentons les modifications et ce qu’il faut revérifier après les mises à jour importantes. La méthode prévoit une nouvelle analyse programmée tous les quatre mois, pour repérer les régressions et les nouvelles possibilités d’amélioration. Les contrôles périodiques permettent de suivre l’évolution du site, sans confondre une intervention initiale avec une garantie de performances immuables.

Un ordinateur puissant avec une connexion stable peut masquer des problèmes qui deviennent évidents sur un smartphone moins performant. L’appareil doit télécharger les ressources, traiter le HTML et le CSS et exécuter le JavaScript : un réseau plus lent ou un processeur moins rapide peut allonger l’attente et rendre les interactions moins réactives.

Le cache déjà présent dans votre navigateur peut aussi rendre votre navigation habituelle plus rapide qu’une première visite. C’est pourquoi nous comparons différents appareils et conditions, en observant le chargement et les interactions. Nous associons tests contrôlés et données de terrain disponibles, pour comprendre ce que vivent les utilisateurs au-delà d’un simple test sur l’ordinateur du gestionnaire du site.

Nous comparons les mêmes types de pages avant et après l’intervention, dans des conditions de test comparables et avec des mesures répétées si nécessaire. La synthèse du travail relie les modifications appliquées aux problèmes constatés, pour que vous puissiez voir où nous sommes intervenus et quels effets nous avons observés.

Les vérifications portent sur le chargement, la stabilité visuelle et la réponse aux interactions, ainsi que sur le fonctionnement des menus, des formulaires et des parcours de commande. Lorsqu’elles sont disponibles, nous suivons aussi les données CrUX, en tenant compte de leur fenêtre de collecte. Nous explicitons à la fois les améliorations et les éventuelles limites restantes : une simple capture d’écran d’un score vert ne décrit pas, à elle seule, le résultat du travail.

Oui. L’absence de données CrUX peut simplement signifier que l’échantillon est trop petit, et elle ne nous empêche pas d’analyser le site. Nous utilisons des tests de laboratoire, les outils de diagnostic du navigateur et des vérifications sur les principaux parcours pour repérer les ressources lourdes, les retards d’exécution et l’instabilité de la mise en page.

Lorsque les données manquent pour une URL donnée, nous vérifions si des données au niveau de l’origine sont disponibles, en les gardant distinctes des résultats de la page. Si elles manquent aussi, nous documentons ce que les tests permettent de vérifier et leurs limites. Nous pouvons envisager de collecter des mesures réelles spécifiquement pour le projet, sans présenter des résultats de laboratoire comme des expériences réellement enregistrées auprès des utilisateurs.