WordPress-Website schneller machen, ohne Design oder Funktionen kaputtzumachen

Du öffnest deine Website auf dem Handy, während du auf deinen Kaffee wartest, und siehst einen weißen Bildschirm, ein Logo und einen Ladekreisel. Eine Sekunde, zwei, drei. Dann kriecht endlich das Banner herein, und die ganze Seite springt einen halben Bildschirm nach unten. Du weißt, dass die Website „eigentlich in Ordnung“ ist, denn zu Hause auf dem Laptop lädt sie schnell. Der Kunde, der in derselben Kaffeeschlange steht, weiß das nicht. Er hat den Tab einfach geschlossen.

Lange Zeit haben Design und Geschwindigkeit an derselben Decke gezerrt, jeder in seine Richtung. Erst bedeutete „schön“ gezeichnete Rahmen, Schatten, Texturen und ausgefallene Buttons, und all das hatte Gewicht. Dann kamen Smartphones mit langsamem mobilem Internet, und das Pendel schlug in die andere Richtung aus: Minimalismus, viel Weißraum, Standardschriften, gleichförmige rechteckige Blöcke. Die Websites wurden leichter, aber auch einander ähnlich wie Reihenhäuser in einem Neubaugebiet.

Heute muss ein Unternehmen sich nicht mehr für eins von beidem entscheiden. Eine Website soll Vertrauen wecken, das Produkt und den Charakter der Marke zeigen und dabei niemanden warten lassen. Design und Geschwindigkeit funktionieren wie die zwei Griffe einer Mischbatterie: Man muss an beiden drehen, und das ist die Aufgabe derjenigen, die die Website bauen.

Als die meisten Menschen noch per Modem online gingen, waren Websites einfache HTML-Seiten mit ein paar Bildern. Heute haben wir schnelles Internet, leistungsstarke Handys und Server, und eine WordPress-Website kann ein Onlineshop mit Filtern, Kundenkonto, Buchungssystem, Karten, Rechnern, CRM-Widgets, Chat und einem Dutzend Werbepixeln sein.

Was sich in zwanzig Jahren verändert hat

Das Problem ist nicht, dass die Website komplex ist. Eine komplexe Website kann schnell sein. Das Problem ist, wie diese Komplexität zusammengebaut ist: ob der Mensch auf einen leeren Bildschirm starrt, während der Browser Skripte lädt, die auf dieser Seite gar nicht gebraucht werden.

Wenn du eine Website beauftragst, kaufst du keine Sammlung von Seiten, Plugins und Figma-Layouts. Du kaufst ein Werkzeug, das Anfragen und Verkäufe bringen soll. Deshalb heißt „die Website lädt“ noch lange nicht „die Website ist fertig“.

Wenn die Startseite acht Sekunden braucht und der Entwickler sagt, „alles funktioniert, das Formular wird ja abgeschickt und das Menü geht auf“, ist das ungefähr so, als würde man ein Auto ohne Getriebe verkaufen: Der Motor springt doch an.

Eine fertige Website zeigt schnell das Wichtigste, fällt auf dem Handy nicht auseinander und übermittelt Anfragen und Analysedaten korrekt. Wenn ein Besucher gegangen ist, bevor der erste Bildschirm geladen war, hat die Website ihren einzigen Job nicht erledigt. Deshalb sollte Geschwindigkeit vom ersten Tag an zur Qualität der Entwicklung gehören und keine kostenpflichtige „Optimierung“ nach dem Launch sein.

Auf dem Markt ist das eine typische Geschichte. Ein Unternehmen beauftragt eine neue Website bei einer bekannten Agentur, erwartet „Premium“ und bekommt schöne Layouts, die auf einem echten Handy zehn Sekunden zum Laden brauchen. Erst versucht man, sie mit Plugins „aufzumotzen“, dann noch einmal, und am Ende wird die Website von Grund auf neu gebaut. Das Geld für die erste Version, Monate an Arbeit und die Nerven: alles verloren.

Damit dir das nicht passiert, prüfe die Website vor der Abnahme unter realen Bedingungen:

• mit echtem Inhalt statt drei Absätzen Blindtext;
• auf einem normalen Mittelklasse-Handy statt auf dem Laptop des Designers;
• über mobiles Internet;
• mit bereits eingebundener Analyse, Pixeln, Chat und allen Integrationen.

