HTTP-Header-Check

Was sind HTTP-Header?

HTTP-Header sind Metadaten, die bei jeder HTTP-Anfrage und -Antwort zwischen Browser und Webserver mitgesendet werden. Sie enthalten wichtige Informationen zu Sicherheit, Caching, Komprimierung und dazu, wie der Browser mit dem Inhalt umgehen soll. Mit unserem kostenlosen HTTP-Header-Check analysieren Sie alle Header einer beliebigen Website und sehen sofort mögliche Sicherheitsrisiken und Optimierungspotenzial.

Header sind für Besucher unsichtbar, spielen aber eine entscheidende Rolle für die Funktionsweise des modernen Webs. Jedes Mal, wenn Ihr Browser eine Website anfordert, werden Dutzende Header ausgetauscht. Der Browser sendet Request-Header (wie User-Agent, Accept-Language) und der Server antwortet mit Response-Headern (wie Content-Type, Cache-Control, Security-Header). Dieser Austausch bestimmt, wie Inhalte angezeigt, gecacht und abgesichert werden.

Es gibt mehrere Kategorien von Headern: Security-Header, die vor Angriffen schützen, Caching-Header, die die Performance verbessern, Content-Header, die Typ und Kodierung festlegen, und CORS-Header, die Cross-Origin-Anfragen regeln. Ein gründlicher HTTP-Header-Check gibt Ihnen Einblick in alle Kategorien und zeigt, wo Verbesserungen möglich sind.

Warum sind Security-Header wichtig?

Security-Header sind eine entscheidende Verteidigungslinie gegen gängige Webangriffe. Sie bilden eine zusätzliche Sicherheitsebene über Ihrem Anwendungscode und schützen sowohl Ihre Website als auch Ihre Besucher. Selbst bei perfekt abgesichertem Code können fehlende Security-Header Sie angreifbar machen. Unser HTTP-Header-Check prüft alle wichtigen Security-Header und gibt Ihnen konkrete Empfehlungen.

Security-Header schützen Ihre Website und Ihre Besucher vor:

• XSS-Angriffen (Cross-Site Scripting): Mit Content-Security-Policy (CSP) verhindern Sie, dass schädliche Skripte ausgeführt werden
• Clickjacking: Mit X-Frame-Options schützen Sie sich vor unsichtbaren iframes, die Klicks abfangen
• Man-in-the-Middle-Angriffen: Mit HSTS erzwingen Sie verschlüsselte HTTPS-Verbindungen
• MIME-Sniffing-Angriffen: Mit X-Content-Type-Options verhindern Sie, dass Browser Inhaltstypen erraten
• Cross-Origin-Angriffen: Mit COOP- und CORP-Headern isolieren Sie Ihre Website von anderen Origins
• Referrer-Lecks: Mit Referrer-Policy steuern Sie, welche Informationen weitergegeben werden
• Missbrauch von Browserfunktionen: Mit Permissions-Policy beschränken Sie den Zugriff auf sensible Browser-APIs

Ohne die richtigen Security-Header ist Ihre Website angreifbar, selbst wenn der Code an sich sicher ist. Sicherheitsforscher und Penetrationstester prüfen immer zuerst die HTTP-Header, um Schwachstellen zu finden. Große Tech-Unternehmen wie Google, Facebook und Microsoft setzen strenge Richtlinien für Security-Header durch. Mit unserem Tool führen Sie dieselben Prüfungen durch wie bei einem professionellen Sicherheitsaudit.

Die wichtigsten Security-Header erklärt

