Messung und Optimierung für Google Core Web Vitals: Ein technischer SEO-Leitfaden

Das Sammeln von Daten zur Leistung Ihrer Website ist der erste Schritt zur Bereitstellung eines großartigen Benutzererlebnisses. Im Laufe der Jahre hat Google verschiedene Tools zur Bewertung und Berichterstattung über die Webleistung bereitgestellt.

Dazu gehören Core Web Vitals, eine Reihe von Leistungssignalen, die Google für alle Web-Erlebnisse als entscheidend erachtet.

Dieser Artikel behandelt die aktuellen Core Web Vitals sowie wichtige Tipps und Tools zur Verbesserung Ihrer Webleistung, um Benutzern ein gutes Seitenerlebnis zu bieten.

Ein Blick auf die Entwicklung der Web-Performance

Vorbei sind die Zeiten, in denen die Verbesserung der Website-Leistung unkompliziert war.

In der Vergangenheit verzögerten häufig überlastete Ressourcen und verzögerte Verbindungen Websites. Aber Sie könnten die Konkurrenz übertreffen, indem Sie einige Bilder komprimieren, die Textkomprimierung aktivieren oder Ihre Stylesheets und JavaScript-Module verkleinern.

Heutzutage sind die Verbindungsgeschwindigkeiten schneller. Die meisten Ressourcen sind standardmäßig komprimiert und viele Plugins übernehmen die Bildkomprimierung, Cache-Bereitstellung usw.

Das Streben von Google nach einem schnelleren Internet geht weiter. PageSpeed ​​Insights (PSI) ist weiterhin auf web.dev aktiv und dient als bestes Tool zur Auswertung einzelner Seitenladevorgänge.

Obwohl viele der Meinung sind, dass PSI-Bewertungen unnötig bestrafend sind, kommen wir damit immer noch am nächsten daran, wie Google Websites anhand von Page-Speed-Signalen gewichtet und einordnet.

Um die neueste Version des Seitengeschwindigkeitstests von Google zu bestehen, müssen Sie das Core Web Vitals Assessment bestehen.

Die wichtigsten Web-Vitals verstehen

Core Web Vitals sind eine Reihe von Metriken, die in die im Jahr 2021 eingeführten umfassenderen Suchsignale für das Seitenerlebnis integriert sind. Jede Metrik „stellt eine bestimmte Facette der Benutzererfahrung dar, ist vor Ort messbar und spiegelt die reale Erfahrung eines kritischen Benutzers wider.“ zentrisches Ergebnis“, so Google.

Zu den aktuellen Core Web Vitals-Metriken gehören:

• Erste inhaltsreiche Farbe
• Verzögerung der ersten Eingabe (wird durch Interaktion mit der nächsten Farbe ersetzt)
• Interaktion mit der nächsten Farbe
• Zeit bis zum ersten Byte
• Größte inhaltsreiche Farbe
• Kumulative Layoutverschiebung

Web.dev erklärt wie folgt, wie jede Metrik funktioniert.

Erste Contentful Paint (FCP)

„Die First Contentful Paint (FCP)-Metrik misst die Zeit vom Beginn des Ladens der Seite bis zur Darstellung eines Teils des Seiteninhalts auf dem Bildschirm. Für diese Metrik bezieht sich „Inhalt“ auf Text, Bilder (einschließlich Hintergrundbilder), <svg> -Elemente oder nicht weiße <canvas> -Elemente.“

Was das für technische SEOs bedeutet

FCP ist ziemlich einfach zu verstehen. Beim Laden einer Webseite werden bestimmte Elemente vor anderen angezeigt (oder „gemalt“). „Malen“ bedeutet in diesem Zusammenhang das Rendern auf dem Bildschirm.

Sobald ein Teil der Seite gerendert wurde – sagen wir, die Hauptnavigationsleiste wird vor anderen Elementen geladen – wird der FCP an diesem Punkt protokolliert.

Stellen Sie sich vor, wie schnell die Seite für Benutzer sichtbar geladen wird. Der Seitenladevorgang wird noch nicht abgeschlossen sein, aber er hat begonnen.

Erste Eingabeverzögerung (FID)

„FID misst die Zeit von der ersten Interaktion eines Benutzers mit einer Seite (d. h. wenn er auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes, JavaScript-gestütztes Steuerelement verwendet) bis zu dem Zeitpunkt, an dem der Browser tatsächlich starten kann Verarbeitung von Ereignishandlern als Reaktion auf diese Interaktion.“

