AMP vs. PWA: Die richtige Technologie für schnelle Seiten

Die richtige Technologie für schnelle Seiten ist heute keine der beiden: AMP ist als Google-Anforderung entfallen, und eine PWA ist eine Ergänzung, kein Ersatz. Entscheidend sind die Core Web Vitals Ihrer bestehenden Seite — Ladezeit, Interaktivität und visuelle Stabilität.

Die Frage „AMP oder PWA" stammt aus einer Zeit, in der Google beschleunigte Seiten in den Nachrichten-Karussells bevorzugte. Diese Bevorzugung gibt es nicht mehr: Seit der Umstellung auf die Core Web Vitals zählt, wie schnell eine Seite tatsächlich ist, nicht in welchem Format sie ausgeliefert wird.

##Was ist aus AMP geworden?

AMP war ein enges Format mit vorgeschriebenen Komponenten und ausgelagertem Rendering. Es machte Seiten zuverlässig schnell — um den Preis einer zweiten Version derselben Inhalte, eingeschränkter Gestaltung und einer URL, die dem Verlag nicht gehörte. Mit dem Wegfall des Ranking-Vorteils blieb nur der Aufwand, und die meisten Publisher haben ihre AMP-Ausgaben abgeschaltet. Für ein mittelständisches Unternehmen war AMP ohnehin nie die richtige Antwort.

##Was ist eine PWA — und was nicht?

Eine Progressive Web App ist keine Technologie, die man installiert, sondern eine Website, die drei Dinge zusätzlich kann: über HTTPS ausgeliefert werden, sich mit einem Manifest zum Startbildschirm hinzufügen lassen und über einen Service Worker offline oder bei schlechter Verbindung sinnvoll reagieren. Nichts davon macht eine langsame Seite schnell — es macht eine schnelle Seite verlässlich.

• ›Manifest mit Name, Symbolen und Startadresse: der Startbildschirm-Eintrag.
• ›Service Worker für Zwischenspeicherung und eine brauchbare Offline-Seite.
• ›HTTPS als Voraussetzung, nicht als Zusatz.
• ›Push-Benachrichtigungen nur mit Einwilligung — und nur, wenn es einen Anlass gibt.

##Was macht Seiten wirklich schnell?

Unabhängig vom Etikett entscheiden dieselben vier Dinge: Bilder in passender Größe und moderner Kodierung, Schriften lokal mit Fallback, so wenig JavaScript wie möglich vor der ersten Darstellung, und eine serverseitige Auslieferung, die nicht bei jedem Aufruf neu rechnet. Wer diese vier erledigt, erreicht bessere Werte als jede AMP-Variante — und behält Gestaltung, URL und Analytik in der eigenen Hand.

Der Service Worker kommt danach, nicht davor. Ein Cache, der eine langsame Seite zwischenspeichert, macht den zweiten Besuch schnell und den ersten weiterhin zäh — und der erste Besuch ist der, bei dem entschieden wird.

##Ist ein Service Worker automatisch ein Tempogewinn?

Ein Service Worker sitzt zwischen Browser und Server und entscheidet, was aus dem Zwischenspeicher kommt. Das ist mächtig und genau deshalb heikel: Eine falsche Cache-Regel liefert Wochen später noch die alte Version aus, und Besucherinnen sehen Änderungen erst nach einem harten Neuladen. Wer einen einsetzt, braucht eine Strategie für Aktualisierung und Ablauf — Netzwerk zuerst für HTML, Cache zuerst für statische Dateien mit Hash im Namen.

Planen Sie außerdem einen Notausgang ein: eine Möglichkeit, den Service Worker aus der Ferne abzumelden. Ohne diesen Schalter wird aus einem Fehler in der Cache-Logik ein Problem, das Sie nicht mehr per Deployment lösen können, weil die alte Version die neue gar nicht erst lädt.

##Wie messen Sie das, statt es zu glauben?

Ob eine Umstellung etwas gebracht hat, zeigt sich in den Felddaten der Search Console, nicht im Labortest auf dem Entwicklerrechner. Beobachten Sie LCP und INP getrennt nach Gerät über vier Wochen. Verbessert sich nur der Laborwert, haben Sie den Testlauf optimiert; verbessert sich das Feld, spüren es auch die Kundinnen.