Ladezeit verbessern

Hallo Leute,

ich habe eine Website wo auf zwei Unterseiten sehr viele Nachrichten auf einmal angezeigt werden sollen (einmal ca. 70 und einmal ca. 250!!!). Das ist erst mal so.
Somit entstehen leider Ladezeiten von bis zu 30 Sekunden. Das möchte ich jetzt gerne so weit wie möglich reduzieren.

Ich habe folgende Dinge zur Verbesserung auf meiner Liste:
1) Server/Hosting optimieren
--opcache
-- PHP Version (ist derzeit 7.4)
-- Cache Einstellungen

2) Bildmaterial
-- Bilder komprimieren und Bildgröße anpassen (derzeit bei den meisten 800 x 600 px)

3) Lazyloading und Responsive Images verwenden
--Das teste ich gerade

4) Nachrichteneinstellungen verändern
-- zur Not die Anzeige der Nachrichten auf eine geringere Anzahl begrenzen (das wird dem Kunden nicht gefallen)

Mit dem opcache würde ich gerne anfangen.

Scheinbar ist der opcache bei meinem Hosting ja zumindest eingeschaltet (siehe Anhänge).
Wie erkenne ich, ob der opcache bei meinem Hosting korrekt eingestellt ist und arbeitet?

Ich habe da leider überhaupt keine Erfahrung.

NetCup Webhosting 8000

Anhang 23657
Anhang 23658

Zitat:

---

Zitat von tschero

2) Bildmaterial
-- Bilder komprimieren und Bildgröße anpassen (derzeit bei den meisten 800 x 600 px)

3) Lazyloading und Responsive Images verwenden
--Das teste ich gerade

---

Das hat unter Contao 4.9 keine Auswirkungen auf die TTFB, da Bilder nicht im Request der HTML Seite erzeugt werden.


Ein paar generelle Anmerkungen:

• Am besten wäre es natürlich mit Tools wie blackfire.io zu prüfen, wo der Bottleneck liegt. Auf einem Shared Hosting wirst du das aber höchstwahrscheinlich nicht zur Verfügung haben.
  
  
• Generell sollten Applikationen, wo die Performance wichtig ist, wohl nicht auf einem Shared Hosting betrieben werden.
  
  
• Generelle Hinweise zur Verbesserung der PHP Performance findest du hier. Wie dort erwähnt solltest du zuerst überprüfen, ob bei dir die PHP Einstellung open_basedir gesetzt ist. Wenn ja, müsstest du den Hoster davon überzeugen, diese Einstellung zu entfernen, falls du das nicht selbst machen kannst. Aber auch hier wirst du bei einem Shared Hosting keine großen Chancen haben.
  
  
• Du könntest auch versuchen vorab folgende Pull Requests bereits in deine Contao Installation zu integrieren: #1840 & #1871.
  
  
• Selbst bei 250 Nachrichten sollte der Bottleneck nicht bei der Datenbank liegen, da die 250 Nachrichten in einem Query geholt werden. Wenn du aber Extensions und angepasste Template verwendest, solltest du überprüfen, ob diese eine negative Auswirkung haben. Also einfach die Extensions nacheinander deinstallieren und jedes mal testen. Und dann die angepassten Nachrichten-Templates löschen/deaktivieren und nacheinander testen.
  
  
• Zu guter Letzt kannst du für die betroffene Unterseite ja auch einfach den Server Cache aktivieren und auf 1 Jahr stellen. Hier musst du aber ggf. auf die COOKIE_WHITELIST achten (COOKIE_ALLOW_LIST ab Contao 4.10). Über diese Liste kontrollierst du, dass Requests mit diesen Cookies deine Applikation immer erreichen und der Response nie aus dem Cache kommen soll.

Testest du gerade auf deinem eigenen Hosting? Falls ja, wo (in welchem Paket) soll es denn beim Kunden laufen?
Ob der OPCache läuft und falls ja mit welchen Einstellungen kannst du in der phpinfo() Seite sehen (Zend OPcache).