Strict-Transport-Security (HSTS): Dieser Header zwingt Browser, ausschließlich über HTTPS eine Verbindung zu Ihrer Website herzustellen. Er verhindert, dass Angreifer Nutzer auf unsicheren HTTP-Verkehr herabstufen (SSL-Stripping-Angriffe). Sobald ein Browser diesen Header empfangen hat, wandelt er für den angegebenen Zeitraum alle HTTP-Anfragen automatisch in HTTPS um, selbst wenn der Nutzer ausdrücklich http:// eingibt. Empfohlene Konfiguration: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Der Wert max-age legt fest, wie lange (in Sekunden) sich der Browser dies merken soll, includeSubDomains wendet die Regel auf alle Subdomains an und preload macht Ihre Website für die HSTS-Preload-Liste der Browser geeignet.

Content-Security-Policy (CSP): Der wirkungsvollste Security-Header gegen XSS-Angriffe. CSP legt fest, welche Quellen (Skripte, Stylesheets, Bilder, Schriften) der Browser laden und ausführen darf. So wird verhindert, dass eingeschleuste schädliche Skripte ausgeführt werden, selbst wenn es einem Angreifer gelingt, Code in Ihr HTML einzuschleusen. Eine einfache CSP kann so aussehen: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'. Für maximale Sicherheit vermeiden Sie 'unsafe-inline' und verwenden Nonces oder Hashes.

X-Frame-Options: Verhindert, dass Ihre Website in einem iframe geladen wird, und wirkt so Clickjacking-Angriffen entgegen. Beim Clickjacking platziert ein Angreifer Ihre Website in einem unsichtbaren iframe über einer gefälschten Oberfläche, sodass Nutzer unbemerkt Aktionen auf Ihrer Website ausführen. Verwenden Sie X-Frame-Options: DENY, um jegliches Framing zu blockieren, oder X-Frame-Options: SAMEORIGIN, um Framing nur von Ihrer eigenen Domain zu erlauben. Für moderne Browser ist Content-Security-Policy: frame-ancestors 'none' eine flexiblere Lösung.

X-Content-Type-Options: Verhindert MIME-Sniffing, indem der Browser angewiesen wird, den angegebenen Inhaltstyp zu respektieren. Browser versuchen manchmal, den Inhaltstyp zu „erraten“, wenn er nicht eindeutig ist, was zu Sicherheitsproblemen führen kann. Eine text/plain-Datei könnte beispielsweise als JavaScript interpretiert werden, wenn sie ausführbaren Code enthält. Verwenden Sie immer X-Content-Type-Options: nosniff, um dies zu verhindern.

Alle Security-Header im Überblick

Eine vollständige Übersicht aller wichtigen Security-Header, die Sie für maximalen Schutz einsetzen können. Alle diese Header werden von unserem HTTP-Header-Check geprüft:

Content-Security-Policy im Detail

Content-Security-Policy (CSP) ist der komplexeste, aber auch der wirkungsvollste Security-Header. Eine gut konfigurierte CSP kann XSS-Angriffe nahezu vollständig ausschließen. CSP arbeitet mit Direktiven, die für jeden Inhaltstyp festlegen, welche Quellen erlaubt sind.

Wichtige CSP-Direktiven:

• default-src: Standardrichtlinie für alle Ressourcentypen. Andere Direktiven erben davon.
• script-src: Legt fest, welche JavaScript-Quellen geladen und ausgeführt werden dürfen. Entscheidend für den XSS-Schutz.
• style-src: Steuert, welche Stylesheets und Inline-Styles erlaubt sind.
• img-src: Legt fest, aus welchen Quellen Bilder geladen werden dürfen.
• font-src: Steuert erlaubte Quellen für Schriften.
• connect-src: Beschränkt, welche URLs über fetch, XMLHttpRequest und WebSocket erreichbar sind.
• frame-src: Legt fest, welche URLs in Frames geladen werden dürfen (ähnlich wie X-Frame-Options, aber für eingebettete Inhalte).
• media-src: Steuert die Quellen für Audio- und Video-Elemente.
• object-src: Legt erlaubte Quellen für <object>-, <embed>- und <applet>-Elemente fest.

