Bonnes pratiques relatives au redimensionnement des images de catalogue
Toutes les images de catalogue doivent être redimensionnées avant le début de la production d’un magasin. Si vous ne redimensionnez pas les images avant la mise en production, le redimensionnement de l’image est forcé pendant le chargement de la page, ce qui réduit considérablement la vitesse du site et augmente la charge du serveur au cours des premiers jours ou semaines suivant le lancement.
La voie lente
Utilisez la commande CLI par défaut pour redimensionner toutes les images :
bin/magento catalog:images:resize
Les inconvénients de cette approche sont les suivants :
- Le processus est à thread unique
- Le processus redimensionne les images qui ont déjà été redimensionnées
- Le processus ne peut pas être interrompu, ce qui peut prendre plusieurs jours
La voie rapide
Le redimensionnement asynchrone des images a été introduit dans Adobe Commerce 2.4 et peut redimensionner les images plus rapidement.
-
Sur chaque serveur web, démarrez temporairement certains gestionnaires de file d’attente supplémentaires (deux fois le nombre de processeurs physiques par serveur) :
code language-bsh for i in {1.."$((2 * `nproc --all`))"};do bin/magento queue:consumers:start media.storage.catalog.image.resize &;done; -
Vérifiez que les gestionnaires de file d’attente sont en cours d’exécution :
code language-bash pgrep -fl media.storage.catalog.image.resize -
Remplissez la file d’attente avec toutes les demandes de redimensionnement d’image :
code language-bash bin/magento catalog:images:resize --async -
Une fois toutes les images redimensionnées, arrêtez le processus :
code language-bash pkill -f media.storage.catalog.image.resize
La voie rapide
Il existe une autre façon de redimensionner les images à l’aide du front-end.
Les avantages de cette approche sont les suivants :
- Le processus est multithread
- Le processus est multi-serveur (si vous avez plusieurs nœuds web, une répartition de charge et un espace disque partagé pour le répertoire
media/) - Le processus ignore les images qui ont déjà été redimensionnées
Cette approche redimensionne 100 000 images en moins de 8 heures, tandis que la commande d’interface de ligne de commande prend 6 jours.
- Connectez-vous au serveur .
- Accédez à
pub/media/catalog/productet notez l’un des hachages (par exemple, 0047d83143a5a3a4683afdf1116df680). - Dans les exemples suivants, remplacez
www.example.compar le domaine de votre boutique et remplacez le hachage par celui que vous avez noté.
| code language-bash |
|---|
|
L’inconvénient de siege est qu’il visite toutes les URL dans les 10 fois si la simultanéité est définie sur 10.
| code language-bash |
|---|
|
| code language-bash |
|---|
|
L’argument -P détermine le nombre de threads.
Le texte en une seule ligne pour l’exemple find/curl, au cas où vous pouvez exécuter curl à partir de la même machine sur laquelle se trouvent les images :
| code language-bash |
|---|
|
Une fois de plus, remplacez www.example.com par le domaine de votre site web et définissez -P nombre de threads que votre serveur peut gérer sans se bloquer.
La sortie renvoie une liste de toutes les images de produit du magasin. Vous pouvez analyser les images (avec siege ou tout autre robot d’exploration) à l’aide de tous les serveurs et cœurs de processeur disponibles et générer le cache de redimensionnement à une vitesse considérablement plus rapide que les autres approches.
La visite d’une URL de cache d’image génère toutes les tailles d’image en arrière-plan si elles n’existent pas encore. En outre, il ignore les fichiers qui ont déjà été redimensionnés.
- Adobe Commerce sur les projets d’infrastructure cloud peut décharger le redimensionnement des images de produit sur le service Fastly . Voir Optimisation profonde des images dans le Guide du cloud.
- Si vous utilisez le module de stockage distant, vous pouvez également essayer de décharger le redimensionnement de l’image sur nginx. Voir Configurer le redimensionnement des images pour le stockage distant dans le Guide de configuration.