WordPress, Wix, Jimdo, TYPO3: welches System lädt in Köln am schnellsten? 736 Websites gemessen

„Wir machen die Seite neu. Nehmen wir wieder WordPress, oder ist Wix schneller?" Die Frage fällt in fast jedem Erstgespräch vor einem Relaunch, meistens mit einer festen Meinung im Gepäck: WordPress sei langsam, Baukästen seien schnell, oder umgekehrt.

Wir haben nachgemessen, statt zu raten. 736 Kölner Handwerks- und Gewerbe-Websites haben wir am 11. September 2026 mit Google PageSpeed Insights geprüft, mobil und als Labormessung. Das Ergebnis vorweg: Kein verbreitetes System lädt in Köln zuverlässig schnell. Nur 12,5 % aller 736 Startseiten bringen ihr größtes sichtbares Element in höchstens 2,5 Sekunden auf das Display.

Zwischen den Systemen gibt es messbare Unterschiede. WordPress kommt auf 4,5 % schnelle Seiten, Wix auf 3,1 %, IONOS MyWebsite und TYPO3 auf keine einzige, Seiten ohne erkennbares System auf 26,7 %. Der größere Unterschied liegt aber innerhalb eines Systems: Die schnellsten 10 % der WordPress-Seiten laden im Median in 2,6 Sekunden, der Rest in 8,1 Sekunden (Stand September 2026). Im Beitrag stehen das Ranking, die Werte je System, die Gründe dahinter und was daraus für eure Systemwahl folgt.

Was wir gemessen haben, und was nicht

Grundlage sind die 736 Websites aus unserem Kölner Handwerks-Website-Report 2026. Jede Startseite lief über die API von Google PageSpeed Insights im mobilen Profil. PageSpeed Insights führt dabei Lighthouse aus, das ein Mittelklasse-Smartphone in einem gedrosselten Mobilfunknetz simuliert. Das ist eine Labormessung mit leerem Cache, keine Aufzeichnung echter Besucher.

Hauptwert ist der Largest Contentful Paint (LCP), der Moment, in dem das größte Bild oder der größte Textblock im sichtbaren Bereich gerendert ist. Google stuft auf web.dev (aktualisiert September 2025) 2,5 Sekunden oder weniger als gut und mehr als 4,0 Sekunden als schlecht ein. Diese Schwellen übernehmen wir. Die Serverantwortzeit stammt aus einem eigenen Crawl, Gewicht und Anfragen aus dem Lighthouse-Bericht.

Grenzen: Das System konnten wir bei 65,4 % der Seiten erkennen, über den Generator-Tag und bekannte Quelltextmuster. Systeme mit weniger als 15 Messungen nennen wir nur als Randnotiz. Über alle 736 Seiten liegt der Median-LCP bei 6,1 Sekunden, das 75. Perzentil bei 10,0 Sekunden, 70,5 % sind schlecht und 62 % brauchen länger als 5 Sekunden.

Eine Verzerrung müssen wir benennen: 31 der 736 Startseiten laden weniger als 100 KB und stellen ein bis vier Anfragen, das sind Platzhalter und Baustellenseiten. Sie bleiben in der Stichprobe, weil der Report sie enthält, und sie zählen alle als schnell. Ohne sie liegt der Anteil schneller Seiten bei 8,7 % statt 12,5 %; wo sie das Bild verzerren, weisen wir es aus.

Das Ranking: welches System am häufigsten schnell lädt

Anteil der Kölner Startseiten mit LCP bis 2,5 Sekunden je System, Lighthouse mobil, 11. September 2026.

Vorne liegen die Seiten ohne erkennbares System mit 26,7 % schnellen Startseiten bei 255 Messungen. 29 der 31 Platzhalterseiten stecken in dieser Gruppe; ohne sie sind es 17,3 % bei 226 Seiten, immer noch der höchste Wert. Die 40 Seiten unter „sonstige" kommen auf 15,0 %, Joomla erreicht mit 16 Seiten 12,5 %, genau den Durchschnitt aller 736.

WordPress liegt mit 310 Seiten bei 4,5 %, Wix mit 32 Seiten bei 3,1 %. IONOS MyWebsite (26 Seiten) und TYPO3 (17 Seiten) haben keine einzige Startseite unter 2,5 Sekunden.

