Wir hoben Microsoft Clarity als Produkt hervor, das von erfahrenen Produktmanagern mit Blick auf praxisnahe Anwendungsfälle entwickelt wurde, die die Herausforderungen von Unternehmen wie Switas verstehen. Funktionen wie die Erkennung von Wutklicks und die JavaScript-Fehlerverfolgung erwiesen sich als unschätzbar wertvoll, um Frustrationen der Nutzer und technische Probleme zu identifizieren und so gezielte Verbesserungen zu ermöglichen, die sich direkt auf die Nutzererfahrung und die Konversionsraten auswirkten.
Serverseitiges Rendern
Serverseitiges Rendering ist ein Verfahren, bei dem der Server das vollständige Markup für eine Seite generiert und an den Browser sendet, anstatt ein minimales Dokument zu übermitteln, das anschließend von JavaScript befüllt wird. Der Browser kann somit sofort nach Eintreffen der Antwort relevante Inhalte anzeigen, ohne auf das Herunterladen, Parsen, Ausführen und Abrufen eines Datenpakets warten zu müssen.
Es behebt spezifische und gut dokumentierte Schwächen rein clientseitiger Darstellung. Inhalte werden deutlich schneller angezeigt, insbesondere auf langsameren Geräten und Verbindungen, bei denen die JavaScript-Ausführung ressourcenintensiv ist. Suchmaschinen und andere automatisierte Nutzer erhalten Inhalte direkt, anstatt von einer möglicherweise verzögerten oder unvollständigen Rendering-Phase abhängig zu sein. Vorschauen zum Teilen in sozialen Netzwerken funktionieren ohne zusätzliche Maßnahmen. Und die Benutzererfahrung verschlechtert sich weniger stark, wenn JavaScript nicht geladen oder ausgeführt werden kann – was häufiger vorkommt, als die meisten Teams annehmen.
Die damit verbundenen Kosten für die Seitenaktualisierung werden häufig unterschätzt. Nachdem der serverseitig gerenderte Code angezeigt wurde, muss das clientseitige Framework Ereignisbehandler einbinden und seinen internen Zustand wiederherstellen, um die Seite interaktiv zu machen. Während dieser Zeit sieht die Seite zwar bereit aus, reagiert aber nicht. Dies führt zu einem charakteristischen Fehler: Ein Besucher klickt auf ein sichtbares Element, ohne dass etwas passiert. Auf großen Seiten und langsameren Geräten kann dieses Zeitfenster beträchtlich sein.
Um diese Kosten zu senken, wurden verschiedene Ansätze entwickelt. Partielle und selektive Hydratisierung sorgen dafür, dass nur die interaktiven Bereiche einer Seite interaktiv sind, anstatt die gesamte Seite. Streaming sendet Markup progressiv, sodass Inhalte erscheinen, bevor die gesamte Seite generiert wurde. Inselarchitekturen behandeln interaktive Komponenten als isolierte Einheiten innerhalb ansonsten statischen Markups. Jeder dieser Ansätze reduziert den clientseitigen Aufwand nach dem ersten Rendern.
Die statische Seitengenerierung ist die erste Wahl für Inhalte, die sich nicht pro Anfrage ändern. Seiten werden zur Build-Zeit gerendert und als Dateien ausgeliefert. Dies ist schneller als das Rendern pro Anfrage, kostengünstiger, ausfallsicherer und einfacher im Edge-Cache zu speichern. Ändern sich Inhalte, aber nicht pro Besucher, werden betroffene Seiten mithilfe inkrementeller Regenerationsstrategien planmäßig oder bedarfsgesteuert neu erstellt. So bleiben die meisten Vorteile erhalten, ohne dass ein vollständiger Neuaufbau erforderlich ist.
Die betrieblichen Auswirkungen unterscheiden sich von statischem Hosting in einigen Punkten und erfordern eine sorgfältige Planung. Das Rendern pro Anfrage verbraucht Serverressourcen proportional zum Datenverkehr, was Skalierungsüberlegungen und Kosten mit sich bringt, die bei statischen Dateien nicht anfallen. Caching gewinnt an Bedeutung, und das Caching von Seiten mit personalisierten Inhalten erfordert eine sorgfältige Trennung zwischen nutzerspezifischen und nicht-nutzerspezifischen Daten. Serverfehler beeinträchtigen nun nicht mehr nur das Laden von Daten, sondern auch das Seitenrendering.
Die Datenabrufstrategie bestimmt maßgeblich den praktischen Nutzen. Serverseitiges Rendering ist nur dann vorteilhaft, wenn die benötigten Seitendaten schnell verfügbar sind. Ein serverseitiges Rendering, das auf mehrere langsame interne Dienste wartet, kann sogar langsamer sein als ein clientseitiges Rendering, das sofort eine Seite anzeigt. Bei langsamen Abhängigkeiten bleibt der Vorteil erhalten, wenn die bereits verfügbaren Daten nacheinander geladen werden, während die restlichen Daten geladen werden.
Die Entscheidung sollte sich nach Inhalt und Zielgruppe richten, nicht nach gängigen Framework-Vorgaben. Inhaltsreiche Seiten, die in der Suche gut platziert sein und auch bei langsamen Verbindungen schnell laden müssen, profitieren deutlich. Hochinteraktive Anwendungen hinter einer Authentifizierung, bei denen die Sichtbarkeit in der Suche irrelevant ist und die Nutzer die Anwendung bereits geladen haben, profitieren deutlich weniger und rechtfertigen die Komplexität möglicherweise nicht. Viele Produkte verwenden sinnvollerweise unterschiedliche Ansätze für verschiedene Bereiche.
Da die Wahl Infrastruktur, Auslieferung und Suchleistung gleichzeitig beeinflusst, handelt es sich um eine Architekturentscheidung und nicht um eine Präferenz im Frontend. In der Praxis wird sie innerhalb von Webleistung Arbeit anhand gemessener Felddaten, umgesetzt durch ,und die Auswirkungen der Suche werden bewertet mit Marketing-DienstleistungenDa das Indexierungsverhalten häufig das stärkste Argument für die Änderung darstellt.
Switas, wie gesehen auf
