WPO-Leitfaden: Optimiere die Geschwindigkeit deiner Website

Was ist WPO?

Web Performance Optimization, was wir als WPO bezeichnen, ist einfach die Optimierung der verschiedenen Prozesse, die das Laden einer Website beeinflussen.

Wie misst man die Ladegeschwindigkeit einer Website?

Es gibt zahlreiche Tools zur Messung der Ladegeschwindigkeit. Die beliebtesten sind:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Bevor wir mit einem Audit beginnen, ist es wichtig zu bedenken, dass die Ladegeschwindigkeit für jeden Nutzer variiert. Verschiedene Variablen können beeinflussen, wie sich die Geschwindigkeit für einen Nutzer in Cuenca im Vergleich zu einem in Ottawa anfühlt.

Aus diesem Grund empfehlen wir, statt mit Ladezeiten in Sekunden zu arbeiten, die Optimierung von Folgendem in den Vordergrund zu stellen:

• ›

  Gewicht der Website (MB)

• ›

  Requests

• ›

  Server-Antwortzeit

Wenn wir diese 3 Bereiche verbessern, wird sich die Ladegeschwindigkeit unabhängig vom Standort des Nutzers verbessern.

Wir werden in jeden Bereich eintauchen und über die verschiedenen Tools sehen, wie wir daran arbeiten können, um die Performance jeder URL zu verbessern. Warum sage ich jeder URL? Weil – auch wenn es offensichtlich erscheinen mag – ich auf viele Fälle gestoßen bin, in denen nur die Daten der Startseite ausgewertet wurden, und natürlich lädt nicht jede Seite einer Site die gleichen Ressourcen.

Google Developer Tools

Bevor wir beginnen, möchte ich einige Optionen erläutern, die Google über seine Entwicklertools anbietet. Dieses Tool ist eines der wichtigsten, um zu analysieren, wie eine Website funktioniert. Klicke mit der rechten Maustaste auf die geöffnete Seite, und es erscheint ein Panel mit verschiedenen Optionen. Wir gehen auf "Untersuchen" (Strg + Umschalt + I).

Sobald dieses Tool geöffnet ist, gehen wir oben auf die Option NETWORK. Wenn wir im Browser erneut ENTER drücken, zeigt uns das Tool das Laden der verschiedenen Ressourcen.

Am unteren Rand des Bildes sehen wir die Daten, die uns für eine allgemeine Sicht auf das Laden der Site interessieren.

Tauchen wir tiefer in dieses Panel oben ein und schauen uns die Spaltenstruktur an:

• ›

  Name: der Name der Ressource.

• ›

  Status: der Antwortcode der Ressource (200, 301, 404 …)

• ›

  Type: der Typ der Ressource (Skript, Schriftart, png, jpg, Stylesheet …)

• ›

  Initiator: welche Ressource die Anfrage auslöst.

• ›

  Time: wie lange die Anfrage gedauert hat.

• ›

  Waterfall: eine grafische Darstellung der Ladezeiten einer Ressource.

Wenn wir oben mit der rechten Maustaste klicken, können wir Spalten mit diesen Informationen hinzufügen oder entfernen.

Zusätzliche Informationselemente wie Domain, Scheme oder Cookies zu aktivieren, kann in bestimmten Fällen helfen, Ressourcen zu lokalisieren, die uns Probleme bereiten könnten, aber an dieser Stelle bleiben wir bei den vordefinierten.

Es gibt einen Aspekt, der zwar sehr interessant ist, den ich aber nur kurz anspreche, damit wir ihn im Hinterkopf behalten. Die Verbindungsgeschwindigkeit, vor allem auf Mobilgeräten, ist ein zentraler Faktor dafür, wie eine Site lädt. Über dieses Tool können wir langsamere Geschwindigkeiten wie 3G auf dem Handy simulieren.

Wie kennt man das Gewicht einer URL und wie reduziert man es?

Das Gewicht, ob in Megabyte oder Kilobyte, ist einer der Hauptgründe, warum eine URL Zeit zum Laden braucht. Deshalb beginnen wir mit diesem Aspekt, denn er gibt den Weg vor, um eine gute Optimierung auf unserer Site zu erreichen.

Die folgenden Daten stammen aus dem oben erwähnten Tool GTMETRIX und entsprechen einer Website, die ich gleich zu optimieren beginne.