Randnotiz zu den kleinen Gruppen: Jimdo haben wir bei 11 Seiten erkannt, keine davon lädt unter 2,5 Sekunden. Webflow (9 Seiten nach Generator-Tag, 10 in der zweiten Prüfung weiter unten), Contao (7), Squarespace (6), Drupal (5) und Framer (2) bleiben ebenfalls unter der Mindestzahl von 15 Messungen. Prozentwerte tragen dort keinen Vergleich.

Gewicht, Anfragen, Serverantwort: wo die Sekunden verloren gehen

Medianwerte je System aus unserer Messung vom 11. September 2026: Ladezeit (LCP), Seitengewicht und Anzahl der Anfragen aus Lighthouse, Serverantwort aus unserem Crawl.

Seitengewicht: Von den drei Größen folgt es der Rangfolge am ehesten. WordPress-Startseiten wiegen im Median 2,32 MB, Wix-Seiten 2,42 MB, die Seiten ohne erkennbares System 1,06 MB, Joomla 0,93 MB. Eine Ausnahme ist IONOS MyWebsite: 1,24 MB und trotzdem keine schnelle Seite. Über alle Systeme liegen 42 % der Kölner Seiten über 2 MB.

Anfragen: Wix fällt mit 182 im Median aus dem Rahmen, WordPress liegt bei 62, die Seiten ohne erkennbares System bei 34. Der Web Almanac 2025 nennt im Kapitel Page Weight (Daten Sommer 2025) für mobile Startseiten weltweit einen Median von 72 Anfragen und 2.362 KB. Die Kölner WordPress-Seiten liegen darunter und sind trotzdem langsam.

Serverantwort: Sie dreht das Bild. Die gehosteten Baukästen antworten in unserem Crawl sehr schnell: Wix in 0,08 Sekunden, IONOS MyWebsite in 0,13 Sekunden. WordPress braucht im Median 0,79 Sekunden, bis das erste Byte ankommt. Google nennt auf web.dev (aktualisiert November 2025) Werte bis 0,8 Sekunden gut; WordPress liegt damit knapp innerhalb, aber jede Zehntelsekunde davon fehlt später beim LCP.

WordPress: das häufigste System gehört zu den langsamsten

WordPress läuft auf 310 der 736 Seiten. Das passt zum Markt: Laut W3Techs (Stand 16. September 2026, Auswertung der meistbesuchten Websites) liegt WordPress bei .de-Domains bei 54,1 %. In Köln gehört es zusammen mit TYPO3 zu den beiden Systemen mit den schwächsten Werten: 4,5 % schnell, 82,9 % schlecht, Median-LCP 7,7 Sekunden, am 75. Perzentil 12,9 Sekunden, der höchste Wert aller Gruppen ab 15 Messungen.

Die Ursachen suchen wir nicht im Kern, der läuft auch auf den 31 schnellsten Seiten. Sie stecken in dem, was darüber liegt: Themes, Page-Builder, Plugins. Der Web Almanac 2025 zählt im Kapitel CMS (Daten Sommer 2025) Elementor auf 43 % der WordPress-Seiten und misst für WordPress ein Median-Gewicht von 2.894 KB und einen Lighthouse-Score von 41.

Dazu kommt das Hosting. 0,79 Sekunden Serverantwort sprechen für geteilte Server ohne Objekt-Cache; Google schreibt auf web.dev (aktualisiert November 2025), dass Shared Hosting in der Regel langsamer ist. Die Versionen verteilen sich in Köln so: 132 Seiten laufen auf WordPress 7.x, 59 auf 6.x, 17 auf 4.x oder 5.x, 102 verbergen ihre Version. Wer noch auf 4.x oder 5.x steht, sollte vor jeder Ladezeit-Optimierung aktualisieren: Lazy Loading (5.5), WebP (5.8), Vorrang fürs Titelbild (6.3) und AVIF (6.5) kamen laut WordPress-Core-Team erst mit diesen Versionen.

Felddaten zeigen, wie stark die Methode das Ergebnis prägt. Im Core Web Vitals Technology Report des HTTP Archive erreichen laut CrUX-Daten, Stand August 2026, 63,2 % der WordPress-Origins bei mobilen Chrome-Nutzern in Deutschland gute Core Web Vitals, weltweit 48,7 %. Unsere 4,5 % widersprechen dem nicht, sie messen etwas anderes. CrUX zeichnet echte Besuche über 28 Tage auf, mit echten Geräten, Netzen und Caches.

