Seitengeschwindigkeit – ein Leitfaden für Einsteiger

Wie wäre es, wenn wir die Geschwindigkeit einer Website nicht anhand der in einem PageSpeed-Test erzielten Punkte betrachten würden, sondern anhand dessen, was tatsächlich mit unserer Website passiert, von dem Moment an, in dem sie online gestellt wird, bis sie dem Benutzer angezeigt wird?

Ich denke, dann würde alles logischer werden und die Elemente, die die Seitengeschwindigkeit beeinflussen, wären keine schwarze Magie mehr. Und genau das soll der folgende Artikel sein – eine logische Erklärung der verschiedenen Elemente der Website-Geschwindigkeit mit Blick auf Anfänger und Fortgeschrittene.

Dieser Leitfaden wurde für Anfänger geschrieben und verwendet ein möglichst einfaches Vokabular. Unter Zwang verstehe ich nicht ungewöhnliche Situationen und Programmierumgebungen.

Zu Beginn: die Karte

Werfen wir einen Blick auf die Schlüsselelemente, die die Geschwindigkeit der Seite beeinflussen….

… und lassen Sie es uns dann Schritt für Schritt analysieren.

Schritt 1: Vorbereitung der Dateien

Sehen wir uns zunächst die Schritte an, die wir unternehmen müssen, bevor der Ladevorgang der Website überhaupt beginnt, d. h. die ordnungsgemäße Vorbereitung der Dateien.

Optimierung der Grafik

Der erste Punkt ist ziemlich selbsterklärend und ich zitiere ihn hier nur der Form halber.

Viele Leute denken, dass die Vorbereitung von Grafiken für die Optimierung der Seitengeschwindigkeit einfach darin besteht, sie mit einem geeigneten Grafikprogramm richtig zu komprimieren.

Dies ist natürlich wichtig – eine verlustfreie Komprimierung (d. h. eine Komprimierung, die die Qualität des Bildes nicht sichtbar beeinträchtigt) ist oft möglich, wodurch die Dateigröße erheblich reduziert wird.

Es ist jedoch wichtig, daran zu denken, dass es nicht nur auf die Größe der Bilddatei ankommt, sondern auch darauf, wie Sie das Bild auf der Seite einbetten.

In erster Linie sollten Sie Grafiken verwenden, die für die Anzeige skaliert sind.

Wenn ein 2080 x 1542 großes Foto unseres Gesichts als winziger Avatar dienen soll, müssen wir es auf die passende Größe verkleinern. Wenn man nicht weiß, wie groß sie sein sollen, weil sie z. B. in der mobilen Version klein sind und in der Desktop-Version den ganzen Bildschirm einnehmen, kann man mehrere Versionen vorbereiten und sie z. B. mit dem Attribut srcset ausgeben.

Wenn möglich, ist es auch eine gute Idee, die Abmessungen des Bildes mit jeder Grafik anzugeben; auf diese Weise kann der Browser Platz für das Bild reservieren, noch bevor es geladen wird, und ist nicht gezwungen, das Aussehen der Seite nach dem Laden „neu zu gestalten“.

Wie wirkt sich die grafische Optimierung auf die Geschwindigkeit der Website aus?

Dies ist eine der ersten und wichtigsten Optimierungsmaßnahmen, da sie oft die Ladezeiten am stärksten verkürzt und in den meisten Fällen relativ einfach zu realisieren ist.

Websites, bei denen ein kleines Logo in Wirklichkeit eine riesige Grafik von mehreren Megabyte ist, sind keine Seltenheit.

Verringerung der Größe von HTML-, CSS- und JS-Code

Ich habe diesen Unterpunkt bereits in dem Artikel beschrieben:
Entfernen Sie ungenutzten Code – CSS- und JS-Optimierung in der Praxis.

Wie wirkt sich die Verringerung der Größe von HTML-, CSS- und JS-Code auf die Geschwindigkeit der Seite aus?

Das hängt natürlich davon ab, wie viel unnötigen Code Sie entfernen können. Die Menge des entfernten Codes steht in direktem Verhältnis zur Verbesserung der Ladegeschwindigkeit, und darüber hinaus kann die Entfernung ungenutzter und oft „schwerer“ JS-Skripte viel Zeit für die unnötige Ausführung durch den Browser sparen.

Begrenzung der Anzahl und Größe der externen Dateien