Was das für technische SEOs bedeutet

FID ist eine Metrik für die Reaktionsfähigkeit der Benutzerinteraktion, die im März 2024 durch Interaction to Next Paint (INP) ersetzt werden soll.

Wenn ein Benutzer mit einem Element auf der Seite interagiert (z. B. einem Link, Sortieren einer Tabelle oder Anwenden einer Facettennavigation), wie lange dauert es, bis die Website mit der Verarbeitung dieser Anfrage beginnt?

Interaktion mit Next Paint (INP)

„INP ist eine Metrik, die die allgemeine Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen bewertet, indem sie die Latenz aller Klick-, Tipp- und Tastaturinteraktionen beobachtet, die während der gesamten Lebensdauer des Besuchs eines Benutzers auf einer Seite auftreten. Der endgültige INP-Wert ist die längste beobachtete Interaktion, Ausreißer werden ignoriert.“

Was das für technische SEOs bedeutet

Wie bereits erwähnt, wird INP im März 2024 FID als Core Web Vital ersetzen.

INP berücksichtigt tiefere Informationen (die offenbar bis zur Tastatur zurückreichen) und ist wahrscheinlich detaillierter und ausgefeilter.

Zeit bis zum ersten Byte (TTFB)

„TTFB ist eine Metrik, die die Zeit zwischen der Anforderung einer Ressource und dem Eintreffen des ersten Bytes einer Antwort misst.“

Was das für technische SEOs bedeutet

Sobald eine „Ressource“ (z. B. ein eingebettetes Bild, ein JavaScript-Modul, ein CSS-Stylesheet usw.) angefordert wird, wie lange dauert es, bis die Website mit der Bereitstellung dieser Ressource beginnt?

Nehmen wir an, Sie besuchen eine Webseite und auf dieser Seite befindet sich ein eingebettetes Bild. Der Ladevorgang beginnt, der Ladevorgang ist jedoch noch nicht abgeschlossen. Wie lange dauert es, bis das allererste Byte dieses Bildes vom Server an den Client (Webbrowser) übermittelt wird?

Größter Contentful Paint (LCP)

„Die Largest Contentful Paint (LCP)-Metrik gibt die Renderzeit des größten im Ansichtsfenster sichtbaren Bild- oder Textblocks im Verhältnis zum ersten Ladebeginn der Seite an.“

Was das für technische SEOs bedeutet

LCP ist eine der wichtigsten Kennzahlen, die jedoch am schwierigsten zu erfüllen ist.

Sobald der größte Teil der visuellen Medien (z. B. Text oder Bild) geladen wurde, wird das LCP protokolliert.

Sie können dies folgendermaßen lesen: Wie lange dauert es, bis der Großteil des Hauptinhalts einer Seite geladen ist?

Möglicherweise laden weiter unten auf der Seite noch kleine Teile und Dinge, die den meisten Benutzern nicht auffallen.

Aber wenn das LCP protokolliert wird, ist der große und offensichtliche Teil Ihrer Seite geladen. Wenn dies zu lange dauert, schlägt die LCP-Prüfung fehl.

Kumulative Layoutverschiebung (CLS)

„CLS ist ein Maß für den größten Anstieg der Layout-Verschiebungswerte für jede unerwartete Layout-Verschiebung, die während der gesamten Lebensdauer einer Seite auftritt.

Eine Layoutverschiebung tritt jedes Mal auf, wenn ein sichtbares Element seine Position von einem gerenderten Frame zum nächsten ändert. (Weitere Informationen zur Berechnung der einzelnen Layout-Verschiebungswerte finden Sie weiter unten.)

Eine Reihe von Layout-Verschiebungen, auch Sitzungsfenster genannt, liegt vor, wenn eine oder mehrere einzelne Layout-Verschiebungen in schneller Folge auftreten, mit weniger als 1 Sekunde zwischen den einzelnen Verschiebungen und maximal 5 Sekunden für die gesamte Fensterdauer.

Der größte Burst ist das Sitzungsfenster mit der maximalen kumulativen Punktzahl aller Layoutverschiebungen innerhalb dieses Fensters.“

Was das für technische SEOs bedeutet