Lighthouse simuliert einen einzelnen kalten Aufruf auf einem Mittelklasse-Gerät im gedrosselten Netz; Google schreibt auf web.dev selbst, dass die Werte deshalb abweichen und Felddaten Vorrang haben, wo beide vorliegen. Dazu kommt ein Auswahleffekt: In CrUX landen laut Methodik-Dokumentation nur Origins mit genug Chrome-Traffic, ohne iOS-Nutzer. Kleine Handwerksseiten fehlen dort oft, und genau die haben wir gemessen.

Die schnellsten 10 % laufen auch auf WordPress

Die 31 schnellsten WordPress-Seiten aus Köln gegen die übrigen 279: Ladezeit, Gewicht und Anfragen aus der Labormessung vom 11. September 2026, Serverantwort aus unserem Crawl.

Die wichtigste Zahl dieser Messung steht nicht im Ranking, sondern innerhalb der WordPress-Gruppe. Die schnellsten 10 %, also 31 der 310 Seiten, wiegen im Median 0,57 MB statt 2,52 MB und stellen 24 statt 64 Anfragen. Ihr Server antwortet in 0,46 statt 0,83 Sekunden, ihr LCP liegt bei 2,6 statt 8,1 Sekunden. Das System ist in beiden Gruppen dasselbe; was sich unterscheidet, sind Gewicht, Anfragen und Serverantwort, also der Aufbau der Seite.

Ein Systemwechsel allein löst deshalb nichts: Wer eine 2,5 MB schwere WordPress-Seite mit demselben Bildmaterial, demselben Slider und denselben Einbettungen nach Wix oder Webflow umzieht, nimmt das Gewicht mit. Im Quelltext der schnellen 31 wiederholen sich Muster, die wir beobachtet, nicht gemessen haben: wenige Plugins, Bilder in WebP oder AVIF in Anzeigegröße, kein Slider im Kopfbereich, ein schlankes Theme ohne Page-Builder, ein Hosting mit Server-Cache. Das häufigste Gegenbild in den langsamen Seiten der Stichprobe ist der Startseiten-Slider, der mehrere Fotos in Kameraauflösung lädt, bevor der erste Text erscheint. Ein einzelnes komprimiertes Bild an dieser Stelle verändert den LCP oft um Sekunden, ohne dass sich am System etwas ändert.

Wix, Jimdo, IONOS: was die Baukästen liefern

Wix überrascht. Die Server antworten in unserem Crawl in 0,08 Sekunden, schneller als bei jedem anderen System. Trotzdem sind nur 3,1 % der 32 Wix-Seiten schnell, 75,0 % schlecht, der Median-LCP liegt bei 6,8 Sekunden. Ein Hinweis steht in den anderen Spalten: 182 Anfragen und 2,42 MB im Median.

Wix beschreibt im eigenen Blog (undatiert, Herstellerangabe) automatisches Caching, WebP-Umwandlung und ein weltweites CDN. Bei 182 Anfragen hilft auch ein schneller Server im Labor wenig.

IONOS MyWebsite (MyWebsite Creator und MyWebsite Now, 26 Seiten) ist das Gegenstück: schlank mit 24 Anfragen und 1,24 MB, Serverantwort 0,13 Sekunden, und trotzdem keine Seite unter 2,5 Sekunden. Der Median-LCP liegt bei 4,8 Sekunden, 69,2 % sind schlecht. Wenig Code allein reicht nicht, wenn das größte Element spät gerendert wird.

Jimdo haben wir bei 11 Kölner Seiten erkannt. Keine lädt im Labor unter 2,5 Sekunden, der Median liegt bei 7,8 Sekunden. Das ist zu wenig für ein Urteil und steht im Gegensatz zu den Felddaten: Laut CrUX (Stand August 2026) erreichen 98,4 % der Jimdo-Origins bei mobilen Nutzern in Deutschland gute Core Web Vitals, bei Wix 90,3 %. Die naheliegende Erklärung ist der Auswahleffekt aus dem WordPress-Abschnitt: Kleine Jimdo-Seiten mit wenig Traffic fehlen in CrUX, in unserer Stichprobe sind sie enthalten.

TYPO3 und Joomla: die Agentur-Systeme