Wir konzentrieren uns auf die Daten in der rechten Spalte, die sich auf (Page Details) bezieht, insbesondere auf die Total Page Size.

Auf den ersten Blick liegt das Gewicht dieser Site weit über dem Durchschnitt, aber bedenke, dass nicht das Gesamtgewicht der Site zählt, sondern wie lange dieses Gewicht zum Laden braucht – denn es gibt etwas, das sich Lazy Load nennt, eine Funktion, die das Laden verzögert, bis der Nutzer die Ressource benötigt. Darüber sprechen wir später.

Diese Information finden wir auch in den Developer Tools, in dem Panel, das wir uns oben angesehen haben und das ich dir erneut in Erinnerung rufe.

Wenn du nach unten schaust, kommen sowohl die 7,5 MB als auch die 215 Requests den von GTMETRIX gemeldeten Zahlen sehr nahe. Es ist wichtig, dass du weißt, woher GTMETRIX seine Informationen bezieht, falls du irgendwann ein anderes Tool verwenden möchtest.

Sehen wir uns nun an, was so viel wiegt und wie wir es beheben können.

Die Waterfall-Option bietet einen visuellen Blick darauf, wie Ressourcen geladen werden, und zeigt die Ressourcen-URL, den Status, die Domain und die Spalte Size. Wenn wir auf diese letzte Spalte klicken, sortiert sie die Gewichte vom größten zum kleinsten und vom kleinsten zum größten.

Wenn wir die Gewichte betrachten, sehen wir, wie es in den meisten Fällen passiert, dass Bilder größtenteils für das übermäßige Gewicht der URL verantwortlich sind.

Es gibt keine formelle Vorgabe für das maximale Gewicht eines Bildes, aber wir empfehlen nicht mehr als 100 KB und – wenn du die Möglichkeit hast (mit Photoshop hast du sie) – Bilder progressiv als JPG zu laden und PNG immer dann zu vermeiden, wenn du keinen Alphakanal (Transparenz) brauchst.

Indem wir das Gewicht der Bilder reduzieren, verbessern wir das Laden der Site deutlich, und dafür gibt es mehrere Tools, die du verwenden kannst. Ich persönlich optimiere mit Photoshop, aber es gibt interessante Online-Optionen:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Sowohl GTMetrix als auch das Google-Tool erlauben uns, Ressourcen nach Typ anzusehen, das heißt nur Bilder, Skripte, CSS …

Das ist nützlich für eine breitere Perspektive darauf, wo gearbeitet werden muss. Auf dieser URL machen Bilder 4 MB von 7,2 MB aus, ein großer Teil des Gewichtsproblems liegt also dort. Trotzdem stechen andere Ressourcen als extrem schwer für ihren Typ heraus, etwa eine CSS-Datei mit über 700 KB und ein Skript mit über 300 KB.

An diesem Punkt möchte ich klarstellen, dass wir bei einer Ladegeschwindigkeitsoptimierung (WPO) bestimmten Problemen gegenüberstehen, die zwar Lösungen haben, aber außerhalb unseres Einflussbereichs liegen.

In diesem Fall sehen wir eine sehr große CSS-Datei. Wenn der Designer ein CSS mit über 700 KB erstellt hat, wird es schwierig sein, genau diese Datei zu optimieren.

Was können wir tun, um das Gewicht dieser Dateien zu reduzieren?

Minify (CSS, JS und HTML)

Minifizierung ist ein Prozess, der versucht, das Dateigewicht zu reduzieren, indem unnötige Daten entfernt werden wie Kommentare, Leerzeichen, doppelter Code und ungenutzter Code. Es gibt viele Tools, um diesen Prozess durchzuführen, mit Ausnahme des ungenutzten Codes, der schwerer zu optimieren ist und ein manuelles Eingreifen in die Datei erfordern würde (was ich nicht empfehle).

Tools zur Minifizierung von Dateien

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

Zum Glück sprechen wir über WordPress, und wie wir alle wissen, gibt es in WordPress so gut wie immer ein Plugin, das diese Operation erledigt.

Persönlich verwende ich gern ein vollständig kostenloses Plugin, Autoptimize, und ein bezahltes, WP Rocket.