CSP-Quellwerte: Jede Direktive akzeptiert eine Liste erlaubter Quellen. Sie können Folgendes verwenden: 'self' (Ihre eigene Domain), 'none' (nichts erlaubt), bestimmte Domains wie https://cdn.beispiel.de, 'unsafe-inline' (Inline-Skripte/-Styles, unsicher), 'unsafe-eval' (die Funktion eval(), unsicher) oder Nonces/Hashes für bestimmte Inline-Skripte.

Nonces und Hashes: Für maximale Sicherheit vermeiden Sie 'unsafe-inline' und verwenden stattdessen Nonces oder Hashes. Eine Nonce ist ein eindeutiger Zufallswert, den Sie pro Anfrage erzeugen und sowohl in den CSP-Header als auch in das Script-Tag einfügen: Content-Security-Policy: script-src 'nonce-abc123' und <script nonce="abc123">. Hashes sind SHA-256/384/512-Hashes des exakten Skriptinhalts: script-src 'sha256-xyz...'.

Report-URI und Reporting: CSP kann Verstöße an einen Endpunkt melden: report-uri /csp-report oder mit der moderneren Direktive report-to. So können Sie überwachen, ob legitime Inhalte blockiert werden und ob es Angriffsversuche gibt. Beginnen Sie immer mit Content-Security-Policy-Report-Only, um zu testen, ohne Inhalte zu blockieren.

Performance- und Caching-Header

Neben der Sicherheit analysiert unser HTTP-Header-Check auch Performance- und Caching-Header, die für schnelle Websites entscheidend sind:

• Content-Encoding: Prüft, ob Komprimierung aktiv ist. Moderne Websites nutzen gzip- oder Brotli-Komprimierung, um Textdateien (HTML, CSS, JavaScript) um 70 bis 80 % zu verkleinern. Content-Encoding: br (Brotli) komprimiert besser als gzip, wird aber nicht von jedem Browser unterstützt. Content-Encoding: gzip ist die sichere Wahl, die überall funktioniert. Ohne Komprimierung laden Seiten deutlich langsamer, vor allem bei mobilen Verbindungen.
• Cache-Control: Analysiert die Cache-Einstellungen für optimale Performance. Dieser Header bestimmt, wie lange Browser und CDNs Inhalte cachen dürfen. Für statische Assets (CSS, JS, Bilder) verwenden Sie Cache-Control: public, max-age=31536000, immutable, um sie ein Jahr lang zu cachen. Für dynamische Inhalte verwenden Sie Cache-Control: private, max-age=0, must-revalidate. Die richtige Cache-Strategie kann Ihre Serverlast um 90 % senken und die Ladezeiten drastisch verbessern.
• ETag: Prüft, ob die Cache-Validierung aktiviert ist. Ein ETag ist eine eindeutige Kennung für eine bestimmte Version einer Ressource. Hat ein Browser Inhalte im Cache, sendet er das ETag in einem If-None-Match-Header. Hat sich der Inhalt nicht geändert, antwortet der Server mit 304 Not Modified, ohne den vollständigen Inhalt zu senden, was Bandbreite spart.
• Vary: Zeigt, welche Request-Header das Caching beeinflussen. Vary: Accept-Encoding weist Caches an, sowohl komprimierte als auch unkomprimierte Versionen zu speichern. Vary: User-Agent cacht unterschiedliche Versionen pro Browsertyp (oft unnötig und ineffizient). Für moderne responsive Websites reicht Vary: Accept-Encoding in der Regel aus.
• Last-Modified: Gibt an, wann der Inhalt zuletzt geändert wurde, und arbeitet für die Cache-Validierung mit If-Modified-Since zusammen.

Die richtigen Caching-Header können Ihre Website deutlich schneller machen, die Serverlast verringern und die Bandbreitenkosten drastisch senken. Für WordPress-Hosting oder andere CMS-Plattformen sind gute Cache-Header für die Performance unverzichtbar.

Wie verbessern Sie Ihren Sicherheitsscore?

