Trouvez les vrais goulots. Corrigez-les avec des données.

Les boutiques lentes perdent des clients. J'audite votre stack Magento 2 de bout en bout — des requêtes base de données au rendu navigateur — et je corrige les vrais goulots, pas les plus évidents.

FPC
Taux de hit du cache de page complète analysé sur chaque audit
7%
Baisse de conversion moyenne par seconde supplémentaire de temps de chargement
Disponible pour audits & optimisation
// résultats en 3–5 jours ouvrés

Audit du Cache de Page Complète

Analyse du taux de hit FPC, identification des trous de cache, configuration des blocs ESI et revue Varnish VCL pour une couverture maximale.

🗃️

Optimisation des Requêtes Base de Données

Analyse des logs de requêtes lentes, élimination des requêtes N+1, identification des index manquants et optimisation des collections EAV.

📦

Optimisation JS/CSS

Analyse des bundles RequireJS, élimination du code mort, extraction CSS critique et chargement différé des ressources non critiques.

🌐

Core Web Vitals

Améliorations LCP, CLS et INP : optimisation des images, stratégie de chargement des polices, élimination des décalages de layout et suppression des ressources bloquant le rendu.

🔍

Audit de Surcharge des Extensions

Identification des extensions qui ajoutent de la surcharge d'observers, des requêtes admin lentes ou du poids JS inutile sur le frontend.

📊

Rapport Avant/Après

Benchmarks PageSpeed, GTmetrix et temps utilisateur réels avant et après. Rapport écrit avec recommandations priorisées.

01

Mesure de base

Scores PageSpeed, traces WebPageTest, logs de requêtes lentes et taux de hit FPC mesurés avant tout changement. Pas de suppositions.

02

Trace complète

Je trace le cycle de vie complet d'une requête : DNS → serveur → PHP → MySQL → FPC → CDN → navigateur. Le goulot est rarement là où on l'attend.

03

Feuille de route priorisée

Liste classée des correctifs par impact vs effort. Certains changements prennent 30 minutes et réduisent le TTFB de moitié. D'autres sont des projets plus longs.

04

Implémentation sur staging

Chaque correctif appliqué d'abord sur staging, benchmarké, puis déployé en production avec monitoring actif.

05

Validation & rapport

Benchmarks post-déploiement confirmant l'amélioration. Résumé écrit que vous pouvez partager avec les parties prenantes ou votre hébergeur.

📏

Mesure avant tout

Je mesure avant de changer. Si un correctif ne se voit pas dans les chiffres, il n'a pas aidé — et je vous le dirai honnêtement.

🎯

Cause racine, pas symptômes

Je ne me contente pas d'exécuter Lighthouse et de suivre ses suggestions. Je trace la requête réelle pour trouver où le temps est vraiment perdu.

🔐

Staging d'abord, toujours

Chaque changement de configuration est testé sur staging avant la production. Les changements de cache et de serveur peuvent casser des choses si faits négligemment.

📝

Livrable écrit

Vous recevez un rapport écrit avec des benchmarks — pas juste une liste de choses que j'ai faites. Quelque chose sur lequel vous pouvez agir, partager ou vous référer.

Notre TTFB est passé de 1,8s à 310ms après la reconfiguration Varnish VCL et Redis. Faouzi a identifié le trou de cache dans notre navigation à facettes dans la première heure de l'audit.

RB
Riadh B.
// Propriétaire de boutique, e-commerce mode · Tunisie

Ce que signifie vraiment « optimisation des performances »

Ce n’est pas juste exécuter bin/magento setup:static-content:deploy avec plus de locales. Le vrai travail de performance Magento signifie comprendre où le temps est dépensé dans l’ensemble de la stack et corriger les problèmes les plus importants en premier.

Les gains les plus courants que je trouve : un taux d’échec FPC supérieur à 30 % dû à un Varnish mal configuré, Redis vidé sous charge à cause d’une mauvaise politique maxmemory, et du JavaScript bloquant qui retarde le Time to Interactive sur les pages produit et catégorie.

Magento 2 FPC Varnish 7 Redis 7 Nginx PageSpeed Insights WebPageTest GTmetrix Blackfire.io New Relic APM MySQL EXPLAIN n98-magerun2 Chrome DevTools PHP-FPM OPcache
Pouvez-vous garantir un score PageSpeed spécifique ?
Non — et ceux qui le font promettent trop. Les scores dépendent de votre hébergement, CDN, ressources images et scripts tiers, dont beaucoup sont hors de mon contrôle. Je garantis de trouver les vrais goulots et de mesurer l'impact avant/après de chaque correctif.
Dois-je vous donner accès au serveur ?
Pour un audit complet, oui — accès SSH pour vérifier la configuration PHP-FPM, Redis, Nginx et les logs de requêtes lentes. Pour un audit frontend uniquement (Core Web Vitals, JS/CSS), je peux travailler sans accès serveur.
Combien de temps prend un audit ?
Un audit complet de la stack prend 2-3 jours pour être réalisé et documenté. Le temps d'implémentation dépend des résultats — certains correctifs prennent des heures, d'autres sont des projets plus longs.
Ma boutique est sur un hébergement managé. Pouvez-vous quand même aider ?
Partiellement. Sur les plateformes managées comme Nexcess ou Adobe Commerce Cloud, je peux m'occuper des performances frontend, de la configuration FPC et de l'optimisation des requêtes au niveau du code, mais pas des changements de configuration serveur.

Votre boutique est plus lente qu'elle ne devrait l'être ?

Partagez votre score PageSpeed et votre configuration d'hébergement. Je vous donnerai une lecture initiale sur où le temps est perdu — avant même de commencer.