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.
Render-Blocking-Ressourcen
Renderblockierende Ressourcen sind Dateien, die ein Browser herunterladen und verarbeiten muss, bevor er Inhalte anzeigen kann. Dabei handelt es sich hauptsächlich um Stylesheets, die im Head-Bereich des Dokuments referenziert werden, und synchrone Skripte, die beim Parsen gefunden werden. Sie sind der häufigste Grund dafür, dass eine Seite länger zum Laden benötigt, als ihr Inhalt eigentlich rechtfertigen würde.
Stylesheets blockieren aus gutem Grund das Laden von Inhalten. Würde der Inhalt vor dem Laden der Stylesheets dargestellt, würde dies zu einem kurzen Aufblitzen unformatierten Inhalts und einem anschließenden abrupten Seitenumbruch führen. Daher warten Browser. Das Problem liegt nicht in den Stylesheets selbst, sondern darin, dass Websites typischerweise viel mehr Stylesheets laden, als für die anfängliche Ansicht benötigt werden. Dazu gehören Stylesheets für Komponenten weiter unten auf der Seite, für andere Templates und für Funktionen, die der Besucher möglicherweise nie verwendet. All diese Stylesheets müssen geladen werden, bevor überhaupt etwas angezeigt wird.
Skripte blockieren, da ein während des Parsens gefundenes Skript das Dokument verändern könnte. Der Parser hält daher an, bis das Skript ausgeführt wurde. Die meisten Skripte benötigen dieses Verhalten nicht: Analysetools, Chat-Widgets, Personalisierungstools und der Großteil des Anwendungscodes können nach dem Parsen des Dokuments ohne Qualitätsverlust ausgeführt werden. Durch Hinzufügen des Attributs `defer` kann das Parsen fortgesetzt und die Skripte anschließend der Reihe nach ausgeführt werden. `async` hingegen führt sie sofort nach ihrem Eintreffen aus, ohne die Reihenfolge zu garantieren.
Die gängige Lösung für Stylesheets besteht darin, die für den anfänglichen Viewport benötigten Styles vom Rest zu trennen. Der kritische Teil wird direkt in das Dokument eingebunden, sodass keine zusätzliche Anfrage erforderlich ist, und der Rest wird so geladen, dass er nicht blockiert. Dies ist zwar effektiv, erhöht aber die Komplexität des Build-Prozesses, da der kritische Satz bei jeder Styleänderung neu generiert werden muss und veraltetes kritisches CSS sichtbare Fehler verursacht.
Drittanbieterressourcen sind häufig die größten Kostenfaktoren und am schwierigsten zu kontrollieren. Tag-Manager, Einwilligungsplattformen, Schriftartenanbieter, Chat-Tools und Testframeworks werden typischerweise mit blockierendem Verhalten in den Dokumentenkopf eingebunden und benötigen jeweils eine Verbindung zu einer separaten Quelle. Die dadurch entstehende Verzögerung ist beträchtlich, und da jede dieser Ressourcen von einem anderen Team aus nachvollziehbaren Gründen hinzugefügt wurde, ist niemand für die Gesamtverzögerung verantwortlich. Erst die Prüfung der Gesamtkosten und deren Zuordnung zur anfordernden Funktion macht diesen Kompromiss sichtbar.
Schriftarten erfordern eine besondere Behandlung, da sie die Textdarstellung und nicht die Seitenstruktur beeinflussen. Je nach Darstellungsstrategie kann Text während des Ladens einer Schriftart unsichtbar sein, was bedeutet, dass bereits geladene Inhalte bewusst zurückgehalten werden. Eine Strategie, die sofort einen Ersatztext anzeigt und diesen ersetzt, sobald die Schriftart geladen ist, sowie das Vorladen von Schriftarten, die im sichtbaren Bereich verwendet werden, verhindern, dass eine Seite zwar technisch gerendert wird, aber leer erscheint.
Die Ermittlung der tatsächlichen Kosten erfordert Sorgfalt, da die Beseitigung einer blockierenden Ressource nicht immer die prognostizierte Einsparung bewirkt. Ressourcen werden parallel heruntergeladen, sodass die Beseitigung einer Ressource lediglich dazu führen kann, dass eine andere zum Engpass wird, und die beobachtete Verbesserung ist häufig geringer als die Summe der Einzelschätzungen. Die Überprüfung durch Messung nach jeder Änderung, anstatt den prognostizierten Gesamtwerten zu vertrauen, gewährleistet realistische Erwartungen.
Die Identifizierung der tatsächlichen Blockierungsursachen ist mit Standardtools unkompliziert. Diese Tools melden blockierende Ressourcen und schätzen die Einsparungen, die sich durch deren Beseitigung ergeben. Die Schätzungen sollten jedoch eher als Richtwerte denn als exakte Werte betrachtet werden, da die Beseitigung einer blockierenden Ressource häufig eine andere als eigentliche Engpassquelle offenbart. Verbesserungen lassen sich am besten durch Messungen überprüfen, anstatt sie allein aus dem Bericht abzuleiten.
Da die benötigten Ressourcen üblicherweise von mehreren Teams im Laufe der Zeit bereitgestellt werden, erfordert die Behebung von Mängeln neben der technischen Umsetzung auch eine gute Steuerung. In der Praxis finden die Prüfung und Priorisierung innerhalb der folgenden Abteilungen statt: Webleistung Die Änderungen am Build werden durch die Arbeit umgesetzt. ,und Entscheidungen darüber, welche Drittanbieter-Tools ihre Blockierungskosten rechtfertigen, bedürfen der Zustimmung der Teams, die sie angefordert haben, was für die meisten Websites bedeutet, Abteilung für digitales Marketing.
Switas, wie gesehen auf
