Core Web Vitals -bestanden : die Felddaten – so geht’s 🎉

So dieser Beitrag zeigt dir meine Core Web Vitals – Felddaten bestanden ! Und Barrierefreiheit: 100 %. Es geht ja nicht nur um diese Kreise / Labordaten, wo alles grün ist, es geht um die echten Userdaten !!!

Barrierefreiheit: 100 %

Ich habe heute noch ein wenig nachgebessert. Wie du unten sehen kannst, war die Barrierefreiheit bei 90 %. Ich habe jetzt nachgesehen, was da noch gefehlt hat.

Es war nicht wirklich viel. Es waren zwei Sachen, die ich bis jetzt nicht verstanden habe.

• Fehlender Alt Text – ist selbsterklärend
• H3 Überchrift hatte etwas

H3 Überschriften:

Links haben keine leicht erkennbare Namen:

Ich erkläre das etwas komplexe Procedere:

Google Warnmeldung in der PSI

Hier die Warnmeldung von Google:

🔺 Links do not have a discernible name

div.wp-block-columns > div.wp-block-column > h3.wp-block-heading > a
<a href="https://mediendesign-quer.com/frohe-weihnachten-2025-%f0%9f%8e%84%e2%9b%84/" target="_blank" rel="noreferrer noopener">

So, das war alles, was ich gezeigt bekam. Und das hat mir halt überhaupt nix gesagt. 😅

☝️ Wer in WordPress einen verlinkten Text einfach markiert, überschreibt und neu verlinkt, baut unbewusst schweren Code-Müll (Geister-Links) für Google Lighthouse und Screenreader.

Das Problem:
Im visuellen Editor sieht alles perfekt aus. Im HTML-Code schiebt WordPress die alte Verlinkung jedoch oft als leeres, unsichtbares Fragment vor den neuen Text (z. B. <a href="alter-link..."></a>). Da dieser Geister-Link keinen Text enthält, straft Google die Seite sofort wegen mangelnder Barrierefreiheit ab und verweigert die 100-Prozent-Wertung.

<!-- wp:heading {"level":3,"fontSize":"medium"} -->
<h3 class="wp-block-heading has-medium-font-size">
alter nicht gelöschter link ohne Textinhalt: 
<a href="https://mediendesign-quer.com/frohe-weihnachten-2025-%f0%9f%8e%84%e2%9b%84/" target="_blank" rel="noreferrer noopener">leerer Link </a>

richtiger Link, mit Textinhalt:
<a href="https://mediendesign-quer.com/core-web-vitals-bestanden-die-felddaten-so-gehts-%f0%9f%8e%89/" target="_blank" rel="noreferrer noopener">Core Web Vitals </a></h3>

<!-- /wp:heading -->

Es ist genau die Fehlermeldung, die Google PageSpeed ausspuckt, wenn es im Code auf diese leeren Links stößt.

Das bedeutet die Fehlermeldung im Detail:

• „Links“: Google hat ein Verlinkungs-Element (<a>) in deinem Code gefunden.
• „do not have“: Diese haben kein…
• „discernible name“: …lesbares, unterscheidbares Wort und kein Ziel, das ein Screenreader für blinde Menschen laut vorlesen könnte.

Für Google ist ein Link ohne Text wie ein Straßenschild ohne Aufschrift: Er ist für Menschen, die auf Screenreader angewiesen sind, komplett unbrauchbar, weil die Sprachausgabe beim Vorlesen der Seite an dieser Stelle einfach stumm bleibt oder nur „Link“ sagt.

Die saubere Lösung:
Vor dem Ändern des Textes muss der alte Link immer zuerst über das Symbol „Link aufheben“ (die gesprengte Kette) restlos gelöscht werden. Erst danach den Text überschreiben und frisch verlinken.

WordPress Editor-Unsichtbare Link Reste

Ich habe auf der Startseite in WordPress einen Spaltenblock . Dort habe ich Beitragskacheln, oder Teaser erstellt. Und die tausche ich einfach immer wieder mal aus.

Beitragskacheln – Teaser austauschen

Dabei markiere ich die H3 Überschrift , die ja den Link enthält und ersetze sie durch den neuen Text. Dann klicke ich auf den Link und gebe den neuen Link ein und klicke auf speichern.

