Core Web Vitals: Das deutsche Handbuch (inkl. 30-Punkte-Checkliste für WordPress)

Alles, was du über die Core Web Vitals wissen musst: Wie wichtig sie sind. Wie du sie misst und optimierst. Und wie du nicht komplett dabei verzweifelst.
Google-Ranking-Faktoren für 2021

Einleitung

Ein neues Schreckgespenst nähert sich in großen Schritten:

Die Core Web Vitals werden bald zum offiziellen Ranking-Faktor.

Das Problem:

Sie sind ein technik- und fachbegrifflastiges Thema. Und Google selbst bietet kaum Hilfestellung dazu auf Deutsch an.

Deshalb habe ich dieses (inoffizielle) deutsche Handbuch zu den Core Web Vitals erstellt. Hier erfährst du unter anderem…

  • Wie du den LCP, CLS und FID deiner WordPress-Website Schritt für Schritt optimieren kannst (in drei separaten Anleitungen)
  • Wie wichtig die Core Web Vitals als Ranking-Faktor werden (und ob es sich lohnt, darauf zu optimieren)
  • Was zur Hölle all die f****** Akronyme eigentlich bedeuten (FID, CLS, LCP, FCP, TTFB, LMAA, Tatütata)

Und nein:

Du musst kein Web-Entwickler sein oder Programmierkenntnisse haben, um die meisten Optimierungen umzusetzen und gute Scores zu erreichen. Denn Gott sei Dank gibt es Plugins dafür.

Aber dazu später mehr.

Fangen wir erst einmal mit den Basics an:

1. Was sind die Core Web Vitals?

Die Core Web Vitals sind ein in 2020 vorgestellter Ranking-Faktor, der dazu dienen soll, die Nutzererfahrung einer Webseite besser zu bewerten.

Die Core Web Vitals bestehen aus folgenden drei Unterpunkten:

  • Largest Contentful Paint (LCP): Der LCP misst, wie lange das größte Elemente einer Webseite (im zuerst sichtbaren Darstellungsberich) zum Laden braucht, wodurch die “wahrgenommene Ladezeit” einer Webseite bewertet wird.
  • First Input Delay (FID): Der FID misst, wie lange eine Webseite braucht, um auf die erste Interaktion eines Nutzers (Mausklick, Scrollen etc.) zu reagieren. Dadurch wird die “Interaktivität” einer Webseite bewertet.
  • Cumulative Layout Shift (CLS): Der CLS misst, wie sehr sich das Seitenlayout während des Ladens verschiebt und soll die visuelle Stabilität einer Webseite bewerten.

Als Ranking-Faktor reihen sie sich in diverse bereits bestehende Faktoren zur Bewertung der Seitenerfahrung (Page Experience) ein, wie z. B. die Nutzerfreundlichkeit auf Mobilgeräten oder HTTPS:

Wann werden die Core Web Vitals eingeführt?

Sie sollten ursprünglich ab Mai 2021 ein Ranking-Faktor für die Google-Suche werden.

Laut einer Mitteilung im April gibt Google Publishern jedoch mehr Zeit für die Anpassung. Sie werden jetzt erst ab Mitte Juni in den Algorithmus integriert. Und da auch erst nach und nach (der Roll-out soll Ende August abgeschlossen sein).

2. Die Core Web Vitals als Ranking-Faktor

Ja, die Core Web Vitals sind ein von Google bestätigter Ranking-Faktor (und davon gibt es nicht allzu viele, oder zumindest nicht so viele, die so gut messbar sind wie die Web Vitals).

Aber nicht so schnell!

Bevor du blind drauflos optimierst, solltest du folgendes über die Core Web Vitals wissen:

1. Die Core Web Vitals werden (erst einmal) kein großes Ding

Es deutet aktuell nichts daraufhin, dass die Core Web Vitals zu ihrer Einführung große Auswirkungen auf das Ranking haben werden.

Gary Illyes von Google betonte z. B. im September 2020 auf Reddit, dass die Core Web Vitals nichts mit der Qualität und Relevanz von Suchergebnisse zu tun haben und deswegen höchstwahrscheinlich nie zum wichtigsten Ranking-Faktor werden würden:

Like any other search engine, Google works hard to surface the highest quality and most relevant results for users’ queries. CWV has nothing to do with either of those, not even remotely, so it’s extremely unlikely that CWV would ever become “the primary factor for Organic Traffic”. That’s not to say you can ignore CWV, though.

