Hummingbird vs Classic Theme: Welches sollten Sie verwenden?

Zwei offizielle Themes, zwei verschiedene Philosophien

PrestaShop wird mit zwei offiziellen Themes ausgeliefert: Classic und Hummingbird. Classic ist das Standard-Theme seit der Veroeffentlichung von PrestaShop 1.7 im Jahr 2016. Hummingbird kam mit PrestaShop 8.x als moderne Alternative, die auf Performance und Zukunftssicherheit ausgelegt ist. Die Wahl zwischen ihnen ist nicht einfach eine Frage, welches besser aussieht. Die beiden Themes repraesentieren grundlegend verschiedene Ansaetze der Front-End-Architektur, und Ihre Wahl beeinflusst Performance, Modulkompatibilitaet, Anpassungsaufwand und langfristige Wartbarkeit.

Dieser Artikel bietet einen gruendlichen Vergleich basierend auf Architektur, realen Performance-Daten, praktischen Ueberlegungen und den spezifischen Situationen, in denen jedes Theme sinnvoll ist. Egal ob Sie einen neuen Shop starten oder eine Migration in Erwaegung ziehen, dies wird Ihnen helfen, eine fundierte Entscheidung zu treffen.

Architektur: Was sich geaendert hat und warum

Classic wurde auf Bootstrap 4, jQuery und Smarty-Templates aufgebaut. Es folgt einem traditionellen server-gerenderten Ansatz, bei dem der Server vollstaendige HTML-Seiten generiert und an den Browser sendet. JavaScript wird hauptsaechlich fuer interaktive Elemente wie den Warenkorb, die Produktseite und den Checkout verwendet. Das CSS wird aus Sass-Dateien kompiliert und als ein einzelnes grosses Stylesheet ausgeliefert.

Hummingbird wurde als Neukonzeption von Grund auf gebaut. Es verwendet Bootstrap 5, verzichtet auf jQuery zugunsten von Vanilla JavaScript und fuehrt eine komponentenbasierte Architektur ein. Das CSS ist modularer, das JavaScript leichter und der gesamte Asset-Footprint deutlich kleiner.

Die Entfernung von jQuery ist die folgenreichste architektonische Aenderung. jQuery fuegte jedem Seitenaufruf ungefaehr 87KB (30KB gzipped) hinzu und foerderte einen Programmierstil, bei dem Module das DOM frei ohne Koordination manipulierten. Hummingbird ersetzt jQuery durch moderne Browser-APIs wie fetch, querySelector, classList und Event Delegation. Das bedeutet, das Theme selbst ist schneller, aber Module, die von jQuery abhaengen, brauchen Updates.

Bootstrap 5 bringt eigene Aenderungen mit sich. Es verzichtet auf jQuery als Abhaengigkeit (passend zu Hummingbirds Ansatz), verwendet CSS Custom Properties (Variablen) fuer einfacheres Theming, verbessert das Grid-System mit besseren responsiven Utilities und aktualisiert Komponenten-Markup-Muster. Der Wechsel von Bootstrap 4 zu 5 betrifft jedes benutzerdefinierte CSS oder Template-Override, das Bootstrap-spezifische Klassen referenziert.

Performance-Vergleich: Echte Zahlen

Performance ist der primaere Grund, warum PrestaShop Hummingbird entwickelt hat, und die Zahlen bestaetigen die Entscheidung. Das Testen beider Themes auf einer identischen PrestaShop 8.1-Installation mit denselben Produkten, Modulen und Serverkonfiguration zeigt bedeutende Unterschiede.

Auf einer typischen Produktseite, gemessen mit Lighthouse bei einer simulierten mobilen Verbindung, erreicht Classic einen Score im Bereich von 45-55 fuer Performance, waehrend Hummingbird im Bereich von 65-75 liegt. Die einzelnen Metriken erzaehlen eine klarere Geschichte.

First Contentful Paint (FCP) verbessert sich mit Hummingbird um ungefaehr 0,5 bis 1,0 Sekunden. Dies liegt hauptsaechlich am kleineren CSS-Payload und dem Fehlen von render-blockierendem jQuery. Largest Contentful Paint (LCP) verbessert sich um eine aehnliche Marge, da der kritische Rendering-Pfad kuerzer ist.

