Die langsame Seite, die zählt, ist nicht die Homepage

Zusammenfassung

Wenn Ihr Chef sagt, die Website sei langsam, ist der Instinkt, Bilder zu komprimieren und sich bei der Startseite zu entschuldigen. Der sinnvollere Schritt ist zu entscheiden, welche Seite tatsächlich zuerst beschleunigt werden sollte. Dieser Artikel durchläuft ein einzelnes Szenario: Ein kleines Marketingteam wurde gebeten, die "Geschwindigkeit" für eine mittelgroße B2B-Website zu "beheben". Es behandelt die Messung der Core Web Vitals mit Felddaten, die Auswahl von Seiten nach geschäftlicher Auswirkung und das Hinzufügen von strukturierten Daten erst nach den kostengünstigen Korrekturen. Der Lohn ist ein kurzer, vertretbarer Plan, der auch für einen nicht-technischen Chef sinnvoll ist.

Die langsamste Seite Ihrer Website ist nicht die, die PageSpeed Insights markiert. Es ist die Seite, die Ihr Chef nie geöffnet hat – die, die mit einer bezahlten Kampagne verbunden ist oder in einem vergessenen Produktbereich vergraben liegt – und sie ist diejenige, die tatsächlich bestimmt, ob das diesmonatige Budget etwas einbringt. Wenn jemand in leitender Position sagt: "Die Website ist langsam, beheben Sie es", braucht er kein Website-Geschwindigkeitsprojekt. Er braucht eine Priorisierungsübung.

Nehmen Sie ein Szenario, das viele von uns erlebt haben. Sie sind das gesamte Marketingteam eines mittelständischen B2B-Softwareunternehmens. Die Website hat eine Startseite, einen Blog, ein Hilfecenter und fünf Landingpages, die mit bestimmten Werbekampagnen verbunden sind. Ihr Chef hat einen Artikel über Core Web Vitals gelesen oder eine Kundenbeschwerde gehört. Die Anweisung ist klar: Machen Sie es schneller.

Wie Sie in der nächsten Stunde reagieren, entscheidet darüber, ob Sie den nächsten Monat mit dem Komprimieren von Bildern verbringen oder mit Arbeiten, die die entscheidenden Zahlen verändern.

Beginnen Sie mit der Seite, die Geld einbringt, nicht mit der, die peinlich ist

Das Prinzip: Geschwindigkeitsarbeit hat einen Ertrag, und dieser Ertrag hängt von Traffic und Conversion-Wert ab. Eine Seite mit geringem Traffic, aber hoher Conversion kann für das Unternehmen wichtiger sein als die Startseite, selbst wenn sie langsamer ist.

Der erste Schritt ist also, eine Liste von Seiten aus den Analysen zu erstellen, nicht aus der Sitemap. Welche Seiten erhalten Geld in Form von Anzeigenklicks? Welche Seiten wurden seit dem Start nicht angefasst? In diesem Szenario wurde die wichtigste Landingpage – die hinter einer bezahlten Suchanzeige, die seit zwei Monaten läuft – mit großen, unoptimierten Screenshots erstellt. Die Startseite hingegen wurde bereits vor einem Jahr von einer Agentur optimiert.

Sie beheben nicht zuerst die Startseite. Sie beheben die Seite, die Geld verdient. Das ist keine technische Entscheidung, sondern eine geschäftliche. Wenn eine vollständige technische Prüfung wie die richtige Antwort klingt, widerstehen Sie ihr einen Moment. Audits erzeugen eine Liste; sie sagen Ihnen nicht, womit Sie beginnen sollen. Ein gut abgegrenztes technisches SEO-Audit ist ein Entscheidungswerkzeug, keine Panikreaktion.

Sie werden oft feststellen, dass eine kleine Anzahl von Seiten den Großteil des Traffics und der Conversions generiert; der Rest ist informativ oder überholt. Das ist kein Grund, die langsamen informativen Seiten für immer zu ignorieren. Es ist ein Grund, sie nach den Seiten einzureihen, die eine direkte Verbindung zum Umsatz haben. Die Startseite mag die langsamste von allen sein, aber wenn das Geschäftsziel Leads sind, ist ein Besuch der Startseite nur ein Ausgangspunkt – auf der Landingpage konvertiert jemand tatsächlich.

Teilen Sie "schnell" in "gemessen" und "gefühlt" auf