Genau in dieser Ausstattung wird die Website leben. Wenn die Geschwindigkeit ohne Pixel und Chat gemessen wurde, hast du eine ganz andere Website geprüft. Was du dir vor der Abnahme sonst noch vom Entwickler geben lassen solltest, um später nicht von ihm abhängig zu sein, haben wir im Artikel „Der Dienstleister ist weg. Was bleibt von deiner Website?“ aufgeschrieben.

Am günstigsten machst du eine Website schneller, solange es sie noch gar nicht gibt. Die meisten Probleme lassen sich leichter vermeiden, als sie später aus einem fertigen Projekt herauszupulen.

1. Hosting. Anbieter und Tarif passend zur realen Last, nicht „der billigste fürs erste Jahr“.
2. Theme. Eine schlanke Basis ohne hundert Vorlagen, die nie jemand benutzt.
3. Funktionen. Nur Plugins und Integrationen, von denen jedes eine klare Aufgabe hat.
4. Inhalte. Regeln für Fotos, Schriften und Videos, noch bevor die Website befüllt wird.

Auf die Geschwindigkeit wirkt sich alles aus: Hosting, Theme, Seitenstruktur, Funktionsumfang, die Art, wie das Design umgesetzt ist, Drittanbieterdienste und wie später mit den Inhalten gearbeitet wird. Deshalb reicht es bei der Wahl des Entwicklers nicht, sich ein schönes Portfolio anzusehen. Bitte ihn, ein paar seiner Live-Websites auf deinem Handy zu öffnen.

Hosting gehört zu den wichtigsten Faktoren für die Geschwindigkeit von WordPress. Das heißt aber nicht, dass du sofort den teuersten Server kaufen musst. Such dir zuerst einen Anbieter mit stabiler Server-Antwortzeit und wähle dann bei ihm den Tarif, der zu deiner Website passt. Die Praxis zeigt: Website-Betreiber wechseln den Anbieter häufiger wegen Instabilität und „Einbrüchen“ zu bestimmten Uhrzeiten als wegen fehlender Funktionen im Tarif.

Das ist eine Orientierung, kein Gesetz. Eine schlecht gebaute Website mit fünf Seiten kann mehr Ressourcen fressen als ein sauberer Shop mit Hunderten Produkten. Fang mit einem Tarif an, der mit Reserve ausreicht, und rüste mit dem Traffic auf.

Und plane das Budget nicht nur für die Entwicklung. Eine billige Website auf schwachem Fundament wird oft am teuersten, weil du sie später noch einmal bezahlst. Was den Preis einer Website generell beeinflusst, siehst du auf der Seite unserer Leistung Websites und Onlineshops.

Ein CDN wie Cloudflare hält Kopien der Website-Dateien näher am Besucher vor, nimmt dem Server einen Teil der Last ab und hilft Menschen aus anderen Ländern.

Was ein CDN bringt: schnellere Auslieferung von Bildern, Stylesheets und Skripten, weniger Last auf dem Hauptserver, stabilerer Betrieb für weit entfernte Besucher.

Was ein CDN nicht repariert: langsame Datenbankabfragen, ein schweres Theme, Plugin-Konflikte, überflüssiges JavaScript und eine verkorkste Architektur. Wenn eine Seite 10 MB wiegt, liefert das CDN eben diese 10 MB schneller aus.

Das beste Ergebnis bringt die Kombination: ordentliches Hosting, der richtige Tarif, ein eingerichteter WordPress-Cache, ein CDN dort, wo es etwas nützt, und eine sauber gebaute Website.

Wenn das Team Erfahrung hat, ist ein eigenes, sauberes Theme oft die beste Wahl. Noch besser, wenn Designer und Entwickler vom ersten Tag an zusammenarbeiten: Dann steckt in der Website nur, was wirklich gebraucht wird, ohne Dutzende ungenutzte Widgets, Animationen und Bibliotheken.

Was ein gut gemachtes Theme kontrolliert

• Struktur: HTML, Seitenvorlagen, responsives Verhalten, die Logik der Inhaltsausgabe.
• Ressourcen: CSS, JavaScript, Schriften, Bilder und die Reihenfolge, in der sie geladen werden.
• Funktionen: interaktive Elemente, Datenbankabfragen, Kompatibilität mit den nötigen Plugins.
• Weiterentwicklung: die Möglichkeit, eine neue Funktion hinzuzufügen, ohne gegen die Architektur kämpfen zu müssen.