Total Blocking Time (TBT) zeigt die dramatischste Verbesserung. Classics jQuery-basiertes JavaScript erzeugt erhebliches Main-Thread-Blocking, waehrend der Browser die Bibliothek plus alle jQuery-abhaengigen Modul-Skripte parst und ausfuehrt. Hummingbirds Vanilla-JavaScript-Ansatz reduziert TBT in typischen Konfigurationen um 40-60%.

Cumulative Layout Shift (CLS) ist bei beiden Themes bei korrekter Konfiguration ungefaehr gleichwertig, da Layoutstabilitaet mehr von Bilddimensionen und Lazy-Loading-Implementierung abhaengt als von der Framework-Wahl.

Die gesamte Uebertragungsgroesse erzaehlt einen weiteren Teil der Geschichte. Eine Standard-Classic-Installation uebertraegt ungefaehr 350-450KB an CSS und JavaScript beim ersten Seitenaufruf. Hummingbird bringt dies auf 200-300KB herunter. Der Unterschied potenziert sich ueber die gesamte Browsing-Session, waehrend Besucher durch Ihren Shop navigieren.

Diese Zahlen setzen eine saubere Installation voraus. In der Praxis fuegen Drittanbieter-Module oft ihr eigenes CSS und JavaScript hinzu, was den Abstand je nach Optimierungsgrad dieser Module fuer jedes Theme vergroessern oder verringern kann.

Modulkompatibilitaet: Der Elefant im Raum

Hier kommen Hummingbirds Vorteile mit einem erheblichen Vorbehalt. Viele PrestaShop-Module wurden mit Blick auf Classics Architektur gebaut. Sie haengen von jQuery ab, verwenden Bootstrap 4 Markup-Muster und setzen bestimmte Template-Strukturen voraus, die Classic bereitstellt.

Wenn Sie diese Module auf Hummingbird installieren, koennen verschiedene Dinge kaputtgehen. JavaScript-Funktionalitaet, die auf jQuery angewiesen ist, wird stillschweigend versagen oder Fehler werfen. Modale Dialoge, Dropdowns und andere Bootstrap 4-Komponenten werden mit Bootstrap 5s geaendertem Markup und geaenderten Klassennamen moeglicherweise nicht korrekt gerendert. Template-Overrides, die Classics Template-Struktur voraussetzen, werden mit Hummingbirds reorganisierten Templates nicht funktionieren.

Die Schwere dieses Problems haengt von Ihrem Modul-Stack ab. Core PrestaShop-Module sind mit beiden Themes kompatibel. Gut gewartete Drittanbieter-Module von aktiven Entwicklern unterstuetzen typischerweise Hummingbird. Aeltere Module, Nischen-Module oder Module von Entwicklern, die aufgehoert haben, ihre Produkte zu aktualisieren, funktionieren moeglicherweise nur mit Classic.

Bevor Sie sich fuer Hummingbird entscheiden, sollten Sie jedes Modul testen, das Sie einsetzen wollen. Installieren Sie sie in einer Staging-Umgebung mit aktivem Hummingbird und testen Sie jede Funktion gruendlich. Achten Sie besonders auf JavaScript-abhaengige Funktionalitaet wie AJAX-Warenkoe rbe, Produktanpassungsfelder, Quick Views und Checkout-Schritte.

Einige Modulentwickler liefern separate Template-Dateien fuer Classic und Hummingbird aus. Wenn Sie Verzeichnisse wie views/templates/hook/classic/ und views/templates/hook/hummingbird/ in einem Modul sehen, unterstuetzt dieses Modul explizit beide Themes. Dies ist der Goldstandard fuer Kompatibilitaet.

Smarty vs Twig: Zukunftssicherheits-Ueberlegungen

PrestaShop hat seine Absicht angekuendigt, von Smarty zu Twig als Template-Engine fuer das Front Office zu wechseln. Dieser Uebergang wird seit Jahren diskutiert und ist im Back Office bereits teilweise implementiert. Hummingbird ist mit diesem Uebergang im Hinterkopf entwickelt worden, obwohl beide Themes in PrestaShop 8.x und 9.x noch Smarty fuer Front-Office-Templates verwenden.