Es liegt auf der Hand, dass die Anzahl und Größe der extern angehängten Dateien (z. B. JS-Skripte) auf ein absolutes Minimum beschränkt werden muss. Jede solche Datei bedeutet, dass ein Skript gelesen, verarbeitet und ausgeführt werden muss.

Außerdem bedeutet jede dieser Dateien, dass eine Verbindung zu einem anderen Server als dem, auf dem unsere Website gehostet wird, hergestellt werden muss, was den gesamten Prozess in die Länge zieht. Als ob das nicht genug wäre, entziehen sich externe JS-Dateien praktisch unserer Kontrolle. Wir können die Dauer der Zwischenspeicherung nicht festlegen; außerdem führt ein möglicher Ausfall des Servers des Providers zu Problemen auf unserer Website.

Wie wirkt sich die Verringerung der Anzahl der externen Dateien auf die Geschwindigkeit der Website aus?

Es ist sehr wichtig, die Anzahl der externen Skripte zu begrenzen. Das Problem ist jedoch, dass dies nicht immer möglich ist, da es zum Beispiel schwierig ist, eine Website ohne Analysen von Google Analytics zu betreiben. Also machen wir es mit unserem Kopf. Wenn wir zum Beispiel vor einem Jahr ein Facebook-Pixel oder ein Skript zur Erstellung von Heatmaps installiert haben und es noch nie benutzt haben, dann sollten Sie es auf jeden Fall loswerden. Je weniger auf der Website passiert, desto besser.

HTML verkleinern, CSS verkleinern, JavaScript verkleinern

Minify oder Code Minification ist eigentlich ein recht einfacher Prozess, bei dem unnötige Leerzeichen, Abstände, Formatierungen, Kommentare, Kommas und andere unnötige Symbole aus dem Code entfernt werden.

Natürlich machen wir das nicht manuell, denn das wäre praktisch unmöglich. Für die Code-Minifizierung empfiehlt Google verschiedene Programme wie HTMLMinifier, CSSNano oder UglifyJS, von denen eine Liste hier zu finden ist.

Wie wirkt sich die Code-Minifizierung auf die Seitengeschwindigkeit aus?

Auch wenn es sich unrealistisch anhört, lassen sich durch das Weglassen von unnötigem Ballast in den Dateien die Dateigrößen tatsächlich erheblich reduzieren, so dass der Download der Website über den Browser beschleunigt wird.

Allerdings gibt es hier ein grundsätzliches „aber“. Mining funktioniert nicht immer nach dem Prinzip „Einstellen und vergessen“. Leider muss der verkleinerte Code jedoch auf seine korrekte Funktionsweise getestet werden. Es kommt zum Beispiel vor, dass unser nicht so transparenter JS-Code nach der Minifizierung auch nicht so funktionaler Code wird.

Schritt 2: Server-seitiges Laden

Der Browser des Internetnutzers hat eine Anfrage an unseren Server gesendet, so dass wir mit der Wiedergabe beginnen können.

Server-Antwortzeit (TTFB)

TTFB oder Time to first byte ist die Zeit von der ersten Anfrage des Browsers bis zum Empfang der ersten Datenbytes. Sie können diese Zeit in DevTools in Chrome leicht überprüfen.

Google empfiehlt einen TTFB von unter 200 Millisekunden, alles unter 100 Millisekunden ist ein sehr gutes Ergebnis. Ergebnisse über 600 Millisekunden bedeuten, dass wahrscheinlich etwas nicht stimmt.

Aber woher kommt diese Zeit wirklich?

Der TTFB setzt sich aus 3 Gruppen von Faktoren zusammen:

  • die an den Server gesendete Anfrage – hier kann es aus verschiedenen Gründen zu Verzögerungen kommen, z. B. durch eine langsame DNS-Antwort (z. B. wenn der Server physisch weit vom Client entfernt ist) oder durch komplizierte Firewall-Regeln
  • Serverseitige Verarbeitung – der Server muss die Anfrage „verarbeiten “ und eine Antwort generieren, d. h. Abfragen an die Datenbank vornehmen, serverseitige Skripte ausführen und die fertige Antwort als ersten Teil der Daten in die Welt senden
  • Antwort an den Client – ausschlaggebend sind hier die Geschwindigkeit der Datenübertragung durch den Server und die Geschwindigkeit der Internetverbindung beim Empfänger; sie bestimmen, wie lange es dauert, bis das erste vom Server gesendete Datenbyte den Empfänger erreicht