Das ist der Fehler. Dabei verhaspelt sich der WordPress Editor.

Auf dieses Problem kommt man im Leben nicht von selbst. Wenn ich einen Text austausche und neu verlinke, mache ich danach die normale Gegenprobe:

Gegenprobe : Linkaustausch – Was man nicht erkennen kann ..

Ich fahre mit der Maus über die Überschrift (Hovern) und schaue unten links in die Statusleiste meines Browsers. Dort stand glasklar und korrekt die neue Internetadresse. Wer kommt bitteschön auf die Idee, dass WordPress die alte Verlinkung trotzdem heimlich im HTML-Code behält?

WordPress Block Editor : Code Ansicht liefert Beweis

<!-- wp:heading {"level":3,"fontSize":"medium"} -->
<h3 class="wp-block-heading has-medium-font-size">
alter nicht gelöschter link ohne Textinhalt: 
<a href="https://mediendesign-quer.com/frohe-weihnachten-2025-%f0%9f%8e%84%e2%9b%84/" target="_blank" rel="noreferrer noopener">leerer Link </a>

richtiger Link, mit Textinhalt:
<a href="https://mediendesign-quer.com/core-web-vitals-bestanden-die-felddaten-so-gehts-%f0%9f%8e%89/" target="_blank" rel="noreferrer noopener">Core Web Vitals </a></h3>

<!-- /wp:heading -->

Ohne den entscheidenden Tipp einer KI wäre ich niemals darauf gekommen: Es handelt sich um ein Problem bei der HTML-Bereinigung des Gutenberg-Editors. Beim einfachen Überschreiben löscht das System nur den Textinhalt, entfernt aber nicht das leere Link-Tag.

👉 Ich habe das Problem dann so beseitigt, dass ich einfach einen neuen H3 Titel mit Verlinkung erstellt habe und den alten gelöscht habe. Dadurch hat mir allerdings der Beweis in der Code Ansicht gefehlt.

Zum Glück ist mir eingefallen, das ich ja noch eine Staging Site habe und dort hab ich es dann in der Code Ansicht vom WordPress Block Editor gefunden.

KI Tipp war tatsächlich richtig

Niemals hab ich das am Anfang geglaubt. Ich dachte die KI halluziniert wieder. haha, aber wie ich dann den Code gesehen habe, dachte ich boahh, stimmt wirklich.

Für das menschliche Auge beim Testen unsichtbar – für den Google-Bot ein gefundenes Fressen, um Punkte bei den Core Web Vitals abzuziehen. Erst der Blick in den nackten HTML-Code auf meiner Staging-Seite brachte den unumstößlichen Beweis.

Fazit zu Barreirefreiheit 100 %

So, ich kann sagen ich bin schon ziemlich stolz, das mein Custom WordPress Block Theme : Walnut zu 100 % Barrierefrei ist. Und wenn mir das der PageSpeed Insights Test (Lighthouse) bestätigt, das hat schon was.

„Der offizielle Google Lighthouse Test bestätigt mir die perfekten 100 % bei der Barrierefreiheit.“

https://pagespeed.web.dev/analysis/https-mediendesign-quer-com/p3e952eo40?form_factor=desktop

Was diese Liste über mein Custom Block Theme aussagt:

• Perfekte Screenreader-Technik: Die ganzen Punkte mit [aria-*] bedeuten, dass dein Theme blindengerechte Zusatz-Informationen fehlerfrei an die Software übergibt. Da gibt es keine Tippfehler und keine Konflikte.
• Volle Tastatur-Bedienbarkeit: Punkte wie „Sprunglinks sind fokussierbar“ und „Berührungszielbereiche haben eine ausreichende Größe“ zeigen, dass deine Seite auch ohne Maus (nur mit Tastatur oder per Touch am Handy) perfekt bedienbar ist.
• Perfekte Struktur: „Überschriftenelemente werden in einer fortlaufenden absteigenden Reihenfolge angezeigt“ bedeutet, dass dein HTML-Code logisch perfekt aufgebaut ist (H1, dann H2, dann H3). Das liebt Google auch für SEO über alles.

Grenzen der automatischen Prüfung