Die Relevanz fuer Ihre Theme-Wahl ist indirekt aber wichtig. Hummingbirds Template-Struktur ist so organisiert, dass die eventuelle Smarty-zu-Twig-Migration reibungsloser verlaeuft. Wenn Sie umfangreiche Anpassungen auf Classics Template-Struktur aufbauen, stehen Sie moeglicherweise vor einem groesseren Migrationsaufwand, wenn (nicht falls) PrestaShop den Twig-Uebergang abschliesst.

Allerdings ist dieser Uebergang seit mehreren Jahren "bald verfuegbar". Eine Entscheidung heute allein aufgrund eines zukuenftigen Template-Engine-Wechsels zu treffen, ist verfrueht. Waehlen Sie basierend auf aktuellen, konkreten Beduerfnissen und akzeptieren Sie, dass ein gewisser Migrationsaufwand erforderlich sein wird, unabhaengig davon, welches Theme Sie waehlen, wenn der Twig-Uebergang kommt.

Anpassungsansatz

Die Anpassung von Classic ist gut dokumentiert und weithin verstanden. Es gibt Hunderte von Tutorials, Tausende von Forenbeitraegen und Jahre an Community-Wissen ueber die Modifikation von Classic. Das Theme verwendet einfaches Sass fuer Styling, traditionelles jQuery fuer Interaktivitaet und Smarty-Templates, die leicht zu lesen und zu aendern sind.

Die Anpassung von Hummingbird erfordert aktualisierte Faehigkeiten. Sie muessen sich mit modernem CSS (Custom Properties, modernen Selektoren, Container Queries), Vanilla JavaScript (keine jQuery-Kruecke) und Bootstrap 5s Utility-First-Ansatz wohlfuehlen. Die Lernkurve ist steiler, wenn Ihr Team an jQuery-basierte Entwicklung gewoehnt ist.

Allerdings machen Hummingbirds CSS Custom Properties bestimmte Arten von Anpassungen viel einfacher als mit Classic. Wollen Sie die Primaerfarbe im gesamten Theme aendern? Aendern Sie eine einzelne CSS Custom Property. Mit Classic mussten Sie jede Sass-Variable aufspueren, neu kompilieren und mit Spezifitaetskonflikten umgehen.

Hummingbird verwendet auch eine semantischere HTML-Struktur, was es einfacher macht, Elemente mit CSS-Selektoren anzusprechen und die Barrierefreiheit verbessert. Die Template-Dateien sind besser organisiert mit klarerer Trennung der Zustaendigkeiten.

Child-Theme-Unterstuetzung

Beide Themes unterstuetzen Child-Themes, was der empfohlene Weg ist, ein PrestaShop-Theme anzupassen, ohne die Parent-Theme-Dateien direkt zu aendern. Child-Themes ermoeglichen es Ihnen, bestimmte Templates zu ueberschreiben, benutzerdefiniertes CSS und JavaScript hinzuzufuegen und Ihre Anpassungen bei Theme-Updates beizubehalten.

Classics Child-Theme-Mechanismus ist ausgereift und gut getestet. Sie erstellen ein Child-Theme-Verzeichnis, definieren eine theme.yml, die Classic als Parent referenziert, und ueberschreiben selektiv die Dateien, die Sie aendern muessen. Dieser Workflow ist seit PrestaShop 1.7 stabil.

Hummingbirds Child-Theme-Unterstuetzung funktioniert auf Framework-Ebene gleich, hat aber einige praktische Unterschiede. Da Hummingbirds Templates anders strukturiert sind, koennen Child-Theme-Overrides eines Classic-basierten Child-Themes nicht wiederverwendet werden. Sie muessen neue Overrides basierend auf Hummingbirds Template-Struktur erstellen.

PrestaShop 8.x hat die Child-Theme-Handhabung generell verbessert und das Ueberschreiben von Assets (CSS und JavaScript) sowie partiellen Templates erleichtert. Diese Verbesserungen kommen sowohl Classic- als auch Hummingbird-Child-Themes gleichermassen zugute.