Damals, als die Optimierung der Seitengeschwindigkeit einfacher war, erkannten viele Websitebesitzer, dass sie unglaublich hohe Seitengeschwindigkeitsbewertungen erzielen konnten, indem sie einfach alle Rendering-blockierenden Ressourcen (üblicherweise CSS-Sheets und JavaScript-Module) zurückstellten.

Dies beschleunigte zwar das Laden von Seiten, machte die Navigation im Internet jedoch fehlerhafter und nerviger.

Wenn Ihr CSS – das den gesamten Stil Ihrer Seite steuert – verzögert ist, kann der Inhalt der Seite geladen werden, bevor die CSS-Regeln angewendet werden.

Das bedeutet, dass der Inhalt Ihrer Seite unformatiert geladen wird und dann beim Laden des CSS etwas springt.

Das ist wirklich ärgerlich, wenn man eine Seite lädt und auf einen Link klickt, der Link dann aber springt und man auf den falschen Link klickt.

Wenn Sie wie ich ein bisschen unter Zwangsstörungen leiden, sind solche Erfahrungen absolut ärgerlich (auch wenn sie nur Sekunden Zeit kosten).

Da Websitebesitzer versuchten, die Seitengeschwindigkeitsbewertungen durch die Zurückstellung aller Ressourcen auszutricksen, benötigte Google eine Gegenmetrik, die alle Seitengeschwindigkeitsgewinne mit dem Defizit bei der Benutzererfahrung ausgleichen würde.

Geben Sie die kumulative Layoutverschiebung (CLS) ein. Dies ist ein heikler Kunde, der darauf aus ist, Ihnen den Tag zu verderben, wenn Sie versuchen, die Seitengeschwindigkeit im Großen und Ganzen zu steigern, ohne an Ihre Benutzer zu denken.

CLS analysiert grundsätzlich Ihre Seitenladevorgänge auf fehlerhafte Verschiebungen und verzögerte CSS-Regeln.

Wenn es zu viele sind, werden Sie die Core Web Vitals-Bewertung nicht bestehen, obwohl Sie alle geschwindigkeitsbezogenen Kennzahlen erfüllt haben.

Bewerten Sie Ihre Core Web Vitals für bessere UX- und SEO-Ergebnisse

Eine der besten Möglichkeiten, die Leistung einer einzelnen Webseite zu analysieren, besteht darin, sie in PageSpeed ​​Insights zu laden. Die Ansicht ist in eine Kombination aus Folgendem unterteilt:

• Daten auf URL-Ebene.
• Ursprungsdaten (Domänenebene).
• Labordaten.
• Felddaten.

Um dies zu verstehen, müssen wir uns ein Beispiel ansehen:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Hier können wir die Seitengeschwindigkeitsbewertungen und -metriken für die TechCrunch-Homepage sehen.

Oben sehen Sie, dass das Core Web Vitals Assessment fehlgeschlagen ist.

In einem Mobile-First-Web ist es wichtig, die Registerkarte „Mobile Ergebnisse“ auszuwählen, die standardmäßig gerendert werden sollte (dies sind die Ergebnisse, die wirklich wichtig sind).

Wählen Sie den Origin- Schalter, damit Sie allgemeine Daten im Durchschnitt der gesamten Domain Ihrer Website und nicht nur der Startseite (oder der Seite, die Sie zum Scannen eingegeben haben) sehen.

Weiter unten auf der Seite sehen Sie die alte, bekannte numerische Seitengeschwindigkeitsbewertung:

Was ist also der Unterschied zwischen der neuen Core Web Vitals-Bewertung und der alten Page-Speed-Bewertung?

Im Wesentlichen basiert die neue Core Web Vitals-Bewertung (Bestanden/Nicht bestanden) auf Felddaten (echte Benutzer).

Die alte numerische Bewertung basiert auf simulierten mobilen Crawls und Labordaten, bei denen es sich lediglich um Schätzungen handelt.

Im Wesentlichen ist Google hinsichtlich der Änderung von Suchrankings auf die Core Web Vitals-Bewertung umgestiegen.

Um es klarzustellen: Die simulierten Labordaten können eine gute Aufschlüsselung dessen liefern, was schiefläuft, aber Google verwendet diese numerische Bewertung nicht in seinen Ranking-Algorithmen.