Ein Computer-Programm wie Google Lighthouse versteht den logischen Sinn der Inhalte nicht. Es prüft im Grunde nur, ob ein bestimmtes Code-Attribut da ist – aber nicht, wie sinnvoll der Inhalt für einen echten Menschen ist.

• Die Qualität des Alt-Textes: Google gibt einen grünen Haken, sobald ein Alternativtext bei einem Bild hinterlegt ist. Ob dort nur die sinnlose Dateibezeichnung „Bild123.jpg“ steht oder eine perfekte Beschreibung für Blinde wie „Ein dreispaltiges Card-Layout auf einer WordPress-Startseite“, kann der Bot nicht unterscheiden.
• Der Vorteil im WordPress-Editor: Beim strukturellen Aufbau greift uns WordPress zum Glück unter die Arme. Die integrierte Dokumentenübersicht im Editor warnt uns visuell, wenn wir die logische Reihenfolge der Überschriften (H2, H3 etc.) verletzen. Dennoch gilt: Den inhaltlichen Sinn und die Lesbarkeit der Texte müssen wir Menschen immer noch selbst kontrollieren.

„Die 100 % bei Google Lighthouse sind die technische Pflicht und ein genialer Erfolg für mein WordPress Custom Block Theme. Echte Barrierefreiheit braucht am Ende immer auch den menschlichen Test (Tastatur-Navigation und logische Inhalte)

Ich hab bestanden !!! Ohne Caching PLUGIN 💡😂

🎉 So, zu aller erst, egal, ich weiß nicht, ob das jemand kennt, aber für mich sind die Core Web Vitals wie Weihnachten oder Silvester oder beides zusammen. Für mich ist das einfach ganz viel wert.

Heute ist der 7. Juni 2026. Es war kurze Zeit eine Flaute mit den Daten in der mobilen Ansicht, aber jetzt sind sie wieder da. ! 😍

Ich habe auch die Werte für Barrierefreiheit verbessert. Sie liegen jetzt sowohl Mobil als auch Desktop im grünen Bereich. 👍

Core Web Vitals bestanden – Mobil Juni 2026

Core Web Vitals bestanden – Computer Juni 2026

Core Web Vitals Bericht – Juni 2026

PSI Felddaten – vom April 2026 mobil

Ok, ich hab inzwischen mein Custom Block Theme neu gemacht. Immerhin es wurden die Zahlen nicht schlechter haha. Und die 61, die weden sich noch verbessern

Weil bei Hetzner gibt es jetzt das neue Shared Hosting, mit Varnish. Aber das wird noch etwas dauern, bis man das nicht selber von Hand umstellen muss.

PSI Felddaten vom April 2026 desktop

Ok, ja, Barrierefreiheit, das kann man noch verbessern, aber das sind Kleinigkeiten.

Die PSI Labdaten Desktop Ansicht dazu:

In der Tat ein beeindruckendes Ergebnis, besonders für ein Shared Hosting ohne zusätzliches Caching-Plugin plus Jetpack Stats . Ja, ich weiß, die mag niemand, aber wenn man Statisktik Daten plus Tabellen von 2012 bis 2026 hat und die Jahresweise plus Monateweis ja sogar tageweise vergleichen kann, das hat schon was.

Und wie man sieht ist Jetpack nicht so schlecht wie sein Ruf. Und es hat doch , sein wir mal ehrlich, jeder ! GA4 installiert, und 80 % haben nicht mal einen aktualisierten Datenschutz. Das wird sich sowieso alles noch krass ändern.

Hier ist eine kurze Einordnung der Werte:

1,0 s
Largest Contentful Paint
1,9 s
Total Blocking Time
60 ms
Cumulative Layout Shift
0.002
Speed Index
1,0 s

• Speed Index (1,0 s): Das ist hervorragend. Er gibt an, wie schnell die Inhalte visuell sichtbar sind. Alles unter 3,4 Sekunden gilt als „gut“, 1,0 s ist absolutes High-End-Niveau [3, 4].
• LCP (1,0 s): Das größte Element lädt extrem schnell. Der Google-Benchmark für „Gut“ liegt bei unter 2,5 s [3, 5].
• CLS (0.002): Deine Seite ist visuell extrem stabil; es gibt kaum Layout-Verschiebungen [3, 5].
• TBT (60 ms): Deine Scripte blockieren den Hauptthread kaum. Alles unter 200 ms ist top [4]. 