TYPO3 liegt laut W3Techs (Stand 16. September 2026) bei .de-Domains bei 6,7 %, hinter WordPress auf Platz zwei. In Köln sind es 17 Seiten mit dem höchsten Median-LCP und dem höchsten Anteil schlechter Seiten aller Gruppen ab 15 Messungen: keine unter 2,5 Sekunden, 88,2 % über 4 Sekunden, Median-LCP 8,4 Sekunden. Dabei wiegen die Seiten nur 1,72 MB, stellen 48 Anfragen und bekommen die Serverantwort nach 0,27 Sekunden. Gewicht und Serverantwort erklären den Wert nicht; wo die Zeit bleibt, zeigt erst der Blick in den einzelnen Lighthouse-Bericht.

Dabei kann TYPO3 schnell sein: Laut CrUX (Felddaten, Stand August 2026) erreichen 87,2 % der TYPO3-Origins bei mobilen Nutzern in Deutschland gute Core Web Vitals. Die Kölner Installationen sind nach unserem Eindruck häufig ältere Agenturprojekte: Skriptbibliotheken aus der Zeit vor 2020 und Galerien, die alle Fotos vor dem ersten Rendern laden. Das CMS selbst spielt dabei eine kleinere Rolle als das, was vor Jahren darauf gebaut wurde.

Joomla zeigt bei 16 Seiten das umgekehrte Bild: 12,5 % schnell, 56,2 % schlecht, Median-LCP 4,2 Sekunden, der niedrigste aller Gruppen. Die Serverantwort ist mit 0,54 Sekunden eher langsam; dass Joomla trotzdem vorne liegt, passt zu 0,93 MB und 34 Anfragen, dem geringsten Seitengewicht aller Gruppen ab 15 Messungen.

Framer, Webflow, Next.js: was die neuen Systeme in Köln zeigen

Offenlegung vorweg: Wir bauen selbst mit Framer und mit Next.js, teils mit einem Headless-CMS dahinter. Dieses Interesse solltet ihr beim Lesen kennen. Weil Generator-Tags diese Systeme kaum verraten, haben wir alle 736 Startseiten in einer zweiten Prüfung auf Quelltextmuster durchsucht, etwa /_next/static, framerusercontent.com und webflow.js.

Gefunden haben wir 14 Next.js-Seiten (13 davon bisher in der Gruppe ohne erkennbares System), 10 Webflow-Seiten, 2 Framer-Seiten, 2 Gatsby- und eine Astro-Seite. Keine einzige Kölner Betriebsseite kombiniert ein modernes Frontend mit WordPress als Headless-CMS. Zusammen sind das 29 Seiten, und davon lädt genau eine unter 2,5 Sekunden.

Die 14 Next.js-Seiten liegen im Median bei 7,4 Sekunden LCP, 2,78 MB und 74 Anfragen, obwohl ihre Server in 0,14 Sekunden antworten und fünf davon bei Vercel liegen. Die Gewichte reichen von 0,7 MB bis 15,7 MB; das spricht für große Bilder und Videos, nicht für das Framework. Bei Webflow (10 Seiten) ist eine schnell, der Median liegt bei 5,7 Sekunden und 3,56 MB, die schwerste Seite bei 108,8 MB. Die zwei Framer-Seiten laden in 3,2 Sekunden bei 4,37 MB, zu wenig für ein Urteil.

Die Felddaten bestätigen das Muster. Laut CrUX (Felddaten, Stand August 2026, im Technology Report des HTTP Archive) erreichen bei mobilen Nutzern in Deutschland 82,6 % der Framer-Origins und 80,7 % der Webflow-Origins gute Core Web Vitals, aber nur 46,3 % der Next.js-Origins und 41,9 % bei Nuxt, weniger als die 63,2 % von WordPress. Ein Teil davon sind Web-Anwendungen statt Firmenseiten, doch die Richtung ist eindeutig: Ein Framework macht eine Seite nicht schnell, es macht sie nur schnell baubar.

Der Vorteil von Framer, Webflow und statisch gebautem Next.js ist real: fertig gerenderte Seiten, Auslieferung über ein CDN, keine Plugin-Landschaft, Serverantworten um 0,1 Sekunden. Er hält aber nur, solange Bilder, Videos und Einbettungen diszipliniert bleiben. Eine 15-MB-Startseite ist auf Next.js genauso langsam wie auf WordPress.

Seiten ohne erkennbares System: schlank, aber keine homogene Gruppe

255 Seiten, mehr als ein Drittel der Stichprobe, geben im Quelltext kein System preis. Diese Gruppe hat mit 26,7 % den höchsten Anteil schneller Seiten, der Median-LCP liegt bei 4,6 Sekunden. 24 % erfüllen im Labor beide messbaren Core-Web-Vitals-Schwellen (LCP und CLS; die Reaktionszeit INP misst Lighthouse nicht). Die Gruppe wiegt im Median 1,06 MB, stellt 34 Anfragen und bekommt die Serverantwort nach 0,10 Sekunden.