Vor etwa zehn Jahren hat sich WordPress endgültig von einer Blog-Software zur Plattform für Unternehmenswebsites und Shops gewandelt. Zur selben Zeit explodierten die Marktplätze für fertige Themes: für jede Nische, mit Demo-Inhalten, hundert Vorlagen und eingebautem Page Builder.

Die typische Falle sieht so aus. Das Theme passt perfekt zum Design, alle nötigen Seiten sind schon da, es fehlt nur noch wenig. Doch sobald echte Inhalte drin und die nötigen Plugins eingebunden sind, stellt sich heraus, dass es sehr schwer ist. Optimierungs-Plugins treiben die Punktzahl nach oben, an der Architektur ändern sie nichts. Früher oder später kostet die Pflege einer solchen Website so viel, dass ein neues Theme die einfachere Lösung ist.

Ein gutes Theme bietet eine saubere Basis, in die sich leicht nur das Nötige einbauen lässt.

Manche Agenturen haben das Gewicht von WordPress satt und bauen ihr eigenes, vereinfachtes CMS. Das erste Ergebnis beeindruckt: Die Websites sind leicht und schnell. Die Probleme beginnen, wenn der Kunde eine neue Funktion, eine Integration, einen Shop oder eine komplexere Struktur braucht. So ein System lässt sich nur mühsam erweitern, und die Abhängigkeit von einer einzigen Agentur wird nahezu total.

Die erste Version eines eigenen CMS ist nur der Anfang. Danach muss man es ständig aktualisieren, testen, absichern, dokumentieren und das Backend samt Integrationen pflegen. Dafür braucht es ein eigenes, festes Team. Der praktischere Weg: WordPress nicht aufgeben, sondern gezielt nutzen. Nimm, was du brauchst, und schlepp den Rest nicht ins Projekt.

Geschwindigkeit zu ignorieren geht nicht, aber die Zahl in PageSpeed Insights anzubeten ebenso wenig. Für ein paar Punkte mehr werden manchmal nützliche Blöcke entfernt, Funktionen abgeschaltet, das Design bis zur Sterilität vereinfacht, und es wird weiter dort „optimiert“, wo der Mensch keinen Unterschied mehr spürt.

Ein schneller Checkout, der keine Zahlung annimmt, nützt niemandem. Genauso wenig ein leichtes Formular, dessen Anfragen nie ankommen.

Punktzahl und echte Geschwindigkeit bewegen sich außerdem nicht immer gemeinsam. Als wir unseren WordPress-Testshop durchgemessen haben, fiel das Gewicht der Startseite bei einem der Schritte von 2,1 MB auf 576 KB, die Zahl der Anfragen von 64 auf 31, und die Lighthouse-Punktzahl blieb bei 85, wo sie war. Ein Mensch mit langsamem mobilem Internet spürt diesen Unterschied. Die Zahl im Bericht nicht.

Das Ziel: die schnellste Version genau der Website, die das Unternehmen braucht, mit all ihren Funktionen.

PageSpeed Insights färbt das Ergebnis in drei Farben ein: 0-49 rot, 50-89 orange, 90-100 grün. Es kommt oft vor, dass ein Betreiber jahrelang dem grünen Bereich hinterherjagt, auf einer Website, die auf einem schweren Framework gebaut ist: Caching, Komprimierung und Servereinstellungen bringen jeweils ein paar Punkte, und die Seiten bleiben trotzdem mitten im gelben Bereich hängen. Eine neue Website, die von Anfang an mit Blick auf Geschwindigkeit geplant wurde, kommt viel leichter in den grünen Bereich.

• Roter Bereich. Die Menschen spüren das Problem. Anfragen und Sichtbarkeit in der Suche können leiden.
• Gelber Bereich. Die Website ist gut benutzbar, aber es gibt Luft nach oben.
• Grüner Bereich. Eine gute Orientierung, aber keine Garantie für Verkäufe, Design oder Rankings.
• 100 Punkte. Ein schönes technisches Ergebnis, aber kein Ziel an sich.

Und das Wichtigste: Der Sprung von Gelb nach Grün verändert die Rankings für sich allein selten spürbar. Google schreibt ausdrücklich, dass gute Ergebnisse im Core-Web-Vitals-Bericht keine Top-Positionen garantieren und die Suche immer versucht, die relevantesten Inhalte zu zeigen, selbst wenn die Nutzererfahrung auf der Seite schwächer ist (Google Search Central). Geschwindigkeit ist nur ein Teil der Arbeit. Für organischen Traffic braucht es systematische Suchmaschinenoptimierung: Struktur, Inhalte, technischer Zustand und externe Signale.