Wow,
das sind ja schon mal sehr wertvolle Info´s.
Danke Euch beiden dafür.

Ich schaue mal, was ich davon umsetzen und überprüfen kann.

Gruß und besten Dank,
tschero

Zitat:

---

Zitat von tab

Ob der OPCache läuft und falls ja mit welchen Einstellungen kannst du in der phpinfo() Seite sehen (Zend OPcache).

---

Gem. meinen Screenshots von oben, müsste ja dann der opcache arbeiten.

Zitat:

---

Zitat von tab

Testest du gerade auf deinem eigenen Hosting? Falls ja, wo (in welchem Paket) soll es denn beim Kunden laufen?

---

Ich selbst entwickle gerade die aktuelle Seite auf Webhosting 8000 bei NetCup. Dort auch die Performanceprobleme.

Momentan läuft die bestehende Website des Kunden noch auf einem Hostingpaket bei einem mir nicht bekannten Anbieter. Derzeit ein Shared Hosting - vermutlich kleiner als Webhosting 8000 bei Netcup.

Die Kollegen sind sehr hilfsbereit, haben jedoch z.B. auch Ihre (Sicherheits-)Bedenken, einen SSH Zugang für das Hosting bereit zu stellen. Naja, wir werden sehen.

Bin zwar mit meinen Ladezeit-Auswertungen dank der Merkwürdigkeiten der netcup Cronjob-Einstellungen noch nicht gestartet, aber anhand einer anderen Installation, auf die sehr selten zugegriffen wird, kann ich schon relativ sicher sagen: Ja, den Servercache (Shared/Public Cache) zu aktivieren bringt eine Menge und vermindert bei mir die seeehr langen Ladezeiten (ebenfalls ca 20-30 Sekunden) beim ersten Zugriff nach längerer Zeit erheblich.

Zitat:

---

Zitat von tab

Bin zwar mit meinen Ladezeit-Auswertungen dank der Merkwürdigkeiten der netcup Cronjob-Einstellungen noch nicht gestartet, aber anhand einer anderen Installation, auf die sehr selten zugegriffen wird, kann ich schon relativ sicher sagen: Ja, den Servercache (Shared/Public Cache) zu aktivieren bringt eine Menge und vermindert bei mir die seeehr langen Ladezeiten (ebenfalls ca 20-30 Sekunden) beim ersten Zugriff nach längerer Zeit erheblich.

---

Welchen Servercache meinst Du hier genau?
In den Contao Einstellungen im Startpunkt einer Seite?
(Cachezeit Private-Cache und Cachezeit Shared-Cache)
Anhang 23659

Gruß
tschero

Shared Cache. Private Cache wäre der Browser Cache.

Ja, Cachezeit Shared Cache. Lässt sich notfalls auch seitenweise einstellen, falls du auf irgendeiner Seite, aus welchem Grund auch immer, keinen Shared Cache brauchen kannst.

Edit: Das kann man wohl auf sehr lange Zeit einstellen, da bei Änderungen an der Seite der Cache das mitbekommen sollte.

wie hoch ist dein PHP memory_limit?

und was sagt Google PageSpeed https://developers.google.com/speed/...sights/?hl=de?

Zitat:

---

Zitat von µaTh

wie hoch ist dein PHP memory_limit?

und was sagt Google PageSpeed https://developers.google.com/speed/...sights/?hl=de?

---

Hi,

memory_limit ist 1024M.

Der Link gibt einen Fehler zurück.

Code:

---

Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_TIMED_OUT)

---

Da mag aber daran liegen, dass ich den Wartungsmodus nur ganz kurz für die Prüfung ausgeschaltet habe.

Ich habe allerdings eine andere Seite von mir mal getestet die mit fast dem gleichen Theme läuft - da könnte man bestimmt noch was verbessern.

Gruß
tschero

Nur um das nochmal zu bestätigen:

Zitat:

---