In der Praxis ist es die zweite Gruppe von Faktoren, die manchmal die größten Schwierigkeiten bereiten und die größten Einsparungen ermöglichen. Der Fehler liegt nicht immer (oder sogar meistens) bei einem langsamen Server.

Wenn eine Website beispielsweise eine große Anzahl von Datenbankabfragen durchführt oder bei jedem Ladevorgang einen komplexen Vorgang ausführt, kann selbst der beste Server den Datenverkehr nicht bewältigen und wird merklich langsamer laufen. Die Antwort könnte das serverseitige Caching oder die Verwendung von CDNa sein.

Wir sollten jedoch immer zuerst sicherstellen, dass unsere Website einfach gut geschrieben ist und den Server nicht überlastet. Ein Wechsel des Servers auf einen leistungsfähigeren könnte sich dann als sinnlos erweisen, da sich die Situation bei steigendem Datenverkehr wiederholen wird.

Wie wirkt sich die Verkürzung der Server-Antwortzeit auf die Seitengeschwindigkeit aus?

Wenn Ihr TTFB bei oder unter 200 Millisekunden schwankt, gönnen Sie sich weitere Optimierungen, bis sie notwendig werden. Je weiter Sie in den Wald vordringen, desto komplexer und schwieriger werden die Schritte.

Wenn die TTFB deutlich größer ist, liegt die Antwort auf die Frage, wie sich eine Verkürzung der TTFB auf die Geschwindigkeit auswirkt, auf der Hand. Dann müssen Sie sich überlegen, wie Ihre Anwendung aufgebaut ist.

Wenn Sie den TTFB für eine einfache, statische Testseite in HTML messen und er deutlich niedriger ist als bei den anderen URLs, liegt das Problem mit ziemlicher Sicherheit im Design Ihrer Website und/oder Datenbank.

Schritt 3: Download-Prozess

Ok, der Server hat die Seite für uns zum Hochladen vorbereitet – wir beginnen mit dem Herunterladen der Daten.

Gzip-Komprimierung

Wenn Sie vor dem Jahr 90 geboren wurden. es ist gut möglich, dass Sie versucht haben, eine große Datenmenge auf einer 1,44 MB-Diskette unterzubringen. Und es ist gut möglich, dass Sie zu diesem Zeitpunkt eine Komprimierungssoftware verwendet haben, z. B. WinZip oder WinRar.

Die Dateikomprimierung ist in diesem Fall vergleichbar mit dem „Packen“ von Dateien mit WinZip. HTML-, CSS- und JS-Dateien werden automatisch in das gzip-Format komprimiert und vom Browser in dieser Form heruntergeladen – so muss der Browser weniger Daten herunterladen. Nach dem Herunterladen dekomprimiert der Browser die Dateien automatisch und liest sie.

Es ist unwahrscheinlich, dass die Komprimierung Bilddateien einschließt – diese werden in den meisten Fällen standardmäßig komprimiert.

Wie wirkt sich die Dateikomprimierung auf die Seitengeschwindigkeit aus?

Die Komprimierung von Dateien in das gzip-Format ist bei Dateien über 150 Byte (d. h. bei fast allen Dateien) immer sinnvoll. Das Lesen komprimierter Daten dauert kürzer als das Herunterladen unkomprimierter Dateien.

Kurz gesagt: Unabhängig von der Zeitersparnis ist die Komprimierung so standardmäßig und einfach zu implementieren, dass sie sich in fast jedem Fall lohnt.

Interessanterweise kann sich die gzip-Komprimierung nachteilig auf TTFB auswirken. Das liegt daran, dass der Server die ersten Datenbytes nicht sofort nach ihrer Erzeugung sendet, sondern erst die gesamte Datei abwarten muss, um sie vollständig zu komprimieren. Die gesamte Ladezeit der Seite wird dadurch jedoch immer noch schneller sein.

Begrenzung von Weiterleitungen

301-Weiterleitungen sind eine Möglichkeit, einen Benutzer automatisch von einer URL zu einer anderen weiterzuleiten. Die Google-Roboter respektieren die Weiterleitung, indem sie ebenfalls der Adresse folgen. Wenn sich also beispielsweise die URL Ihrer Website ändert, hat der Google-Robot dank der 301-Weiterleitung die richtige Adresse angezeigt, und der Browser des Nutzers führt ihn fast unmerklich dorthin.

