ABAKUS

> Auf dem Server läuft LightSpeed Enterprise. Was Du mit h2 meinst weiß ich nicht

OK, nach deiner Umstellung habe ich aber nur Requests mit dem h2 Protokoll gesehen.

> Wenn ich die Seite mit der Dev Console anschaue, kommen da bei mir aktuell keine Fehler, weder auf der Startseite noch in einem Beitrag. Könntest Du mir hier ein Beispiel sagen?

Keine JS/CSS Fehler, die man als Laie sehen würde. Ein SEO sollte es aber sofort sehen.

omp-blog hat geschrieben: ↑21.01.2022, 13:15...

Außerdem existieren auf der Seite weitere technische Mängel.

Wenn ich die Seite mit der Dev Console anschaue, kommen da bei mir aktuell keine Fehler, weder auf der Startseite noch in einem Beitrag. Könntest Du mir hier ein Beispiel sagen?

Browser sind ziemlich Fehlertolerant. Schau mal hier:

https://validator.w3.org/nu/?doc=https% ... places.com

https://jigsaw.w3.org/css-validator/val ... places.com

Browser sind ziemlich Fehlertolerant

Ok, das ist dann aber wahrscheinlich - wie supervisior es schon gesagt hat - eher ein strukturelles Problem von Wordpress und einer sauberen Programmierung der Plugins, und nichts, dass ich jetzt mal eben so beheben kann, oder?

omp-blog hat geschrieben: ↑21.01.2022, 14:32

Browser sind ziemlich Fehlertolerant

Ok, das ist dann aber wahrscheinlich - wie supervisior es schon gesagt hat - eher ein strukturelles Problem von Wordpress und einer sauberen Programmierung der Plugins, und nichts, dass ich jetzt mal eben so beheben kann, oder?

Es geht nicht um Fehler oder strukturelle Probleme von Wordpress selbst. Die Probleme speziell in Deinem Fall generieren sich einerseits aus dem verwendeten Theme und dessen mehr oder weniger unvermeidbaren Verschachtelung des HTML Codes in Kombination mit der Fülle an Content. Deswegen muss es aber nicht zwangsläufig Fehler im Code geben. Heißt, je umfangreicher und verschachtelter das DOM ist und je mehr sichtbarer Content besteht, umso mehr wirkt sich das auf das Anzeigeverhalten aus. Kommen dann noch 3 Tonnen CSS und die Eigenheiten des Responsive Webdesign dazu, muss der Browser richtig schuften. Und genau diese Widrigkeiten bestimmen/beinträchtigen maßgeblich, aber nicht ausschließlich, den Page Experience Report von Pagespeed. Die pure Menge an zu ladenden Daten ist, abgesehen von der verfügbaren Bandbreite, fast nebensächlich. Diese Daten müssen geparsed werden und darin liegt in weiterer Folge der nächste Hund begraben. Deswegen kann und will Pagespeed auch nicht die Ladezeit messen, sondern die Anzeigezeit nachdem alle für die Anzeige notwendige Daten geladen wurden.

Die klassischen und allseits bekannten Optimierungsmethoden kann man sich zwar nicht gänzlich ersparen, aber damit sich diese noch besser niederschlagen, müssen die Voraussetzungen stimmen. Will heißen, je flacher und umso weniger das HTML Konstrukt verschachtelt ist, umso weniger ist der Browser mit dem Aufbau des DOM beschäftigt, den er als Ganzes für eine aufgerufene Seite erstellt. Ginge es nach Google dürfte/sollte sich der Browser nur damit beschäftigen müssen, was man beim Aufruf einer Seite als erstes sieht, also den Bereich above the fold. Das wäre quasi ein sehr partielles Verarbeiten der Anzeige nur der dafür benötigter Daten. Und erst beim Scrollen würde die Verarbeitung der Daten und der Anzeige fortgesetzt werden. Hört sich sehr theoretisch an und womöglich unmöglich umsetzbar, weil Browser ja so arbeiten wie sie arbeiten, aber so was lässt sich tatsächlich umsetzen, ohne dass man dafür den Browser erst eine andere Arbeitsweise beibringen muss. Allerdings lässt sich so was nur mit einem indiviuell erstellten Theme nicht nur für Wordpress machen.

Vielen Dank für die genaue Beschreibung. Das fand ich sehr aufschlußreich und verständlich erklärt.

omp-blog hat geschrieben: ↑22.01.2022, 13:32 Vielen Dank für die genaue Beschreibung. Das fand ich sehr aufschlußreich und verständlich erklärt.

Tu mir feil jetzt nur nicht in den A**** kriechen, gell! Du bist ein Abtrünniger und bekommst den Segen erst wieder, wenn Du Dich wieder bekehrst!