Umgekehrt bietet die Core Web Vitals-Bewertung nicht viele detaillierte Informationen. Diese Einschätzung fließt jedoch in die Ranking-Algorithmen von Google ein.

Ihr Hauptziel besteht also darin, die umfassendere Labordiagnostik zu nutzen, damit Sie letztendlich die Core Web Vitals-Bewertung (abgeleitet aus Felddaten) bestehen.

Denken Sie daran: Wenn Sie Änderungen an Ihrer Website vornehmen, erkennt die numerische Bewertung zwar möglicherweise sofort Änderungen, Sie müssen jedoch warten, bis Google weitere Felddaten abruft, bevor Sie schließlich die Core Web Vitals-Bewertung bestehen können.

Sie werden feststellen, dass sowohl die Core Web Vitals-Bewertung als auch die alte Seitengeschwindigkeitsbewertung teilweise dieselben Metriken verwenden.

Beide beziehen sich beispielsweise auf First Contentful Paint (FCP), Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS).

In gewisser Weise sind die Arten von Metriken, die von den einzelnen Bewertungssystemen untersucht werden, ziemlich ähnlich. Es sind der Detaillierungsgrad und die Quelle der untersuchten Daten, die unterschiedlich sind.

Ihr Ziel ist es, die feldbasierte Core Web Vitals-Bewertung zu bestehen. Da die Daten jedoch nicht allzu umfangreich sind, möchten Sie möglicherweise die herkömmlichen Labordaten und Diagnosen nutzen, um Fortschritte zu erzielen.

Die Hoffnung besteht darin, dass Sie die Core Web Vitals-Bewertung bestehen können, indem Sie sich mit den Labormöglichkeiten und Diagnosen befassen. Bedenken Sie jedoch, dass diese beiden Tests nicht unbedingt miteinander verbunden sind.

Bewerten Sie Ihre CWVs über PageSpeed ​​Insights

Nachdem Sie nun die wichtigsten Core Web Vitals-Metriken kennen und wissen, wie diese technisch erfüllt werden können, ist es an der Zeit, ein Beispiel durchzugehen.

Kehren wir zu unserer Untersuchung von TechCrunch zurück:

https://pagespeed.web.dev/analysis/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Hier ist FID erfüllt und INP versagt nur knapp.

CLS hat einige Probleme, aber die Hauptprobleme liegen bei LCP und FCP.

Sehen wir uns an, was PageSpeed ​​Insights in Bezug auf Chancen und Diagnosen zu sagen hat.

Wir müssen nun von den Felddaten zu den Labordaten übergehen und versuchen, alle Muster zu isolieren, die sich möglicherweise auf die Core Web Vitals auswirken:

Oben sehen Sie eine kleine Unternavigation in der oberen rechten Ecke, grün umrahmt.

Damit können Sie die verschiedenen Möglichkeiten und Diagnosen auf bestimmte Core Web Vitals-Metriken eingrenzen.

In diesem Fall erzählen die Daten jedoch eine sehr klare Geschichte, ohne sie einzugrenzen.

Erstens wird uns gesagt, dass wir ungenutztes JavaScript reduzieren sollen. Dies bedeutet, dass manchmal JavaScript geladen wird, ohne ausgeführt zu werden.

Es gibt auch Hinweise zur Reduzierung ungenutzten CSS. Mit anderen Worten: Es wird ein CSS-Stil geladen, der jedoch nicht angewendet wird (ähnliches Problem).

Außerdem wird uns gesagt, dass wir Rendering-blockierende Ressourcen eliminieren sollen, die fast immer mit JavaScript-Modulen und CSS-Sheets zusammenhängen.

Renderblockierende Ressourcen müssen zurückgestellt werden, um zu verhindern, dass sie das Laden einer Seite blockieren. Wie wir jedoch bereits untersucht haben, kann dies die CLS-Bewertung beeinträchtigen.

Aus diesem Grund wäre es ratsam, mit der Entwicklung sowohl eines kritischen CSS- als auch eines kritischen JavaScript-Renderingpfads zu beginnen. Dadurch werden JavaScript und CSS, die benötigt werden, oberhalb der Falte integriert, während der Rest zurückgestellt wird.

Dieser Ansatz ermöglicht es dem Websitebesitzer, die Anforderungen an das Laden von Seiten zu erfüllen und gleichzeitig einen Ausgleich mit der CLS-Metrik zu schaffen. Das ist keine leichte Aufgabe und erfordert in der Regel einen erfahrenen Webentwickler.