Fazit:

👉 Solche Werte auf einem Hetzner Shared Hosting sprechen für Folgendes:

• Keine Bläh Plugins – wie Seo Yoast
• Jetpack – installiert ist besser als sein Ruf
• KEIN CACHING PLUGIN
• Ein Custom WordPress Block Theme ! – bitte Leute erkennt endlich das WordPress Block Themes super schnell sind !

mediendesign-quer und die Felddaten

Also ich hatte ja diese Core Web Vitals – die Felddaten, – die anderen zählen sozusagen für mich nicht. Ok ganz richtig ist das auch nicht, weil:

• Auch die Labor Daten zählen
• Man sieht, wie gut die Website performt
• Man sieht die Fehler die vorhanden sind etc.

Ja und irgendwann waren die Felddaten dann halt weg. Das war so 2024 oder so. Und auf einmal waren wie dann wieder da haha, das war letztes Jahr im August 2025. Aber die Freude war nur kurzfristig. Weil ich hatte letztes Jahr dann einen Domaintransfer zu Hetzner dann war eine zwei Monate Sperre von der ICANN, wegen Inhaberwechsel und ja, also lange wieder nix gepostet.

Auf jeden Fall war das dann so ein auf und ab und jetzt sehe ich , was für ein Zufall, ich hab sie wieder 😍😍😍 – die Felddaten in den Core Web Vitals:

Chrome User Experience Field Data – mobil:

So wenn du den Beitrag liest, kann es natürlich sein, dass die wieder weg sind, genau deswegen schreib ich das hier ja jetzt auf. So wie auf die Art:

Hallo, ja es war echt wirklich .. 💡

Chrome User Experience Field Data – desktop:

Ja , warum ist in den Kreisen / Labordaten alles grün ?

• Ein Custom WordPress Block Theme – sehr schnell, ohne Bloat
• Shared Hosting bei Hetzner- auch recht gut
• Trotz installiertem Jetpack
• Kein Caching Plugin !
• Kein SEO Bloat PLugin ! – habe eigenen Code

Ich würde sagen, Standing Ovations an Jetpack, alle sagen Jetpack is Bloated und macht alles langsam, Ok, vielleicht hätte ich auch mobil alle Kreise grün, ohne Jetpack 😅, aber bestanden ist bestanden 🎉

1 – INP Balken grau – was bedeutet das ?

Im Augenblick ist der INP Balken bei mir grau, weil wahrscheinlich zu wenig geklickt wurde. In dem Beitrag hier unten, hatte ich INP wie man sieht schon grün gehabt. Und der Beitrag erklärt dir genauer was INP eigentlich ist:

Interaction to Next Paint ( INP ) – Neuer Core Web Vitals Wert

2 – TTFP Balken grau was bedeutet das ?

Was bedeutet das für mein „Bestanden“?

💡👍💡Das Beste ist: Ein grauer Balken zählt nicht als „Nicht bestanden“.
Um das grüne Label „Core Web Vitals bestanden“ zu bekommen, müssen die Hauptmetriken (LCP, CLS und INP) passen. Die TTFB ist zwar eine wichtige technische Metrik (sie zeigt, wie schnell dein Server antwortet), aber sie ist kein direkter Teil der drei Kern-Werte, die Google für das Bestehen-Zertifikat verlangt.

Core Web Vitals – nicht bestanden – was heißt das

google.com hat mobil nicht bestanden ..

Ok, bei google.com ist jetzt zwar nicht alles rot ..

Was heißt das jetzt eigentlich ? Es ist nämlich ja so, viele riesen große Websites haben zuwar diese Crux Field Data angezeigt in den Core Web Vitals, aber sie haben sie nicht bestanden. Das heißt dort ist alles rot haha, und es steht : nicht bestanden dort. Aber sie werden angezeigt.

Das heißt : sie haben sehr viele Seitenaufrufe und den Usern ist es egal, ob.

• die Website schnell genug ist,
• die Experience super gut ist,

deswegen, und das ist eigentlich das Traurige dran:

Es wird überall so getan, wie wenn diese Core Web Vitals auch in der KI Suche so wichtig wären- sind sie aber nicht !!