In diesem Artikel will ich nicht so sehr erklären, wie diese Plugins funktionieren, sondern wie man die Optimierungsaufgaben durchführt. Denn wenn wir andere Plugins verwenden, haben sie ebenfalls diese Optionen, und das Beste ist, zu verstehen, was wir tun.

Minifizieren mit WP Rocket

Dieser Teil ist nicht komplex. Wir gehen einfach in den Tab File Optimization und setzen den Haken bei Minify HTML. In WP Rocket wiederholt sich diese Option weiter unten für CSS- und JS-Dateien. Trotzdem empfehle ich, dieses Kästchen zu aktivieren und zu testen. Wiederhole diese Option Schritt für Schritt, denn wenn etwas schiefläuft, ist es einfacher, das Problem einzugrenzen.

Bevor wir den Effekt der Minifizierung prüfen, müssen wir den Cache leeren, sonst sehen wir das Ergebnis des aktualisierten HTML nicht.

Wie leert man den Browser-Cache?

Diese Art von Plugins kommt mit Optionen zum Leeren des Caches, die wir oben sehen können.

Eine andere Möglichkeit ist über den Browser, sobald Google Developer Tools aktiviert ist (Strg + Umschalt + I).

Klicke mit der rechten Maustaste auf den "Seite neu laden"-Pfeil und wähle "Cache leeren und vollständig neu laden".

Minifizieren mit Autoptimize

Bei Autoptimize ist die Aktion "Optimize" das, was die Minifizierung durchführt, mit der Besonderheit, dass eine Option angeboten wird, HTML-Kommentare zu behalten. Diese Kommentare werden in der Regel von Entwicklern eingefügt, um Informationen aufzubewahren, die in Zukunft nützlich sein können.

Um zu prüfen, ob diese Optimierung gegriffen hat, gehen wir in den Quellcode der URL und sollten so etwas sehen:

Der Code wird unleserlich, aber seine Funktionalität ist dieselbe.

Diese Optionen wiederholen sich auf die gleiche Weise in WP Rocket und Autoptimize für CSS- und JS-Dateien. Wie ich vorher erwähnt habe, empfehle ich nicht, alles auf einmal zu optimieren, sondern Stück für Stück. Diese Plugins behalten Kopien der minifizierten Dateien, sodass das Zurücksetzen auf das Original durch Deaktivieren des entsprechenden Kästchens möglich ist.

Um das Seitengewicht weiter zu reduzieren, haben wir 2 weitere Optionen:

• ›

  Plugins, die CSS oder JS zur Last hinzufügen, entfernen oder reduzieren.

• ›

  Ungenutzten Code aus der CSS-Datei entfernen oder kürzen.

Diese 2 Optionen sind komplexer und erfordern mehr Wissen, denn du musst vorsichtig sein und sicherstellen, dass es keine Aufrufe von anderen Seiten auf den Teil gibt, den du entfernst.

Auch wenn das Entfernen von Plugins wegen der Ressource, die sie liefern, nicht immer möglich ist, gibt es Plugins, die besser optimiert sind als andere – das heißt, weniger Requests und leichteres JS. Im wunderbaren WordPress-Ökosystem gibt es also fast immer eine Alternative.

Ladezeit vs. Antwortzeit

Jetzt ist es an der Zeit, über Requests, Antwortzeit und Ladezeit zu sprechen. An diesem Punkt müssen wir einen grundlegenden Teil des Prozesses erwähnen: den Server. Die Server-Optimierung liegt meist nicht in unserer Hand, daher ist es wichtig, eine effiziente Lösung zu wählen.

Aber gehen wir Schritt für Schritt vor.

Was ist ein Request?

Ein Request, oder HTTP Request, ist ein Aufruf, den der Client an den Server stellt, um eine bestimmte Ressource anzufordern. Requests können verschiedene Server treffen.

Requests können entweder HTTP oder HTTPS sein. Wenn wir die Struktur eines Requests betrachten, können wir analysieren, wo die Verzögerung entsteht.

Analyse einer HTTP-Request-Zeit

Lass uns aufschlüsseln, was wir in diesem Timing-Diagramm sehen.

• ›

  Der Request wird gestartet, aber blockiert oder in die Warteschlange gestellt: Wenn der Block lange dauert, kann das mehrere Gründe haben: Requests höherer Priorität oder viele Requests an diesen Origin.

• ›

  DNS Lookup: Der Browser löst die IP-Adresse des Requests auf.