Zitat von tschero

Somit entstehen leider Ladezeiten von bis zu 30 Sekunden.

---

Welche Art von Ladezeit meinst du überhaupt? Ich bin von der TTFB (Time To First Byte) ausgegangen. Also die Zeit, die der Server benötigt auf die Anfrage eine Antwort zu liefern.

Zitat:

---

Zitat von Spooky

Nur um das nochmal zu bestätigen:Welche Art von Ladezeit meinst du überhaupt? Ich bin von der TTFB (Time To First Byte) ausgegangen. Also die Zeit, die der Server benötigt auf die Anfrage eine Antwort zu liefern.

---

Ich meine die Zeit vom ersten Klick auf den Link - über die Zeit wo der Punkt im Faviconbereich lustig hin und her wippt - bis zum Anzeigen des Inhalts.
Mal dumm gefragt - ist das der TTFB (Oh Mann, ich versteck mich hier gleich lieber)? :o

Zitat:

---

Zitat von tschero

Ich meine die Zeit vom ersten Klick auf den Link - über die Zeit wo der Punkt im Faviconbereich lustig hin und her wippt - bis zum Anzeigen des Inhalts.
Mal dumm gefragt - ist das der TTFB (Oh Mann, ich versteck mich hier gleich lieber)? :o

---

Aus deiner Beschreibung geht leider nicht hervor, ob du TTFB oder FMP (First Meaningful Paint) meinst ;). Du solltest daher tatsächlich zuerst klären, was wie lange dauert, ansonsten kannst du ja nicht an der richtigen Stelle ansetzen. Und das machst du am besten tatsächlich mit Google Page Speed Insights.

Dauert es denn immer so lang oder vorzugsweise dann, wenn die Contao-Installation längere Zeit nicht aufgerufen wurde?

Zitat:

---

Zitat von tab

Dauert es denn immer so lang oder vorzugsweise dann, wenn die Contao-Installation längere Zeit nicht aufgerufen wurde?

---

Es dauert immer so lange.
Aber nur bei den beiden Seiten mit den vielen Nachrichten.
Die mit den ca. 70 nachrichten wird schneller aufgebaut als die mit den ca. 250.

EDIT:
Hinzu kommt, dass ich ein recht "Ressourcen-hungriges" Theme verwende.

Gruß
tschero

Zitat:

---

Zitat von Spooky

Aus deiner Beschreibung geht leider nicht hervor, ob du TTFB oder FMP (First Meaningful Paint) meinst ;). Du solltest daher tatsächlich zuerst klären, was wie lange dauert, ansonsten kannst du ja nicht an der richtigen Stelle ansetzen. Und das machst du am besten tatsächlich mit Google Page Speed Insights.

---

Nachdem ich mir mal angesehen habe, was das für Unterschiede sind,
https://wao.io/de/ratgeber/website-s...fb-optimieren/

meine ich tatsächlich den TTFB.
Wenn der Nutzer auf den Link der Seite klickt, passiert nichts außer dem blinkenden Favicon-Ball.
Wenn man beim FCP angekommen ist, geht es zum FMP und TTI recht flott.

Gruß
tschero

Na dann. Hast du meine Anmerkungen bei deiner Analyse schon berücksichtigt?

Zitat:

---

Zitat von tschero

Der Link gibt einen Fehler zurück.

---

Merkwürdig.
Und der Link funktioniert auch nicht? https://developers.google.com/speed/pagespeed/insights/

Magst du uns ein Screenshot von aus der Browser Developer-Bar (Entwicklungswerkzeuge) Reiter "Netzwerkanalyse" erstellen?

Vielleicht können wir dir auch noch besser helfen, wenn du uns die (temporäre?) Webadresse geben könntest.

Zitat:

---

Zitat von Spooky

Na dann. Hast du meine Anmerkungen bei deiner Analyse schon berücksichtigt?

---

Zitat:

---

Zitat von Spooky