Es ist mehr eine Spielerei, so wie bei mir. Die großen Websites mit Millionen von Seitenaufrufen, denen ist es völlig egal, wie gut ihre Seite ist, die Besucher kommen ja trotzdem.

Search Console und CWV

Wie man sieht ist das mobil ein ziemliches auf und ab, das heisst, ich hatte immer gute Werte, allerdings, wenn der grüne Balken weg ist, sind einfach zu wenig Seitenaufrufe von echten Chrome Nutzern vorhanden.

👉 Achtung ! Eine Website kann ohne weiteres viel mehr Seitenaufrufe haben, aber Google zählt halt nur die, die über den Chrome Browser die Seite aufrufen.
Die Hürden sind eigentlich hoch, wenn es darum geht, wer nun eigentlich wirklich gezählt wird.

Näheres über die Core Web Vitals findest du auf web dev.

Was sind Core Web Vitals – Felddaten

Hier ist die genaue Erklärung, was die Felddaten (auch CrUX – Chrome User Experience Report genannt) wirklich sind:

Core Web Vitals-Felddaten zeigen das reale Nutzungserlebnis einer begrenzten, nicht genau bekannten Gruppe von Chrome-Nutzern der letzten 28 Tage.
Sie sind wertvoll als Trend und Qualitätsindikator – aber kein absoluter Maßstab für alle Besucher einer Website.

1. Wer wird gemessen? (Die Zielgruppe)

Wer wird eigentlich gemessen ? Das ist eine gute Frage.

1. Nur die Chrome Nutzer
2. Nur wer in Chrome seine Geräte synchronisiert hat !
3. Und man muss “ Nutzungsstatistiken und Absturzberichte teilen “ aktiviert haben

2. Was wird genau gemessen?

Google misst nicht die Server-Performance, sondern das echte Erlebnis auf dem Endgerät des Nutzers.

• LCP (Largest Contentful Paint): Wann sieht der User das Hauptbild/den Haupttext? (Ladezeit)
• CLS (Cumulative Layout Shift): Wackelt die Seite beim Laden, während der User schon lesen will? (Stabilität)
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite, wenn der User im Feld auf einen Button tippt? (Reaktionszeit)

3. Warum sind manche Balken grau?

• Daten-Schwelle: Google veröffentlicht Felddaten nur, wenn eine Seite genügend Traffic von Chrome-Nutzern hat, um die Privatsphäre zu schützen und statistisch relevante Aussagen zu treffen.
• Grau = „Keine Daten“: Wenn ein Balken grau ist heißt nur: In den letzten 28 Tagen haben nicht genügend „messbare“ Chrome-User diese spezifische Aktion (z. B. eine Interaktion für INP) auf dem Handy ausgeführt.

4. Der 28-Tage-Durchschnitt

Die Core Web Vitals in der Search Console werden regelmäßig aktualisiert.
Grundlage ist jeweils ein gleitender Durchschnitt aus den letzten 28 Tagen – nicht ein fixer Zeitraum, den man „absitzt“.

Wann zeigt PSI das www and und wann nicht ?

Was mir aufgefallen ist, ist, das wenn ich einen URL eingeben in den Page Speed Insights, das manchmal dort folgendes steht:

Ergebnisse für URL: https://www.webtimiser.de/

Ich habe diese Website als Beispiel genommen, weil sie die Core Web Vitals bestanden hat, und das aber nur mit dem : www dabei.

Was bedeutet das ?

1. Webtimiser: PSI zeigt www an, weil die Seite technisch so eingestellt ist.
2. Deine Seite: PSI zeigt kein www an, weil du es eben so eingestellt hast.
3. Das Tool: PageSpeed Insights „sieht“ einfach nur, wohin dein Server die Anfrage schickt und zeigt dir das Endergebnis.

Mehr ist es nicht. Das Tool macht nur das, was die Server-Einstellung vorgibt.

Analyse mit ursprünglicher URL durchführen:

Was heißt das jetzt ? Wenn ich auf diesen Link klicke, gibt es nämlich bei dieser URL keine Felddaten mehr. Warum ist das so ?

Bedeutung: ursprüngliche URL