• ›

  Connecting: die Zeit, die benötigt wird, um sich mit dem Server zu verbinden, um den Request aufzulösen. Wenn diese Zeit hoch ist, kann das auf Netzwerkprobleme, Verbindungsfehler oder einen überlasteten Server hindeuten.

• ›

  Sending: Die Ressourcen-Anfrage wird gesendet.

• ›

  Waiting: Das ist die Zeit, die der Server braucht, um einen Request aufzulösen und eine Antwort zu senden; wenn sie lang ist, gibt es ein Problem auf dem Server.

• ›

  Receiving: Empfang der Ressource.

Ein HTTPS-Request fügt einen zusätzlichen Schritt hinzu, hier dargestellt.

Diese beiden Screenshots gehören zu zwei verschiedenen Sites, einer nicht optimierten (HTTP Request) und einer optimierten (HTTPS Request).

Wenn du genau hinsiehst und vergleichst, liegt der größte Unterschied in der Wartezeit. In diesen Fällen müsstest du den Server genauer analysieren.

Server-Requests: Wie können wir sie reduzieren?

Wie wir gesehen haben, ist die Anzahl der Requests eng mit der Ladezeit verbunden, sodass eine Reduzierung die Ladezeiten einer URL verbessern würde. Gesunder Menschenverstand spielt im Optimierungsprozess eine Rolle, und zu wissen, ob eine Ressource für den Nutzer oder unser Geschäft wirklich nützlich ist. Das ist der Moment, sich von bestimmten Ressourcen zu verabschieden, die nichts beitragen, aber das ist nicht meine Entscheidung.

Trotzdem haben wir Optionen, um Requests zu verbessern, auch wenn diese Aktionen das Laden der Site nicht riesig verändern. Ich wiederhole mich: Das Beste ist, Ressourcen zu entfernen, die nichts beitragen.

CSS und JS kombinieren

Eine weitere beliebte Aktion bei der Optimierung einer Webseite ist das Kombinieren von CSS- und JS-Ressourcen, aber was bedeutet das?

Das Ziel des Kombinierens ist, Requests zu reduzieren, auf Kosten eines erhöhten Dateigewichts. Kombinieren bedeutet, die verschiedenen CSS- oder JS-Ressourcen in einer einzigen zu vereinheitlichen.

Wenn die Antwortzeiten lang sind, kann das Kombinieren von Vorteil sein. Wenn die Sendezeiten sehr langsam sind, ist vielleicht eine andere Technik besser.

Ideal ist, zu kombinieren und gleichzeitig einen guten Server zu haben, sodass wir auf beiden Seiten gewinnen.

Ressourcen mit WP Rocket und Autoptimize kombinieren

Die Combine-Operation mit diesen Plugins ist genauso einfach wie zuvor. Wir setzen einfach den Haken im entsprechenden Kästchen.

In WP Rocket sind die Optionen zum Kombinieren von CSS und JS gleich; die Panels sind praktisch identisch. Wie wir im Bild sehen, gibt es ein Feld, um den Pfad von Dateien hinzuzufügen, die wir nicht kombinieren wollen.

Unter der Checkbox sehen wir auch einen Hinweis darauf, die Combine-Option nicht zu verwenden, wenn wir HTTP/2 nutzen. Dieser Artikel erklärt mehr zu HTTP/2.

Autoptimize bietet mehr Optionen, um mit CSS zu arbeiten und Requests zu reduzieren. In der Option, die ich markiere, wird kombiniert, und es wird vor der möglichen Wirkung gewarnt, aber am Ende ist das immer relativ.

In diesem ersten Teil des Artikels wollte ich erklären, worin bestimmte grundlegende Aktionen bestehen – die, die wir praktisch in allen WPO-Optimierungs-Plugins sehen –, aber wir können noch eine Menge tun, um sowohl Requests als auch Ladezeiten zu verbessern.

Cache-Konfiguration

Ohne Zweifel ist die Cache-Optimierung eine der Aktionen, bei denen wir die größten Verbesserungen beim Laden einer Site bemerken werden. In diesem Artikel über SEO für WordPress habe ich erklärt, wie der Cache funktioniert. Ich empfehle dir, ihn dir anzusehen, um zu verstehen, wie er funktioniert.

