OpenLiteSpeed vs Nginx: Unterschiede und welcher Server passt?

OpenLiteSpeed vs Nginx: Was ist der wichtigste Unterschied?

OpenLiteSpeed ist die Open Source Edition von LiteSpeed Enterprise und bringt .htaccess Rewrite Regeln sowie den LSCache Seitencache von Haus aus mit. Nginx ist ein universeller Webserver und Reverse Proxy, den Sie über Textdateien konfigurieren und der .htaccess nie liest. Der Unterschied zeigt sich vor allem bei Kompatibilität und Caching.

Beim Vergleich OpenLiteSpeed vs Nginx gewinnt keiner immer. Die richtige Wahl hängt von Ihrer Website und von Ihrer Arbeitsweise ab.

In diesem Leitfaden vergleichen wir beide Server mit einer neutralen Tabelle und mit offizieller Dokumentation. Benchmark Zahlen nennen wir bewusst nicht, denn Zahlen ohne Quelle führen in die Irre.

Was macht ein Webserver und warum vergleicht man diese beiden?

Ein Webserver nimmt die Anfrage eines Browsers entgegen und liefert also die Antwort zurück. Zunächst liefert er statische Dateien selbst aus. Bei dynamischen Inhalten wie PHP reicht er die Anfrage an eine Anwendungsschicht weiter.

Man vergleicht die beiden aus einem einfachen Grund. Denn beide wollen auch bei viel Traffic schlank bleiben. Außerdem sind beide beliebt für WordPress und andere PHP Websites.

Die Ansätze unterscheiden sich allerdings. OpenLiteSpeed wirkt vertraut, wenn Sie von Apache kommen. Nginx dagegen arbeitet vollständig über Konfigurationsdateien.

Zum Beispiel besteht eine Firmenwebsite meist aus statischen Dateien und wenigen PHP Seiten. Ein Onlineshop greift dagegen bei fast jedem Besuch auf die Datenbank zu. Daher kann dieselbe Software auf zwei Websites unterschiedlich wirken.

Die Nginx Dokumentation erklärt statische Inhalte mit server und location Blöcken und der Direktive root. Kurz gesagt legen Sie fest, welche Adresse welchen Ordner bedient. Einen breiteren Überblick finden Sie in unserem Beitrag Webhosting auswählen: Server Kriterien.

Wie funktioniert die ereignisgesteuerte Architektur bei beiden Servern?

Beide Produkte gelten als ereignisgesteuert. Statt für jede Verbindung einen neuen Prozess zu starten, bedienen wenige Prozesse viele Verbindungen gleichzeitig.

Die Nginx Dokumentation beschreibt das über einen Master Prozess und Worker Prozesse. Der Master liest die Konfiguration und hält die Worker am Laufen. Danach bearbeiten die Worker die Anfragen. Außerdem legen Sie die Zahl der Worker fest oder lassen sie an den CPU Kernen ausrichten.

Die Website von OpenLiteSpeed stellt diese Behauptung auf: „Event driven processes, less overhead, and enormous scalability." Das ist eine Herstelleraussage. Wir geben sie nicht als gemessenes Ergebnis aus.

In der Praxis heißt ereignisgesteuert: Langsame Besucher blockieren den Server nicht. Allerdings kann langsamer PHP Code oder eine schwere Datenbankabfrage diesen Vorteil wieder auffressen. Der Engpass liegt also oft in der Anwendung und nicht im Webserver. Räumen Sie daher zuerst Abfragen und Plugins auf, bevor Sie die Software wechseln.

Entscheidet die .htaccess Unterstützung bei OpenLiteSpeed vs Nginx?

Für viele Website Betreiber ja. Daher entscheidet dieses Thema oft die Wahl. Nginx liest keine .htaccess Dateien. Weiterleitungen und Zugriffsregeln stehen in der Hauptkonfiguration oder in Dateien, die Sie dort einbinden.

OpenLiteSpeed nennt sich auf der Website „mod_rewrite compatible". Laut Dokumentation unterstützt der Server Apache mod_rewrite Regeln. Außerdem können Sie einstellen, dass .htaccess Dateien auf Server, Virtual Host oder Kontext Ebene automatisch geladen werden.

Eine WordPress Seite von Apache lässt sich daher oft mit Kopieren und Einfügen der Rewrite Regeln umziehen. Trotzdem spricht die Dokumentation nur von Rewrite Regeln. Gehen Sie nicht davon aus, dass andere Apache Direktiven genauso funktionieren.