Da wir auch ungenutztes CSS und JavaScript gefunden haben, können wir auch ein allgemeines JavaScript-Code-Audit durchführen, um zu sehen, ob JavaScript intelligenter eingesetzt werden könnte.

Kehren wir zurück zu Chancen und Diagnose :

Jetzt wollen wir uns auf die Diagnostik konzentrieren. Google drosselt diese Überprüfungen absichtlich aufgrund schlechter 4G-Verbindungen, sodass Elemente wie die Haupt-Thread-Arbeit so lang erscheinen (17 Sekunden).

Dies ist beabsichtigt, um Benutzer mit geringer Bandbreite und/oder langsamen Geräten zufriedenzustellen, die weltweit üblich sind.

Ich möchte Ihre Aufmerksamkeit hier auf „Haupt-Thread-Arbeit minimieren“ lenken. Dieser einzelne Eintrag ist oft eine Goldgrube an Erkenntnissen.

Standardmäßig werden die meisten Rendering- und Skriptausführungsaufgaben (JavaScript) einer Webseite durch den Hauptverarbeitungsthread (einen einzelnen Verarbeitungsthread) des Webbrowsers eines Clients geleitet. Sie können verstehen, dass dies zu erheblichen Engpässen beim Laden von Seiten führt.

Auch wenn Ihr gesamtes JavaScript perfekt minimiert und schnell an den Browser des Benutzers gesendet wird, muss es standardmäßig in einer einzelnen Thread-Verarbeitungswarteschlange warten, was bedeutet, dass nur ein Skript gleichzeitig ausgeführt werden kann.

Das schnelle Versenden einer Menge JavaScript an Ihren Benutzer ist also so, als würde man mit einem Feuerwehrschlauch auf eine Mauer mit einem Abstand von einem Zentimeter schießen.

Gute Arbeit geleistet, aber es wird nicht alles klappen!

Google macht die schnelle Reaktionsfähigkeit auf der Client-Seite immer mehr zu unserer Aufgabe. Ob Sie es mögen oder in einen Topf werfen, so ist es (also machen Sie sich besser damit vertraut).

Sie könnten frustriert sagen: „Warum ist das so!?“ Webbrowser haben seit Jahren Zugriff auf mehrere Verarbeitungsthreads, selbst mobile Browser haben aufgeholt. Es ist doch nicht nötig, dass die Dinge so umständlich sind, oder?“

Eigentlich ja. Einige Skripte sind auf die Ausgabe anderer Skripte angewiesen, bevor sie selbst ausgeführt werden können.

Aller Wahrscheinlichkeit nach würde der größte Teil des Webs abstürzen und brennen, wenn alle Browser plötzlich beginnen würden, das gesamte JavaScript parallel und nicht in der richtigen Reihenfolge zu verarbeiten.

Es gibt also einen guten Grund dafür, dass die sequenzielle Skriptausführung das Standardverhalten moderner Webbrowser ist. Ich betone immer wieder das Wort „Standard“. Warum das?

Das liegt daran, dass es andere Möglichkeiten gibt. Eine besteht darin, den Browser des Clients daran zu hindern, Skripte zu verarbeiten, indem diese im Namen des Benutzers verarbeitet werden. Dies wird als serverseitiges Rendering (SSR) bezeichnet.

Es ist ein leistungsstarkes Tool zum Entwirren clientseitiger JavaScript-Ausführungsknoten, aber auch sehr teuer.

Ihr Server muss alle Skriptanforderungen (von allen Benutzern) schneller verarbeiten, als der Browser eines durchschnittlichen Benutzers ein einzelnes Skript verarbeitet. Lassen Sie das einen Moment auf sich wirken.

Kein Fan dieser Option? OK, lassen Sie uns die JavaScript-Parallelisierung untersuchen. Die Grundidee besteht darin, Web-Worker zu nutzen, um zu definieren, welche Skripte nacheinander geladen werden und welche möglicherweise parallel geladen werden.

Sie können zwar das parallele Laden von JavaScript erzwingen, es ist jedoch äußerst davon abzuraten, dies standardmäßig zu tun. Die Integration einer solchen Technologie würde den Bedarf an SSR in den meisten Fällen weitgehend verringern.