Was du bei den Core Web Vitals ohne Entwickler reparieren kannst, haben wir separat beschrieben: Core Web Vitals: ohne Entwickler verbessern.

Die Website ist abgenommen, alles grün. Drei Monate später lädt jemand im Team Handyfotos „so wie sie sind“ in den Blog hoch, und die Startseite kriecht wieder. Wenn du die Website selbst befüllen willst, lautet die erste Frage an dich oder dein Team deshalb: Wer kann Fotos fürs Web vorbereiten?

Ein modernes Handy macht Fotos mit 4000 Pixeln Breite und mehr. Für den Druck großartig, für eine Website zu viel. Auf unserem Teststand wogen sechs solcher Fotos, auf der Startseite in „Vollständiger Größe“ eingefügt, 8,3 MB, also 82 % des gesamten Seitengewichts. Die Seite selbst wog damit fast 10 MB, und das größte Element (LCP) erschien auf dem Handy nach 44,7 Sekunden. Als wir in denselben Blöcken die Größe „Groß“ (1024 Pixel) gewählt haben, fiel das Gewicht der Startseite auf 2,3 MB und der LCP auf 5,1 Sekunden. Ganz ohne Plugin.

Was du wissen solltest:

• WordPress verkleinert seit Version 5.3 zu große Fotos selbst auf 2560 Pixel an der längeren Seite und speichert eine Version mit dem Zusatz -scaled (WordPress Developer Blog). Für einen Bildblock im Text ist das aber immer noch zu viel.
• Im Block „Bild“ gibt es im Editor die Einstellung „Auflösung“. Für Fotos im Text reicht fast immer „Groß“. „Vollständige Größe“ ist für seltene Fälle.
• WordPress setzt loading="lazy" selbst bei Fotos unterhalb des ersten Bildschirms und fetchpriority="high" beim Hauptbanner, wenn du sie mit den Standardblöcken einfügst und nicht von Hand per Code.
• Die Umwandlung in WebP hilft, aber nicht immer. Auf dem Teststand hat ein Konverter-Plugin einen Teil der Fotos einfach übersprungen, weil die WebP-Version schwerer war als das ohnehin gut komprimierte JPEG. Den größten Gewinn bringt die richtige Größe, nicht das Format.

Was du den Leuten erklären solltest, die die Website befüllen: die empfohlene Fotobreite, das ungefähre maximale Dateigewicht (für Fotos im Text ist bis 200-300 KB eine vernünftige Grenze), das Format und eine kurze Anleitung zur Vorbereitung.

Was keine Automatisierung löst: Ein Plugin komprimiert Dateien, aber es entschuldigt nicht die Angewohnheit, Originale direkt aus der Kamera hochzuladen.

Deshalb muss man die Geschwindigkeit die ganze Zeit pflegen, solange die Website lebt, und nicht nur am Tag des Launchs.

Für WordPress gibt es Dutzende Plugins für Caching, CSS- und JavaScript-Minimierung, Bildkomprimierung, Datenbankbereinigung und CDN-Integration. Daher die Versuchung, gleich mehrere zu installieren: Jedes beschleunigt ja irgendetwas.

In der Praxis kommt oft das Gegenteil heraus. Das Hosting hat bereits einen eigenen Server-Cache. Die Website läuft über Cloudflare. Ein Plugin minimiert das CSS, ein zweites fasst Dateien zusammen, der Server cacht das Ergebnis, und das CDN bearbeitet es noch einmal. Unterm Strich: doppelte Arbeit, veraltete Seiten und Fehler, die sich schwer reproduzieren lassen.

Auch Spuren alter Lösungen stören. Auf dem Teststand ließ sich ein neues Cache-Plugin, kaum dass wir es gegen ein anderes ausgetauscht hatten, nicht aktivieren: Das vorherige hatte seine Systemdatei advanced-cache.php hinterlassen, und WP Super Cache warnte ausdrücklich, dass es nicht arbeiten kann, solange diese Datei da ist. Auf einer Live-Website spuken solche „Geister“ jahrelang herum.