Ein Hilfedokument zu den Core Web Vitals in der Google Search Central bestärkt die Aussage von Illyes. Die Core Web Vitals sind demnach eher ein Zünglein an der Waage:

Die Nutzerfreundlichkeit ist zwar wichtig, dennoch berücksichtigt Google beim Ranking weiterhin vor allem die angebotenen Informationen, auch wenn die Nutzererfahrung in mancher Hinsicht unterdurchschnittlich ausfällt. Eine gute Nutzerfreundlichkeit bedeutet nicht, dass relevante Inhalte unwichtiger werden. Wenn allerdings viele Seiten ähnlich relevante Inhalte haben, kann die Nutzerfreundlichkeit einen wesentlich größeren Einfluss auf die Sichtbarkeit in der Google Suche haben.

Ähnliche Aussagen findet man auch von anderen Google-Mitarbeitern, wie z. B. Danny Sullivan, Martin Splitt oder John Mueller.

Und nein, falls du dich wunderst:

Viele von Googles eigenen Webseiten bestehen den Test selbst nicht. Darunter auch die offizielle Seite zu den Core Web Vitals, die einen viel zu hohen CLS-Wert hat:

2. Sie sind nur Ranking-Faktor für die mobile Suche

Die Desktop-Werte der Core Web Vitals sind für das Ranking egal, denn sie werden (erst einmal zumindest) ausschließlich ein Ranking-Faktor für die mobile Suche sein.

Das lässt dich diesem FAQ in der Search Console-Hilfe entnehmen:

Q: Is there a difference between desktop and mobile ranking? 
A: At this time, using page experience as a signal for ranking will apply only to mobile Search.

Achte beim Testen also vornehmlich darauf, dass deine Seiten den Core-Web-Vitals-Test mobil bestehen:

3. Du musst alle drei Tests bestehen

Beim Testen und Optimieren auf die Core Web Vitals ist es wichtig zu verstehen, dass eine Seite die Schwellenwerte aller drei Core Web Vitals (in PageSpeed Insights markiert durch ) erreichen muss, um den Test zu bestehen und von einem möglichen Ranking-Boost zu profitieren.

Die besten FID- und LCP-Werte nützen dir also nichts, wenn du einen zu hohen CLS-Wert hast.

Hier findest du einen Überbick über die Schwellenwerte:

GutSchlechtPerzentil
LCP≤ 2,5 s> 4 s75
FID≤ 100 ms> 300 ms75
CLS≤ 0,1> 0,2575

Ein Perzentil von 75 bedeutet, dass 3 von 4 Nutzermessungen (also 75 %) im guten Bereich liegen müssen, damit deine Seite insgesamt als “gut” für einen der drei Core Web Vitals eingestuft wird.

Der PageSpeed-Score (im grünen, gelben oder roten Kreis) ist für die Core Web Vitals übrigens irrelevant, obwohl er natürlich ein guter Indikator ist.

Du kannst Werte von 95, 97 oder sogar 100 haben und den Core-Web-Vitals-Test trotzdem nicht bestehen:

Wegen mehrerer Layout-Verschiebungen hat mein Blogartikel den Test nicht bestanden. Die konnte ich durch Vorladen meiner selbst gehosteten Google Fonts jedoch komplett beseitigen.

Das hat zwei Gründe:

Erstens errechnet sich der PageSpeed-Score nicht nur aus den Core Web Vitals (LCP, FID und CLS), sondern auch aus TTI, TTB, SI und FCP. Die genaue Zusammensetzung des Scores findest du hier.

Zweitens errechnet er sich ausschließlich aus Labdaten. Die sind jedoch für die Core Web Vitals nicht entscheidend:

4. Die Felddaten zählen, nicht die Labdaten!

Zum Bestehen des Core Web Vitals-Tests zählen ausschließlich Felddaten, wie man auf der offizielle Seite bei web.dev nachlesen kann:

While all of the Core Web Vitals are, first and foremost, field metrics, many of them are also measurable in the lab.

Bei Felddaten handelt es sich um Messungen von echten Chrome-Nutzern, die im sogenannten Chrome User Experience Report (CrUX) gesammelt werden.

Die Labdaten, die dir in PageSpeed Insights oder einem Lighthouse-Test mit den Chrome DevTools angezeigt werden, sind hingegen “unter Laborbedingungen” gemessen und stellen als solche nur eine eingeschränkte Momentaufnahme dar, weshalb sie auch nur bedingt als Ranking-Faktor taugen.

