Bonnes pratiques relatives au redimensionnement des images du catalogue
Toutes les images du catalogue doivent être redimensionnées avant qu’un magasin ne soit en production. L’échec du redimensionnement des images avant production force le redimensionnement des images au chargement de la page, ce qui réduit considérablement la vitesse du site et augmente la charge du serveur dans les premiers jours à quelques semaines après le lancement.
La lenteur
Utilisez la commande d’interface de ligne de commande par défaut pour redimensionner toutes les images :
bin/magento catalog:images:resize
Cette approche présente les inconvénients 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 des jours.
La méthode 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 des 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 manière de redimensionner les images à l’aide du front-end.
Cette approche présente les avantages suivants :
- Le processus est multithread
- Le processus est multi-serveur (si vous avez plusieurs noeuds web, un équilibreur 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 de l’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, 0047d83143a5a3a4683afdf116df680). - 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 consulte toutes les URL 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.
La ligne unique de l'exemple find/curl, si vous pouvez exécuter curl à partir de la même machine que celle sur laquelle se trouvent les images :
| code language-bash |
|---|
|
Encore une fois, remplacez www.example.com par le domaine de votre site web et définissez -P sur le nombre de threads que votre serveur peut gérer sans blocage.
La sortie renvoie une liste de toutes les images de produits dans le magasin. Vous pouvez analyser les images (avec siege ou tout autre robot d’indexation) à l’aide de tous les serveurs et des coeurs de processeur disponibles et générer le cache de redimensionnement à une vitesse sensiblement supérieure à celle des autres approches.
La consultation 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 du produit vers le service Fastly. Voir Optimisation des images profondes dans le Guide Cloud.
- Si vous utilisez le module de stockage à distance, vous pouvez également essayer de décharger le redimensionnement de l’image sur nginx. Voir Configuration du redimensionnement des images pour le stockage à distance dans le Guide de configuration.