Ein Beispiel: Ändern Sie in WordPress die Struktur der Permalinks, schreibt ein Plugin eine Rewrite Regel in die .htaccess. Dann wenden Apache und OpenLiteSpeed sie an. Dagegen übernimmt in Nginx dieselbe Aufgabe eine try_files Zeile in der Serverkonfiguration.

Ein Plugin kann auch einen Sicherheitsheader oder eine Zugriffsbeschränkung in die .htaccess schreiben. Dann wird es schwieriger. In Nginx müssen Sie solche Regeln in die Hauptkonfiguration übertragen. Bei OpenLiteSpeed müssen Sie dagegen testen, ob sie wirken.

Wie verarbeiten OpenLiteSpeed und Nginx PHP?

Es gibt zwei Wege. Nginx spricht über das FastCGI Protokoll mit einem Backend Prozess und nutzt dafür die Direktive fastcgi_pass. Konkret geben Sie als Adresse einen Port oder einen UNIX Socket an.

OpenLiteSpeed nutzt LSAPI, die eigene Schnittstelle von LiteSpeed. Laut der offiziellen Seite lässt die native SAPI für PHP Anwendungen „up to 50% faster" laufen. Diese Zahl ist die Aussage des Herstellers und hängt von den Bedingungen ab.

Wichtig ist: Bei Nginx läuft das PHP Backend als eigener Prozess. Nginx reicht die Anfrage weiter und führt PHP Code nicht selbst aus. Deshalb können Sie PHP aktualisieren, ohne den Webserver anzufassen.

Bei OpenLiteSpeed steuern Sie die PHP Verarbeitung über Definitionen externer Anwendungen (ExtApp) in den Servereinstellungen. Das vereinfacht zudem die Einrichtung. Andererseits müssen Sie bei der Fehlersuche eventuell Logs aus zwei Schichten lesen.

Wollen Sie den Unterschied auf Ihrer eigenen Website messen, vergleichen Sie zwei Setups mit derselben PHP Version auf gleichen Maschinen. Sonst ist der Vergleich unfair.

Worin unterscheiden sich LSCache und der Nginx FastCGI Cache?

Beide Systeme speichern eine dynamische Seite als statische Kopie. Dadurch laufen PHP und Datenbank also nicht bei jedem Besuch neu. Der Unterschied liegt darin, wie eng der Cache mit der Anwendung spricht.

LSCache ist eine Cache Engine direkt im Server und hat ein Plugin für WordPress. Die Plugin Dokumentation nennt es eine effizientere und anpassbarere Antwort auf Apache mod_cache und Varnish. Zudem kann das Plugin zugehörige Cache Einträge leeren, wenn sich eine Seite ändert.

Bei Nginx nutzen Sie dagegen den FastCGI Cache. Konkret legen Sie Pfad, Schlüssel und Laufzeit selbst fest. Laut offizieller Dokumentation hat Open Source Nginx keine Direktive fastcgi_cache_purge. Diese Funktion gehört zum kommerziellen Abonnement.

Intelligentes Leeren nach einer Inhaltsänderung kostet bei Nginx also zusätzliche Arbeit. LSCache bringt das dagegen schon mit.

Bedenken Sie außerdem, wann der Cache aus bleiben muss. Eingeloggte Nutzer, Warenkörbe und Kassenseiten dürfen nie im Cache landen. Im LSCache Plugin stellen Sie solche Ausnahmen meist im Einstellungsbereich ein, den genauen Umfang finden Sie in der Plugin Dokumentation. Bei Nginx schreiben Sie die Ausnahmen als Regeln. Das gibt zwar mehr Kontrolle. Dafür tragen Sie aber auch das Risiko einer vergessenen Regel.

Wie sieht ein Vergleich OpenLiteSpeed vs Nginx als Tabelle aus?

Die Tabelle fasst zusammen, was wir in offiziellen Dokumenten bestätigen konnten. Sie enthält keine Zahlen, denn Ihr eigenes Setup bestimmt die Zahlen.

Lesen Sie die Tabelle sorgfältig. „Unterstützt" heißt nicht, dass jedes Detail gleich funktioniert. Testen Sie deshalb vor einem Umzug auf einer Staging Kopie.

Beachten Sie auch: Keine Zeile sagt, welcher Server besser ist. Denn jede Zeile zeigt nur einen Unterschied. Die Gewichtung bestimmen Sie.

Welcher Server passt besser zu WordPress?

