Hummingbird vs Classic : quel thème PrestaShop choisir ?

Deux thèmes officiels, deux philosophies différentes

PrestaShop est livré avec deux thèmes officiels : Classic et Hummingbird. Classic est le thème par défaut depuis la sortie de PrestaShop 1.7 en 2016. Hummingbird est arrivé avec PrestaShop 8.x comme alternative moderne conçue pour la performance et la pérennité. Choisir entre les deux ne se résume pas à une question d'apparence. Les deux thèmes représentent des approches fondamentalement différentes de l'architecture front-end, et votre choix affecte les performances, la compatibilité des modules, l'effort de personnalisation et la maintenabilité à long terme.

Cet article propose une comparaison approfondie basée sur l'architecture, des données de performance réelles, des considérations pratiques et les situations spécifiques où chaque thème est le plus pertinent. Que vous lanciez une nouvelle boutique ou envisagiez une migration, cela vous aidera à prendre une décision éclairée.

Architecture : ce qui a changé et pourquoi

Classic a été construit sur Bootstrap 4, jQuery et les templates Smarty. Il suit une approche traditionnelle de rendu côté serveur où le serveur génère des pages HTML complètes et les envoie au navigateur. Le JavaScript est utilisé principalement pour les éléments interactifs comme le panier, la page produit et le tunnel de commande. Le CSS est compilé à partir de fichiers Sass et livré sous forme d'une seule grande feuille de style.

Hummingbird a été conçu comme une réimagination complète. Il utilise Bootstrap 5, abandonne jQuery au profit du JavaScript natif et introduit une architecture basée sur les composants. Le CSS est plus modulaire, le JavaScript est plus léger et l'empreinte globale des ressources est significativement réduite.

La suppression de jQuery est le changement architectural le plus conséquent. jQuery ajoutait environ 87 Ko (30 Ko compressé en gzip) à chaque chargement de page et encourageait un style de codage où les modules manipulaient librement le DOM sans coordination. Hummingbird remplace jQuery par les API modernes des navigateurs comme fetch, querySelector, classList et la délégation d'événements. Cela signifie que le thème lui-même est plus rapide, mais les modules qui dépendent de jQuery nécessitent des mises à jour.