• Am besten wäre es natürlich mit Tools wie blackfire.io zu prüfen, wo der Bottleneck liegt. Auf einem Shared Hosting wirst du das aber höchstwahrscheinlich nicht zur Verfügung haben.
  

---

Habe ich leider nicht zur Verfügung.

Zitat:

---

Zitat von Spooky

• Generell sollten Applikationen, wo die Performance wichtig ist, wohl nicht auf einem Shared Hosting betrieben werden.
  

---

Für die Entwicklung - für mich - kein Problem. Mit dem Kunden werde ich das noch besprechen.

Zitat:

---

Zitat von Spooky

Das hat unter Contao 4.9 keine Auswirkungen auf die TTFB, da Bilder nicht im Request der HTML Seite erzeugt werden.


Ein paar generelle Anmerkungen:

• Generelle Hinweise zur Verbesserung der PHP Performance findest du hier. Wie dort erwähnt solltest du zuerst überprüfen, ob bei dir die PHP Einstellung open_basedir gesetzt ist. Wenn ja, müsstest du den Hoster davon überzeugen, diese Einstellung zu entfernen, falls du das nicht selbst machen kannst. Aber auch hier wirst du bei einem Shared Hosting keine großen Chancen haben.

---

Die Hinweise bekommt der Hoster noch mitgeteilt, mit der Bitte um Umsetzung. Das "open_basedir" entfernt wird, halte ich für unwahrscheinlich, da der Hoster schon Sicherheitsbedenken hat, mir einen SSH-Zugang zu geben - sehr schade.

Zitat:

---

Zitat von Spooky

[*]Du könntest auch versuchen vorab folgende Pull Requests bereits in deine Contao Installation zu integrieren: #1840 & #1871.[/list]

---

Nein, da warte ich lieber auf ein Update. Sonst mache ich zu viel kaputt.

Zitat:

---

Zitat von Spooky

[*]Selbst bei 250 Nachrichten sollte der Bottleneck nicht bei der Datenbank liegen, da die 250 Nachrichten in einem Query geholt werden. Wenn du aber Extensions und angepasste Template verwendest, solltest du überprüfen, ob diese eine negative Auswirkung haben. Also einfach die Extensions nacheinander deinstallieren und jedes mal testen. Und dann die angepassten Nachrichten-Templates löschen/deaktivieren und nacheinander testen.[/list]

---

Ich verwende nur wenige zusätzliche Extensions plus die notwendigen des Themes welche ich nicht deinstallieren kann. Ob ich die Nachrichtentemplates zum testen ändern kann muss ich noch ausprobieren.
Hier mal meine composer.json wegen der Extensions:

Code:

---

{
    "type": "project",
    "require": {
        "contao/calendar-bundle": "4.9.*",
        "contao/comments-bundle": "4.9.*",
        "contao/conflicts": "*@dev",
        "contao/faq-bundle": "4.9.*",
        "contao/listing-bundle": "4.9.*",
        "contao/manager-bundle": "4.9.*",
        "contao/news-bundle": "4.9.*",
        "contao/newsletter-bundle": "4.9.*",
        "do-while/contao-backupdb-bundle": "^1.4",
        "inspiredminds/contao-include-info": "^1.0",
        "inspiredminds/contao-news-sync": "dev-master",
        "jrgregory/m17-sticky-backend-footer": "^2.0",
        "terminal42/contao-easy_themes": "^2.2"
    },
    "extra": {
        "contao-component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://token:xyz"
        }
    ]
}

---

Zitat:

---

Zitat von Spooky

Zu guter Letzt kannst du für die betroffene Unterseite ja auch einfach den Server Cache aktivieren und auf 1 Jahr stellen. Hier musst du aber ggf. auf die COOKIE_WHITELIST achten (COOKIE_ALLOW_LIST ab Contao 4.10). Über diese Liste kontrollierst du, dass Requests mit diesen Cookies deine Applikation immer erreichen und der Response nie aus dem Cache kommen soll.

---