Nach einem HTTP-Header-Check gibt unser Tool pro Kategorie einen Score und konkrete Empfehlungen aus. Security-Header können Sie auf verschiedene Weise einrichten:

1. Webserver-Konfiguration: Die effizienteste Methode ist, Header auf Webserver-Ebene zu setzen. Für Apache (.htaccess), Nginx oder IIS können Sie Header hinzufügen, die für alle Anfragen gelten. Das ist schneller als Header auf Anwendungsebene, weil der Webserver sie direkt hinzufügt, ohne PHP oder anderen Anwendungscode auszuführen. Mit VPS-Hosting haben Sie die volle Kontrolle über die Webserver-Konfiguration.

2. Anwendungscode: In PHP, Node.js, Python oder anderen Sprachen können Sie Header programmatisch hinzufügen. Das bietet mehr Flexibilität (zum Beispiel unterschiedliche CSP-Richtlinien pro Seite), ist aber etwas langsamer. Für WordPress-Websites können Sie Header über functions.php oder Sicherheits-Plugins hinzufügen.

3. CDN-/Proxy-Ebene: Dienste wie Cloudflare, AWS CloudFront oder andere CDNs können Header hinzufügen oder ändern. Das ist ideal für Websites, die bereits ein CDN nutzen. Cloudflare bietet zum Beispiel einfache „Transform Rules“, um Header hinzuzufügen.

4. CMS-Plugins: Für WordPress gibt es ausgezeichnete Sicherheits-Plugins, die Header automatisch konfigurieren, etwa Really Simple SSL, Security Headers oder All In One WP Security. Diese Plugins bieten eine benutzerfreundliche Oberfläche, sodass Sie keine Konfigurationsdateien bearbeiten müssen.

Beginnen Sie mit den wichtigsten Headern (HSTS, CSP, X-Frame-Options, X-Content-Type-Options) und ergänzen Sie danach weitere Security-Header wie Referrer-Policy und Permissions-Policy. Testen Sie nach dem Hinzufügen von Headern immer gründlich; vor allem CSP kann legitime Funktionen blockieren, wenn sie zu streng konfiguriert ist.

HTTP-Header für WordPress

Für WordPress-Websites gelten bei HTTP-Headern besondere Punkte. Standardmäßig sendet WordPress nur minimale Security-Header, Sie müssen sie also selbst hinzufügen. Es gibt drei Möglichkeiten, Header zu WordPress hinzuzufügen:

Methode 1: Über .htaccess (Apache): Läuft Ihre Website auf Apache (die meisten Webhosting-Pakete), fügen Sie diese Regeln in die Datei .htaccess im WordPress-Stammverzeichnis ein:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
</IfModule>

Hinweis: Diese CSP ist mit 'unsafe-inline' und 'unsafe-eval' relativ großzügig, weil WordPress und viele Plugins Inline-Skripte verwenden. Für eine strengere CSP müssen Sie gegebenenfalls Plugin-Code anpassen.

Methode 2: Über wp-config.php: Sie können Header in wp-config.php hinzufügen (fügen Sie dies vor der Zeile „That's all, stop editing!“ ein):

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Frame-Options: SAMEORIGIN');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');

Methode 3: Über functions.php: Fügen Sie in der functions.php Ihres Themes (oder in einem eigenen Plugin) diese Funktion hinzu:

function add_security_headers() {
  header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
}
add_action('send_headers', 'add_security_headers');

WordPress-Plugins: Für eine benutzerfreundlichere Einrichtung können Sie Plugins wie „HTTP Headers“ (von Dimitar Ivanov) oder „Security Headers“ verwenden, die eine grafische Oberfläche zur Konfiguration von Headern bieten. Auch Really Simple SSL fügt nach der Aktivierung automatisch einige Security-Header hinzu. Für WordPress-Hosting bei Theory7 können Sie sich für Hilfe bei der Konfiguration von Headern auch an den Support wenden.