Der zweite Schritt besteht darin, zu trennen, was Leistungstests über Ihre Seite aussagen, von dem, was echte Nutzer erleben. Die Dokumentation der Core Web Vitals von Google nennt drei Metriken, die für das Suchranking zählen: Largest Contentful Paint (Laden), Interaction to Next Paint (Reaktionsfähigkeit) und Cumulative Layout Shift (visuelle Stabilität). Sie sind wichtig, weil sie Momente verfolgen, die beeinflussen, ob jemand die Seite tatsächlich nutzen kann.

Im Szenario öffnen Sie die Landingpage in einem Leistungstester und erhalten eine vernünftige Punktzahl. Aber wenn Sie das mit Felddaten in der Google Search Console vergleichen – die reale Erfahrungen von Besuchern widerspiegeln – erweist sich die Seite als häufig langsam. Das ist das entscheidende Signal. Labortests sind nach einer Änderung weiterhin nützlich, um Vorher und Nachher zu vergleichen. Aber Felddaten sind die Grundwahrheit für Menschen, die Ihre Anzeige von verschiedenen Geräten und Verbindungen aus angeklickt haben.

Stattdessen dies	Beginnen Sie mit	Warum
PageSpeed-Score als eine Zahl	Core-Web-Vitals-Felddaten	Felddaten stammen von echten Nutzern, nicht von einem Testserver
"Die Website ist langsam"	Welche Seiten unterstützen Geschäftsziele	Schnelle nutzlose Seiten generieren keine Leads
CMS neu aufbauen	Bilder komprimieren und Skripte bereinigen	Maßnahmen mit geringem Risiko bringen den größten Nutzen

Wenn Sie später eine tiefere Referenz wünschen, kann ein Core-Web-Vitals-Leitfaden Sie durch jede Metrik führen. Aber für jetzt brauchen Sie nur genug, um den Plan zu erstellen. Der Schlüssel ist zu benennen, welche der drei Metriken das Problem auf dieser speziellen Seite tatsächlich verursacht. Wenn der Text spät erscheint, schauen Sie sich Bilder und Serverantwort an. Wenn sich Buttons ruckartig anfühlen, schauen Sie sich lange JavaScript-Aufgaben an. Wenn das Layout springt, schauen Sie sich die für Anzeigen und Einbettungen reservierten Bereiche an. Diese Nuance ist es, die eine gezielte Korrektur von einer zufälligen Optimierung unterscheidet.

Beheben Sie zuerst die günstigen Dinge, bevor Sie die teuren angehen

Das dritte Prinzip: Lassen Sie nicht zu, dass ein Leistungsprojekt zu einem Redesign aufbläht. Die meisten Verbesserungen, die die Benutzererfahrung tatsächlich verbessern, sind unspektakulär und günstig.

Schauen Sie sich die Landingpage an und benennen Sie die offensichtlichen Übeltäter. Die Bilder sind Screenshots in voller Auflösung. Es gibt ein Drittanbieter-Skript auf der Seite, das niemand mehr identifizieren kann. Eine Webschrift blockiert das Rendern von Text. Das sind bekannte Probleme.

In einer perfekten Welt würden Sie eine Woche damit verbringen, die Seite mit einem modernen Framework neu zu schreiben. In der Praxis beginnen Sie mit Halbtagesaufgaben: Bilder komprimieren, das ungenutzte Skript verzögern, das Heldenbild vorladen. Sie können diese Änderungen an einem Nachmittag testen, und sie erfordern keinen Genehmigungsausschuss.

Einschränkung: Geschwindigkeit ist nicht immer so einfach. Einige Seiten sind langsam wegen eines Servers, einer Datenbank oder einer Drittanbieter-Abhängigkeit, die Sie nicht kontrollieren. Aber wenn Sie die kostengünstigen Korrekturen nicht geprüft haben, können Sie die teure noch nicht rechtfertigen. Viele Teams verschwenden ein Budget für einen Neuaufbau, weil sie die Screenshots nie komprimiert haben. Hier gibt es eine Bescheidenheit, die man bewahren sollte: Ein Leistungsscore ist ein Symptom, keine Diagnose. Die kostengünstigen Korrekturen sind selbst diagnostisch. Nachdem Sie die Bilder komprimiert haben, erfahren Sie, ob der Engpass Ihr Inhalt oder Ihre Infrastruktur war.

Fügen Sie strukturierte Daten hinzu, während Sie ohnehin im Code sind