Die Implementierung wird jedoch sehr umständlich sein und (Sie haben es erraten!) die Zeit eines erfahrenen Webentwicklers in Anspruch nehmen.

Derselbe Mann, den Sie mit der Durchführung Ihres vollständigen JavaScript-Code-Audits beauftragen, kann Ihnen möglicherweise auch dabei helfen. Wenn Sie die JavaScript-Parallelisierung mit einem kritischen JavaScript-Rendering-Pfad kombinieren, sind Sie wirklich auf dem Vormarsch.

In diesem Beispiel ist hier das wirklich Interessante:

Sie können sofort erkennen, dass der Hauptthread 17 Sekunden lang belegt ist, während die JavaScript-Ausführung 12 Sekunden in Anspruch nimmt.

Bedeutet das, dass 12 Sekunden der 17 Sekunden Thread-Arbeit JavaScript-Ausführung sind? Das ist sehr wahrscheinlich.

Wir wissen, dass das gesamte JavaScript standardmäßig durch den Hauptthread gepusht wird.

So ist auch WordPress, das aktive CMS, standardmäßig eingerichtet.

Da auf dieser Website WordPress ausgeführt wird, stammen die gesamten 12 Sekunden JavaScript-Ausführungszeit wahrscheinlich aus den 17 Sekunden der Hauptthread-Arbeit.

Das ist eine großartige Erkenntnis, denn sie zeigt uns, dass die meiste Zeit des Hauptverarbeitungsthreads für die Ausführung von JavaScript aufgewendet wird. Und wenn man sich die Anzahl der referenzierten Skripte ansieht, ist das nicht schwer zu glauben.

Machen Sie den Kreuzzug zu den Chrome Dev Tools

Es ist Zeit, technisch zu werden und die Stützräder abzunehmen.

Öffnen Sie eine neue Instanz von Chrome. Sie sollten ein Gastprofil eröffnen, um sicherzustellen, dass es keine Unordnung oder aktivierte Plugins gibt, die unsere Ergebnisse aufblähen.

Denken Sie daran: Führen Sie diese Aktionen über ein sauberes Chrome-Gastprofil aus.

Laden Sie die Site hoch, die Sie analysieren möchten. In unserem Fall ist das TechCrunch.

Akzeptieren Sie Cookies nach Bedarf. Sobald die Seite geladen ist, öffnen Sie Chrome DevTools (klicken Sie mit der rechten Maustaste auf eine Seite und wählen Sie „Inspizieren“ ).

Navigieren Sie zu Leistung > Screenshots.

Klicken Sie auf die Schaltfläche „Neu laden“, um den Ladevorgang der Seite aufzuzeichnen. Anschließend wird ein Bericht erstellt:

Hier müssen wir alle tief durchatmen und versuchen, nicht in Panik zu geraten.

Oben sehen Sie, grün eingerahmt, einen dünnen Bereich, der Anfragen im Zeitverlauf veranschaulicht.

In diesem Feld können Sie mit der Maus einen Zeitabschnitt auswählen. Der Rest der Seite und die Analyse werden dann automatisch angepasst.

Der Bereich, den ich manuell ausgewählt habe, ist der Bereich, der mit einem halbtransparenten blauen Kästchen bedeckt ist.

Dort findet das Laden der Hauptseite statt und das ist es, was ich untersuchen möchte.

In diesem Fall habe ich den Zeit- und Ereignisbereich grob zwischen 32 ms und 2,97 Sekunden gewählt. Konzentrieren wir unseren Blick auf das Innere des Hauptthreads:

Wissen Sie, dass ich vorhin gesagt habe, dass die meisten Rendering-Aufgaben und JavaScript-Ausführungen durch den Engpass des Hauptthreads erzwungen werden?

Nun schauen wir uns das Innere dieses Hauptthreads im Laufe der Zeit an. Und ja, in Gelb können Sie viele Skriptaufgaben sehen.

In den oberen Zeilen erscheinen im Laufe der Zeit immer mehr dunkelgelbe Blöcke, die alle ausgeführten Skripte und deren Verarbeitungsdauer bestätigen. Sie können auf einzelne Balkenabschnitte klicken, um eine Anzeige für jedes Element zu erhalten.

Obwohl es sich hierbei um ein aussagekräftiges Bild handelt, finden Sie im Abschnitt „Zusammenfassung“ ein noch aussagekräftigeres Bild:

Dadurch werden alle granularen Daten zusammengefasst, unterteilt in einfache thematische Abschnitte (z. B. Skripterstellung , Laden , Rendern ) über das leicht verständliche visuelle Medium eines Donut-Diagramms.

Wie Sie sehen, nimmt die Skripterstellung (Skriptausführung) den größten Teil der Seitenlast ein. Unsere frühere Vermutung aus Googles Mischung aus Feld- und Labordaten, die auf Engpässe bei der JavaScript-Ausführung im Hauptthread hindeutete, scheint also zutreffend gewesen zu sein.

Im Jahr 2023 ist dies eines der am häufigsten auftretenden Probleme, für das es nur wenige einfache Lösungen von der Stange gibt.

Es ist komplex, kritische JavaScript-Renderingpfade zu erstellen. Für die Durchführung von JavaScript-Code-Audits ist Fachwissen erforderlich, und es ist nicht so einfach, JavaScript-Parallelisierung oder SSR einzuführen.

Schauen wir uns nun den Aufrufbaum an:

Call Tree ist oft nützlicher als Bottom-Up .

Die Daten sind ähnlich, aber Call Tree gruppiert Aufgaben thematisch in praktische Bereiche wie „Skript auswerten“ (Skriptausführung).

Sie können dann auf eine Gruppe klicken, sie erweitern und die Skripte sowie deren Ladezeit sehen. 11 % der Zeit wurde für das Laden pubads_impl.jsm benötigt, während 6 % der Zeit für das Laden opus.js benötigt wurden.

Ich weiß nicht, was diese Module sind (und Sie vielleicht auch nicht), aber hier beginnt oft die Optimierungsreise.

Wir können jetzt einen Schritt zurückgehen zu:

• Googeln Sie diese Skripte und prüfen Sie, ob sie Teil von Bibliotheken von Drittanbietern sind, was sie tun und welche Auswirkungen sie haben.
• Wenden Sie sich an den Entwickler, um zu erfahren, wie diese intelligenter eingesetzt werden können.
• Grenzen Sie das Problem auf einzelne Ressourcen ein und suchen Sie nach Alternativen.
• Beheben Sie das Leistungsdefizit (oder kämpfen Sie alternativ für mehr Ressourcen/Bandbreite und eine starke Hosting-Umgebung – falls dies tatsächlich erforderlich ist).

Weitere Tools zur Messung und Optimierung der Core Web Vitals

Wenn Sie es bis hierhin geschafft haben, bei mir zu bleiben, herzlichen Glückwunsch. Im Hinblick auf tiefgreifende Core Web Vitals und Seitengeschwindigkeitsanalysen haben wir nur Folgendes verwendet:

• PageSpeed-Einblicke
• Chrome DevTools (Registerkarte „Leistung “)

Ja, man kann wirklich so schlank sein. Es gibt jedoch noch andere Tools, die Ihnen eine große Hilfe sein können:

• GTMetrix : Besonders nützlich für sein Wasserfalldiagramm (erfordert ein kostenloses Konto für Wasserfall), dessen Lesen Sie hier erfahren können. Vergessen Sie nicht, dass GTMetrix standardmäßig ungedrosselt läuft, was zu sehr günstigen Ergebnissen führt. Stellen Sie unbedingt eine LTE-Verbindung ein.
• Google Search Console : Wenn Sie dies einrichten und Ihre Website überprüfen, können Sie im Laufe der Zeit viele Leistungs- und Benutzerfreundlichkeitsdaten sehen, einschließlich Core Web Vitals-Metriken über mehrere Seiten hinweg (aggregiert).
• Screaming Frog SEO Spider : Dies kann mit der Page-Speed-API verbunden werden, um das Massenabrufen von Core Web Vitals-Bestehens- oder Nichtbestehensnoten (für mehrere Seiten) zu ermöglichen. Wenn Sie die kostenlose Page-Speed-API verwenden, sollten Sie diese nicht unangemessen übertreiben

Früher war die Verbesserung Ihrer Page-Speed-Bewertungen so einfach wie das Komprimieren und Hochladen einiger Bilder.

Heutzutage? Es ist ein komplexer Core Web Vitals-Kreuzzug.

Bereiten Sie sich darauf vor, sich voll und ganz zu engagieren. Alles andere führt zum Scheitern.