Die Felddaten aus dem CrUX der letzten 28 Tage kannst du in PageSpeed Insights sehen:

Wenn du Daten aus dem CrUX einsehen möchtest, die länger zurückliegen, kannst du das mit dem CrUX Dashboard in Google Data Studio machen.

Damit kann ich mir für Blogmojo z. B. die aggregierten Daten für den aggregierten FID von Mai 2020 bis Feburar 2021 anzeigen lassen:

Auch die Daten aus dem Core Web Vitals-Bericht in der Google Search Console zeigen Felddaten an:

Hinweis: Bitte achte beim Testen und Optimieren darauf, dass es bis zu 28 Tage dauern kann, bis deine Optimierungen sich in den Felddaten widerspiegeln.

5. Aggregierte vs. URL-spezifische Felddaten

Vielleicht ist dir bei PageSpeed Insights schon einmal aufgefallen, dass nicht bei allen URLs Felddaten angezeigt werden, sondern nur die sogenannte Origin Summary:

Dabei handelt es sich um einen domainweit berechneten Mittelwert, der immer dann angezeigt wird, wenn nicht genügend Felddaten zur Verfügung stehen, also eine Seite nicht von ausreichend vielen Chrome-Nutzern besucht wurde.

Im Core Web Vitals-Bericht in der Google Search Console werden LCP, FID und CLS übrigens auch aggregiert angezeigt (aufgeteilt nach verschiedenen URL-Gruppen):

Dabei gilt:

Wenn in den letzten 28 Tagen genügend Felddaten für eine URL gesammelt werden konnten, dann wird diese auch nach diesen URL-spezifischen Felddaten bewertet.

Denn die Core Web Vitals sind laut Core Web Vitals FAQ von Dezember 2020 sind prinzipiell ein seitenbezogener Ranking-Faktor:

Q: Is Google recommending that all my pages hit these thresholds? What’s the benefit?
A: We recommend that websites use these three thresholds as a guidepost for optimal user experience across all pages. Core Web Vitals thresholds are assessed at the per-page level […]

Wenn allerdings nicht genügend Felddaten zur Verfügung stellen, z. B. bei neu veröffentlichten oder wenig besuchten Seiten, wird eine Seite laut Core Web Vitals FAQ von März 2021 nach aggregierten Daten der dazugehörigen Domain/Website bewertet, also den Daten, die du in der Origin Summary sehen kannst:

Q: How is a score calculated for a URL that was recently published, and hasn’t yet generated 28 days of data?
A: Similar to how Search Console reports page experience data, we can employ techniques like grouping pages that are similar and compute scores based on that aggregation. This is applicable to pages that receive little to no traffic, so small sites without field data don’t need to be worried.

Und das heißt:

Du solltest alle Seiten auf deiner Website optimieren, denn schlecht optimierte Seiten können die gut optimierten herunterziehen.

3. Lohnt sich die Optimierung?

Es kommt darauf an:

Wenn du bislang keine oder nur wenige Rankings in den Top 10 hast, dann solltest du dich eher auf andere Dinge konzentrieren, wie z. B. Link-Building, Keyword-Recherche und -Optimierung und die Qualität deines Contents.

Wenn du allerdings viele Rankings in den Top 10 hast und du vielleicht sogar in einer Nische mit starker Konkurrenz unterwegs bist (Finanzen, Webhosting, Fitness, Online-Marketing, Ernährung etc.), kann es sich durchaus lohnen, deine Core Web Vitals zu optimieren.

Sagen wir z. B. deine Seite ist auf Platz 4 für ein Keyword mit hohem Suchvolumen und hoher Kaufbereitschaft und in puncto E-A-T und Relevanz für Google fast genauso stark wie die Seite auf Platz 3.

Dann kann ein kleiner Boost durch die Core Web Vitals möglicherweise dafür sorgen, dass sich die Waage zu deiner Seite neigt und du auf Platz 3 landest. Und, je nach Keyword, kann das einige hundert oder sogar einige tausend Euro mehr Umsatz im Monat bedeuten.

Hinweis: Es kann sich auch lohnen die Core Web Vitals zu optimieren, einfach um deine Nutzererfahrung zu verbessern (unabhängig von irgendwelchen Ranking-Vorteilen). Google hat sie nicht nur aus reiner Schikane entwickelt. Webseiten mit zu starkem CLS oder hohem LID finde ich auch selbst nervig.