Ein weiterer Fund vom Teststand betrifft die Plugins selbst. Acht Plugins aus einem typischen Paket (Page Builder, seine Add-ons, ein Slider, zwei Formulare, Teilen-Buttons, WooCommerce) brachten zusammen etwa 130 KB auf die Startseite, ungefähr sechzigmal weniger als die Fotos. Aber die Styles des Page Builders und seiner Add-ons blockierten die Darstellung einer Seite, auf der kein einziger Block dieses Page Builders vorkam. Nachdem wir fünf Plugins deaktiviert hatten, die auf der Website nichts zu tun hatten, stieg die Punktzahl der Startseite von 60 auf 85, und das „Springen“ des Layouts (CLS) verschwand. Die Frage ist also nicht, wie viele Plugins es sind, sondern was jedes davon lädt und wo.

Ein gutes Optimierungs-Set ist kurz: Jedes Werkzeug hat eine klare Aufgabe.

WP Rocket. Ein kostenpflichtiges Plugin, das auf normalen Apache- und Nginx-Servern läuft. Es wird oft gewählt, wenn das Hosting kein eigenes Optimierungspaket mitbringt: Seiten-Cache, verzögertes Laden von Skripten und Lazy Loading an einem Ort.

LiteSpeed Cache. Kostenlos. CSS- und JavaScript-Minimierung sowie Bildoptimierung lassen sich auf jedem Server nutzen, aber die Hauptfunktion, der Seiten-Cache, funktioniert nur auf einem LiteSpeed-Server oder über das CDN QUIC.cloud (Plugin-Seite). Wir haben das auf Apache geprüft: Der Schalter „Enable Cache“ steht auf ON, und darüber steht eine Warnung, dass Caching ohne LiteSpeed-Server nicht verfügbar ist. „Aktiviert“ in den Einstellungen heißt also noch nicht „funktioniert“. Frag deinen Hoster, auf welchem Server deine Website läuft, bevor du bei diesem Plugin auf den Cache setzt.

Entscheiden solltest du nach Serverumgebung und Gesamtarchitektur, nicht nach der Zahl der Häkchen in den Einstellungen oder nach Beliebtheit. Wenn das Hosting keine kostenlosen Plugins mitliefert, gibt es für Apache einfache kostenlose Lösungen wie WP Super Cache. Auf dem Teststand hat es die Server-Antwortzeit der Startseite von 150-250 Millisekunden auf 10-30 gesenkt.

Mehrere Caching-Systeme gleichzeitig setzt man nur ein, wenn man genau weiß, welches davon was cacht.

Experimente sind normal, aus ihnen lernt man. Plugins vergleichen, Themes wechseln, das verzögerte Laden von Skripten ein- und ausschalten: alles nützlich. Aber das gehört auf eine lokale Kopie, einen Testserver oder eine Staging-Version der Website. Die Live-Website, über die Anfragen reinkommen, ist kein Versuchsgelände.

Warum das wichtig ist: Ein falsch eingestellter Cache kann alte Preise anzeigen. Aggressives Verzögern von JavaScript macht Formulare und Checkout kaputt. Eine missglückte „Bereinigung“ der Datenbank löscht Daten, die gebraucht werden. Und all das kann eine Woche lang unbemerkt bleiben, weil ein in WordPress eingeloggter Administrator oft die ungecachte Version sieht und die Kunden die gecachte.

Wenn die Live-Website ein Geschwindigkeitsproblem hat und dir die Erfahrung fehlt, gib es lieber an einen WordPress-Profi ab, statt an echten Anfragen zu lernen.

Zieh keine Schlüsse aus einem einzigen Test der Startseite. Probleme stecken oft in einzelnen Vorlagen: Die Startseite fliegt, die Produktseite kriecht.

Was du testen solltest

• Informationsseiten: Startseite, Leistungsseite, Blogartikel.
• Katalog: Kategorie, Suche, Filter, Sortierung.
• Verkaufsseiten: Produkt, Warenkorb, Checkout, Anfrageformular.
• Echte Interaktion: Menü, Buttons, Formulare, Layoutstabilität, Verhalten auf dem Handy.

Und lass jeden Test mehrmals laufen. Auf unserem Teststand lieferte dieselbe Artikelseite in drei Durchläufen hintereinander 74, 48 und 74 Punkte. Die Startseite schwankte in verschiedenen Serien zwischen 33 und 58. Ein Durchlauf ist Rauschen, der Median aus drei sagt schon etwas.

