Un site qui charge vite, ça ne se laisse pas au hasard.

Parce qu'en dessous, il y a presque toujours un vrai problème : une image trop lourde, un script inutile, une requête lente. 95/100, c'est le niveau où le site est bon pour le SEO, pour la conversion et pour le visiteur. Nous avons choisi un seuil que l'on peut tenir sur tous nos sites, et on s'y tient : pas de 95 annoncé et de 82 en production.

Oui, parce qu'elle est native dans notre stack EaaS. On ne construit pas un site puis on l'optimise : la performance est une contrainte de conception dès la première ligne. Chaque store qui part en production sur la stack démarre à 95/100 minimum, sans phase de rattrapage après coup.

C'est à entretenir, et c'est justement le rôle de l'abonnement EaaS. Chaque nouvelle fonctionnalité, chaque module de paiement, chaque intégration ajoutée peut dégrader les scores. Comme le système est maintenu et amélioré en continu, les tests de performance font partie du cycle de mise en production : le 95/100 n'est pas un acquis, c'est un standard que l'on défend pour tous les stores de la stack.

TTFB, FCP, LCP et CLS : ce sont les métriques que Google utilise pour évaluer l'expérience réelle des visiteurs. On les mesure en conditions réelles, pas seulement en laboratoire : c'est ce qui compte pour le classement et pour vos visiteurs. Un site qui fait 90 en test de laboratoire mais est lent sur le terrain ne convertit pas, et on le sait.

Oui, à condition de bien le régler. C'est exactement le point : on ne met pas en cache n'importe quoi. Les pages vitrines, catégories et produits sont servies depuis le cache, et l'invalidation est précise : quand un prix ou un stock change, ce sont les pages concernées qui se régénèrent, pas tout le site. Le client voit toujours les bonnes données, sans payer le prix d'une page générée à la volée.

Non, et c'est un choix assumé. La performance ne s'ajoute pas après coup sur une plateforme existante : elle vient de l'architecture, du rendu, du cache et de la façon dont le frontend charge ses assets. C'est pour ça que nos clients arrivent sur la stack par un re-platforming, pas par une optimisation de leur site en place. Une fois sur la stack, les performances sont là dès le lancement.

Pas principalement. Un serveur plus puissant ne compense pas une architecture mal pensée : beaucoup de sites lents tournent sur une infrastructure performante simplement mal configurée. Ce qui compte, c'est la façon dont le contenu est généré, mis en cache et servi. Dans l'abonnement EaaS, l'infrastructure est incluse et dimensionnée par nos soins, vous n'avez rien à régler.

C'est vrai, certains scripts tiers sont ce qu'ils sont. Comme ils sont intégrés à la stack, on les connaît et on les encadre : chargement différé, alternative plus légère quand elle existe, ou limitation au moment où le script est réellement utile. Ce qu'on ne peut pas améliorer, on vous le dit clairement avec son impact chiffré.