Du hast dich, dazu entschieden, deine Core Web Vitals zu optimieren?

Dann lies weiter und hake einfach jeden der folgenden Punkte ab!

Damit du deine Seiten gezielter optimieren kannst, habe ich meine Checkliste nach LCP, FID und CLS sortiert und dafür eigene Unterseiten erstellt (bitte beachte dabei, dass sich manche Punkte bei LCP und FID überschneiden).

4. Empfohlene WordPress-Plugins

Ich habe viele verschiedene Caching- und Performance-Plugins getestet, darunter auch z. B. Nitropack, Flying Press oder Autoptimize. WP Rocket bietet jedoch das beste Gesamtpaket. Mit dem Plugin alleine lassen sich ca. 80 % aller Punkte auf der Checkliste abhaken.


Mit perfmatters kannst du nicht benötigte CSS- und JS-Dateien global oder auf Seitenbasis ausschalten. Das hilft enorm dabei, überladene WordPress-Installationen zu entschlacken.


Mit dem EWWW Image Optimizer kannst du Bilder komprimieren und in WebP umwandeln, was sie deutlich verkleinert und deinen LCP verbessern kann. Wahlweise kannst du auch Imagify oder ShortPixel nehmen.

5. Die 30-Punkte-Checkliste

Damit du deine Seiten gezielter optimieren kannst, habe ich drei Unterseiten erstellt, die sich jeweils mit der Optimierung des LCP, FID und CLS befassen (klicke auf die Überschrift um zur jeweiligen Seite zu kommen):

Hinweis: Manche Optimierungsmaßnahmen verbessern zwei Core Web Vitals gleichzeitig. Viele Maßnahmen, um den FID zu verbessern, wirken sich z. B. auch positiv auf den LCP aus. Punkte, die schon bei anderen Web Vitals genannt wurden, habe ich mit Stern (✪) markiert

Cumulative Layout Shift (CLS) optimieren

1Breite und Höhe von Bildern ergänzen
2Vermeide Flash of Invisible Text (FOIT)
3Vermeide Flash of Unstyled Text (FOUT)
4Embeds und iframes
5Anzeigen
6Nicht zusammengesetzte Animationen vermeiden
7Pop-ups, Banner und anderer dynamischer Content
8Kritisches CSS vorab laden (auch LCP)

Largest Contentful Paint (LCP) optimieren

9Page-Caching verwenden
10Cache Preloading verwenden
11Lazy-Loading bei Bildern above the fold ausstellen
12Textkomprimierung aktivieren (auch FID)
13Drittanbieter-Code reduzieren (auch FID)
14JavaScript verzögert laden (auch FID)
15Verbindungen zu Drittservern vorab aufbauen (auch FID)
Kritisches CSS vorab laden (auch CLS)
16HTTP/2 verwenden
17Bilder komprimieren
18Bildqualität verringern
19Moderne Bildformate verwenden
20Bild-Abmessungen auf verfügbaren Platz anpassen
21Bildgrößen regenerieren
22Videoformate für animierte Bilder verwenden
24Deinen Server optimieren
25Unnötiges CSS und JavaScript entfernen (auch FID)
26CSS- und JS-Dateien komprimieren (auch FID)
27Unnötige Plugins deaktivieren (auch FID)
28Ein schlankes WordPress-Theme verwenden (auch FID)

First Input Delay (FID) optimieren

29Übermäßige DOM-Größe vermeiden
30Long Tasks aufteilen
Unnötiges JavaScript entfernen (auch LCP)
Ein schlankes WordPress-Theme verwenden (auch LCP)
JS-Dateien komprimieren (auch LCP)
Textkomprimierung aktivieren (auch LCP)
Unnötige Plugins deaktivieren (auch LCP)
Drittserver-Code reduzieren (auch LCP)
JavaScript verzögert laden (auch LCP)
Drittservern-Verbindungen vorab aufbauen (auch LCP)

6. Glossar (die Akronyme aus der Hölle)

FID, CLS, LCP, FCP, TTFB, LMAA, Tatütata?

Wie du vielleicht schon mitbekommen hast, bringen die Core Web Vitals (und der generelle Bereich der Speed-Optimierung) dutzende Fachbegriffe mit sich, davon sehr viele Akronyme.