Das ist richtig: fast unmerklich. Der Browser sendet eine Anfrage, um den Inhalt der URL abzurufen, erhält eine Umleitungsnachricht zurück und sendet dann die Anfrage an die neue Adresse. Kurz gesagt, er hat also mehr zu tun (er verbindet sich öfter mit dem Server).

Das Problem entsteht, wenn die so genannte „neue“ Technologie geschaffen wird. Umleitungskette – das heißt, wenn eine angeforderte URL zu einer URL umleitet, die wiederum zu einer anderen URL umleitet. Dies kann z. B. bei Weiterleitungen der Art:

domena.com -> www.domena.com -> www.domena.com/pl

Wie wirkt sich die Begrenzung von 301-Weiterleitungen auf die Seitengeschwindigkeit aus?

Hier hängt die Wirkung natürlich vom Ausmaß des Problems ab. In extremen Fällen, in denen die Umleitungskette lang ist, innerhalb mehrerer URLs auftritt oder sogar in eine Schleife fällt, kann die Behebung dieses Problems eine heilsame Wirkung auf die Geschwindigkeit der Website haben.

Unerwünschte Anfragen vermeiden

Eine schlechte Anfrage (nicht zu verwechseln mit einem 400 Bad Request Fehler) ist eine Anfrage, die nicht erfüllt werden kann und einen 404 oder 410 Code zurückgibt. Kurz gesagt, wenn z. B. im Code ein Verweis auf ein JS-Skript enthalten ist: domain.pl/skrypt.js , und es gibt kein solches Skript an der angegebenen Adresse – dann haben wir es mit einer fehlerhaften Anfrage zu tun.

Wie wirkt sich die Vermeidung fehlerhafter Anfragen auf die Seitengeschwindigkeit aus?

Es ist ganz einfach: Sich auf nicht vorhandene Ressourcen zu beziehen, ist Zeitverschwendung. Dies liegt daran, dass der Browser die Anfrage vergeblich senden muss; er erhält keine Datei als Antwort.

CDN – Dienst zur Bereitstellung von Inhalten (Verteilung)

Ein CDN ist, kurz gesagt, ein Netzwerk von Hochgeschwindigkeitsservern, die eine relativ „frische“ Kopie Ihrer Website (oder nur Elemente davon, wie z. B. Bilddateien) auf ihren Festplatten speichern und sie vom schnellsten Server für den Benutzer bereitstellen. Für einige Parteien mag eine solche Lösung heilsam sein, für andere völlig unnötig.

Wie wird sich das CDN auf die Geschwindigkeit der Website auswirken?

Während die Antwort „es kommt darauf an“ für fast jedes Element der Verbesserung der Website-Geschwindigkeit gilt, wirft die Verwendung von CDNs die meisten Fragen auf. Für einige große Websites ist ein CDN oder eine ähnliche Technologie fast eine Notwendigkeit. Wenn wir die Website beispielsweise in Polen hosten und die Nutzer unserer Website beispielsweise hauptsächlich Amerikaner sind, kann sich ein CDN ebenfalls als nützlich erweisen. Ein CDN kann auch die Sicherheit verbessern, indem es z. B. vor DDoS-Angriffen schützt.

Das CDN ist jedoch eine recht anspruchsvolle Optimierung, die eine angemessene Konfiguration erfordert, kostenpflichtig ist und auf kommerziellen Lösungen Dritter basiert. Wenn ich schon ein CDN empfehle, dann meist nur als letzten Schritt im Optimierungsprozess – es lohnt sich, alle anderen Empfehlungen vorher zu machen und ihre Wirkung zu überprüfen. Wenn Sie eine einfache WordPress-Website mit Hosting und Kunden in Polen betreiben, keine Videos auf der Website streamen, keine Grafiken und Downloads bereitstellen und vor allem: keinen großen Datenverkehr haben, ist die Wahrscheinlichkeit, dass Sie ein CDN benötigen, vernachlässigbar.

Schritt 4: Laden im Browser

Wir haben bereits – oder werden jeden Moment – eine Seite vom Server heruntergeladen, nun kümmert sich unser Browser um das Rendern – er denkt darüber nach, wie die Seite aussehen soll, was die verschiedenen Skripte tun und zeigt sie uns schließlich an.

Browser-Cache

Die Verwendung des Browser-Caches kann die Ladezeiten von Seiten für wiederkehrende Besucher erheblich verkürzen. Das liegt daran, dass wir für jeden Dateityp (oder für einzelne Dateien) einen „expires“- oder „max-age“-Header setzen können (oder eine andere Methode verwenden – je nach Konfiguration) – d.h. dem Browser mitteilen, wie oft er die neueste Version der Datei vom Server herunterladen soll.

