ABAKUS

omp-blog hat geschrieben: ↑16.01.2022, 18:09 Ich hab echt schon viel versucht, die Seite für den Speed zu optimieren (Caching, CDN, Critical CSS usw). Der Hauptfaktor (denke ich) ist einfach, dass wir einfach viele Bilder in unseren Reiseberichten haben.

Echt? Davon sehe ich aber nichts wenn ich mir die seite mit den chrome dev tools ansehe: 67 requests, 4.4MB. Du hast einfach ZU VIELE elemente auf der seite.
Da sind allein 11 css files, 5 davon unter 1kb. Die koenntest du auch einfach alle in ein einziges file packen (reihenfolge dabei beachten!), oder die <1kB files einfach inline einbinden. Es ist besser eine einzige grosse datei zu uebertragen statt viele kleine.

Das selbe bei den .js dateien, ich wuerde mal vermuten dass da einige sachen nicht zwingend benoetigt sind.

omp-blog hat geschrieben: ↑16.01.2022, 18:09 Klar sind die Bilder optimiert (z.B. als webp, mit Lazy Load, CDN usw), aber die Menge macht einfach den Hauptteil der Ladezeit aus.

Wenn du die requests nach groesse sortierst, sieht du zuerst deine bilder:
https://v7k3m3s6.rocketcdn.me/wp-conten ... elbild.jpg

310kb, pixelgroesse die uebertragen wird ist 1200x800, angezeigt im browser werden in der kachel unter "Aktuelle Reiseberichte" aber nur ~320x200px. ich bin sicher das ein passend skaliertes bild hier mit ~50kB oder weniger auskommen wuerde. Webp ist auch nicht zwingend besser als jpeg. Ich wuerde die bilder eher passend verkleinern, und anschliessend nochmal durch tinyjpg durchlaufen lassen. Ich selbst speichere jpg-vorschaubilder immer nur mit 80-85% qualitaet, danach geht der platzbedarf stark nach oben. Deine besucher ueberfliegen die vorschaubilder innerhalb von 5 sekunden, das sind keine kunstkritiker die jedes pixel einzeln bewerten. Normale qualitaet ist gut genug.

Dein problem ist imho eher wordpress mit seinem plugin management. Wenn du 10 plugins hast, dann erzeugen die wenn du pech hast 10 css dateien und 10 js dateien, statt eine einzige grosse datei zu erzeugen. Viele der wordpress themes sehen zwar schoen auf, sind aber technisch eine katastrophe weil sie jede menge andere files einbinden, statt es schon selbst zu minimieren.
kann sein das es da eine loesung gibt, bin aber selbst nicht so tief in wordpress drinnen.

arnego2 hat geschrieben: ↑16.01.2022, 19:18 Der Pagespeed erzählt allerdings eine andere Story:

Pagespeed ist voellig ungeeignet fuer diese fragestellung. Ich hab auch schon e-commerce seiten gesehen die 10 sekunden lang geladen haben, aber laut pagespeed war alles voll knorke und hat alles gruen bekommen....

Lazy Load ist ja bereits aktiviert, gut. Aber wenn ich die Seite lade dauert es 3 Sekunden für jedes Bild. Da ist irgendwas im Server langsam. Und es passieren nach WebConsole immer komische Requests dazwischen die ich nicht verstehe

@omp-blog

Wenn Du den Post von @nerd aufmerksam gelesen hast, dann solltest schon in etwa verstehen können, wo die Problematik liegen könnte. Wenn Du Dich daraufhin fragst, was Du dagegen tun kannst, weil Du augenscheinlich ja schon so viel gemacht hast, muss ich Dir darauf leider antworten: Goar Nix! Du hast das technisch mögliche m.E. schon ausgereizt, wobei der CDN eher kontraproduktiv ist und ebenso Deine bislang störrische Ansicht, dass ein PHP getriebener HTTP Cache besser wäre als der Webserver basierte HTTP Cache von LiteSpeed. Das ist aber nicht das eigentliche Problem und löst es auch nicht ursächlich. Um das zu verstehen, muss man die Ideologie von Pagespeed verstehen.

Pagespeed hat, und auch wenn der Name es glauben lassen will, nix mit der Ladezeit zu tun. Paradoxerweise will und kann Pagespeed die Ladezeit gar nicht messen, weil der Fokus von Pagespeed ganz woanders liegt. Pagespeed gehts nicht um die Ladezeit, sondern um die Anzeigezeit ab dem Moment, wo alle zur Anzeige benötigten Objekte/Sourcen, usw. geladen sind. Von daher müsste Pagespeed eigentlich Displayspeed heißen. Pagespeed moniert zwar eine schlechte Reaktionszeit des Servers, aber alles, was zwischen dem sog. Time to First Byte und der Anzeige im Browser passiert, ist Pagespeed schnurz piep egal. Zumal dieses dazwischen höchst dynamisch ist und sich nicht geordnet messen lässt, weil es zu viele Faktoren gibt, die das beeinflussen.

Es gibt also ein offensichtliches Missverständnis zwischen dem, was so ziemlich jeder unter Pagespeed == Ladezeit und was Google unter Pagespeed == Anzeigezeit versteht. Aus diesem offensichtlichen Missverständnis erklärt sich dann auch, warum eine bestmöglich optimierte Seite, aber grottenlangsamer Server Bestnoten bekommt, aber ein blitzschneller Server, dessen Seite nicht nach Pagespeed Vorgaben optimiert ist, abgestraft wird, was @nerd ja schon angedeutet hatte.

Für Dich heißt das jetzt konkret, dass Du auf technischer Seite nix mehr machen kannst, um den Pagespeed Score noch wesentlich zu verbessern, weil Du ein strukturelles Problem hast, was aber eigentlich jeder (Du auch) hat, der Wordpress und ein Theme mit Bootstrap verwendet. Eine weitere Ursache findet sich in Deinem zu viel Content, der mit den Vorgaben von Pagespeed korreliert. Hört sich irritierend an und ist es auch, aber erklärt sich wie folgt.

Wenn Pagespeed nun die Anzeigezeit und nicht die Ladezeit misst, dann muss man diese Anzeigezeit in das Verhältnis zur Anzeige bringen. Die Anzeige ist das, was früher von Google noch als "above the fold" bezeichnet hat und darauf richtet Pagespeed seinen maßgeblichen Fokus. Was Pagespeed also gerne hätte, wäre eine uneingeschränkte Priorisierung dessen, was man im Sichtbereich im Browser als erstes sieht. Alles andere ist dabei aber nicht unwichtig. Es darf nach den Vorstellungen von Google aber nicht den besagten Sichtbereich bei der Anzeige beeinflussen. Wird es aber zwangsläufig, weil ein jeder Browser keine Priorisierung vornimmt und jede Seite als Ganzes behandelt und dazu gehört maßgeblich der, bzw. das Data Objekt Model. Bezogen auf Deine Seite bedeutet das, dass die Größe Deines DOM viel zu groß ist, als dass es diesen besagten Sichtbereich nicht beeinflussen würde. Ganz einfach ausgedrückt, Du hast ursächlich zu viel Content auf Deiner Seite und der Browser braucht zu viel Zeit dafür den DOM aufzubauen und daraus resultieren unweigerlich Verzögerungen bei den von Pagespeed festgelegten Kriterien, die, ganz wichtig, untereinander in Wechselwirkung stehen.

Da stellt sich jetzt unweigerlich die Frage, wie man dieses Problem lösen kann, was aber eigentlich unlösbar scheint. Unlösbar, wenn man ein Theme von der Stange hat, weil die Anforderung darin besteht das Lade- und Anzeigeverhalten so zu verändern, dass beim Erstaufruf nur das geladen und angezeigt wird, was man maximal für den Sichtbereich benötigt. Und das würde wirklich alles einschließen, also HTML, CSS, Javascript, Bilder usw. und quasi erst auf ein "Weiter" würde die Seite unter der gleichen URL neu geladen werden, um dann alles anzuzeigen. Dafür benötigtes CSS und Javascript müssten dann inline definiert sein, wobei man Javascript eigentlich ausschließen könnte. Erst auf ein "Weiter" würde die Seite unter gleicher URL neu geladen werden und erst dann würde auch der restliche Bereich angezeigt werden. Damit es dabei keine Verzögerungen gibt, nutzt man die PUSH Funktion oder ähnlich geartete Preloading Funktionen, um benötigte Sourcen, wie css und Javascript im Hintergrund zu laden, damit diese Sourcen schon mal im Browser Cache sind.

Hört sich jetzt nach grauer Theorie an, ist aber zumindest meine gängige Praxis und hat sich seither bewehrt. Übertragen auf Deinen Fall kannst Du wie bereits erwähnt absolut nichts dagegen machen. Dein beschriebener Ansatz mit Deinem "Weiter" geht aber schon in die richtige Richtung, bist aber noch Lichtjahre davon entfernt, dass daraus eine wirkliche Lösung werden könnte.

Trotzdem glaube ich, dass auch irgendwas mit dem Server / Konfiguration nicht stimmt. Ich habe jetzt gerade noch mal die Seite aufgerufen: Das Root Dokument hat 13 Sekunden gebraucht bis es da war. Meist dauert es unter 200ms. Irgendwas klemmt da manchmal.

Server steht ja in der Republik. Falls dahinter ein Wordpress hängt evtl doch den Webserver ein bisschen cachen lassen?

Und DOM Größe ist schon ein Problem. Allerdings werden auch 11 CSS Dateien, 9 JS Dateien und 4 Schriften geladen. Vielleicht kann man da noch bissel optimieren.

Weiterhin schiebe ich alls JS Dateien immer ganz nach unten, damit sie am Ende geladen werden und ich tagge sie mit "defer" oder "async" wenn es passt. Da musst du aber schauen was für deine Seite passt.

Achja und das kleine Fähnchen für die Sprachauswahl könnte man auch inline einbinden. Sind nur ein paar Byte und spart wieder einen Request.

HelgeSchneider hat geschrieben: ↑17.01.2022, 08:12 Trotzdem glaube ich, dass auch irgendwas mit dem Server / Konfiguration nicht stimmt. Ich habe jetzt gerade noch mal die Seite aufgerufen: Das Root Dokument hat 13 Sekunden gebraucht bis es da war. Meist dauert es unter 200ms. Irgendwas klemmt da manchmal.

Server steht ja in der Republik. Falls dahinter ein Wordpress hängt evtl doch den Webserver ein bisschen cachen lassen?

Und DOM Größe ist schon ein Problem. Allerdings werden auch 11 CSS Dateien, 9 JS Dateien und 4 Schriften geladen. Vielleicht kann man da noch bissel optimieren.

Weiterhin schiebe ich alls JS Dateien immer ganz nach unten, damit sie am Ende geladen werden und ich tagge sie mit "defer" oder "async" wenn es passt. Da musst du aber schauen was für deine Seite passt.

Der Kollege hat ja zumindest was den Webserver anbetrifft das Beste, was man für Geld bekommen kann und HTTP cacht auch, allerdings, und das will er sich nicht ausreden lassen, nutzt er dafür einen PHP getriebenen Cache und nicht den schnellsten HTTP Cache, der Bestandteil des Webservers ist.

Dass es zu viele statische Sourcen gibt, ist natürlich ein Problem, aber solange sich der Browser den DOM nicht verinnerlicht hat, kannst Du die statischen Sourcen noch so schnell und würde nichts bringen. Dazu zählt auch das verzögerte Laden, zumal dann, wenn man Javascript für die Bildanzeige verwendet, die dann unweigerlich auch verzögert geladen werden. Alles, was unter dem Fold ist, ist das ja okay, aber eben nicht above the fold. Und bei der Gelegeheit, Javascript an das Ende der Seite zu setzen, steht im Widerspruch zu defer. Da kannst es auch gleich seinlassen, weil du die gedachten Vorteile insbesondere von defer gar nicht nutzen kannst.

Hallo zusammen,

erst einmal Danke für Euer umfangreiches Feedback. Wie ich merke, ist das doch ein etwas umfangreicheres Thema. Auf ein paar Punkte kann ich versuchen näher eingehen.

Dein problem ist imho eher wordpress mit seinem plugin management. Wenn du 10 plugins hast, dann erzeugen die wenn du pech hast 10 css dateien und 10 js dateien, statt eine einzige grosse datei zu erzeugen

Ja, das ist leider so, kann ich aber nur schwer ändern, ohne die Funktionalitäten im Blog zu deaktivieren. Ich achte zumindest darauf, dass es immer "professionelle" Plugins sind, wobei man da natürlich auch da keine Garantie hat, dass die immer sauber programmiert sind. Blöd, aber ist leider so.

Du hast das technisch mögliche m.E. schon ausgereizt

OK.

Deine bislang störrische Ansicht, dass ein PHP getriebener HTTP Cache besser wäre als der Webserver basierte HTTP Cache von LiteSpeed.

Ich find das Wort störrisch hier etwas unpassend. Ich weiß, wir hatten es vor einiger Zeit schon einmal vom dem Thema und ich kann Dir auch sagen, dass ich natürlich auch den Lightspeed Cache ausprobiert hatte. Die Tests damals hatten aber leider nicht zu einem besseren Ergebnis geführt, im Gegenteil sogar. Vielleicht - oder sogar wahrscheinlich - hab ich das was falsch gemacht oder es war nicht richtig eingestellt. Aber an der Stelle bin ich damals leider nicht weitergekommen.

Trotzdem glaube ich, dass auch irgendwas mit dem Server / Konfiguration nicht stimmt. Ich habe jetzt gerade noch mal die Seite aufgerufen: Das Root Dokument hat 13 Sekunden gebraucht bis es da war. Meist dauert es unter 200ms. Irgendwas klemmt da manchmal.

Kannst Du mir sagen, welche Seite das war? Sowas darf und soll natürlich nicht sein.

Für Dich heißt das jetzt konkret, dass Du auf technischer Seite nix mehr machen kannst, um den Pagespeed Score noch wesentlich zu verbessern, weil Du ein strukturelles Problem hast, was aber eigentlich jeder (Du auch) hat, der Wordpress und ein Theme mit Bootstrap verwendet.

Ja, das Wordpress hier nicht ideal ist, weiß ich. Ich habe dafür aber keine andere Lösung.

Einne weitere Ursache findet sich in Deinem zu viel Content, der mit den Vorgaben von Pagespeed korreliert.

Das führt mich zu meiner Ursprungsfrage zurück, ob es helfen würde, den Content einmal reduziert und einmal mit Bildern anzubieten?

Ich Danke Euch auf jeden Fall für Euer Feedback. Das technisch sicherlich noch einiges optimiert werden kann, ist mir bewusst. Mit dem Wissen heute würde ich sicherlich auch z.B. ein ganz anderes - für Ladezeiten optimiertes - Theme auswählen. Aber das jetzt umzustellen, ist leider gar nicht so einfach. Und wie supervisor schon schreibt, das wir mein grundlegendes Problem wahrscheinlich nicht lösen.

omp-blog hat geschrieben: ↑17.01.2022, 09:54 Ja, das Wordpress hier nicht ideal ist, weiß ich. Ich habe dafür aber keine andere Lösung.

Das ist kein unmittelbares und nur bei Wordpress auftretendes Problem, sondern betrifft ausnahmslos jedes CMS. Von daher würde Dir auch ein Wechsel nix bringen. Heißt im Gegenzug, dass man jedes CMS erstmal und zwar so richtig anpassen müsste, was sich aber überwiegend auf das Theme/Template reduzieren lässt.

omp-blog hat geschrieben: ↑17.01.2022, 09:54 Das führt mich zu meiner Ursprungsfrage zurück, ob es helfen würde, den Content einmal reduziert und einmal mit Bildern anzubieten?

Dazu hatte ich mich schon geäußert. Ansatzweise bist Du damit schon auf dem richtigen Weg, aber eben nur ansatzweise, sodass Du damit 0,nix erreichst. Entweder so gravierend ändern, wie ich das mache oder seinlassen. Zumal Du gar nicht abschätzen kannst, wie sich ein auf noindex gesetzer Content auswirkt.

omp-blog hat geschrieben: ↑17.01.2022, 09:54 Ich Danke Euch auf jeden Fall für Euer Feedback. Das technisch sicherlich noch einiges optimiert werden kann, ist mir bewusst. Mit dem Wissen heute würde ich sicherlich auch z.B. ein ganz anderes - für Ladezeiten optimiertes - Theme auswählen. Aber das jetzt umzustellen, ist leider gar nicht so einfach. Und wie supervisor schon schreibt, das wir mein grundlegendes Problem wahrscheinlich nicht lösen.

Du kannst nix mehr wesentliches optimieren, weil Du erst die eigentliche Ursache in den Griff bekommen musst. Solange Du das nicht machst, ist jede Maßnahme sinnfrei. Was Dir mit Einschränkung vielleicht noch was bringen würde, wäre ungenütztes CSS zu entfernen. Die aktuelle Version des LiteSpeed Plugins für WP hält eine eigens dafür geschaffene Funktion bereit. Es gibt aber noch andere gute Neuerungen und Verbesserungen.

Vielleicht doch noch eine Ergänzung, will Dir ja die letzte Hoffnung nicht gänzlich nehmen. Was ich mir vorstellen könnte, wäre das Splitten/Verteilen des Contents auf mehrere Seite. Allerdings müsste man mal schauen, obs nicht auch dafür ein Plugin gäbe. Das wäre in jedem Fall besser als Deine gegenwärtige Lösung mit dem Weiter und dem noindex. Allerdings gäbs damt auch neue Probleme. Google mag keine Paginator Seiten, weshalb immer nur die erste Seite im Index stehen würde.

So, und noch was hinterher betont. Es gibt kein wirklich optimiertes Theme für Wordpress, was ursächlich daran liegt, dass auch ein vermeintlich optimiertes Theme immer auf Bootstrap setzt. Darin liegt ein und vielleicht sogar das größte Übel!