Damit du nicht beim Lesen dieses Guides verzweifelst, habe ich dir eine Liste mit den wichtigsten Begriffen und Akronymen zusammengestellt:

above the fold

Wenn etwas above the fold einer Webseite ist, dann ist es in dem Darstellungbereich, den ein Nutzer direkt beim Öffnen der Webseite sieht (ohne zu scrollen). Je nach Endgerät kann dieser Bereich unterschiedlich groß sein.

CLS (Cumulative Layout Shift)

Der CLS misst, wie sehr sich das Seitenlayout während des Ladens verschiebt und soll die visuelle Stabilität einer Webseite bewerten.

CPCSS (Critical Path CSS)

Als CPCSS bezeichnet man das CSS, das zur Darstellung des Contents above the fold einer Webseite benötigt wird.

CruX (Chrome User Experience Report)

Im CruX werden Daten zur Nutzererfahrung von Webseiten gesammelt. Dazu zählen neben LCP, FID und CLS auch weitere Performance-Daten die TTFB und den FCP. Die Daten stammen von echten Nutzern von Google Chrome, die ihren Browser-Verlauf mit ihrem Google-Account synchronisieren.

DOM (Document Object Model)

Als DOM bezeichnet man die verzweigte Baumstruktur eines HTML-Dokuments. Jedes HTML-Element (z. B. <p> oder <h1>) stellt ein DOM-Element (also einen Zweig des Baumes) dar und kann anderen Elementen über- oder untergeordnet sein. Eine übermäßige DOM-Größe kann den FID erhöhen.

FCP (First Contentful Paint)

Als FCP bezeichnet man die Zeit, die ein Browser benötigt, um das erste sichtbare Element einer Webseite (z. B. Text oder ein Bild) darstellt.

FID (First Input Delay)

Der FID misst, wie lange eine Webseite braucht, um auf die erste Interaktion eines Nutzers (Mausklick, Scrollen etc.) zu reagieren. Dadurch wird die “Interaktivität” einer Webseite bewertet.

FOIT (Flash of Invisible Test)

Als FOIT bezeichnet man das Phänomen, dass Text vor dem Ladens eines Webfonts (wie z. B. Google Fonts) kurze oder längere Zeit gar nicht sichtbar ist.

FOUC (Flash of Unstyled Content)

Als FOUC bezeichnet man das Phänomen, das HTML-Elemente zunächst ohne CSS-Stile (also mit dem Default-Stylesheet des Browsers) “aufblitzen”, bevor die eigentlichen Stile geladen werden. FOUC kann entsprechend den CLS-Score verschlechtern.

FOUT (Flash of Unstyled Text)

Als FOUT bezeichnet man das Phänomen, dass Text, der in einem Webfont (z. B. Google Font) dargestellt werden soll, zunächst in einer lokal vorhandenen Standard-Schriftart (z. B. Arial oder Times New Roman) “aufblitzt”.

Haupt-Thread

Im Haupt-Thread (engl. main thread) eines Browsers werden die meisten wichtigen Rechenprozesse ausgeführt, die für das Anzeigen einer Webseite wichtig sind. Dazu zählen z. B. Layout (die Berechnung, wie groß jedes HTML-Element ist und wo es auf der Seite platziert ist), Paint (das Setzen der einzelnen Pixel) und die Ausführung von JavaScript.

LCP (Largest Contentful Paint)

Der LCP misst, wie lange das größte Elemente einer Webseite (im zuerst sichtbaren Darstellungsberich) zum Laden braucht, wodurch die “wahrgenommene Ladezeit” einer Webseite bewertet wird.

Long Task

Als Long Task bezeichnet man eine JavaScript-Aufgabe mit einer langen Ausführungszeit (über 50 ms). Solange ein Long Task aktiv ist, ist der Haupt-Thread des Browsers blockiert und Nutzer können nicht mit einer Webseite interagieren (scrollen, Text eingeben etc.). Viele Long Tasks auf eine Seite können zu einem hohen FID führen.

SI (Speed Index)

Der SI ist eine von Google verwendete Metrik, um die Geschwindigkeit einer Website zu messen. Die Kennzahl berücksichtigt nicht nur die Ladezeit einer Webseite, sondern auch den Verlauf des Seitenaufbaus.

TBT (Total Blocking Time)