Wenn wir also zum Beispiel beim ersten Besuch ein großes Bild laden, wird dem Browser mitgeteilt, wie lange er es in seinem Cache behalten soll. Wenn es sich beispielsweise um 30 Tage handelt, wird der Browser im nächsten Monat bei weiteren Besuchen der Website keine Zeit mit dem erneuten Herunterladen desselben Bildes verschwenden und es einfach aus dem Cache laden.

Wenn wir also nicht ständig mit dem Design unserer Website experimentieren, können Dateien wie CSS-Sheets, Grafiken oder JS-Skripte auch für längere Zeiträume wie ein Jahr mit einem Verfallsdatum versehen werden.

Wie wirkt sich die Verwendung von Browser-Caching auf die Seitengeschwindigkeit aus?

Der Einfluss der Browser-Cache-Nutzung kann sehr groß sein, aber es ist zu beachten, dass der Unterschied nur bei wiederkehrenden Nutzern spürbar sein wird.

In einigen Fällen kann das Browser-Caching auch das Laden einer Website für Erstbesucher beschleunigen. Dies geschieht z. B. beim Herunterladen externer Skripte und Dateien, die auf anderen Websites unverändert benötigt werden.

Das beste Beispiel sind die von Google Fonts heruntergeladenen Schriftarten. Dieselbe Schriftart, die auf zwei Websites verwendet wird, wird nur einmal heruntergeladen; beim Besuch der zweiten Website verwendet der Browser bereits den Cache.

Bei extern geladenen Dateien haben wir jedoch keinen Einfluss auf den „expires“-Header. Und ob Schriftarten – auch mit der beschriebenen Eigenschaft – besser von Google Fonts oder lokal geladen werden, können Sie in meinem Artikel von vor einem Jahr nachlesen.

Rendering und JavaScript

Wenn der Browser den Code unserer Website herunterlädt, beginnt er, ihn zu analysieren und baut den so genannten „Code“ auf. HOPE-Baum. Durch die zeilenweise Analyse des Codes fügt es weitere Elemente zur Struktur der Website hinzu, noch bevor es sie uns anzeigt. Wenn es im Code auf JavaScript-Code stößt, muss es die Analyse anhalten und das gefundene Skript ausführen, um zu erfahren, welche Auswirkungen es auf die Struktur der Website hat.

Dies wirkt sich sehr negativ auf die Geschwindigkeit der Website aus, denn bevor der Browser uns überhaupt etwas anzeigt, verschwendet er viel Zeit mit der Ausführung von Skripten, die oft nicht relevant sind und warten könnten.

Noch schlimmer ist es, wenn das Skript von einem externen Server heruntergeladen wird – dazu muss eine Verbindung zu einem anderen Server hergestellt und die Datei heruntergeladen werden. In der Zwischenzeit wartet der Benutzer die ganze Zeit darauf, dass der Seiteninhalt gerendert wird.

Was sollte also getan werden? Vermeiden Sie vor allem ladungshemmende Skripte. Wenn wir sie verwenden müssen, bleiben uns die Attribute defer und async.

<script async src="skrypt.js"></script>
<script defer src="skrypt.js"></script>

Das async-Attribut ändert die Standardmethode zum Aufbau des DOM-Baums. Damit gekennzeichnete Skripte blockieren das Rendering der Website nicht und werden sozusagen im Hintergrund geladen. Dies hat auch seine Nachteile – es ist nicht möglich, die Reihenfolge zu kontrollieren, in der solche Skripte ausgeführt werden, oder beispielsweise auf document.write zu verweisen.

Das Attribut defer blockiert die Ausführung der damit gekennzeichneten Skripte vollständig, bis das Rendering aller kritischen Elemente der Website abgeschlossen ist.

Beide Methoden sind nicht ideal, da einige Skripte frühzeitig geladen werden müssen – viele JS-Frameworks funktionieren beispielsweise nicht, wenn Sie Bibliotheken mit dem Attribut async oder defer markieren.

Wie wirkt sich die Einschränkung von JavaScript, das die Darstellung einer Website blockiert, auf deren Geschwindigkeit aus?