Den Cache werde ich wohl so einstellen, wenn die Seite fertig ist.
Mit der "COOKIE_ALLOW_LIST" habe ich noch nichts zu tun gehabt, muss ich mir dann in 4.10 erst noch anschauen. Ebenfalls, ob die Auswirkungen auf das Cookieverfahren des Themes hat.

Auf jeden Fall schon mal herzlichen Dank für Deine/Eure Mühe hier an dieser Stelle.

Gruß
tschero

Zitat:

---

Zitat von tschero

Ich verwende nur wenige zusätzliche Extensions plus die notwendigen des Themes welche ich nicht deinstallieren kann.

---

Welches Theme?

Dieses hier.

Ah, da hast du natürlich schon sehr viele Extensions.

Zitat:

---

Zitat von µaTh

Merkwürdig.
Und der Link funktioniert auch nicht? https://developers.google.com/speed/pagespeed/insights/

Magst du uns ein Screenshot von aus der Browser Developer-Bar (Entwicklungswerkzeuge) Reiter "Netzwerkanalyse" erstellen?

Vielleicht können wir dir auch noch besser helfen, wenn du uns die (temporäre?) Webadresse geben könntest.

---

Die Webadresse ist diese hier.

Ich möchte die Seite jedoch gerne im Wartungsmodus belassen, da sie einfach noch nicht fertig und auch noch nicht freigegeben ist.

Ich denke der Wartungsmodus ist auch Schuld an der Fehlermeldung. Ich hatte ihn zwar ganz kurz ausgeschaltet, hat aber scheinbar nichts genutzt.

VG
tschero

Um Google Page Speed Insights benutzen zu können, musst du natürlich den Wartungsmodus deaktivieren. ggf. musst du dann einige Minuten warten, bis du die Website nochmals analysieren lassen kannst. Aber da es dir um die TTFB geht, wird Google Page Speed Insights auch nur sagen, dass genau das zu hoch ist.

Zitat:

---

Zitat von tschero

Die Webadresse ist diese hier.

Ich möchte die Seite jedoch gerne im Wartungsmodus belassen, da sie einfach noch nicht fertig und auch noch nicht freigegeben ist.

Ich denke der Wartungsmodus ist auch Schuld an der Fehlermeldung. Ich hatte ihn zwar ganz kurz ausgeschaltet, hat aber scheinbar nichts genutzt.

VG
tschero

---

ja, diese "Fehlerseite" liefert ein 503-Fehler (Service not available).

Leg einfach eine neue Subdomain auf die Seite, die du hier veröffentlichen kannst. Später löscht du die Subdomain und alle Links hier im Forum sind nicht mehr aktiv.

Zitat:

---

Zitat von µaTh

ja, diese "Fehlerseite" liefert ein 503-Fehler (Service not available).

Leg einfach eine neue Subdomain auf die Seite, die du hier veröffentlichen kannst. Später löscht du die Subdomain und alle Links hier im Forum sind nicht mehr aktiv.

---

Leider darf ich die Seite nicht veröffentlichen - auch nicht auf einer neuen Subdomain.
Ich hatte auch schon mal, dass Google die Inhalte der Subdomain indiziert hat. Das würde ich gerne vermeiden.

Trotzdem recht herzlichen Dank für die Hilfe.

mach doch einen htaccess-Schutz davor ... den kannst Du ja mit posten

Zitat:

---

Zitat von zonky

mach doch einen htaccess-Schutz davor ... den kannst Du ja mit posten

---

Dann kann er aber wieder PageSpeed Insights nicht verwenden ;)

Pagespeed Insights bringt doch hier keine grossen Erkenntnisse, wenn es doch offenbar um die TTFB geht. Wie weiter oben geschrieben, wird Pagespeed Insights da auch nichts anderes sagen, als dass halt die TTFB zu lang ist. Ist auch nicht gesagt, dass Pagespeed Insights am Wartungsmodus gescheitert ist, vielleicht war die TTFB einfach zu lang.