Als TBT bezeichnet man die Gesamtzeit, in der der Haupt-Thread des Browser durch das JavaScript einer Webseite blockiert ist. Je höher die TBT ist, desto mehr müssen Nutzer mit Verzögerungen bei der Interaktion mit einer Webseite rechnen. Eine hohe TBT geht oft mit einem hohen FID einher.

TTFB (Time to First Byte)

Als Time To First Byte (TTFB) bezeichnet man die Zeit, die ein Browser benötigt um das erste geladenen Byte einer Webseite zu laden.

TTI (Time to Interactive)

TTI misst, wie lange es dauert, bis eine Webseite komplett interaktiv ist (also keine Eingabeverzögerungen durch JavaScript mehr zu erwarten sind).

WebP

WebP ist ein modernes Bildformat, das von Google entwickelt wurde und eine bessere verlustbehaftete oder verlustfreie Kompression bietet als JPEG oder PNG, was für 24 bis 34 % kleinere Bilddateien sorgt.

7. FAQ

Hier findest du Antworten auf häufige Fragen rund um die Core Web Vitals:

7.1 Warum empfiehlst du NitroPack nicht?

Ich finde das Konzept der cloudbasieren Performance-Optimierung durchaus spannend und innovativ. Die Resultate sind für die wenige Arbeit, die man bei der Konfiguration aufwenden muss, ebenfalls beeindruckend.

Allerdings hat NitroPack viele Probleme mit CLS, insbesondere durch Flash of Unstyled Content (FOUT). Zudem sind die Bewertungen des Supports eher durchwachsen.

7.2 Sind die Core Web Vitals auch in anderen Browsern (außer Chrome) ein Ranking-Faktor?

Ja, sind auch in anderen Browsern auf Mobilgeräten ein Ranking-Faktor. Sie werden lediglich durch Chrome-Nutzer gemessen.

7.3 Bietet es Ranking-Vorteile, die Grenzen für einen “guten” Score zu übertreffen?

Nein, ob dein LCP bei 1.000 ms (also deutlich besser als gefordert) oder bei 2.500 ms (genau auf der Grenze zwischen gut und verbesserungswürdig) liegt, ist egal. Es zählt, dass die Core Web Vitals im grünen Bereich liegen.

7.4 Zählen Seiten, die über die robots.txt oder mittels noindex vom Crawling bzw. der Indexierung ausgeschlossen wurden, in die Origin Summary mit rein?

Ja, soweit ich John Mueller und das Core Web Vitals FAQ das verstanden habe, ist das möglich. Das heißt, dass du auch nicht indexierte oder vom Crawling ausgeschlossene Seiten auf die Core Web Vitals optimieren solltest.

Allerdings werden nicht indexierte Seiten natürlich nur in den CrUX Report aufgenommen, wenn sie von Chrome-Nutzern besucht wurden und auch dann nur, wenn sie die Synchronisierung ihres Browser-Verlaufs in Chrome aktiviert haben.

Dazu kommt, dass die Origin Summary auch nur dann relevant ist, wenn keine Felddaten zu einer Seite vorliegen.

7.5 Bestehe ich automatisch den Core Web Vitals-Test, wenn ich AMP nutze?

Nein, nicht unbedingt, auch wenn die Nutzung von AMP sicherlich beim Bestehen des Tests helfen kann.

Tatsächlich werden laut Google sogar sämtliche Sichtbarkeits-Vorteile mit dem Page Experience Update aufgehoben, was sehr begrüßenswert ist. So werden AMP-Seiten nicht mehr durch das Blitz-Icon hervorgehoben und AMP ist auch nicht mehr erforderlich, um in das Schlagzeilen-Karussel (Top Stories) zu kommen.

7.6 Werden Webseiten, die den Core Web Vitals-Test bestehen in der Suchergebnissen optisch hervorgehoben?

Google hat auf jeden Fall schon eine Markierung mit einem Badge getestet. Ob es tatsächlich kommen wird, ist noch nicht zu 100 % klar.

Werbehinweis für Links mit Sternchen (*)

Es handelt sich um einen Affiliate-Link, das heißt, wenn du auf der verlinkten Website etwas kaufst, erhalten wir eine Provision. Dies hat keinerlei Einfluss darauf, wie wir ein Tool oder einen Anbieter bewerten.

Wir empfehlen nur Tools bzw. Anbieter, hinter denen wir auch wirklich stehen. Für dich entstehen dadurch natürlich keine zusätzlichen Kosten! Du hilfst jedoch uns und diesem Projekt. Danke! ❤️