Was ist ein Server?

Das Wort steht für zwei Dinge zugleich. MDN unterscheidet die Hardware, einen mit dem Internet verbundenen Rechner, der die Dateien der Website speichert, also HTML, Bilder, Stylesheets und JavaScript, und die Software. Diese ist mindestens ein HTTP-Server: das Programm, das Webadressen und das Protokoll HTTP versteht und die Inhalte ausliefert.

Der Server ist die andere Hälfte jedes Besuchs. Der Browser ist der Client, der eine Seite anfordert, der Server hat sie und schickt sie. Ein Rechner kann viele Websites beherbergen, und eine große Website kann auf viele Rechner verteilt sein.

Braucht ein Browser eine Datei, fordert er sie per HTTP an. Der Server nimmt die Anfrage entgegen, sucht das Dokument und schickt es zurück, zusammen mit einem Statuscode, zum Beispiel 200, wenn alles geklappt hat, oder 404, wenn es die Seite nicht gibt.

MDN unterscheidet zwei Arten von Webservern. Ein statischer schickt die Dateien so, wie sie gespeichert sind. Ein dynamischer hat zusätzlich einen Anwendungsserver und meist eine Datenbank und baut die Seite bei jeder Anfrage neu, etwa indem er eine HTML-Vorlage mit Inhalten aus der Datenbank füllt. Eine Website mit Tausenden Seiten kann so mit wenigen Vorlagen und einer großen Datenbank auskommen.

Zwischen Nutzer und Ursprungsserver stehen oft weitere Server. Laut MDN ist ein CDN eine Gruppe von Servern an vielen Standorten, die Kopien der Daten speichern und vom Server aus antworten, der dem Nutzer am nächsten ist. Anfragen, die das CDN beantwortet, erreichen den Ursprungsserver nicht mehr.

Die Geschwindigkeit des Servers ist das Erste, was bei einem Besuch zählt. Die TTFB, die Time to First Byte, misst, wie lange es dauert, bis der Anfang der Antwort ankommt. web.dev nennt als grobe Orientierung 0,8 Sekunden oder weniger als guten Wert und mehr als 1,8 Sekunden als schlechten. Die TTFB gehört nicht zu den Core Web Vitals, kommt aber vor ihnen: Braucht der Server lange, beginnt alles andere später.

Der Server bestimmt auch, wie viel Google crawlt. Laut Google berechnen seine Crawler eine Crawling-Kapazitätsgrenze, damit sie den Server nicht überlasten. Antwortet die Website gleichmäßig und bleiben die Antwortzeiten stabil oder werden besser, steigt die Grenze. Wird sie langsamer oder antwortet mit 5xx-Fehlern oder einem 429, sinkt die Grenze, und Google crawlt weniger.

Für zds.es haben wir das am 15. Oktober 2026 gemessen, mit je zehn Anfragen an eine Glossarseite und an eine JavaScript-Datei der Vorlage. Cloudflare kennzeichnet die HTML-Seiten als DYNAMIC, sie beantwortet also der Ursprungsserver: Das erste Byte kam im Schnitt nach 0,17 Sekunden. Die JavaScript-Datei kommt aus dem Cache von Cloudflare und kam nach 0,06 Sekunden. Beide Werte liegen weit unter den 0,8 Sekunden.

• Die TTFB der wichtigen Seiten messen, nicht nur die der Startseite.
• Statische Dateien über ein CDN oder einen Cache ausliefern, damit der Ursprungsserver nur bearbeitet, was sich ändert.
• In der Search Console den Bericht „Crawling-Statistik“ prüfen, der die durchschnittliche Reaktionszeit und den Hoststatus zeigt.
• Ein Hosting mit genug Kapazität für Spitzen bei Besuchern und Crawlern wählen.
• Die Software des Servers aktuell halten.

• Die Geschwindigkeit nur mit vollem Browser-Cache messen und dabei nicht sehen, wie lange der Server braucht.
• Ursprungsserver und CDN verwechseln und das Problem an der falschen Stelle suchen.
• Den Server tagelang 5xx-Fehler liefern lassen, ohne es zu bemerken.
• Crawler mit zu strengen Sicherheitsregeln aussperren.
• Annehmen, ein gutes Hosting gleiche eine sehr schwere Seite aus.