HTTP-Header für Apache und Nginx

Die Konfiguration von HTTP-Headern unterscheidet sich zwischen den Webservern Apache und Nginx. Beide sind leistungsstarke Optionen, aber die Syntax ist unterschiedlich.

Apache-Konfiguration (.htaccess oder httpd.conf):

Für Apache verwenden Sie das Modul mod_headers. Fügen Sie Folgendes in die .htaccess oder Ihre Virtual-Host-Konfiguration ein:

<IfModule mod_headers.c>
  # Security headers
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'"

  # Performance headers
  Header always set Cache-Control "public, max-age=31536000, immutable" "expr=%{REQUEST_URI} =~ m#\.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$#"
  Header always set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#\.(html|php)$#"
</IfModule>

Stellen Sie sicher, dass mod_headers aktiviert ist: a2enmod headers, und starten Sie Apache anschließend neu.

Nginx-Konfiguration (nginx.conf oder Server-Block):

Bei Nginx fügen Sie Header in Ihrem Server-Block oder im Location-Kontext hinzu:

server {
  # Security headers
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'" always;

  # Static assets caching
  location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    expires 1y;
  }

  # Dynamic content
  location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
}

Testen Sie die Konfiguration nach Änderungen mit nginx -t und laden Sie sie mit nginx -s reload neu. Das Schlüsselwort always sorgt dafür, dass Header auch bei Fehlerantworten (4xx, 5xx) hinzugefügt werden.

Für beide Webserver gilt: Testen Sie nach dem Hinzufügen von Headern gründlich mit unserem HTTP-Header-Check und prüfen Sie, ob Ihre Website weiterhin korrekt funktioniert.

HTTP-Statuscodes

HTTP-Statuscodes werden über Header gesendet und zeigen an, ob eine Anfrage erfolgreich war. Unser Tool zeigt bei jeder Prüfung den Statuscode an. Häufige Codes:

Der Statuscode steht in der ersten Zeile der Response-Header, zum Beispiel HTTP/1.1 200 OK. Bei Weiterleitungen (301/302) wird die neue Adresse im Header Location angegeben. Bei Fehlern senden Server oft einen Header Content-Type: text/html mit einer Fehlerseite. Korrekte Statuscodes sind für SEO entscheidend: Verwenden Sie 301 für dauerhafte Weiterleitungen und sorgen Sie dafür, dass gelöschte Seiten 404 zurückgeben (nicht 200).

CORS-Header erklärt

CORS-Header (Cross-Origin Resource Sharing) bestimmen, ob eine Website Ressourcen von einer anderen Domain laden darf. Browser blockieren Cross-Origin-Anfragen aus Sicherheitsgründen standardmäßig. CORS-Header erteilen dafür eine ausdrückliche Erlaubnis.

Access-Control-Allow-Origin: Der wichtigste CORS-Header. Er legt fest, welche Origins Zugriff auf Ihre Ressourcen haben. Access-Control-Allow-Origin: * erlaubt alle Origins (gefährlich für sensible APIs), Access-Control-Allow-Origin: https://beispiel.de erlaubt nur diese eine Domain. Für APIs, die aus dem Browser aufgerufen werden (z. B. AJAX-Anfragen), muss dieser Header korrekt gesetzt sein.

Access-Control-Allow-Methods: Gibt an, welche HTTP-Methoden erlaubt sind: Access-Control-Allow-Methods: GET, POST, PUT, DELETE. Standardmäßig sind bei einfachen Anfragen nur GET und POST erlaubt.

Access-Control-Allow-Headers: Legt fest, welche Request-Header der Client senden darf: Access-Control-Allow-Headers: Content-Type, Authorization. Erforderlich für eigene Header oder Authentifizierungstokens.