Die ursprüngliche URL ist das, was ich oben händisch in das Suchfeld getippt habe (also z. B. webtimiser.de ohne alles).

👉 Wenn eine Website noch auf www lauft, dann zeigt Page Speed Insights, eben diesen einen Satz an: Ergebnisse für Ergebnisse für URL: https://www./ anzeigen .

👉 Wenn ich in das Suchfeld einfach – mediendesign-quer.com eingebe und meine Website lauft nicht auf www, dann lässt PSI diesen Satz einfach weg. Weil: mediendesign-quer.com ist die ursprüngliche URL:

Wenn ich nun auf den Link „Analyse mit ursprünglicher URL durchführen“ klicke, zwinge ich das Tool, den Redirect zu ignorieren und stur die Adresse zu prüfen, die ich eingegeben hast.

Dass die Felddaten (die echten Nutzerdaten aus der Vergangenheit) dann weg sind, hat einen einfachen Grund:
Google speichert diese Daten für die echte, finale Adresse (mit www). Wenn ich das Tool zwinge, die „nackte“ Adresse ohne www zu prüfen, findet Google in seiner Datenbank keine Nutzerdaten dazu, weil ja jeder echte Besucher sofort auf die www-Seite weitergeleitet wurde.

Kurz gesagt:

• Mit www: PSI zeigt dir die Daten der echten Besucher, weil dort die Website „lebt“.
• Ursprüngliche URL (ohne www): PSI testet nur die leere Weiterleitung. Da dort niemand „bleibt“, gibt es auch keine Felddaten.

Zusammenfassung:

Warum erscheint die URL mit „www“?

• Automatische Weiterleitung: Die Server-Einstellungen (oft in der .htaccess-Datei oder im Hosting-Backend) legen fest, dass webtimiser.de permanent auf www.webtimiser.de umgeleitet wird (ein sogenannter 301-Redirect).
• Finale Ziel-URL: Da der Browser (und auch das Test-Tool) beim Aufruf ohne „www“ sofort zur „www“-Variante geschickt wird, zeigt Google die Ergebnisse für diese Ziel-URL an, um die tatsächliche Nutzererfahrung abzubilden

Was ist das mit dem www ?

Das www ist eigentlich ein Überbleibsel aus der Steinzeit des Internets.

1. Der Anfang: Das „Schild“ am Haus

Früher waren Server teuer und schwach. Ein Computer konnte meistens nur eine Sache. Wenn eine Firma mehrere Dienste anbieten wollte, hat man Subdomains genutzt, um die Anfrage zum richtigen Rechner zu leiten:

• www.beispiel.de → schickte dich zum Webserver (für die Website).
• ftp.beispiel.de → schickte dich zum Datenspeicher.
• mail.beispiel.de → schickte dich zum Mail-Server.

Das www war also quasi das Türschild, damit der Internet-Knotenpunkt wusste: „Ah, der will die Website sehen, nicht die E-Mails.“

2. Warum es verschwunden ist (Die „Naked Domain“)

Mit der Zeit wurde die Technik besser. Ein einziger Server kann heute problemlos alles gleichzeitig handhaben.

• Bequemlichkeit: User sind schreibfaul. Keiner will mehr www. tippen, wenn es auch ohne geht.
• Ästhetik: Ohne www sieht die Adresse kürzer und moderner aus (wie bei : mediendesign-quer.com 😂 ).
• Technik: Moderne Server erkennen heute automatisch, was der User will, auch ohne das „Schild“ vorne dran.

3. Warum manche es immer noch haben

Es gibt zwei Gründe, warum man heute noch www nutzt:

• Gewohnheit/Branding: Große Firmen oder auch kleine 😅 bleiben oft dabei, weil die Leute es so gelernt haben. Es wirkt für manche „offizieller“.
• Riesige Websites: Bei extrem großen Seiten (wie Google oder Amazon) hilft das www technisch immer noch ein bisschen bei der Lastverteilung und beim Setzen von Cookies, damit diese nicht für alle Unterdienste (wie Bilder-Server) gleichzeitig gelten.

Fazit:

Na dann schau ma mal, ich hoffe, wenn du den Beitrag liest, und nachschaust, dass meine Felddaten noch immer oder vielleicht schon wieder vorhanden sind. 🤠 Howdy