Une boutique PrestaShop qui fonctionne au ralenti entraîne une perte de clients, de moins bons résultats en matière de référencement et une gestion plus difficile des commandes. En revanche, une « boutique qui ralentit » est un symptôme, pas un diagnostic: il existe une quinzaine de causes possibles, et chaque boutique peut présenter un ensemble de problèmes différent.
Cette page vous explique comment nous déterminons quels problèmes vous concernent, combien coûte la réparation et dans quels cas vous n’avez vraiment pas besoin de nous.
Commençons par ce qui vous a amené ici
« Ma boutique est trop lente »
Temps de chargement supérieur à 3 secondes, PageSpeed médiocre, panneau d'administration lent, processus de paiement lent.
Vous êtes au bon endroit
→ lire la suite
« Je ne pense pas que ce soit le serveur. Peut-être des bots ? »
La boutique plante en cas de pic de trafic, des entrées étranges dans les journaux, quelque chose de suspect dans le code, des alertes de Google.
Cliquez ici
→ faites défiler jusqu’à la section « Sécurité »
« Je n’ai pas de trafic provenant de Google »
La concurrence est mieux classée, Search Console signale des erreurs, les positions ont chuté après la migration, il y a des URL en double.
C'est un autre domaine
→ du référencement et de la visibilité
Ces trois problèmes peuvent avoir la même origine : une boutique en ligne lente nuit au référencement, des bots attaquent le serveur et des filtres générant des milliers d’URL perturbent tout en même temps. Le problème trouve son origine à plusieurs endroits, alors commençons par déterminer où se trouve son épicentre.
13 secondes → 0,9 seconde
C’est le temps de chargement de la boutique sous PrestaShop 8.1 avant et après notre optimisation. Il ne s’agit ni d’une simulation, ni d’un test sur une installation vierge, mais d’une boutique en activité avec un catalogue réel et des modules réels.
Nous ne promettons pas que vous obtiendrez les mêmes résultats : votre boutique dispose d’un catalogue différent, d’autres modules et d’un serveur différent. Mais envoyez-nous le lien, et en 30 minutes, nous vous indiquerons dans quelle direction chercher et quelle est l’ampleur de la tâche.
74
boutiques optimisées
14,17 secondes
réduction médiane
18 ans d’expériencedans le commerce en ligne
Qui est l'auteur de cet article ?
PrestaShow est une agence polonaise spécialisée dans le e-commerce et PrestaShop: nous développons nos propres modules, mettons en place des boutiques en ligne et en assurons la gestion (maintenance, optimisation, référencement et développement). Nous travaillons avec les propriétaires de boutiques, et non avec le système en dehors du contexte commercial.
Nous faisons partie du programme PrestaShop Expert: il s'agit d'une reconnaissance officielle de nos compétences par les créateurs du système, et non d'un label que l'on achète. Nous disposons de 76 modules PrestaShop développés en interne, utilisés par des boutiques dans 18 pays : nous maîtrisons le moteur PrestaShop au niveau du code, et pas seulement via le panneau d'administration.
Modules personnalisés
Nous les développons depuis plus d’une dizaine d’années
Mises en place
Nouvelles boutiques et migrations
Gestion de boutique
: maintenance, surveillance, développement
Optimisationd’
: vitesse, serveur, base de données, sécurité
SEO et visibilitéd’
: nous nous en chargeons également, grâce à nos propres modules
Nous commençons par une analyse préliminaire, et non par un audit
Toutes les missions ne commencent pas par un audit à 4 920 zł. Elles commencent par une question : que se passe-t-il exactement, depuis quand et sur quelle boutique en ligne ? Parfois, la réponse se résume à un module à 300 zł et une demi-heure dans le panneau d’administration. Parfois, c’est un projet de trois semaines. L’analyse préliminaire permet de déterminer de quel cas il s’agit : nous examinons la boutique et le serveur, nous vérifions la sécurité, le trafic, la base de données, les modules et le PHP. Cela représente 4 à 6 heures de travail, soit 800 zł.
Mais avant même d’envisager cela, sachez que PrestaShop ralentit rarement pour une seule raison ; en revanche, le symptôme indique généralement la cause. Identifiez votre problème ; dans certains cas, vous constaterez peut-être que vous n’avez pas besoin d’une analyse :
Cliquez sur un symptôme : nous vous expliquerons ce qui le provoque généralement et par où commencer développement L'importation ou la synchronisation s'effectue dans la fenêtre des mouvements. Importation depuis un entrepôt (XML/CSV/API), synchronisation des stocks avec l’ERP, mise à jour des prix : si ces opérations sont trop fréquentes, effectuées à des heures inopportunes ou mal préparées, la boutique et la base de données sont soumises à une charge constante au moment où les clients effectuent leurs achats. Par où commencer : en déterminant à quel moment précis les ralentissements se produisent et ce qui se passe à ce moment-là. En général, il suffit de décaler la fenêtre d’importation et de réduire la fréquence — ce sont des horaires de travail, pas un projet. développement importante Navigation par niveaux avec un grand nombre d’attributs et de combinaisons. Chaque combinaison de filtres correspond à une requête distincte vers la base de données et à une URL distincte. Avec une quinzaine d’attributs, le nombre de combinaisons se compte en milliers — cela surcharge la base de données et encombre l’index Google de doublons. Par où commencer : c’est le seul symptôme qui affecte à la fois la vitesse et le référencement naturel. Il faut déterminer quels filtres doivent être indexés et lesquels ne le doivent pas — et créer des index dans la base de données correspondant à des modèles de filtrage réels. développement Les combinaisons constituent l’un des éléments les plus lourds de PrestaShop. 10 000 produits, chacun disponible en 5 tailles et 6 couleurs, cela ne représente pas 10 000 enregistrements, mais bien 300 000. Une boutique qui semble de taille moyenne pour le client est en réalité volumineuse pour la base de données. Par où commencer ? Par la structure du catalogue. Il est parfois plus économique de remanier le catalogue que d’acheter un serveur plus puissant — et c’est une discussion qu’il faut avoir avant de dépenser de l’argent pour l’infrastructure. chaque étape En général, les deux parties ont leur part de responsabilité – et aucune n’a intérêt à ce que le litige soit tranché. L’hébergeur voit la charge, mais ne voit pas le code. Le développeur voit le code, mais n’a pas accès au serveur. Par où commencer ? Par quelqu’un qui examine les deux aspects à la fois. L’audit porte sur la boutique, les modules et le serveur, et aboutit à un document qui précise : « ceci relève de l’hébergeur », « ceci relève de la boutique », « ceci relève des modules ». Vous pouvez le montrer à l’hébergeur. développement important Un serveur dimensionné pour un trafic moyen, et non pour les pics de fréquentation. Une boutique en ligne qui gère sans problème 300 visiteurs par jour peut tomber en panne si 300 personnes se connectent simultanément. Ce sont deux chiffres différents et deux configurations différentes. Par où commencer : par un test de charge, pour connaître la limite — puis par la décision de relever cette limite ou de refondre la boutique. C’est le meilleur moment pour créer une copie de développement, et le pire pour faire des expériences en production. développement important PrestaShop est conçu pour un panier de vente au détail : trois ou cinq articles. Dans le cas d’une commande en gros comprenant plusieurs centaines de lignes, chaque opération effectuée sur le panier (calcul des prix, des remises par seuil, de la disponibilité, des taxes) est multipliée par le nombre d’articles. À cela s’ajoutent des grilles de prix individuelles par client et des quantités minimales de commande. Par où commencer : en déterminant quelle opération coûte le plus cher lorsque le panier est volumineux. En général, il est possible d’y remédier : en mettant les calculs en file d’attente, en mettant les listes de prix en cache, ou en réécrivant la logique d’ajout des articles. Il s’agit d’une optimisation spécialisée qui relève d’une catégorie à part. développement à grande échelle Multistore, c'est une seule installation, une seule base de données et un seul serveur — pour toutes les boutiques à la fois. Une importation vers une boutique sollicite la base de données commune à toutes les autres. Un module développé sans tenir compte du multistore peut récupérer des données de toutes les boutiques pour n'en afficher qu'une seule. Et une campagne menée sur une boutique peut saturer le serveur des autres. Par où commencer : en déterminant quelle boutique génère la charge et si le problème réside dans la configuration ou dans le module. Le multistore obéit à ses propres règles — c’est une catégorie à part, et non une variante de l’optimisation classique. développement Quelqu'un vous scrape. Des scrapers qui collectent les prix pour la concurrence, des bots qui tentent de se connecter, du trafic indésirable provenant de fermes de serveurs. Pour une boutique en ligne, ce sont des requêtes normales : la base de données les traite, le serveur effectue les calculs, PHP fonctionne. Sauf qu’à l’autre bout, personne n’achète quoi que ce soit. À forte intensité, cela peut consommer la moitié de la puissance du serveur. Par où commencer : en vérifiant quelle part du trafic provient réellement d’utilisateurs humains. Ensuite, un CDN et des règles de blocage — c’est généralement moins cher qu’un serveur plus puissant. chaque étape Ce n’est plus un problème de performances. C’est un piratage. Une boutique infectée est lente parce qu’à côté de la vôtre, sur ce même serveur, quelque chose d’autre est en train de tourner : un mineur de cryptomonnaie, une injection de spam ou des redirections ajoutées au modèle. Le chargement lent n’est qu’un symptôme secondaire, pas le problème lui-même. Par où commencer : tout de suite , et pas par PageSpeed. Analysez le site, identifiez la porte dérobée, nettoyez-le, comblez les failles, changez tous les mots de passe. Optimiser une boutique infectée, c’est comme peindre de l’herbe. chaque étape Un module écrit sans souci de performance envoie des requêtes à la base de données à chaque affichage de la page. Un seul module de ce type peut coûter plusieurs centaines de millisecondes — sur chaque sous-page, pour chaque utilisateur. Par où commencer ? Par un profilage qui indique le temps de traitement de chaque module en millisecondes. Ce n’est qu’ensuite que vous décidez : faut-il l’améliorer, le remplacer ou le supprimer ? chaque étape En général, dans cet ordre : images, JavaScript, absence de cache. Dans la plupart des boutiques en ligne, les images représentent la majeure partie du score — et c’est la partie que vous pouvez corriger vous-même. Par où commencer : par les images. La conversion au format WebP et le chargement différé (lazy load) constituent la mesure la moins coûteuse ayant le plus grand impact sur les performances. Si, après cela, PageSpeed continue de signaler des problèmes, alors il faut se pencher sur le JavaScript et le modèle de page.Quelle est l'activité de votre magasin ?
Il ralentit à certains moments : la nuit ou le matin. Pendant la journée, tout va bien.
La catégorie avec les filtres met une quinzaine de secondes à se charger. Le reste fonctionne à toute vitesse.
J'ai 8 000 produits, et la base de données contient 240 000 enregistrements. D'où viennent-ils ?
L'hébergeur dit que c'est une boutique en ligne. La boutique en ligne dit que c'est un hébergeur. Qui a raison ?
Dans six semaines, c'est le Black Friday, et je sais que le magasin ne tiendra pas le coup.
Un client grossiste ajoute 300 articles à son panier et le processus de paiement plante.
J'ai un système multistore et une seule boutique peut mettre toutes les autres hors service.
La boutique a ralenti, et je vois dans les journaux de connexion des milliers de visites provenant d'adresses étranges.
Le site a ralenti et des choses étranges se produisent : des redirections, des liens inconnus, des alertes de Google.
Nous avons ajouté quelques modules et la boutique a ralenti.
PageSpeed affiche un score de 28/100 et l'agence de référencement me demande de corriger cela.
Le stade de développement de votre boutique change tout
On aborde une boutique qui vient de démarrer de manière totalement différente d’une boutique comptant cinquante mille index et cinq intégrations. Les mêmes symptômes ont une signification différente.
Étape 1
Une boutique en phase de démarrage
jusqu’à environ 2 000 produits · sans intégration
La base de données n’a pas encore eu le temps de s’alourdir, il y a peu de combinaisons possibles, les filtres ne posent pas de problème. En général, des images légères, un cache et un hébergement correct suffisent.
Pour être honnête : un module à 300 zł et une demi-heure dans le panneau d'administration. Un audit serait exagéré.
Étape 2
Boutique en cours de développement
des milliers de produits · combinaisons · intégrations
C’est là que le travail sérieux commence. Les combinaisons multiplient la taille de la base de données, les filtres génèrent des milliers d’URL, l’importation se lance aux heures de pointe. Il y a généralement plusieurs causes à la fois.
En toute honnêteté: c’est ici que l’audit porte ses fruits le plus rapidement, car sans lui, la mise en œuvre n’est qu’une question de devinettes.
Étape 3
Grande boutique / boutique très sollicitée
Plus de 100 000 index · ERP · place de marché
Les index par défaut de PrestaShop ne suffisent plus. Place aux index composites, au cache en mémoire et à une architecture serveur bien pensée.
Soyons honnêtes: un audit est le minimum requis. En pratique, il s’agit d’un projet à part entière, et non d’une simple ligne de la grille tarifaire.
Ce qui ralentit généralement une boutique, même si personne n’en parle
Les guides parlent des images et de la mise en cache, car cela se voit dans PageSpeed. Mais dans les boutiques en pleine croissance, les véritables freins se trouvent ailleurs – et ils ont tous un point commun : ils évoluent au rythme de l’activité.
Combinaisons de produits : la boutique est plus grande qu’elle n’en a l’air
C’est l’un des éléments les plus lourds de PrestaShop et souvent sous-estimé. Un produit disponible en 5 tailles et 6 couleurs ne correspond pas à une seule entrée dans la base de données, mais à 30. C’est pourquoi la question « combien avez-vous de produits ? » est trompeuse. La bonne question est : combien avez-vous de combinaisons? Il est parfois plus économique de restructurer le catalogue que d’acheter un serveur plus puissant.
Les filtres : le seul problème qui affecte à la fois la vitesse du site et son référencement sur Google
La navigation par couches est indispensable pour un catalogue volumineux. Mais chaque combinaison de filtres correspond à une requête distincte vers la base de données et à une URL distincte. La base de données effectue un calcul à chaque clic, et Google indexe des milliers d’URL presque identiques. C’est à ce moment-là que l’optimisation et le référencement naturel cessent d’être des sujets distincts.
Importation depuis l'entrepôt : la boutique ralentit à certaines heures précises
Symptôme caractéristique : la boutique ralentit le matin ou la nuit, tandis qu’elle fonctionne normalement pendant la journée. Il s’agit souvent d’une synchronisation qui coïncide avec la fenêtre d’importation. L’importation sollicite la base de données exactement de la même manière que les clients, mais sans qu’aucun achat ne soit effectué. Le décalage du calendrier et l’optimisation du processus permettent de résoudre le problème sans dépenser un zloty pour le serveur.
Statistiques PrestaShop : pourquoi le panneau d'administration est-il lent alors que le site fonctionne normalement ?
Par défaut, PrestaShop collecte ses propres statistiques. Les tables ps_connections, ps_guest et ps_page_viewed grossissent à chaque connexion. C’est la cause la plus fréquente de la lenteur du back-office. Si vous utilisez Google Analytics, ces statistiques ne vous sont pas nécessaires: vous pouvez les désactiver et les effacer.
Panier B2B : PrestaShop n'a pas été conçu pour gérer plus de 300 articles
PrestaShop a été conçu pour un panier de vente au détail. Chaque opération sur le panier (calcul des prix, des remises, des quantités, des taxes) est multipliée par le nombre d'articles. Ce genre de problème se résout en mettant en file d'attente les calculs et en mettant en cache les grilles tarifaires par client. C'est une tout autre histoire.
Multiboutique : une autre dimension
Le mode multistore, ce n’est pas simplement « PrestaShop, mais en plus ». Il s’agit d’une seule installation, d’une seule base de données et d’un seul serveur pour plusieurs boutiques à la fois. Un module non adapté au multistore récupère les données de toutes les boutiques pour les afficher dans une seule boutique. Une campagne sur une boutique monopolise le serveur au détriment des autres.
L’optimisation ne se résume pas à la vitesse
La moitié des boutiques qui s'adressent à nous en invoquant un « site lent » ont un problème qui n'a pas grand-chose à voir avec les performances. Le chargement lent n'est que la partie visible de l'iceberg.
Une boutique infectée par un virus est toujours lente
Car à côté de votre boutique, sur le même serveur, quelque chose d’autre est à l’œuvre : un mineur de cryptomonnaie, un script de spam, une porte dérobée. C’est pourquoi chaque demande importante donne lieu à une analyse: il est arrivé à plusieurs reprises qu’un client paie pour accélérer quelque chose qui devait d’abord être nettoyé.
Une version obsolète de PrestaShop ne se traduit pas seulement par une boutique plus lente
Chaque version que vous n’avez pas mise à jour représente une liste de failles connues du grand public. Pas besoin d’être une cible : les scanners parcourent tout Internet et vérifient tout les uns après les autres.
Les bots peuvent saturer la moitié d'un serveur
Des scrapers qui collectent les prix pour la concurrence, des bots qui se connectent avec les mots de passe d’autrui, du trafic indésirable. Nous avons vu des boutiques en ligne où la majeure partie du trafic n'était pas générée par des humains : le propriétaire augmentait la puissance de son serveur parce que « ça ralenti », et payait ainsi pour héberger les bots d'autrui.
Absence de CDN : tout transite par un seul point
Sans CDN, chaque image, chaque fichier CSS et chaque client sollicitent votre serveur. Avec un CDN, les éléments statiques proviennent d’un nœud plus proche du client. C’est généralement la mesure la moins coûteuse et la plus efficace pour les boutiques qui n’en disposent pas encore.
Trois façons de commencer – choisissez celle qui vous convient
1
Faites-le vous-même
Le back-office est lent, mais le front-end fonctionne ? C'est presque certainement la base de données : utilisez Cleaner. PageSpeed signale des images trop lourdes ? Optez pour WebP et le chargement différé (Lazy Load). Vous n'avez pas besoin de nous pour utiliser ces modules.
à partir de 300 zł
immédiatement
2
Analyse préliminaire – envoyez-nous le lien vers votre boutique
30 minutes de notre temps. Nous effectuons une analyse externe : vitesse, version, configuration, traces de robots, bases de la sécurité. S'il y a matière à discussion, nous fixons un rendez-vous.
0 zł
30 minutes
3
Analyse préliminaire – c’est là que les choses sérieuses commencent
Nous accédons à la boutique en ligne et au serveur – là où les détails ne sont pas visibles de l’extérieur. Analyse de sécurité, trafic, base de données, modules, PHP. À l’issue de cette analyse, vous saurez quelle est la cause du problème, ce qu’il est possible d’y faire et combien cela coûtera. Cela représente 4 à 6 heures de travail – à un tarif inférieur à notre tarif habituel, et ce, de manière délibérée. Nous ne recommandons pas de dépenser 4 920 zł pour un audit qui vous apprendra qu’un module à 400 zł suffit.
800 zł
4 à 6 h
4
Une vue d’ensemble complète – Audit PrestaShop
Nous procédons à un audit lorsque l’analyse préliminaire révèle plusieurs causes simultanées ou que les pertes de la boutique sont importantes — le tarif est alors élevé. Fichier PDF présentant l’état de la boutique et du serveur : liste des problèmes, recommandations et devis détaillé pour chaque élément. Sans obligation de faire appel à nos services pour la mise en œuvre.
1 230,00 EUR
jusqu’à 15 jours ouvrés
La plupart des cas se classent au niveau 1 ou 3
L'analyse préliminaire à 800 zł est là pour que vous n'ayez pas à deviner ni à acheter immédiatement un audit. Il arrive qu'à l'issue de celle-ci, nous vous disions : « achetez un module à 400 zł et vérifiez si le problème disparaît » – et c'est tout. Il arrive aussi qu’on vous remette une liste de recommandations nécessitant trois semaines de travail. Mais dans les deux cas , vous savez exactement ce pour quoi vous payez avant de passer à la caisse.
Quand un audit est-il vraiment nécessaire – et quand ne l’est-il pas ?
Toutes les optimisations ne nécessitent pas les mêmes interventions. Une boutique a un problème de serveur, une autre de base de données, une troisième de modules, une quatrième d’importation pendant les heures de pointe.
Un audit est pertinent lorsque…
- il y a plusieurs causes à la fois
- la boutique est en pleine croissance et le trafic augmente
- vous vous préparez pour la saison
- vous passez à la version 1.6
- vous avez besoin d'un arbitrage dans un litige avec votre hébergeur
- vous souhaitez obtenir un deuxième avis sur le travail de votre agence
Un audit n'a pas de sens lorsque...
- la boutique vient tout juste de démarrer
- le symptôme indique clairement la cause (le panneau est lent = la base de données)
- vous avez une tâche précise et ciblée
- vous savez déjà ce qu’il faut faire : vous avez besoin d’un prestataire, pas d’un diagnosticien
Un audit, c’est un plan de travail pour votre boutique : un PDF présentant l’état de la boutique et du serveur, une liste des problèmes, des opportunités et des recommandations – avec un devis détaillé pour chaque élément. Réalisation sous 15 jours ouvrés.
Le diagnostic, c’est une chose. La mise en œuvre, c’est un processus
L’analyse préliminaire et l’audit sont des processus fermés : ils ont un début, une fin et une réponse à la clé. La mise en œuvre des changements ne fonctionne pas ainsi. Parfois, les images, le cache et la base de données sont traités en une seule fois et, au bout d’une semaine, c’est terminé. Mais il arrive parfois qu’il faille décomposer le processus en étapes, car une correction à un endroit peut nécessiter des travaux à un autre. Dans ce cas, nous avançons pas à pas : nous vérifions chaque étape avant de passer à la suivante.
Nous facturons ces étapes en fonction du temps passé, à partir de 200 zł de l’heure. Avant chaque étape, nous vous indiquons le nombre d’heures estimé ; une fois le travail terminé, vous voyez combien d’heures ont réellement été nécessaires. Exception : en cas d’urgence – la boutique est hors service, il y a eu une intrusion – nous intervenons immédiatement, à un tarif plus élevé, et nous fixons toujours ce tarif au cas par cas. Et inversement : il arrive que le problème se résume à des images de 4 Mo chacune – dans ce cas, un module, le format WebP, le chargement différé, et le problème est réglé pour 300 zł. Toutes les visites chez le médecin ne se terminent pas forcément par une opération.
Une procédure sécurisée qui ne perturbera pas le fonctionnement de votre boutique
- Nous réalisons un audit approfondi de votre boutique, de vos modules et de votre serveur.
- Nous préparons le serveur et y lançons une copie de votre boutique.
- Nous optimisons cette copie en mettant en œuvre les recommandations issues de l'audit.
- Nous testons la boutique et le serveur, puis nous apportons les corrections nécessaires.
- La migration de l'ancienne boutique vers la nouvelle ne prend que quelques heures : c'est le seul moment d'interruption. Nous convenons d'une date qui vous convient.
- Vous commencez à travailler sur la nouvelle boutique. Toutes les données sont conservées à l'identique.
- Vous bénéficiez d’une garantie de 3 mois sur l’optimisation et d’une offre d’assistance continue.
Combien coûte l’optimisation d’un site PrestaShop ?
Nous ne proposons pas de prix unique, car deux boutiques qui semblent similaires pour le client peuvent présenter des situations techniques totalement différentes. Mais nous pouvons vous indiquer les facteurs qui déterminent ce prix.
| Travaux | Portée | Prix |
| Analyse préliminaire | Nous examinons la boutique en ligne et le serveur : scan de sécurité, trafic, base de données, modules, PHP, version. À l’issue de cette analyse, vous savez quelle est la cause du problème et combien coûte la réparation. Nous facturons ce service à un tarif inférieur à notre taux horaire habituel – et ce, de manière délibérée. | 800 zł 4 à 6 h |
| Audit PrestaShop | PDF : état de la boutique et du serveur, problèmes, recommandations, devis détaillé pour chaque élément. | 1 230,00 EUR |
| Travaux de mise en œuvre par étapes, en fonction du temps | Facturation à l'heure. Avant chaque étape, estimation du nombre d'heures ; après, facturation en fonction du temps réellement passé. Mode d'urgence défini au cas par cas. | à partir de 200 PLN / h |
| Mise à jour de PrestaShop + PHP | 1.6.x, 1.7.x, vers 8.x et vers PrestaShop 9. Modules, composants serveur, PHP. | à partir de 5 000 zł |
| Optimisation et Search Console: PageSpeed, Lighthouse, GTmetrix | Modèle, JavaScript, code source, modules, base de données. Correction des erreurs dans Search Console. | à partir de 3 500 zł |
| Serveur PRO | VPS/dédié avec accès root, Linux + Plesk + SSL + CloudFlare, sauvegardes, GIT. | 615,00 EUR |
| Copie de développement + GIT | Environnement de travail 1:1, pour éviter de tester en production. | 615,00 EUR |
Quels sont les autres facteurs qui influencent le prix ?
Version de PHP et de PrestaShop · nombre de modifications et de redéfinitions · nombre de modules · nombre de combinaisons de produits · nombre et type d'intégrations (entrepôts, ERP, places de marché) · configuration du serveur · résultats des tests de charge.
Optimisation de PrestaShop - Foire aux questions Nous n'avons pas de tarif unique, car deux magasins d'apparence similaire peuvent présenter des situations techniques différentes. Nous commençons par une analyse préliminaire (800 zł, 4 à 6 h), qui permet de déterminer s'il s'agit d'un cas nécessitant un module à 300–400 zł, d'une mission ponctuelle ou d'un audit 1 230,00 EUR. Les travaux de mise en œuvre sont facturés à partir de 200 zł/h. Mise à jour : à partir de 2 000 zł. Profilage et PageSpeed : à partir de 3 500 zł. Non. Nous travaillons sur une copie de développement à l'échelle 1:1; votre boutique continue de fonctionner normalement. La seule interruption aura lieu lors de la migration de l'ancienne boutique vers la nouvelle — cela prendra quelques heures et nous fixerons cette intervention à une date qui vous convient. C'est possible, mais il s'agit d'une spécialisation à part entière. Pour une commande de plusieurs centaines de lignes, chaque opération est multipliée par le nombre de postes. Point important : augmenter la puissance du serveur n'est généralement d'aucune aide, car le problème réside dans le nombre d'opérations. On y remédie en mettant les calculs en file d'attente, en mettant en cache les grilles tarifaires par partenaire et en modifiant la manière d'ajouter des articles. Voir : modules B2B. Oui, et c'est l'un des cas les plus fréquents. Un back-office lent est le plus souvent dû à une base de données surchargée : statistiques, journaux, paniers abandonnés. La table Cela aide, mais ce n'est pas suffisant en soi. La vitesse et les Core Web Vitals constituent l'un des signaux de référencement : les améliorer permet d'éliminer un frein, mais ne remplace ni le contenu, ni la structure des URL, ni les liens. Si votre problème est que « je n'ai pas de trafic provenant de Google », commencez par les modules SEO et visibilité. Probablement pas. Avec un répertoire de petite taille et sans intégration, il n'y a généralement encore aucun problème. Réglez la compression JPEG sur 80, désactivez la collecte de statistiques (si vous collectez des données dans GA4), activez la mise en cache et optez pour un hébergement de qualité. Un module de gestion des images à 300 zł sera plus efficace qu'un audit. Revenez-y lorsque vous constaterez des problèmes ou que votre catalogue s'étoffera. Il faut d'abord procéder à un audit, car cela dépend du nombre de modifications et de redéfinitions. Il est parfois plus économique de procéder à une mise à jour accompagnée d'une optimisation plutôt que d'optimiser la version 1.6, qui devra de toute façon être mise à jour d'ici peu. Nous effectuons des mises à jour des versions 1.6.x, 1.7.x, jusqu'à la version 8.x et vers PrestaShop 9. Nous offrons une garantie de 3 mois sur l'optimisation. Mais une boutique en ligne est un organisme vivant : vous y ajoutez des produits, des modules, des campagnes. C'est pourquoi, pendant ces 3 mois, nous surveillons votre boutique en continu et c'est nous qui vous contactons si quelque chose commence à ne plus fonctionner correctement. Par la suite, cette surveillance peut être prolongée dans le cadre de PrestaShow Care. Cela dépend de la boutique en ligne et c'est le risque qui est déterminant, pas notre confort. Si plusieurs tâches ne se gênent pas mutuellement (images, cache, base de données), nous les exécutons en une seule tâche efficace. Mais si la boutique en ligne comporte de nombreuses modifications et intégrations, nous divisons le projet en étapes. À la fin de chaque étape , vous voyez le résultat et pouvez vous arrêter lorsque vous estimez que cela ne vaut plus la peine de continuer. En fonction du temps passé, à partir de 250 zł par heure. Avant chaque étape, nous vous indiquons le nombre d'heures que nous estimons nécessaires pour la tâche en question ; une fois celle-ci réalisée, vous pouvez voir combien de temps elle a réellement pris. Nous ne fixons pas de forfait à l'aveuglette, car dans ce type de travail, cela peut entraîner des écarts. Nous nous efforçons de travailler rapidement et avec précision, et seules des développeurs seniors participent à ces missions. Dans ce cas, nous laissons tout le reste de côté et nous nous mettons immédiatement au travail. Le mode d'urgence coûte plus cher et nous en fixons toujours le tarif au cas par cas avant de commencer quoi que ce soit — pour éviter toute mauvaise surprise sur la facture. Signalez-nous le problème via le formulaire de contact et précisez que la boutique est hors service — nous vous répondrons en priorité. C'est pourquoi nous le mesurons en continu, et non pas une fois par trimestre. Notre système de surveillance propriétaire affiche le temps de réponse, les Core Web Vitals issus du trafic, la taille de la base de données, les erreurs 5xx et la charge du serveur aux heures de pointe, le tout en temps réel. Nous constatons non seulement que le site a ralenti, mais aussi quel jour cela s'est produit et ce qui s'est passé à ce moment-là : quelles modifications apportées à la boutique en ligne ont eu une incidence sur ce ralentissement.Les questions qui nous sont le plus souvent posées
Combien coûte l'optimisation de PrestaShop ?
La boutique sera-t-elle mise hors ligne pendant l'optimisation ?
Je gère un site de vente en gros : les paniers contiennent plusieurs centaines d'articles et le processus de paiement est ralenti. Y a-t-il une solution ?
Le panneau fonctionne lentement, mais la face avant est OK. Est-ce que ça, c'est aussi de l'optimisation ?
ps_connections peut atteindre plus de 200 Mo. On commence par Cleaner 100,00 EUR; si cela ne suffit pas, on passe au profilage de la base de données.L'optimisation va-t-elle améliorer mon classement sur Google ?
Je viens tout juste de lancer ma boutique en ligne : ai-je besoin d'une optimisation ?
J'ai PrestaShop 1.6. Faut-il l'optimiser ou passer directement à la version suivante ?
Et si, après l'optimisation, la boutique redevenait lente ?
Allez-vous tout faire d'un coup, ou est-ce que ça va s'étaler sur plusieurs mois ?
Comment facturez-vous vos prestations : forfait ou à l'heure ?
Et si la boutique est déjà fermée et que je ne peux pas attendre ?
Comment saurai-je que le magasin ralentit à nouveau, avant même que les clients ne s'en rendent compte ?
Quels sont les résultats de l'optimisation de PrestaShop ?
Résultats techniques
- temps de chargement des pages réduit
- meilleurs résultats PageSpeed et Lighthouse
- amélioration des Core Web Vitals
- un panneau d'administration plus rapide
- processus de paiement plus stable
- une charge moindre sur le serveur
- une base de données plus épurée
Résultats commerciaux
- une meilleure expérience client
- un risque moindre d'abandon de panier
- une meilleure qualité du référencement technique
- une meilleure préparation aux campagnes publicitaires
- fonctionnement plus stable en cas d'augmentation du trafic
- développement ultérieur plus aisé de la boutique
L'optimisation est un événement. La performance est un état.
Une fois optimisée, la boutique est rapide. Et c’est le seul jour où personne n’a rien gâché.
Puis la vie reprend son cours normal. Une vidéo fait son apparition sur la page d’accueil. Le service marketing veut une bannière d’information, puis une deuxième. Un nouveau grossiste s’ajoute. Quelqu’un publie un article avec huit photos tout droit sorties de l’appareil photo et Search Console se met à crier. Aucune de ces choses n’est une erreur : c’est le développement de la boutique. Mais chacune d’entre elles coûte des millisecondes, et au bout de six mois, la boutique est à nouveau lente. Personne ne sait quand, car personne n’y a prêté attention.
C’est pourquoi, pour une boutique en constante évolution, l’optimisation n’est pas une tâche à cocher sur une liste. C’est un processus. Et nous le mesurons en permanence :
| Ce que nous surveillons | Pourquoi |
| Temps de réponse et de chargement | On voit le jour où la boutique a ralenti – et ce qui s’est passé à ce moment-là. |
| Les Core Web Vitals basés sur le trafic des clients, et non des bots | Pas à partir d’un seul test, mais à partir de ce que voient les clients. |
| Taille de la base de données et rythme de gonflement | Quand le nettoyage ne suffit plus et que le profilage devient nécessaire. |
| Disponibilité et erreurs 5xx | Une boutique qui plante une fois par semaine à 3 heures du matin ne le signalera pas d’elle-même. |
| Charge du serveur aux heures de pointe | Pour savoir avant la saison où se situe le plafond — avant de s’y heurter. |
| Sécurité et mises à jour | Un PrestaShop obsolète, ce n’est pas seulement une boutique plus lente. |
3 mois de garantie
la surveillance est comprise dans le prix de l'optimisation
Pendant les trois mois suivant la mise en ligne de votre boutique optimisée, nous vérifions que les résultats perdurent – et c’est nous qui vous contactons si quelque chose nécessite votre attention. À l’issue de la période de garantie, la surveillance peut être prolongée dans le cadre de PrestaShow Care.
Ils nous ont fait confiance
Les boutiques pour lesquelles nous avons réalisé des travaux d’optimisation, de gestion des serveurs ou de sécurité au cours des deux dernières années :
Découvrez nos réalisations · Avis clients
Vous ne savez pas de quel niveau de service vous avez besoin ?
Envoyez-nous le lien vers votre boutique en ligne : nous effectuerons un premier audit de 30 minutes et vous ferons part de nos conclusions. Cela ne coûte rien et suffit souvent à cerner le sujet. Et s’il y a matière à discussion, nous fixerons un rendez-vous.
Nous répondons sous 2 jours ouvrés · sans engagement
Robert JAKUBOWSKI
Dzień dobry. Proszę o informacje czy dacie radę zoptymalizować sklep robik.radom.pl Zależy mi na podniesieniu szybkości na mobile. Pozdrawiam Robert Jakubowski
Piotrek Kula
Byłbym zainteresowany usługą. Jakie serwery polecacie dla Presty i optymalizacji pod Prestę?
prestashow.pl
Piotrek, trochę czasu minęło, ale... dziś polecamy serwery dedykowane OVH lub rozwiązania chmurowe w Digital Ocean. Jeśli macie budżet może to być również Google Cloud.
Patrycja
Wczoraj otworzyłam zgłoszenie na helpdesk w sprawie nowego serwera. Kiedy uzyskamy odpowiedź?
prestashow.pl
Patrycja mamy Twoje zgłoszenie. Na wyceny dot. optymalizacji odpowiadamy w ciągu 5 dni. Damy znać :-)
Bronisław
Jakie dane trzeba przygotować abyście mogli wycenić optymalizację mojego sklepu?
prestashow.pl
Bronisław, admin sklepu, FTP i baza danych. Opcjonalnie SSH root.
Paweł
Przedstawię przepis na możliwie największy wynik w Google PageSpeed: - włączenie PHP 7.4 na serwerze - Prestashop - aktualizacja do najnowszej wersji - wykorzystanie technologii LiteSpeed na serwerze + wtyczki LiteSpeed w Prestashop