Access-Control-Allow-Credentials: Bestimmt, ob Cookies und Authentifizierungs-Header mitgesendet werden dürfen: Access-Control-Allow-Credentials: true. Ist dieser Wert true, darf Access-Control-Allow-Origin nicht * sein.

Preflight-Anfragen: Bei „nicht einfachen“ Anfragen (z. B. PUT, DELETE oder eigene Header) sendet der Browser zuerst eine OPTIONS-Anfrage (Preflight), um zu prüfen, ob die Anfrage erlaubt ist. Der Server muss dann mit den richtigen CORS-Headern antworten. Eine Preflight-Antwort sieht so aus:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://beispiel.de
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Der Header Access-Control-Max-Age gibt an, wie lange (in Sekunden) die Preflight-Antwort gecacht werden darf, was die Performance verbessert. Für Web-APIs und SSL-gesicherte Endpunkte sind korrekte CORS-Header unverzichtbar.

HTTP/2- und HTTP/3-Header

Die modernen Protokolle HTTP/2 und HTTP/3 verarbeiten Header effizienter als HTTP/1.1, Namen und Werte der Header bleiben aber weitgehend gleich. Unser HTTP-Header-Check funktioniert mit allen HTTP-Versionen.

Verbesserungen in HTTP/2: HTTP/2 führt die Header-Komprimierung HPACK ein, wodurch Header erheblich kleiner werden. Header werden mit Huffman-Kodierung und einer statischen/dynamischen Tabelle häufiger Header kodiert. Das spart Bandbreite, weil zum Beispiel Content-Type: text/html als einzelnes Byte statt als 24 Byte kodiert wird. HTTP/2 unterstützt außerdem Multiplexing, sodass mehrere Anfragen dieselbe Verbindung teilen und der Header-Overhead weiter sinkt.

Pseudo-Header in HTTP/2: HTTP/2 verwendet spezielle Pseudo-Header, die mit einem Doppelpunkt beginnen: :method, :path, :scheme, :authority. Sie ersetzen die erste Zeile von HTTP/1.1-Anfragen (GET /path HTTP/1.1). Für Entwickler sind sie meist unsichtbar, weil Bibliotheken dies automatisch übernehmen.

HTTP/3 und QUIC: HTTP/3 baut auf HTTP/2 auf, verwendet als Transportprotokoll aber QUIC statt TCP. Header funktionieren genauso wie bei HTTP/2, doch QPACK (eine verbesserte Version von HPACK) bietet eine noch bessere Komprimierung und kommt besser mit Paketverlust zurecht. HTTP/3 nutzt UDP statt TCP, was die Latenz verringert, weil kein TCP-Handshake nötig ist.

Server Push (HTTP/2): HTTP/2 unterstützt Server Push, bei dem der Server Ressourcen proaktiv sendet, bevor der Browser sie anfordert. Das funktioniert über den Header Link mit rel=preload: Link: </style.css>; rel=preload; as=style. Server Push ist experimentell und wird nicht von allen CDNs unterstützt. In HTTP/3 wurde Push zugunsten von Early Hints (HTTP 103) aufgegeben.

Hinweise zur Migration: Wenn Sie auf HTTP/2 oder HTTP/3 umstellen, funktionieren Ihre Security-, Caching- und CORS-Header genau wie bisher. Die Protokolle sind auf Header-Ebene abwärtskompatibel. Ihre SSL/TLS-Zertifikate müssen Sie allerdings korrekt konfigurieren, weil HTTP/2 und HTTP/3 HTTPS voraussetzen. Für einen VPS oder dedizierte Server benötigen Sie für HTTP/2-Unterstützung nginx 1.9.5+ oder Apache 2.4.17+.

Prüfen Sie mit unserem Tool, welches Protokoll Ihre Website verwendet: Die HTTP-Version wird in den Response-Headern angezeigt. HTTP/2 und HTTP/3 können die Ladezeiten um 20 bis 50 % verbessern, vor allem bei Websites mit vielen kleinen Ressourcen.