Wenn Sie ein individuelles Theme von einem Entwickler in Auftrag geben, ist der Beginn mit Hummingbird als Parent die bessere langfristige Wahl. Die sauberere Architektur bedeutet weniger technische Schulden, und der moderne CSS-Ansatz bedeutet, dass weniger Overrides fuer gaengige Anpassungen benoetigt werden.

Migrationspfad: Von Classic zu Hummingbird

Wenn Sie derzeit Classic betreiben und einen Wechsel zu Hummingbird in Erwaegung ziehen, ist hier, was die Migration tatsaechlich beinhaltet.

Template-Overrides muessen von Grund auf neu erstellt werden. Sie koennen Ihre Classic-Template-Overrides nicht einfach in ein Hummingbird-Child-Theme kopieren. Die Template-Dateistruktur, Variablennamen und Blocknamen sind unterschiedlich. Sie muessen jedes Override untersuchen, verstehen, was es bewirkt, und es mit Hummingbirds Template-Struktur neu erstellen.

Benutzerdefiniertes CSS muss ueberarbeitet und wahrscheinlich erheblich ueberarbeitet werden. Wenn Ihr CSS Bootstrap 4-Klassen anspricht, haben sich diese Klassennamen moeglicherweise in Bootstrap 5 geaendert. Wenn Ihr CSS jQuery-abhaengige Muster verwendet (wie das Styling von Elementen basierend auf jQuery-hinzugefuegten Klassen), werden diese kaputtgehen. Wenn Ihr CSS theme-spezifische Klassennamen von Classic verwendet, existieren diese moeglicherweise in Hummingbird nicht.

Benutzerdefiniertes JavaScript muss umgeschrieben werden. Jeder jQuery-Code muss in Vanilla JavaScript konvertiert werden. Dies ist oft der zeitaufwaendigste Teil der Migration, da jQuery-Code dazu neigt, tief mit DOM-Manipulationsmustern verflochten zu sein, die neu durchdacht werden muessen.

Die Modulkompatibilitaet muss fuer jedes installierte Modul verifiziert werden. Wie oben besprochen, koennen Module, die von jQuery oder Bootstrap 4 abhaengen, Updates oder Ersatz benoetigen.

Ein realistischer Zeitrahmen fuer die Migration eines maessig angepassten Classic-Shops zu Hummingbird betraegt 40-80 Stunden Entwicklerzeit. Dies ist kein Wochenendprojekt. Planen Sie es als ordentliches Entwicklungsprojekt mit Staging-Umgebung, gruendlichem Testen und einem Rollback-Plan.

Wann Classic waehlen

Waehlen Sie Classic, wenn Ihr Shop von aelteren Drittanbieter-Modulen abhaengt, die nicht fuer Hummingbird-Kompatibilitaet aktualisiert wurden. Waehlen Sie es, wenn Ihr Entwicklungsteam sich mit jQuery und Bootstrap 4 wohler fuehlt und Sie nicht das Budget fuer Umschulung oder Neueinstellung haben. Waehlen Sie es, wenn Sie unter Zeitdruck bauen und die breitest moegliche Auswahl an kompatiblen Themes und Modulen aus dem PrestaShop-Marktplatz brauchen.

Classic ist auch die sicherere Wahl fuer Shops, die PrestaShop 1.7.x oder fruehe 8.0.x-Versionen betreiben. Hummingbird wurde spaeter im 8.x-Zyklus eingefuehrt und ist moeglicherweise nicht vollstaendig verfuegbar oder stabil auf aelteren PrestaShop-Versionen.

Wenn Ihr Shop bereits auf Classic mit umfangreichen Anpassungen laeuft und adaequat performt, gibt es moeglicherweise keinen zwingenden Grund zur Migration. Die Performance-Gewinne von Hummingbird sind real, rechtfertigen aber moeglicherweise nicht den Migrationsaufwand, wenn Ihr Shop bereits schnell laedt und gut konvertiert.

Wann Hummingbird waehlen