Autoptimize und WP Rocket führen Caching-Aktionen durch, aber WP Rocket bietet ein paar mehr Optionen. Erwähnenswert ist, dass die Plugins diese Optimierung zu etwas Einfachem gemacht haben: Du hast kaum mehr als ein paar Optionen, und der Prozess ist schnell und schmerzlos.

Wie du siehst, lässt dich WP Rocket an 4 Dingen arbeiten:

• ›

  Caching für mobile Geräte aktivieren.

• ›

  Dateien für mobile Geräte separat speichern.

• ›

  Caching für eingeloggte Nutzer aktivieren.

• ›

  Die Zeit zum Leeren des Caches angeben.

Es hängt vom jeweiligen Projekt ab, welche Option zu wählen ist, aber mit all dem im Hinterkopf ist mein Rat:

• ›

  Mobile Cache immer, denn obwohl die meisten Sites responsive sind, gibt es Inhalte, die du auf dem Handy haben kannst, aber nicht auf dem Desktop.

• ›

  Dateien separat.

• ›

  Kein Cache für eingeloggte Nutzer, vor allem, weil ich beim Bearbeiten kein Caching möchte.

• ›

  Cache-Zeit, die davon abhängt, wie viele Änderungen du an deiner Site vornimmst. Bei einer täglichen Nachrichtenseite kurz; bei Inhalten, die nicht häufig aktualisiert werden, länger.

Lazyload

Die Lazyload-Funktion hilft dabei, Ressourcen (Bilder und Iframes) anzuzeigen, wenn der Nutzer sie braucht; das heißt, der Browser lädt diese Ressourcen erst, wenn der Nutzer zu ihnen scrollt. Diese Funktion ist in vielen Plugins implementiert und kommt sogar in einigen WordPress-Themes vorkonfiguriert. Ab Chrome-Version 76 ist sie sogar nativ im Browser enthalten.

Das bedeutet, dass durch das Hinzufügen des Attributs loading="lazy" der Browser das Lazy Loading des Bildes bereits interpretiert, aber natürlich werden nicht alle Browser das interpretieren, daher empfehle ich, das Plugin weiter zu verwenden. Hier ist ein Video, das von web.dev stammt und ein Beispiel zeigt, worum es beim Lazy Loading von Bildern geht.

Iframe-Optimierung

Wenn wir Iframes verwenden, um Inhalte von anderen Seiten einzubetten, haben wir zwei Aktionen, die wir nutzen können, um unser Laden zu verbessern.

• ›

  Lazy Loading über die Lazyload-Funktion

• ›

  Oder Ersetzen des Iframes durch ein Bild, bis der Nutzer darauf klickt.

Sowohl die erste als auch die zweite Option lassen sich – einmal mehr – über unser Lieblings-Plugin WP Rocket aktivieren.

Autoptimize hat diesen Teil nicht, bietet aber die Installation eines ergänzenden Plugins dafür an: https://wordpress.org/plugins/wp-youtube-lyte/

Verzögertes Laden von JS-Dateien mit Defer oder Async

JS-Dateien sind eine der Übeltäter dessen, was Geschwindigkeits-Audits als Render-Blocking einer Seite bezeichnen. Das passiert, wenn der Browser beim Rendern anhält, um eine JS-Datei herunterzuladen und auszuführen. Das Ziel der WPO-Optimierung ist, dem Nutzer Informationen so schnell wie möglich zu liefern, weshalb das als blockierend gilt – denn nichts wird gerendert, bis das heruntergeladene JS ausgeführt wird.

Deshalb wird diese Art von Aktion im Audit oft markiert. Bei der Verwendung von Drittanbieter-Plugins oder Themes, die nicht gut optimiert sind, kann es sein, dass JS das Rendering blockiert, weil es zum Beispiel im Header steht.

In diesen Fällen sollten wir zwei Attribute verwenden, die im JS-Aufrufcode hinzugefügt werden, Defer und Async. Damit diese Attribute funktionieren, müssen die Skripte extern sein.

Bei SEO Alive verwenden wir das Plugin Pre Party Resource Hints, mit dem du auswählen kannst, welche Dateien und welche Lademethode angewendet werden sollen. Ein Wunder!

Was ist der Unterschied zwischen Defer und Async?

Obwohl beide Attribute ein ähnliches Ziel verfolgen, nämlich die Interpretation des DOM-HTML nicht durch das JS zu stoppen, gibt es einen bemerkenswerten Unterschied zwischen den beiden.

