Zum Artikel springen
Performance20. Okt. 20263 Min. Lesezeit

HTTP/2 und Brotli in Next.js: Einrichtung und Prüfung

Prüfen Sie Protokoll und Komprimierung einer Next.js-Anwendung. Unterscheiden Sie HTTPS, HTTP/2, Prefetching und Server Push und messen Sie die Wirkung.

HTTP/2 und Brotli in Next.js: Einrichtung und Prüfung

HTTP/2 und Komprimierung können die Übertragung verkürzen und Ladezeiten wie LCP verbessern. Sie beheben allein weder Layoutverschiebungen noch garantieren sie bessere Suchpositionen. Prüfen Sie Übertragung, Darstellung und Bedienung getrennt.

HTTP/2 und HTTPS richtig einordnen

HTTP/2 bündelt mehrere Anfrageströme in einer Verbindung und reduziert Blockierungen auf HTTP-Ebene. Da es TCP nutzt, kann Paketverlust weiterhin mehrere Streams verzögern. HTTP/3 wird bereits eingesetzt und nutzt einen anderen Transport. Entscheidend sind Hosting-Unterstützung und Messwerte.

Browser nutzen HTTP/2 über TLS. Prüfen Sie bei Vercel oder anderem Managed Hosting das tatsächlich ausgehandelte Protokoll. Beim Selbsthosting kann ein Reverse Proxy oder CDN TLS und HTTP/2 vor Next.js übernehmen. Das Node.js-Modul https aktiviert allein kein HTTP/2.

Ein Zertifikat für einen lokalen HTTPS-Versuch mit localhost lässt sich so erzeugen. Es ist nicht für die Produktion bestimmt:

openssl req -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -days 365 -subj '/CN=localhost' -addext 'subjectAltName=DNS:localhost'

Dieser Custom Server zeigt HTTPS mit HTTP/1.1, keine HTTP/2-Bereitstellung. Er benötigt ein bestehendes Next.js-Projekt und im Produktionsmodus einen fertigen Build. Nutzen Sie normalerweise den Standardserver hinter einem Proxy.

import next from 'next'
import fs from 'node:fs'
import https from 'node:https'

const app = next({ dev: process.env.NODE_ENV !== 'production', port: 3000 })
const handle = app.getRequestHandler()

async function startServer() {
	await app.prepare()

	https
		.createServer(
			{
				cert: fs.readFileSync('./cert.pem'),
				key: fs.readFileSync('./key.pem'),
			},
			async (request, response) => {
				await handle(request, response)
			},
		)
		.listen(3000)

	console.info(`Ready on https://localhost:3000`)
}

startServer()

Protokoll und Komprimierung prüfen

Kontrollieren Sie die Spalte Protocol in Chrome DevTools Network. Bei einem curl-Build mit HTTP/2-Unterstützung zeigt der erste Befehl das verwendete Protokoll; ein Fallback ist möglich. Der zweite prüft die Header einer GET-Antwort mit angebotener Brotli- und gzip-Unterstützung.

curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://your-site.com
curl -sS -D - -o /dev/null -H 'Accept-Encoding: br, gzip' https://your-site.com

Brotli und gzip konfigurieren

Mit next start komprimiert Next.js standardmäßig mit gzip. Brotli kann kleinere Textantworten liefern; eine pauschale Einsparung von 20–25 % gilt nicht. Prüfen Sie beim Managed Hosting die Antworten. Beim Selbsthosting konfigurieren Sie Brotli auf einem geeigneten Proxy oder CDN.

Deaktivieren Sie die Next.js-Komprimierung nur, wenn eine andere Ebene sie bereits übernimmt. Folgende Einstellung aktiviert selbst kein Brotli:

// next.config.mjs
export default {
  compress: false,
}

Eine Brotli-Antwort kann diese Header enthalten:

Content-Encoding: br
Vary: Accept-Encoding

Setzen Sie Content-Encoding niemals für einen unkomprimierten Inhalt. Prüfen Sie Fallbacks und die Behandlung von Accept-Encoding im Cache. Die folgenden Größen sind illustrative Beispiele, keine Messung oder Zusage:

FormatJavaScript ursprünglichKomprimiert im Beispiel
Gzip100 KB30 KB
Brotli100 KB22 KB

Prefetching statt Verwechslung mit Server Push

Next.js Link kann Routenressourcen vorab anfordern. Dabei sendet der Browser eine Anfrage; das ist kein HTTP/2 Server Push. Chrome hat Server Push ab Version 106 standardmäßig deaktiviert. Bauen Sie eine aktuelle Optimierung nicht darauf auf.

import Link from 'next/link'

export default function AboutLink() {
  return <Link href="/about" prefetch>About</Link>
}

Für eine nachweislich kritische Schrift kann Preload sinnvoll sein. Ersetzen Sie die Beispiel-URL und stimmen Sie Typ und Cross-Origin-Einstellungen ab:

<link rel="preload" href="/fonts/site.woff2" as="font" type="font/woff2" crossorigin>

Prefetch und Preload verbrauchen Bandbreite. Es gibt keine allgemeine Grenze von fünf oder sechs Ressourcen. Behalten Sie nur Hinweise mit nachgewiesenem Nutzen.

Bilder optimieren

next/image wählt optimierte Formate anhand der Konfiguration und des Accept-Headers. WebP ist das Standardformat; AVIF erfordert eine passende Konfiguration. Reservierte Bildabmessungen helfen gegen Layoutverschiebungen.

import Image from 'next/image'

export default function ExampleImage() {
  return <Image src="/example.jpg" alt="Example" width={800} height={600} quality={75} />
}

Diese Größen sind illustrativ und hängen von Motiv, Auflösung und Qualität ab. Prüfen Sie die Zielbrowser, statt feste Unterstützungsquoten zu übernehmen.

FormatBeispiel für 1920 × 1080Unterstützung prüfen
JPEG200 KBZielbrowser
WebP120 KBZielbrowser
AVIF80 KBZielbrowser

Häufige Fehler und Vergleich

ProblemPrüfung
Kein gültiges TLS-ZertifikatEin vertrauenswürdiges Produktionszertifikat einrichten, etwa über Let’s Encrypt.
Brotli fehlt unerwartetAnfrage- und Antwortheader, Inhaltstyp und Proxy prüfen.
Zu viele frühe AnfragenUnnötige Prefetch-/Preload-Hinweise entfernen und erneut messen.

Vergleichen Sie dieselbe Seite unter gleichen Geräte-, Netzwerk- und Cache-Bedingungen. Speed Scanner und WebPageTest helfen bei der Bewertung. Der Protokollname allein belegt keine Verbesserung. Halten Sie Konfiguration und Ergebnisse fest.

Website-Geschwindigkeit prüfen

Finden Sie heraus, was Ihre Website verlangsamt

Prüfen Sie Ihre Seite mit Milten und erhalten Sie Core Web Vitals sowie Empfehlungen für kürzere Ladezeiten.

Website prüfen
Cookies

Wir verwenden Cookies

Wir verwenden Cookies, um Ihnen ein besseres Erlebnis auf unserer Website zu bieten. Mehr über die Verwendung von Cookies erfahren Sie in unserer Datenschutzrichtlinie.