Waehlen Sie Hummingbird, wenn Sie einen neuen PrestaShop 8.x oder 9.x Shop von Grund auf starten. Die Performance-Vorteile sind kostenlos, wenn Sie keine Legacy-Anpassungen migrieren muessen. Waehlen Sie es, wenn Performance hoechste Prioritaet fuer Ihr Geschaeft hat, besonders wenn Ihr Publikum hauptsaechlich mobile Nutzer auf langsameren Verbindungen sind, wo jedes Kilobyte zaehlt.

Waehlen Sie Hummingbird, wenn Sie Ihren Shop zukunftssicher machen wollen. Da PrestaShop sich weiterhin in Richtung moderner Front-End-Praktiken entwickelt, wird Hummingbird die meiste Entwicklungsaufmerksamkeit erhalten und als Erstes von neuen Funktionen profitieren.

Waehlen Sie es, wenn Sie Entwickler haben, die sich mit modernem JavaScript und CSS wohlfuehlen. Hummingbirds Architektur ist sauberer und wartbarer fuer Teams mit aktuellen Front-End-Faehigkeiten.

Und waehlen Sie es, wenn Ihnen Barrierefreiheit wichtig ist. Hummingbirds semantisches HTML, ARIA-Attribute und Tastaturnavigationsunterstuetzung sind merklich besser als bei Classic. Wenn Ihr Shop WCAG-Barrierefreiheitsstandards erfuellen muss, gibt Ihnen Hummingbird einen besseren Ausgangspunkt.

Die Drittanbieter-Theme-Frage

Viele Shop-Betreiber ueberspringen beide offiziellen Themes vollstaendig und kaufen ein Drittanbieter-Theme aus dem PrestaShop Addons-Marktplatz oder von unabhaengigen Anbietern. Diese Themes basieren fast immer auf Classics Architektur, da Classic laenger verfuegbar ist und die groessere installierte Basis repraesentiert.

Wenn Sie ein Drittanbieter-Theme verwenden, ist die Classic-vs-Hummingbird-Frage fuer Ihren aktuellen Shop weitgehend akademisch. Der Entwickler Ihres Themes hat die architektonischen Entscheidungen fuer Sie getroffen. Allerdings sollten Sie beim Bewerten neuer Drittanbieter-Themes pruefen, ob sie auf Classic- oder Hummingbird-Grundlagen aufgebaut sind. Themes, die auf Hummingbird aufgebaut sind, werden besser performen und laenger kompatibel bleiben.

Seien Sie vorsichtig mit Drittanbieter-Themes, die behaupten, "auf Hummingbird basierend" zu sein, aber tatsaechlich nur den visuellen Stil uebernehmen und darunter Classics jQuery-abhaengige Architektur beibehalten. Pruefen Sie die JavaScript-Abhaengigkeiten und das CSS-Framework des Themes zur Verifizierung.

Fazit: Es gibt keine falsche Antwort, aber eine bessere

Fuer neue Shops auf PrestaShop 8.x oder spaeter ist Hummingbird die klare Empfehlung. Es ist schneller, moderner, besser gewartet und zukunftssicherer. Das Modulkompatibilitaetsproblem nimmt ab, waehrend das Oekosystem aufholt, und ein Neustart bedeutet, dass Sie keine Legacy-Migrationskosten haben.

Fuer bestehende Shops, die Classic mit erheblichen Anpassungen betreiben, erfordert die Entscheidung eine Kosten-Nutzen-Analyse. Kalkulieren Sie den Migrationsaufwand ehrlich, messen Sie Ihre aktuelle Performance, um den potenziellen Gewinn zu verstehen, und entscheiden Sie, ob die Verbesserung die Investition rechtfertigt. Manchmal ist die Antwort ja, manchmal nicht, und manchmal ist die richtige Antwort, bis zu Ihrem naechsten grossen Redesign mit dem Wechsel zu warten.

Unabhaengig davon, welches Theme Sie waehlen, gelten die Prinzipien guter Front-End-Performance gleichermassen: Asset-Groessen minimieren, Below-the-Fold-Inhalte verzoeogert laden, Bilder optimieren und regelmaessig Ihre Seitengeschwindigkeit pruefen. Ein gut optimierter Classic-Shop wird einen schlecht konfigurierten Hummingbird-Shop jedes Mal uebertreffen. Das Theme liefert das Fundament, aber die Ausfuehrung bestimmt das Ergebnis.