Bootstrap 5 apporte ses propres changements. Il abandonne jQuery comme dépendance (en accord avec l'approche de Hummingbird), utilise les propriétés personnalisées CSS (variables) pour une personnalisation plus facile du thème, améliore le système de grille avec de meilleures classes utilitaires responsive, et met à jour les modèles de balisage des composants. Passer de Bootstrap 4 à 5 affecte tout CSS personnalisé ou surcharge de template qui référence des classes spécifiques à Bootstrap.

Comparaison de performances : les chiffres réels

La performance est la raison principale pour laquelle PrestaShop a créé Hummingbird, et les chiffres confirment cette décision. En testant les deux thèmes sur une installation PrestaShop 8.1 identique avec les mêmes produits, modules et configuration serveur, on observe des différences significatives.

Sur une page produit typique mesurée avec Lighthouse en simulation de connexion mobile, Classic obtient un score de performance dans la plage de 45 à 55, tandis que Hummingbird obtient un score dans la plage de 65 à 75. Les métriques spécifiques racontent une histoire plus claire.

Le First Contentful Paint (FCP) s'améliore d'environ 0,5 à 1,0 seconde avec Hummingbird. Cela est principalement dû au CSS plus léger et à l'absence de jQuery bloquant le rendu. Le Largest Contentful Paint (LCP) s'améliore dans une proportion similaire car le chemin de rendu critique est plus court.

Le Total Blocking Time (TBT) connaît l'amélioration la plus spectaculaire. Le JavaScript basé sur jQuery de Classic crée un blocage significatif du fil principal pendant que le navigateur analyse et exécute la bibliothèque ainsi que tous les scripts de modules dépendants de jQuery. L'approche JavaScript natif de Hummingbird réduit le TBT de 40 à 60 % dans les configurations typiques.

Le Cumulative Layout Shift (CLS) est à peu près équivalent entre les deux thèmes lorsqu'ils sont correctement configurés, car la stabilité de la mise en page dépend davantage des dimensions des images et de l'implémentation du chargement différé que du choix du framework.

La taille totale de transfert raconte une autre partie de l'histoire. Une installation Classic par défaut transfère environ 350 à 450 Ko de CSS et JavaScript au premier chargement de page. Hummingbird ramène cela à 200 à 300 Ko. La différence se cumule tout au long de la session de navigation alors que les visiteurs naviguent dans votre boutique.

Ces chiffres supposent une installation propre. En pratique, les modules tiers ajoutent souvent leurs propres CSS et JavaScript, ce qui peut réduire ou élargir l'écart selon le degré d'optimisation de ces modules pour chaque thème.

Compatibilité des modules : le problème majeur

C'est ici que les avantages de Hummingbird s'accompagnent d'une réserve significative. De nombreux modules PrestaShop ont été conçus avec l'architecture de Classic en tête. Ils dépendent de jQuery, utilisent des modèles de balisage Bootstrap 4 et supposent des structures de template spécifiques que Classic fournit.

Lorsque vous installez ces modules sur Hummingbird, plusieurs choses peuvent se casser. Les fonctionnalités JavaScript qui reposent sur jQuery échoueront silencieusement ou lèveront des erreurs. Les boîtes de dialogue modales, les menus déroulants et autres composants Bootstrap 4 peuvent ne pas s'afficher correctement avec le balisage et les noms de classes modifiés de Bootstrap 5. Les surcharges de templates qui supposent la structure de templates de Classic ne fonctionneront pas avec les templates réorganisés de Hummingbird.

La gravité de ce problème dépend de votre pile de modules. Les modules core de PrestaShop sont compatibles avec les deux thèmes. Les modules tiers bien maintenus provenant de développeurs actifs prennent généralement en charge Hummingbird. Cependant, les modules plus anciens, les modules de niche ou les modules de développeurs qui ont cessé de mettre à jour leurs produits peuvent ne fonctionner qu'avec Classic.

Avant de choisir Hummingbird, vous devez tester chaque module que vous prévoyez d'utiliser. Installez-les dans un environnement de staging avec Hummingbird actif et testez minutieusement chaque fonctionnalité. Portez une attention particulière aux fonctionnalités dépendantes du JavaScript comme les paniers AJAX, les champs de personnalisation de produits, les vues rapides et les étapes de commande.

Certains développeurs de modules fournissent des fichiers de templates séparés pour Classic et Hummingbird. Lorsque vous voyez des répertoires comme views/templates/hook/classic/ et views/templates/hook/hummingbird/ dans un module, ce module prend explicitement en charge les deux thèmes. C'est le standard d'excellence en matière de compatibilité.

Smarty vs Twig : considérations de pérennité

PrestaShop a annoncé son intention de passer de Smarty à Twig comme moteur de templates pour le front-office. Cette transition est discutée depuis des années et est partiellement implémentée dans le back-office. Hummingbird est conçu avec cette transition à l'esprit, bien qu'à partir de PrestaShop 8.x et 9.x, les deux thèmes utilisent encore Smarty pour les templates front-office.

La pertinence pour votre choix de thème est indirecte mais importante. La structure de templates de Hummingbird est organisée de manière à faciliter la migration éventuelle de Smarty vers Twig. Si vous construisez des personnalisations étendues sur la structure de templates de Classic, vous pourriez faire face à un effort de migration plus important lorsque (et non si) PrestaShop achèvera la transition vers Twig.

Cela dit, cette transition est « en cours » depuis plusieurs années maintenant. Prendre une décision aujourd'hui basée uniquement sur un futur changement de moteur de templates est prématuré. Choisissez en fonction des besoins actuels et concrets et acceptez qu'un certain effort de migration sera nécessaire quel que soit le thème choisi lorsque la transition Twig aura lieu.

Approche de personnalisation

Personnaliser Classic est bien documenté et largement compris. Il existe des centaines de tutoriels, des milliers de posts sur les forums et des années de connaissances communautaires sur la modification de Classic. Le thème utilise du Sass classique pour le style, du jQuery traditionnel pour l'interactivité et des templates Smarty faciles à lire et à modifier.

Personnaliser Hummingbird nécessite des compétences mises à jour. Vous devez être à l'aise avec le CSS moderne (propriétés personnalisées, sélecteurs modernes, container queries), le JavaScript natif (sans la béquille jQuery) et l'approche utility-first de Bootstrap 5. La courbe d'apprentissage est plus raide si votre équipe est habituée au développement basé sur jQuery.

Cependant, les propriétés personnalisées CSS de Hummingbird rendent certains types de personnalisation beaucoup plus faciles qu'avec Classic. Vous voulez changer la couleur principale dans tout le thème ? Modifiez une seule propriété personnalisée CSS. Avec Classic, il fallait traquer chaque variable Sass, recompiler et gérer les conflits de spécificité.

Hummingbird utilise également une structure HTML plus sémantique, ce qui facilite le ciblage des éléments avec des sélecteurs CSS et améliore l'accessibilité. Les fichiers de templates sont mieux organisés avec une séparation des responsabilités plus claire.

Support des thèmes enfants

Les deux thèmes prennent en charge les thèmes enfants, qui constituent la méthode recommandée pour personnaliser un thème PrestaShop sans modifier directement les fichiers du thème parent. Les thèmes enfants vous permettent de surcharger des templates spécifiques, d'ajouter du CSS et du JavaScript personnalisés, et de maintenir vos personnalisations lors des mises à jour du thème.

Le mécanisme de thème enfant de Classic est mature et bien testé. Vous créez un répertoire de thème enfant, définissez un theme.yml qui référence Classic comme parent, et surchargez sélectivement les fichiers que vous devez modifier. Ce workflow est stable depuis PrestaShop 1.7.

Le support des thèmes enfants de Hummingbird fonctionne de la même manière au niveau du framework mais présente des différences pratiques. Comme les templates de Hummingbird sont structurés différemment, les surcharges de thèmes enfants basées sur Classic ne peuvent pas être réutilisées. Vous devez créer de nouvelles surcharges basées sur la structure de templates de Hummingbird.

PrestaShop 8.x a amélioré la gestion des thèmes enfants en général, facilitant la surcharge des ressources (CSS et JavaScript) et des templates partiels. Ces améliorations bénéficient également aux thèmes enfants de Classic et de Hummingbird.

Si vous commandez un thème personnalisé à un développeur, partir de Hummingbird comme parent est le meilleur choix à long terme. L'architecture plus propre signifie moins de dette technique, et l'approche CSS moderne signifie moins de surcharges nécessaires pour les personnalisations courantes.

Parcours de migration : de Classic à Hummingbird

Si vous utilisez actuellement Classic et envisagez un passage à Hummingbird, voici ce que la migration implique concrètement.

Les surcharges de templates doivent être reconstruites de zéro. Vous ne pouvez pas simplement copier vos surcharges de templates Classic dans un thème enfant Hummingbird. La structure des fichiers de templates, les noms de variables et les noms de blocs sont différents. Vous devez examiner chaque surcharge, comprendre ce qu'elle accomplit et la recréer en utilisant la structure de templates de Hummingbird.

Le CSS personnalisé nécessite une révision et probablement une refonte significative. Si votre CSS cible des classes Bootstrap 4, ces noms de classes peuvent avoir changé dans Bootstrap 5. Si votre CSS utilise des patterns dépendants de jQuery (comme le style d'éléments basé sur des classes ajoutées par jQuery), ceux-ci se casseront. Si votre CSS utilise des noms de classes spécifiques au thème Classic, ceux-ci peuvent ne pas exister dans Hummingbird.

Le JavaScript personnalisé doit être réécrit. Tout code jQuery doit être converti en JavaScript natif. C'est souvent la partie la plus chronophage de la migration car le code jQuery tend à être profondément entrelacé avec des patterns de manipulation du DOM qui doivent être repensés.

La compatibilité des modules doit être vérifiée pour chaque module installé. Comme évoqué plus haut, les modules qui dépendent de jQuery ou de Bootstrap 4 peuvent nécessiter des mises à jour ou des remplacements.

Un calendrier réaliste pour migrer une boutique Classic modérément personnalisée vers Hummingbird est de 40 à 80 heures de travail de développeur. Ce n'est pas un projet de week-end. Planifiez-le comme un véritable effort de développement avec un environnement de staging, des tests approfondis et un plan de retour arrière.

Quand choisir Classic

Choisissez Classic lorsque votre boutique dépend de modules tiers plus anciens qui n'ont pas été mis à jour pour la compatibilité avec Hummingbird. Choisissez-le lorsque votre équipe de développement est plus à l'aise avec jQuery et Bootstrap 4 et que vous n'avez pas le budget pour la formation ou le recrutement. Choisissez-le lorsque vous construisez dans des délais serrés et avez besoin de la plus large sélection possible de thèmes et modules compatibles depuis la marketplace PrestaShop.

Classic est également le choix le plus sûr pour les boutiques fonctionnant sous PrestaShop 1.7.x ou les premières versions 8.0.x. Hummingbird a été introduit plus tard dans le cycle 8.x et peut ne pas être entièrement disponible ou stable sur les versions plus anciennes de PrestaShop.

Si votre boutique fonctionne déjà sur Classic avec des personnalisations étendues et des performances adéquates, il peut n'y avoir aucune raison impérieuse de migrer. Les gains de performance de Hummingbird sont réels mais peuvent ne pas justifier l'effort de migration si votre boutique se charge déjà rapidement et convertit bien.

Quand choisir Hummingbird

Choisissez Hummingbird lorsque vous lancez une nouvelle boutique PrestaShop 8.x ou 9.x à partir de zéro. Les avantages en termes de performance sont gratuits lorsque vous n'avez pas de personnalisations héritées à migrer. Choisissez-le lorsque la performance est une priorité absolue pour votre activité, en particulier si votre audience est principalement composée d'utilisateurs mobiles sur des connexions plus lentes où chaque kilooctet compte.

Choisissez Hummingbird lorsque vous souhaitez pérenniser votre boutique. Alors que PrestaShop continue d'évoluer vers des pratiques front-end modernes, Hummingbird recevra le plus d'attention en termes de développement et sera le premier à bénéficier des nouvelles fonctionnalités.

Choisissez-le lorsque vous avez des développeurs à l'aise avec le JavaScript et le CSS modernes. L'architecture de Hummingbird est plus propre et plus maintenable pour les équipes possédant des compétences front-end actuelles.

Et choisissez-le lorsque vous vous souciez de l'accessibilité. Le HTML sémantique, les attributs ARIA et le support de la navigation au clavier de Hummingbird sont nettement meilleurs que ceux de Classic. Si votre boutique doit répondre aux normes d'accessibilité WCAG, Hummingbird vous offre un meilleur point de départ.

La question du thème tiers

De nombreux propriétaires de boutiques passent outre les deux thèmes officiels et achètent un thème tiers sur la marketplace PrestaShop Addons ou auprès de vendeurs indépendants. Ces thèmes sont presque toujours basés sur l'architecture de Classic car Classic est disponible depuis bien plus longtemps et représente la base installée la plus importante.

Si vous utilisez un thème tiers, la question Classic vs Hummingbird est largement théorique pour votre boutique actuelle. Le développeur de votre thème a pris les décisions architecturales pour vous. Cependant, lors de l'évaluation de nouveaux thèmes tiers, vérifiez s'ils sont construits sur les fondations de Classic ou de Hummingbird. Les thèmes construits sur Hummingbird seront plus performants et maintiendront leur compatibilité plus longtemps.

Méfiez-vous des thèmes tiers qui prétendent être « basés sur Hummingbird » mais qui en réalité n'empruntent que son style visuel tout en conservant l'architecture dépendante de jQuery de Classic en dessous. Vérifiez les dépendances JavaScript et le framework CSS du thème pour vous en assurer.

Verdict : il n'y a pas de mauvaise réponse, mais il y en a une meilleure

Pour les nouvelles boutiques sur PrestaShop 8.x ou ultérieur, Hummingbird est la recommandation claire. Il est plus rapide, plus moderne, mieux maintenu et plus pérenne. Le problème de compatibilité des modules diminue à mesure que l'écosystème rattrape son retard, et partir de zéro signifie que vous n'avez pas de coûts de migration hérités.

Pour les boutiques existantes fonctionnant sous Classic avec des personnalisations significatives, la décision nécessite une analyse coûts-bénéfices. Calculez honnêtement l'effort de migration, mesurez vos performances actuelles pour comprendre le gain potentiel, et décidez si l'amélioration justifie l'investissement. Parfois la réponse est oui, parfois non, et parfois la bonne réponse est d'attendre votre prochaine refonte majeure pour effectuer le changement.

Quel que soit le thème que vous choisissez, les principes de bonnes performances front-end s'appliquent de la même manière : minimisez la taille des ressources, chargez en différé le contenu sous la ligne de flottaison, optimisez les images et auditez régulièrement la vitesse de vos pages. Une boutique Classic bien optimisée surpassera une boutique Hummingbird mal configurée à chaque fois. Le thème fournit la fondation, mais c'est l'exécution qui détermine le résultat.