Zitat:

---

Zitat von Spooky

Dann kann er aber wieder PageSpeed Insights nicht verwenden ;)

---

das ist schon richtig, dachte es geht um das Posten hier im Forum...

Zitat:

---

Zitat von tab

Pagespeed Insights bringt doch hier keine grossen Erkenntnisse, wenn es doch offenbar um die TTFB geht. Wie weiter oben geschrieben, wird Pagespeed Insights da auch nichts anderes sagen, als dass halt die TTFB zu lang ist. Ist auch nicht gesagt, dass Pagespeed Insights am Wartungsmodus gescheitert ist, vielleicht war die TTFB einfach zu lang.

---

Ist er m.E. auf jeden Fall.

Die Seite mit den ca. 70 Nachrichten läd ca. 15 - 20 Sek. ohne dass sich für den Nutzer was tut und die Seite mit den ca. 250 Nachrichten braucht noch länger.
Das würde ich eben gerne soweit wie möglich verkürzen. Ist nicht schön.

Danke Euch allen für die Hilfe

Seite kurz freischalten, dann Test via https://www.webpagetest.org

Wasserfall-Diagramm gibt dann Auskunftwo es hakt.

Ja, wenn es allerdings an der TTFB hakt ... Aber zumindest das sollte man sehen, ebenso wie in den Browsertools.

kannst Du die Seite nicht testweise mal auf einen anderen Server packen?

Zitat:

---

Zitat von zonky

kannst Du die Seite nicht testweise mal auf einen anderen Server packen?

---

Ich habe dazu nur noch ein Shared Hosting bei IONOS.
Da bezweifle ich, dass dort ein merkbar besseres Ergebnis kommt.

Einen eigenen Server habe ich leider (noch) nicht.
Ich könnte es höchstens mal lokal mit XAMPP versuchen.


Gruß
tschero

Zitat:

---

Zitat von tschero

Ich könnte es höchstens mal lokal mit XAMPP versuchen.

---

ich habe Lokal Laragon - aber unter Win sind nach meiner Einschätzung eh die Seiten alle recht langsam... habe das nur fürs debugging

IONOS ist ggf. nicht so ideal, da dort die DBs auch auf anderen Servern laufen und wenn man Pech hat, das schon sehr langsam sein kann... hast Du nicht ein Mittwald oder All-inkl Account?

Zitat:

---

Zitat von zonky

ich habe Lokal Laragon - aber unter Win sind nach meiner Einschätzung eh die Seiten alle recht langsam... habe das nur fürs debugging

IONOS ist ggf. nicht so ideal, da dort die DBs auch auf anderen Servern laufen und wenn man Pech hat, das schon sehr langsam sein kann... hast Du nicht ein Mittwald oder All-inkl Account?

---

Leider nicht.

Ich könnte ein Webhosting bei Hostingwerk oder einen Uberspace 7 für diesen Zweck anbieten. Müsste man halt sehen, wie man das praktisch gestaltet.

Momentan liegt bei mir der PageSpeed Score 98% und der YSlow Score liegt bei 90% das nenn ich mal werte und ich habe auch ein Shared Hosting.

Anhang 23661

Ich glaub die A Werte sind ziemlich gut, wobei man auch sagen muss das natürlich verschiedene Aspekte CSS, JavaScript ankuccken muss. Wenn mann die Seite noch optimieren kann dann sagt es mir.

Gesendet von iPhone mit Tapatalk Pro

Zitat:

---

Zitat von designpilot

Momentan liegt bei mir der PageSpeed Score 98% und der YSlow Score liegt bei 90% das nenn ich mal werte und ich habe auch ein Shared Hosting.

---

verstehe den Zusammenhang mit tscheros Problem nicht - oder bist Du mit der Seite auch bei netcup?

Sorry ich hbae gedacht es ginge allgemein um die Ladezeit zu verbessern.


Gesendet von iPhone mit Tapatalk Pro