Das ist keine homogene Gruppe. Die zweite Quelltextprüfung findet darin 13 Next.js-Seiten, 9 weitere IONOS-Seiten, 7 Shopify-Shops, 5 Duda- und 4 Strato-Baukästen. 210 Seiten zeigen kein bekanntes Muster, darunter die 29 Platzhalter, sonst meist handgeschriebenes HTML oder ältere Baukästen. Der Vergleich ist deshalb nur mit Vorsicht möglich.

Gemeinsam ist ihnen trotzdem eines: wenig Code, wenige Anfragen und eine Serverantwort nach 0,10 Sekunden im Median. Und selbst hier sind 55,3 % der Seiten langsamer als 4 Sekunden.

Drei Kennzahlen unserer Labormessung vom 11. September 2026 über alle 736 Kölner Betriebsseiten: Anteil schneller Seiten, Median-Ladezeit, Anteil über 5 Sekunden.

Was das für eure Systemwahl bedeutet

Erste Regel: Wählt das System nach Team und Pflege, nicht nach Geschwindigkeitsversprechen. Die Kölner Daten zeigen kein System, das von selbst schnell ist, auch nicht Framer oder Next.js, und die Felddaten zeigen kein System, das nicht schnell sein könnte. Entscheidend ist, wer die Seite in drei Jahren pflegt.

Zweite Regel: Geschwindigkeit entsteht im Aufbau, an vier Stellschrauben: Bilder, Erweiterungen, Theme und Hosting. Bilder gehören ins richtige Format und in die angezeigte Größe, Slider raus; Erweiterungen nur, wo sie gebraucht werden, ein Theme ohne Page-Builder-Ballast, ein Server mit aktuellem PHP und Cache. Das Update auf WordPress 7.0 ist übrigens kein Performance-Update: Der Release-Beitrag (Mai 2026) enthält keine Passage zur Ladezeit. Erst WordPress 7.1 (August 2026) verkleinert Bilder beim Upload direkt im Browser, laut Entwicklerhinweis JPEGs um rund 15 %, allerdings nur in Chromium-Browsern ab Version 137.

Dritte Regel: Vor dem Relaunch messen, danach wieder messen. Ohne Ausgangswert könnt ihr nicht beurteilen, ob der Relaunch die Ladezeit verbessert hat oder nur das Design. Wir haben Relaunches gesehen, bei denen die neue Seite schwerer war als die alte, weil die alten Bilder unverändert mitkamen. Ob sich ein Relaunch überhaupt lohnt, steht im Beitrag Website-Relaunch: wann er sich lohnt.

Google nennt die Core Web Vitals auf Search Central (aktualisiert Dezember 2025) als Teil seiner Ranking-Systeme, stellt aber klar, dass relevanter Inhalt auch bei schwacher Seitenerfahrung vorne stehen kann.

Ein einfacher Einstieg zum Messen ist unser Speed-Check. Er misst Handy und Desktop gleichzeitig über Google PageSpeed Insights, also dieselbe Grundlage wie diese Messung, und zeigt neben dem Laborwert auch echte Nutzerdaten, wo Google welche hat. Zum Vergleich die Kölner Mediane: 6,1 Sekunden LCP, 1,63 MB und 50 Anfragen; die Serverantwort von 0,23 Sekunden stammt aus unserem Crawl und ist mit dem PageSpeed-Wert nur grob vergleichbar. Der Bericht zeigt unter „Largest Contentful Paint" das Element, auf das Lighthouse wartet; damit wisst ihr, ob ein Bild, ein Slider oder eine Schrift die Zeit kostet.

Ihr wollt wissen, wo eure Seite die Sekunden verliert?

Ein LCP bis 2,5 Sekunden ist gut, zwischen 2,5 und 4 Sekunden lohnt ein Blick auf Bilder und Skripte. Über 4 Sekunden, und dort liegen 70,5 % der Kölner Betriebsseiten, gehört die Ladezeit in die nächste Überarbeitung, mit oder ohne Systemwechsel. Wenn ihr die Werte habt und nicht wisst, woran es liegt, schickt uns die Adresse über das Kontaktformular. Wir antworten innerhalb von 24 Stunden, persönlich und ohne Vertriebsgespräch.