Mit dem Async-Attribut wird die Ressource heruntergeladen, ohne das HTML-Laden zu stoppen, aber sobald sie heruntergeladen ist, wird das HTML-Laden pausiert, um das JS auszuführen; mit dem Defer-Attribut wird die Ressource ebenfalls parallel zum HTML-Laden heruntergeladen, aber sie wird ausgeführt, wenn das Laden beendet ist, sodass es keine Blockierung durch das Skript gibt.

In dieser Hinsicht gibt es Unterschiede zwischen WP Rocket und Autoptimize. WP Rocket macht dir die Entscheidungen viel einfacher und handelt halbautomatisch, um zu verhindern, dass JS das Rendern blockiert; in Autoptimize hingegen kannst du nur die Async-Option umschalten.

In Autoptimize haben wir unter dem Tab Extra diese Option, um die JS-Dateien hinzuzufügen, die wir mit Async laden wollen, aber für mehr Flexibilität wird ein weiteres ergänzendes Plugin empfohlen, "Async Javascript".

Mit diesem Plugin können wir sowohl mit Defer als auch mit Async arbeiten, und es bietet sogar Ein-Klick-Optionen, um die Dinge zu erleichtern. Das Gute an diesem Plugin ist, dass wir mit Skripten arbeiten und diejenigen ausschließen können, die wir für nötig halten. In WP Rocket hingegen müssen wir auf das vertrauen, was das Plugin tut, auch wenn es das gut macht.

Diese Option befindet sich im selben File-Optimization-Tab.

Was ist ein CDN und wie kann es uns helfen?

Ein CDN ist das, was als Content Delivery Network bekannt ist. Das CDN ist dafür zuständig, einen Teil der Informationen und Ressourcen zu speichern, um die Last des Servers für diese Ressourcen zu erleichtern und besser auf das Laden zu reagieren. CDNs haben außerdem eine geografische Kopierfunktion, um die Ressource an verschiedenen Punkten verfügbar zu halten und sie dem Nutzer unabhängig davon zu liefern, von wo er sich verbindet. Normalerweise wird diese Art von Service für schwere Dateien wie Bilder und Videos verwendet.

Sich für diesen Service anzumelden, ist wichtig, wenn wir Sites mit viel Traffic haben, sollte aber auch bei Sites mit wenig Traffic nicht ausgeschlossen werden.

Weitere Maßnahmen, die uns noch ein bisschen mehr Verbesserung bringen

Um den Artikel abzuschließen, haben wir 3 weitere Verbesserungen, die zwar keine großen Veränderungen bei den Ladezeiten bewirken, uns aber helfen werden, Requests zu reduzieren, und am Ende ist es das, was wir wollen.

Schriftarten-Optimierung

Schriftarten-Optimierung kann über Plugins oder manuell durch Bearbeiten und Optimieren des CSS erfolgen. Ideal wäre, nur die Schriftart aufzurufen, die du verwenden wirst, und nicht – wie es in vielen Fällen passiert – eine Datei mit allen Google Fonts herunterzuladen.

Autoptimize hat eine Option, um an Schriftarten zu arbeiten.

Es ist schwer zu sagen, welche Option du wählen sollst, ohne das Projekt gesehen zu haben, denn ich weiß nicht, welche Schriftart dein Template verwendet und wann sie geladen wird, sodass das Beste ist, zu testen und das Ergebnis zu sehen.

Wie du siehst, haben wir direkt nach den Google-Fonts-Optionen "Remove Emoji", was uns einen Request an den Server spart. Seine Funktion besteht einfach darin, Symbole, die Emojis darstellen, in das Icon umzuwandeln.

Auch WP Rocket erlaubt uns, diese Emojis zu deaktivieren, und bietet außerdem die Option, das Einbetten von Inhalten auf Drittseiten zu verhindern.

Am Ende gibt es viele Aktionen, um die Ladegeschwindigkeit einer Site zu verbessern. Es ist nicht immer möglich, in die Tiefe zu gehen, um jede Ressource zu optimieren, denn das hängt vom Geschäftstyp und seinen Bedürfnissen ab.

Ich hoffe, dieser WPO-Optimierungsleitfaden ist hilfreich und du kannst ihn auf deine Projekte oder für deine Kunden anwenden.