Bei WordPress zählen vor allem zwei Dinge: Caching und .htaccess Kompatibilität. OpenLiteSpeed bietet beides zusammen. Sie installieren das LSCache Plugin, und weil die Serverseite bereit ist, bleibt wenig Zusatzarbeit.

Die Plugin Dokumentation weist auf ein wichtiges Detail hin. Sie können das Plugin auch ohne LiteSpeed Server nutzen, erhalten dann aber nur die Optimierungsfunktionen. Die Cache Funktionen brauchen die LSCache Serverkomponente.

Nginx mit WordPress ist dagegen ebenfalls sehr verbreitet. Allerdings entwerfen Sie Weiterleitungs, Cache und Löschregeln selbst. Das gibt Flexibilität, erhöht aber auch die Fehleranfälligkeit.

Bei einem Shop, zum Beispiel mit WooCommerce, sind Cache Regeln noch wichtiger. Zum Beispiel müssen Warenkorb und Kasse aus dem Cache draußen bleiben. Testen Sie diese Ausnahmen auf beiden Servern vor dem Livegang.

Ein schneller Server allein erreicht Ihre Ladezeit Ziele nicht. Zudem wiegen Bilder, Schriften und Skripte von Drittanbietern. Messen Sie daher zuerst, entscheiden Sie dann. Wenn Sie ein CMS gegen Individualcode abwägen, lesen Sie WordPress oder individuelle Website.

Wie unterscheiden sich Konfiguration und Verwaltungsoberfläche?

OpenLiteSpeed bringt ein eingebautes WebAdmin GUI mit. Virtual Hosts, Listener und SSL richten Sie im Browser ein. Für Menschen ohne Routine in der Kommandozeile ist das eine echte Erleichterung.

Nginx hat dagegen keine Oberfläche. Die Einstellungen stehen in Textdateien mit Kontexten wie main, events, http, server und location. Außerdem endet jede Direktive mit einem Semikolon.

Nach einer Änderung übernehmen Sie sie laut offizieller Dokumentation mit diesem Befehl:

nginx -s reload

Der Master Prozess prüft die Syntax der neuen Konfiguration. Danach wendet er die Änderung an, ohne den Dienst zu stoppen. Alte Worker beenden ihre laufenden Anfragen und schließen sich dann.

Dateibasierte Einstellungen haben einen weiteren Vorteil: Der Rückweg ist einfach. Dann legen Sie die alte Datei zurück und laden neu. Änderungen in einer Oberfläche lassen sich dagegen schwerer nachverfolgen, wenn Sie nichts notieren. Führen Sie daher in jedem Fall ein Änderungsprotokoll. Was Sie wann und warum geändert haben, spart im Störungsfall viel Zeit.

Wie sieht eine einfache Nginx Konfiguration für WordPress aus?

Das folgende Beispiel ist nur ein Gerüst. Außerdem ist die Domain ein Beispiel, die Pfade passen Sie an Ihre Umgebung an. Auch die Adresse von PHP FPM kann je nach Distribution abweichen.

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Die Direktive try_files sucht zuerst die Datei, dann das Verzeichnis. Findet sie beides nicht, schickt sie die Anfrage über index.php an WordPress. Diese eine Zeile ersetzt, was die .htaccess für schöne Permalinks leistet.

Allerdings enthält dieses Gerüst kein SSL. Für HTTPS definieren Sie außerdem die Zertifikatsdateien und einen Listener auf Port 443. Viele lassen an dieser Stelle die Zertifikatskette unvollständig und sehen dann eine Browserwarnung.

Sichern Sie die Konfiguration und probieren Sie sie zuerst in einer Testumgebung. Für einen Sicherungsplan lesen Sie unsere Strategie für Website Backups.

Wie aktivieren Sie den Nginx FastCGI Cache?

Zunächst definieren Sie im Kontext http den Cache Pfad. Dann schalten Sie die Zone in einer location ein. Die Direktiven der offiziellen Dokumentation heißen fastcgi_cache_path, fastcgi_cache, fastcgi_cache_key und fastcgi_cache_valid.

http {
    fastcgi_cache_path /var/cache/nginx/example levels=1:2 keys_zone=WPCACHE:10m inactive=60m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
}

Danach ergänzen Sie im PHP Block diese Zeilen:

fastcgi_cache WPCACHE;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_use_stale error timeout updating http_500 http_503;

