Direkt zum Inhalt

Cookie-Einstellungen

Wählen Sie, welche Arten von Cookies Sie erlauben. Sie können Ihre Auswahl jederzeit über Cookie-Einstellungen unten auf jeder Seite ändern. Datenschutzerklärung

Notwendig

Immer aktiv

Nötig zum Einloggen, für Ihren Warenkorb und um Ihre Auswahl zu speichern. Diese sind immer aktiv.

Welche Cookies?
  • weboke_sessie, weboke_klant, weboke_remember: Ihre Sitzung und eingeloggt bleiben
  • weboke_basket: Ihr Warenkorb
  • wkBtwIncl: Preise mit oder ohne MwSt. anzeigen
  • wok_cookies: Ihre Cookie-Auswahl, 12 Monate

Misst, welche Anzeige zu einem Besuch oder einer Bestellung führt, damit wir nicht für Anzeigen zahlen, die nichts bringen.

Welche Cookies?
  • Google Ads über Google Tag Manager (_gcl_au, _gcl_aw), bis zu 90 Tage
  • OpenAI Ads, Anzeigen in ChatGPT
  • wok_aff: über welchen Partner Sie zu uns kamen (Partnerprogramm), 60 Tage

4,6

Land und Sprache

Jedes Land hat seine eigene Website, mit Preisen und MwSt. dieses Landes.

Anzeigen

Modul 1 · 1.2

Deutsch

Unter der Haube: Webserver, PHP und Datenbank

Modul 1: Wie WordPress funktioniert · Lesezeit: 8 Minuten

Lernziel: Nach dieser Lektion können Sie Schritt für Schritt erklären, wie aus einer Seitenanfrage bei WordPress eine HTML-Seite wird, und wo ein Cache diesen Weg abkürzt.