Unterscheide Labordaten von echten Daten. Lighthouse und die Diagnose in PageSpeed Insights simulieren einen einzelnen Seitenaufruf. Der Block mit den Daten echter Nutzer oben in PageSpeed Insights und der Core-Web-Vitals-Bericht in der Search Console zeigen die Erfahrung echter Besucher der letzten 28 Tage, sofern genug Traffic da ist (PageSpeed Insights). Schau nicht nur auf die Punktzahl, sondern auch darauf, wann der Hauptinhalt erscheint, ob man sofort auf einen Button tippen kann, ob die Seite springt und ob die Formulare funktionieren.

Schau dir außerdem Analyse-Tools, Werbepixel, Online-Chats, Videos, Karten, CRM-Widgets und Bewertungsdienste an. Entfernen kann man sie meist nicht, weil das Unternehmen sie braucht. Die Aufgabe ist, sie so zu laden, dass sie das Wichtigste nicht blockieren. Auf dem Teststand zogen eingebettete YouTube-Videos und Google Maps zusammen etwa 1,5 MB, noch bevor jemand bis zu ihnen gescrollt hatte. Ein einfaches loading="lazy" half nicht: Die Seite ist kurz, und der Browser hat sie vorab geladen. Geholfen hat ein simpler Tausch: ein Vorschaubild des Videos mit Link zu YouTube und ein Button „Auf der Karte öffnen“ statt der eingebetteten Karte.

1. Stell sicher, dass es das Problem gibt. Teste mehrere Seitentypen auf Handy und Computer, jeweils drei Durchläufe.
2. Finde den größten Engpass. Server, Theme, Fotos, Datenbank, JavaScript oder ein Drittanbieterdienst. Schau im Lighthouse-Bericht, was genau am meisten wiegt.
3. Beseitige das größte Problem. Eine große Korrektur bringt mehr als zwanzig kleine Einstellungen.
4. Prüfe, ob alles funktioniert. Formulare, Menü, Filter, Warenkorb, Zahlung, Kundenkonto. Erst danach wird neu gemessen.

So hat dieser Fahrplan bei einem WordPress-Testshop mit dem Theme Astra, WooCommerce und einem typischen Plugin-Paket funktioniert. Median aus drei Lighthouse-Durchläufen, mobiles Profil:

Gemacht wurden vier Dinge: die richtige Fotogröße, das Deaktivieren von Plugins ohne Aufgabe, der Tausch eingebetteter Videos und der Karte gegen leichte Links und ein Seiten-Cache. Die Produktseite hat sich kaum verändert, weil ihr Gewicht aus der WooCommerce-Galerie und deren Skripten besteht. Das ist schon Arbeit für einen Entwickler und nichts mehr für einen Betreiber mit Einstellungen. Der Teststand läuft lokal, deshalb werden die absoluten Zahlen bei deinem Hosting anders aussehen. Vergleichen solltest du die Richtung und das Ausmaß der Veränderungen.

Nach dem technischen Teil muss die Website noch Sichtbarkeit gewinnen. Ein guter Anfang ist der SEO-Audit: was du selbst prüfen kannst und was du beauftragen solltest.

Eine schnelle WordPress-Website ist fast nie das Verdienst eines einzelnen Plugins. Geschwindigkeit entsteht aus Entscheidungen in jeder Phase: Hosting, Theme, die Art, wie das Design umgesetzt ist, der Funktionsumfang und wie später mit den Inhalten gearbeitet wird.

Und Geschwindigkeit kann nicht der einzige Maßstab für eine gute Website sein. Ein primitives Design, beschnittene Funktionen oder kaputte Formulare werden durch 100 Punkte in PageSpeed nicht besser.

Eine schöne und funktionale Website ist nicht fertig, wenn man auf sie warten muss. Eine schnelle Website ist nicht erfolgreich, wenn ihr niemand vertraut und sie keine Anfragen bringt.

Frag dich deshalb: Welche ist die schnellste Version der Website, die Design, nötige Funktionen und Nutzen fürs Unternehmen behält?

Wenn deine Website langsam ist und du nicht weißt, wo du anfangen sollst, schreib uns. Wir schauen uns an, was sie ausbremst, und sagen dir, was sich mit Einstellungen wirklich beheben lässt und was schon Entwicklung braucht. Wie das in der Praxis aussieht, zeigt der Case LMakeup: Baukasten-Website beschleunigen, bei dem wir überhaupt keinen Zugriff auf den Code hatten.