Das ist sehr wichtig, vor allem, wenn unsere Website-Vorlage beispielsweise viele JavaScript-Wasserfunktionen verwendet. Das Wichtigste ist, alle Skripte, die unsere Website lädt, zu überprüfen und so viele unnötige Skripte wie möglich loszuwerden. Vor allem, wenn es sich um extern geladene Skripte handelt.

Außerdem entfällt dadurch das Risiko, dass z. B. der Server des Skriptanbieters abstürzt, was zu einer Wartezeit von mehreren Dutzend Sekunden bis zum Laden des Skripts führen kann.

Schritt 5: Messung der Auswirkungen

Der Prozess ist abgeschlossen, jetzt wollen wir seine Auswirkungen messen.

Im Internet wimmelt es von „Zauberern“, die Ihnen Optimierungen anbieten, damit Sie beim PageSpeed-Test 100 von 100 Punkten erreichen. Es ist toll, wenn Ihre Website ein solches Ergebnis erzielt, mit dem Sie bei einem Abendessen mit Ihrer Schwiegermutter angeben können, aber darüber hinaus wird es Ihnen nicht viel nützen.

Tests wie zum Beispiel. GTMetrix sollte als Leitfaden betrachtet werden. Eine hohe Punktzahl wirkt sich sicherlich positiv auf die Geschwindigkeit der Website aus, aber diese Punkte können kein Selbstzweck sein.

Ich lobe selten die Maßnahmen von Google, aber eine Initiative von Google ist meiner Meinung nach fantastisch und sehr richtig.

Dies sind die neuen Core Web Vitals-Indikatoren, die – und das ist wichtig – in Kürze zu einem direkten Ranking-Faktor werden sollen.

Mehr über Core Web Vitals habe ich vor einiger Zeit in diesem Artikel geschrieben. Zur Erinnerung: Dies ist eine Liste von Indikatoren, die sich tatsächlich und realistisch auf die Seitengeschwindigkeit und die Benutzerfreundlichkeit auswirken.

Kurz gesagt sind dies:

  • First Input Delay – wie lange es dauert, mit einer Seite zu interagieren (z. B. einen Link anzuklicken)
  • Kumulative Layoutverschiebung – um wie viel sich der Inhalt gegenüber der ersten Anzeige verschiebt, wenn weitere Elemente zur Website hinzugefügt werden
  • Größtes inhaltsreiches Bild – wie lange es dauert, bis eine Seite das größte inhaltsreiche Element im Browserfenster lädt

Core Web Vitals kann auf verschiedene Weise gemessen werden, z. B. durch einen Google PageSpeed-Test oder in Search Consoli.

Gibt es Abkürzungen?

Natürlich sind sie das. Für WordPress und andere beliebte CMS gibt es fertige Plug-ins. Selbst wenn Sie einen solchen verwenden wollen, lohnt es sich, die oben genannten Texte zu lesen, um zu wissen, was getan wird und warum. Denken Sie daran, dass alle diese Plug-ins konfiguriert werden müssen. Es gibt keine gute Lösung für alle Beteiligten, und jeder muss diese Einstellungen für sich selbst herausfinden. So ist zum Beispiel ein 30-Tage-Cache für die Startseite einer Nachrichten-Website keine gute Idee.

Eine weitere Abkürzung, die sich letztlich als sehr holprig erweisen kann, ist die Implementierung von AMP. Ich habe auch schon etwas über AMP geschrieben, aber die wichtigsten Fakten sind: Wenn es um die Optimierung Ihrer Seitengeschwindigkeit geht, wird AMP den größten Teil der Arbeit für Sie erledigen. Aber in vielen anderen Fragen sind Ihnen die Hände gebunden. Ihre Entscheidung.


Und so ist es. Es gibt natürlich noch weitere Themen wie Lazy Loading, CSS-Sprites und viele andere, aber die Umsetzung der genannten Punkte dürfte den größten Nutzen bringen. Unabhängig davon, ob wir die Optimierung der Website-Geschwindigkeit an einen Spezialisten auslagern oder selbst durchführen, ist es natürlich wichtig, dass wir immer wissen, was wir tun und welchen Nutzen wir daraus ziehen können.

Und wenn Sie Hilfe bei der Geschwindigkeitsoptimierung oder bei einem anderen SEO-Problem benötigen, dann erinnere ich Sie daran, dass ich bei kleineren Problemen kostenlos helfe, und etwas mehr für eine Gebühr mache ich umfassende SEO mit einem Schwerpunkt auf dem technischen Aspekt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert