Beitrag
supervisior » 17.01.2022, 07:47 Ladezeit wegen viele Bilder - Suche nach Alternative
@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.