Hier gilt eine wichtige Warnung. Eingeloggte Nutzer, Warenkörbe und Kassenseiten gehören nicht in den Cache. Sonst könnte ein Besucher die Seite eines anderen sehen. Eine Cookie Prüfung ist bei WordPress Logins ein üblicher Weg, den Cache zu umgehen:

set $skip_cache 0;
if ($http_cookie ~* "wordpress_logged_in") {
    set $skip_cache 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Ob der Cache arbeitet, prüfen Sie mit einem Statusheader über add_header X-Cache-Status $upstream_cache_status;. Bei Shops sollte ein Fachmann diese Einrichtung testen.

Wie richten Sie WordPress und LSCache auf OpenLiteSpeed ein?

Verwalten Sie einen eigenen VPS, sieht der grobe Ablauf so aus. Prüfen Sie Details in der offiziellen Dokumentation, denn Oberflächen und Versionen ändern sich.

1. Installieren Sie OpenLiteSpeed auf einem der in der Dokumentation genannten Betriebssysteme.
2. Öffnen Sie die WebAdmin Konsole und definieren Sie einen Virtual Host und einen Listener.
3. Richten Sie den DNS Eintrag Ihrer Domain auf den Server und fügen Sie das SSL Zertifikat hinzu.
4. Installieren Sie WordPress und aktivieren Sie das LSCache Plugin.
5. Prüfen Sie, ob der Cache serverseitig aktiv ist, denn das Plugin allein liefert keinen Cache.

Für die Prüfung von DNS und Zertifikat helfen die Tools DNS Abfrage und SSL Check. Zertifikate haben wir in Was ist ein SSL Zertifikat erklärt, deshalb wiederholen wir das hier nicht.

Lassen Sie die Admin Konsole außerdem nach der Einrichtung nicht offen im Internet stehen. Beschränken Sie den Zugriff per Firewall auf Ihre eigene Adresse und wählen Sie ein starkes Passwort. So verkleinern Sie die Angriffsfläche, egal wie die Wahl OpenLiteSpeed vs Nginx ausgeht.

Wie läuft die HTTPS Einrichtung bei OpenLiteSpeed vs Nginx ab?

Auf beiden Servern brauchen Sie für HTTPS dasselbe Grundmaterial: ein Zertifikat, einen privaten Schlüssel und eine Definition, die Port 443 abhört. Der Unterschied liegt allerdings darin, wo Sie das einstellen.

Bei OpenLiteSpeed legen Sie Listener und Zertifikate im WebAdmin an. Auch der offizielle Einrichtungsablauf beschreibt Virtual Host, Listener und SSL auf diese Weise. Bei Nginx dagegen stehen die Zertifikatspfade in der Konfigurationsdatei.

Die Erneuerung des Zertifikats dürfen Sie auf keinem Server vergessen. Denn ein abgelaufenes Zertifikat zeigt Besuchern eine beängstigende Warnung. Tragen Sie daher das Ablaufdatum in Ihren Kalender ein und prüfen Sie das Zertifikat regelmäßig.

Für eine schnelle Kontrolle zeigt das Tool SSL Check das Ablaufdatum. Zusammengefasst hängt HTTPS mehr von Ihrer Betriebsdisziplin ab als vom gewählten Server.

Warum nutzt man Nginx auch gern als Reverse Proxy?

Die Nginx Dokumentation zeigt, dass die Direktive proxy_pass Anfragen an eine andere Adresse weiterleiten kann. Das ist praktisch, wenn Sie hinter einer Domain mehrere Anwendungen betreiben.

location / {
    proxy_pass http://127.0.0.1:8080;
}

Zum Beispiel können Sie eine Node.js Anwendung hinter Nginx stellen. Nginx spricht dann nach außen, die Anwendung bleibt innen. Außerdem bündelt dieser Aufbau die Zertifikatsverwaltung an einer Stelle.

Das ist allerdings ein anderer Bedarf als bei einer reinen WordPress Seite. Läuft bei Ihnen nur PHP, brauchen Sie die Reverse Proxy Rolle oft nicht. Betreiben Sie dagegen eine gemischte Anwendungslandschaft, kann diese Rolle für Nginx sprechen.

Wie vergleichen Sie bei OpenLiteSpeed vs Nginx den Ressourcenbedarf auf einem kleinen VPS?

Eine Zahl zum Ressourcenbedarf nennen wir nicht. Denn das Ergebnis hängt von Ihrem Traffic und Ihrer PHP Konfiguration ab. Stattdessen erklären wir, wie Sie selbst messen.

Zunächst bereiten Sie zwei Testserver gleicher Größe vor. Installieren Sie dann dieselbe PHP Version und dieselbe Kopie Ihrer Website. Danach gehen Sie so vor:

1. Messen Sie jeden Server einmal mit abgeschaltetem und einmal mit aktivem Cache.
2. Simulieren Sie mit einem Lasttest Tool dieselbe Zahl gleichzeitiger Besucher.
3. Beobachten Sie Antwortzeit und Speicherbedarf mit einem Prozessmonitor wie top.
4. Tragen Sie die Ergebnisse in eine Tabelle ein und wiederholen Sie den Lauf.

Außerdem führen Sie Lasttests nur gegen Ihren eigenen Server aus. Denn Last auf fremde Server zu schicken ist unethisch und verursacht Ärger.

So entscheiden Sie auf Basis eigener Daten und nicht auf Basis von Behauptungen. Außerdem dient die Messung später als Referenz, falls Sie den Server wechseln.

Warum sollten Sie Benchmark Zahlen mit Vorsicht lesen?

Im Netz finden Sie viele Tests, die beide Server vergleichen. Die Ergebnisse schwanken allerdings stark mit Hardware, PHP Version, Cache Einstellung und Testwerkzeug.

Deshalb nennen wir keine Zahl. Herstelleraussagen sind zudem Marketingsprache. Stellen Sie beim Lesen eines Benchmarks diese Fragen:

• Mit welcher Hardware und PHP Version lief der Test?
• War der Cache auf beiden Seiten gleich eingestellt?
• Misst der Test eine statische Datei oder eine dynamische Seite?
• Zeigt das Ergebnis die echte Nutzererfahrung oder nur Anfragen pro Sekunde?

Fragen Sie zudem, ob der Cache warm oder kalt war. Beim ersten Besuch ist der Cache leer, und PHP baut die Seite auf. Spätere Besuche kommen dann aus dem Cache. Ein guter Test weist beide Fälle getrennt aus.

Um Ihre eigene Website zu messen, ist Google Lighthouse für die Website Performance ein guter Anfang. Dann wiederholen Sie den Test vor und nach jedem Serverwechsel.

Welches Szenario spricht für welchen Server?

Eine feste Regel gibt es allerdings nicht. Wir können aber einen Startbereich aus der Praxis nennen. Er ist keine Garantie, sondern zeigt nur eine Richtung.

• WordPress mit Plugins, die von der .htaccess abhängen: OpenLiteSpeed macht weniger Reibung.
• Sie wollen einen fertigen Seitencache: LSCache ist ein praktischer Weg.
• Ein Team, das Einstellungen in Dateien unter Versionskontrolle hält: Nginx fühlt sich angenehm an.
• Reverse Proxy, Lastverteilung und gemischte Anwendungen: Nginx ist eine gängige Wahl.
• Betreiber ohne Kommandozeilenkenntnisse: Das WebAdmin GUI ist ein Vorteil.

Zudem entscheiden viele Anbieter von Managed Hosting dies für Sie. Ein Etikett „LiteSpeed" oder „Nginx" im Kundenbereich beweist keine Qualität. Support, Backups und Update Disziplin zählen daher mehr.

Wo passen Apache, Varnish und ein CDN ins Bild?

Apache ist der langjährige Server, bei dem die .htaccess entstand. Zum Beispiel laufen viele Shared Hosting Tarife noch auf Apache. Deshalb ist die Apache Kompatibilität von OpenLiteSpeed wichtig.

Varnish ist dagegen eine eigene HTTP Cache Schicht. Die Dokumentation des LSCache Plugins versteht sich als Alternative zu Varnish. Varnish behandeln wir in einem eigenen Beitrag und wiederholen es hier nicht.

Ein CDN liefert eine Kopie aus, die dem Besucher geografisch nahe ist. Somit beschleunigt es statische Dateien, unabhängig vom gewählten Server.

Caching auf Anwendungsebene, also Objekt Caching, ist wieder eine eigene Schicht. Caching erklärt: Redis und Memcached behandelt diese Seite.

Welche Risiken sollten Sie vor einem Serverwechsel kennen?

Der Wechsel von Apache zu OpenLiteSpeed oder Nginx ist mehr als ein Softwaretausch. Weiterleitungen, Sicherheitsheader und Cache Regeln müssen Sie erneut prüfen.

Gehen Sie vor dem Umzug so vor:

1. Erstellen Sie ein vollständiges Backup und testen Sie einmal die Wiederherstellung.
2. Listen Sie Ihre alten .htaccess Regeln auf und legen Sie für jede das Gegenstück fest.
3. Prüfen Sie 301 Weiterleitungen und das 404 Verhalten auf einer Staging Kopie.
4. Nehmen Sie Warenkorb, Konto und Kasse aus den Cache Regeln heraus.
5. Beobachten Sie danach die Crawling Fehler in der Search Console.

Bricht die Weiterleitungskette, können Ihre Rankings leiden. Legen Sie den Wechsel daher auf eine Zeit mit wenig Traffic.

Wer ist für Wartung und Updates zuständig?

Beim Managed Hosting aktualisiert der Anbieter die Serversoftware. Auf dem eigenen VPS liegt diese Pflicht dagegen bei Ihnen, also bei Ihrem Team. Betriebssystem Patches, die Version des Webservers und die PHP Version brauchen regelmäßige Aufmerksamkeit.

Stellen Sie daher bei der Wahl eine weitere Frage: Wer spielt die Patches ein, und wie oft? Ist die Antwort unklar, wird selbst die beste Software zum Risiko.

Außerdem ist die aktuelle stabile Version meist der sicherste Weg. Versionsnummern ändern sich oft, prüfen Sie den aktuellen Stand deshalb auf der offiziellen Download Seite.

Testen Sie Updates zudem nie direkt auf der Live Seite. Probieren Sie sie zuerst an einer Kopie aus und übernehmen Sie sie dann. Haben Sie kein Backup, starten Sie das Update nicht.

Wann sollten Sie es nicht selbst tun und Ihrem Hoster überlassen?

Wir sind ein Team für digitales Marketing und Web, kein Hosting Unternehmen. Daher stützt sich alles hier auf offizielle Dokumentation. Ehrlich gesagt überlässt man manche Aufgaben besser dem Anbieter.

Kümmern Sie sich in diesen Fällen nicht selbst darum:

• Ihre Website bringt direkt Umsatz und Sie können keinen Ausfall verkraften.
• Sie betreiben einen Shop mit Zahlungsseite oder personenbezogenen Daten.
• Zudem haben Sie keine Zeit, Sicherheitspatches regelmäßig einzuspielen.
• Oder Sie haben die Wiederherstellung aus einem Backup noch nie getestet.

Managed Hosting nimmt Ihnen diese Aufgaben ab. Andererseits ist es sinnvoll, auf einem eigenen VPS zu lernen, wenn Sie mit der Kommandozeile vertraut sind und eine Testumgebung haben. Beginnen Sie dann mit einem kleinen Projekt.

Wie wirkt sich die Serverwahl auf SEO und Umsatz aus?

Zunächst bestimmt die Serversoftware Rankings nicht direkt. Dennoch prägen Antwortzeit und Ladezeit das Nutzererlebnis. Das wiederum spiegelt sich indirekt in der Suchleistung.

Details finden Sie in Wie beeinflusst die Ladezeit SEO. Shop Betreiber lesen außerdem Ladezeit im Onlineshop und Umsatz.

Denken Sie daran, dass ein schneller Server seinen Vorteil verliert, wenn er auf ein träges Theme oder schwere Bilder trifft. Machen Sie daher zuerst die Seite selbst schlanker.

Risiken auf Anwendungsebene schließt ein Webserver nie von allein. Dazu passt OWASP Top 10: Sicherheitslücken in Webanwendungen. Welche Technik Ihre Seite heute nutzt, zeigt Ihnen der CMS Checker.

Welche Checkliste sollten Sie vor der Entscheidung nutzen?

Die folgende Liste schärft Ihre Wahl. Dann beantworten Sie jeden Punkt mit Ja oder Nein.

• Läuft meine Seite mit WordPress, und schreiben Plugins Regeln in die .htaccess?
• Möchte ich einen fertigen Cache auf Serverebene?
• Verwalte ich Einstellungen lieber über eine Oberfläche oder über Dateien?
• Wer betreibt den Server, und wen rufe ich bei einer Störung an?
• Sind mein Backup und mein Rückweg bereit?

Zeigen die ersten drei Antworten auf Oberfläche, fertigen Cache und .htaccess, schauen Sie sich OpenLiteSpeed an. Wollen Sie dagegen Kontrolle über Dateien und Flexibilität, schauen Sie sich Nginx an.

Möchten Sie diese Entscheidung zur Infrastruktur gemeinsam mit technischen und Marketing Zielen abwägen, unterstützt Sie unser Webdesign Angebot.