Kernbegriffe: Webserver (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, Query, index.php, Template-Hierarchie, dynamisch vs. statisch, TTFB

Eine statische und eine dynamische Seite

Bei einer statischen Website liegt jede Seite als fertige Datei auf dem Server. Der Webserver nimmt die Datei und sendet sie ab. Das ist schnell und einfach, aber jede Änderung bedeutet eine neue Datei.

WordPress ist dynamisch: Die Seite entsteht erst in dem Moment, in dem jemand sie anfragt. Es gibt keine Datei contact.html. Es gibt einen Text in der Datenbank, ein Theme mit Templates und einen Stapel PHP-Code, der beides zusammenfügt. Das bringt Komfort (Sie passen den Text in Ihrem Browser an), kostet aber bei jedem Besuch Rechenarbeit. Wenn Sie diese Rechenarbeit verstehen, verstehen Sie später auch, warum eine Website langsam ist, warum Caching so viel ausmacht und warum ein PHP-Upgrade etwas kaputt machen kann.

Die Reise einer Seitenanfrage

Stellen Sie sich vor: Ein Besucher öffnet https://example.com/contact/. Das passiert dabei:

  1. DNS: Der Browser sucht die IP-Adresse von example.com (siehe den DNS-Kurs). Er baut eine gesicherte Verbindung zu dieser Adresse auf.
  2. Webserver: Auf dem Server läuft ein Webserver, zum Beispiel LiteSpeed, Apache oder nginx. Dieser empfängt die Anfrage. Existiert eine echte Datei oder ein Verzeichnis mit diesem Namen (ein Bild, ein Stylesheet), sendet er es direkt. Falls nicht, gilt die Regel aus .htaccess (bei LiteSpeed und Apache) oder aus der nginx-Konfiguration: „gib alles, was nicht existiert, an index.php weiter".
  3. PHP: index.php ist eine PHP-Datei. Der Webserver lässt sie von PHP ausführen, der Programmiersprache, in der WordPress geschrieben ist. PHP lädt zuerst wp-config.php (die Einstellungen mit den Datenbankzugangsdaten), dann den Rest von WordPress, dann alle aktiven Plugins und das aktive Theme.
  4. Datenbank: WordPress ermittelt, welcher Inhalt zu /contact/ gehört, und stellt der Datenbank (MariaDB oder MySQL) Fragen: Welche Seite hat den Slug contact, was sind die Einstellungen der Website, welches Menü gehört dazu? So eine Frage heißt Query. Eine einfache Seite kostet schnell Dutzende Queries; mit Plugins können es Hunderte werden.
  5. Theme: WordPress wählt aus, welches Template des Themes die Seite gestaltet. Das geschieht nach der Template-Hierarchie: Für eine Seite mit dem Slug contact sucht WordPress zuerst ein Template page-contact, dann page-<id> (die Nummer der Seite), dann page, dann singular und schließlich index. Das erste, das existiert, gewinnt.
  6. HTML zurück: Das Ergebnis ist eine HTML-Seite, die PHP an den Webserver übergibt, und der Webserver an den Browser.
  7. Der Browser liest das HTML und holt danach noch die Stylesheets, Scripts, Schriftarten und Bilder ab. Das sind gewöhnliche Dateien, die also direkt vom Webserver kommen (oder aus einem Cache).

Zwischen Schritt 2 und Schritt 6 liegt die Zeit, die der Server benötigt, um die Seite zu erstellen. Das sehen Sie als TTFB (time to first byte): die Zeit zwischen der Anfrage und dem ersten Byte der Antwort. Bei einer gut eingerichteten Website liegt diese deutlich unter einer Sekunde. In Modul 6 messen Sie das selbst.

Warum jedes Plugin mitzählt

Bei Schritt 3 werden alle aktiven Plugins geladen, bei jeder Anfrage. Auch wenn dieses Plugin auf dieser Seite nichts tut. Ein Plugin für eine Fotogalerie wird also auch geladen, wenn jemand Ihre Kontaktseite öffnet. Jedes Plugin kann zusätzliche Queries ausführen, zusätzlichen Code laden und zusätzliche Scripts zur Seite hinzufügen.

Das erklärt zwei Dinge, die Ihnen in diesem Kurs öfter begegnen:

  • Weniger Plugins ist meistens schneller. Nicht weil die Anzahl an sich zählt, sondern weil jedes Plugin bei jeder Anfrage Arbeit leisten kann.
  • Ein kaputtes Plugin kann die ganze Website lahmlegen. Geht in Schritt 3 etwas schief (zum Beispiel ein Plugin, das nicht mit der neuen PHP-Version funktioniert), kommt PHP nie bei Schritt 6 an. Der Besucher bekommt eine weiße Seite oder die Meldung „Es gab einen kritischen Fehler auf dieser Website" (Lektion 5.4).

Woher PHP und die Datenbank kommen

PHP und die Datenbank laufen auf dem Server Ihres Hosters. Sie wählen meist selbst die PHP-Version im Kontrollpanel (bei DirectAdmin heißt das Select PHP version, siehe Lektion 8.4). Die Datenbank legen Sie bei der Installation an; der Installer erledigt das oft für Sie (Lektion 2.2).

Ein paar Dinge zum Merken:

  • PHP-Version: Jede neue PHP-Version ist schneller und sicherer, aber alter Code kann daran scheitern. wordpress.org empfiehlt derzeit PHP 8.3 oder höher (Stand November 2026).
  • Datenbank: wordpress.org empfiehlt MariaDB 10.11 oder höher, oder MySQL 8.0 oder höher. MariaDB ist ein Ableger von MySQL; für WordPress macht das keinen Unterschied.
  • Die Datenbank liegt meist auf demselben Server (DB_HOST ist dann localhost). Bei größerem Hosting kann sie auf einem separaten Server liegen.

Cache: der Weg wird abgekürzt

Wenn hundert Besucher dieselbe Kontaktseite anfragen, erstellt WordPress sie ohne Cache hundertmal neu. Jedes Mal dieselben Queries, dasselbe Template, dasselbe HTML. Ein Seiten-Cache speichert das HTML nach dem ersten Mal. Der nächste Besucher erhält die gespeicherte Version: Schritt 3 bis einschließlich 6 entfallen.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

Deshalb bringt Caching den größten Geschwindigkeitsgewinn (Lektion 6.2). Es erklärt auch eine häufig gehörte Verwirrung: „Ich habe den Text angepasst, sehe aber noch die alte Version." Dann sehen Sie eine gespeicherte Version; nach dem Leeren des Caches sehen Sie die neue.

Nicht alles darf aus einem Cache kommen. Ein eingeloggter Administrator, ein Warenkorb oder eine Kassenseite ist für jeden Besucher anders. Ein gutes Cache-Plugin lässt diese aus.

Header: was der Server Ihnen mitteilt

Jede Antwort eines Webservers beginnt mit Headern, vor dem HTML. Diese sehen Sie nicht auf der Seite, wohl aber in den Entwicklertools Ihres Browsers (F12, Reiter Netzwerk, klicken Sie auf die erste Anfrage). Ein Beispiel:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit
  • server sagt, welcher Webserver antwortet.
  • link mit wp-json verrät, dass es sich um WordPress handelt.
  • x-litespeed-cache: hit bedeutet, dass diese Seite aus dem LiteSpeed-Cache kam. Andere Caches nutzen andere Namen, wie x-cache: HIT oder cf-cache-status: HIT bei Cloudflare.

Sie müssen diese Zeilen nicht auswendig kennen. Aber wer sie lesen kann, findet viele Probleme selbst.

Zusammenfassung

  • WordPress erstellt jede Seite im Moment der Anfrage: Webserver, PHP, Plugins, Datenbank, Theme, HTML.
  • Bei jeder Anfrage werden alle aktiven Plugins geladen; ein kaputtes Plugin kann die ganze Website stoppen.
  • Die Template-Hierarchie bestimmt, welches Template des Themes eine Seite gestaltet.
  • Ein Seiten-Cache überspringt die Rechenarbeit, indem er gespeichertes HTML liefert. Eingeloggte Benutzer und Warenkörbe gehören nicht in diesen Cache.
  • Die Header einer Antwort verraten, welcher Webserver antwortet und ob die Seite aus einem Cache kam.

Quiz

1. Wer führt den PHP-Code von WordPress aus?



2. Eine Website mit 40 Plugins ist langsam, auch auf Seiten, auf denen diese Plugins nichts Sichtbares tun. Was ist die beste Erklärung?



3. Woher kommt ein Stylesheet wie /wp-content/themes/thema/style.css meistens?



4. Sie sehen in den Headern x-litespeed-cache: hit. Was bedeutet das?



5. Welches Template verwendet WordPress für eine Seite mit dem Slug contact, wenn das Theme nur page und index hat?



Aufgabe

Aufgabe A1.2: Lesen Sie die Header Ihrer Website. Öffnen Sie Ihre eigene Website (oder wordpress.org) mit den Entwicklertools Ihres Browsers (F12, Reiter Netzwerk, laden Sie die Seite neu, klicken Sie auf die erste Anfrage). Tragen Sie ein, welcher Webserver im Header server steht (oder „keiner", falls dieser fehlt) und ob es einen Header gibt, der angibt, dass die Seite aus einem Cache kam (welcher Name und welcher Wert). Das Programm ruft dieselbe Seite ab und vergleicht.

Aufgabe A1.2: Lesen Sie die Header Ihrer Website




Was Sie eingeben und was wir finden, speichern wir nicht. Ihr Browser merkt sich Ihre Antworten und ob Sie die Aufgabe bestanden haben. Sind Sie angemeldet, speichern wir in Meine Kurse nur, dass Sie die Aufgabe (fast) richtig hatten; auch das können Sie dort löschen.

Weiterführende Informationen

Diese Artikel beschreiben die Schritte in den Panels von WebOké; in anderen Panels funktionieren sie ähnlich.

Einen Moment bitte…

Richten Sie Ihre Domains ein

Legen Sie für jede Domain die Nameserver, die Verknüpfung mit Ihrem Hosting und den künftigen Inhaber fest.

Ihre Domains werden geladen…