Das ist die Ebene, die den Chef überrascht. Nachdem Sie die kostengünstigen Korrekturen vorgenommen haben, sind Sie bereits in der Seite. Das ist der richtige Moment, um etwas hinzuzufügen, das überhaupt keine Geschwindigkeit ist: strukturierte Daten.

Strukturierte Daten sind Auszeichnungen, die Suchmaschinen helfen zu verstehen, was eine Seite enthält. Es ist dasselbe HTML, das zu reichhaltigeren Suchergebnissen und besserer Sichtbarkeit führen kann – und es wird relevanter, da sich die Suche in Richtung KI-generierter Antworten verschiebt. Für ein kleines Team ist das ein ungenutzter Hebel, weil es nicht erfordert, neue Inhalte zu schreiben. Sie beschriften, was bereits existiert.

Im Szenario fügen Sie der Landingpage ein dienstleistungsorientiertes Schema hinzu. Der genaue Typ hängt davon ab, worum es auf der Seite geht: eine Dienstleistungsseite, ein Artikel, ein Produkt. Sie müssen nicht alle Typen auf einmal hinzufügen. Ein sorgfältig hinzugefügter ist besser als zehn schlampig hinzugefügte. Kein Ergebnis ist garantiert; Google entscheidet, was angezeigt wird. Aber das Risiko ist gering und das potenzielle Aufwärtspotenzial ist real. Wenn Sie tiefer gehen möchten, deckt ein Leitfaden zur Implementierung strukturierter Daten die praktischen Schritte ab.

Übersetzen Sie Korrekturen in "Hat es Geld gebracht?"

Der schwierige Teil ist nicht die technische Arbeit. Es ist die Art, wie Sie sie einem nicht-technischen Chef präsentieren.

Ihr Chef hat eine Sache verlangt: Machen Sie die Website schneller. Wenn Sie sagen "wir haben das LCP auf der Landingpage verbessert", ernten Sie vielleicht einen verständnislosen Blick. Übersetzen Sie stattdessen die Arbeit in geschäftliche Konsequenzen.

In diesem Szenario ist die Landingpage das Ziel für eine bezahlte Kampagne. Jede Sekunde, die sie wartet, ist eine Sekunde, in der ein Besucher die Seite verlassen könnte, bevor der Call-to-Action erscheint. Sie erklären also: Wir haben offensichtliche Reibungspunkte auf der Seite entfernt, auf der Geld den Besitzer wechselt. Sie können keinen bestimmten Ranking-Sprung versprechen – jeder, der das tut, rät –, aber Sie können ein vernünftiges, ehrliches Argument vorbringen. Sie können dies auch mit dem Budget verbinden, das Ihr Chef bereits versteht. Dieselbe Werbeausgabe kauft einen Besuch; der Unterschied ist, ob dieser Besuch eine Chance hat, zu einem Lead zu werden.

Ein einfacher monatlicher Bericht funktioniert besser als ein Dashboard voller Fachjargon. Zeigen Sie drei Dinge: welche Seite Sie gewählt haben, welche Metrik Sie gemessen haben und was Sie geändert haben. Wenn sich die Metrik verbessert, ist das eine Bestätigung. Wenn nicht, haben Sie immer noch ein klares Experiment zur Neubewertung. Jagen Sie nicht Monat für Monat einem einzelnen Score hinterher; Core Web Vitals schwanken mit dem Traffic-Mix, den Gerätetypen und sogar der geografischen Region. Berichten Sie den Trend, nicht die Zahl.

Was Sie nächsten Montag tun sollten

Die Lehre aus dem Szenario: Sie beheben nicht "die Website". Sie beheben eine bestimmte Seite, basierend auf Daten, und Sie enden mit einem wiederholbaren Prozess statt mit einem einmaligen Projekt. Wenn jemand mit Macht sagt: "Machen Sie es schneller", ist die nützlichste Antwort eine einzige klärende Frage: welche Seite und für wen?

Dann messen Sie Felddaten, beheben Sie die kostengünstigen Dinge, fügen Sie strukturierte Daten hinzu, wenn Sie bereits im Code sind, und berichten Sie in einfacher Sprache. Die Ergebnisse mögen nicht dramatisch sein. Aber Sie werden genau wissen, welche Seite schneller wurde, warum Sie sie gewählt haben und was als Nächstes zu tun ist. Das ist ein besseres Ergebnis als ein vages Projekt, das mit einem Geschwindigkeitswert begann und in einem Redesign endete, das niemand verstand.