Seltsames Ladezeit-Phänomen

[soweit_ok]

Gebe ich als URL nur meinedomain.de ein, ist beim Firstview die Wartezeit auf das erste Byte bis zu 4x, mindestens aber doppelt solange, als wenn ich meinedomain/home.html eingebe.

URL-Umschreibung in den Einstellungen ist aktiviert + entsprechende Anweisungen in der .htaccess. Testweise Deaktivierung brachte keinen Unterschied. Der Support des Providers Variomedia hat auch keine Idee. Die Datenbank läuft auf einem anderen Server auf einer SSD-Platte, er sagte dazu aber, signifikante Ladezeitverzögerungen aufgrund dessen seien durch andere Kunden nicht bekannt geworden.

Habt ihr eine Idee, woran das liegen könnte? Ist eine Contao 2 Seite - kann sie wegen einiger wichtiger Erweiterungen derzeit noch nicht auf C 3 updaten.

Ich hänge 2 Screenshots von webpagetest.org an, da könnt ihr den Unterschied sehen.

websitetest-tld.jpg websitetest-mit-htmlseite.jpg

Daneben finde ich auch merkwürdig, dass beim Repeat View die Wartezeit bis zum ersten Byte immer bei ca. 1,7 Sek. liegt. Ziemlich lang. Es wird dann nur eine 3,5 kb große HTML Datei geladen, wenn Mitglied eingeloggt, und sonst ggf. bloß mal neu geladen, wo die Cache-Verfallszeit abgelaufen ist. Es sind Browser- u. Servercache aktiviert.

[dazzle89]

Ich habe das auf zwei Websites von mir ausprobiert und habe ebenfalls große Unterschiede zwischen domain.de und domain.de/home.html festgestellt.

Wenn ich allerdings für z.b. domain.de mehrmals nacheinander den Test mache kommt auch immer was anderes bei heraus.

[Spooky]

@soweit_ok:

1. Du solltest deiner Startseite den Seitenalias "index" geben (unabhängig von deinem Problem).
2. Welche Contao Version verwendest du? In Contao 3.2 bis 3.4 (?) gibt es einen Fehler, wodurch die Startseite (ohne Seitenfragment) manchmal nicht aus dem Cache geladen wird.

[tab]

Ist eine Contao 2 Seite - kann sie wegen einiger wichtiger Erweiterungen derzeit noch nicht auf C 3 updaten.

Also Contao 2.x

[soweit_ok]

@soweit_ok:

1. Du solltest deiner Startseite den Seitenalias "index" geben (unabhängig von deinem Problem).

Danke für den Tipp! Meintest Du die obere "Startpunkt einer Webseite" oder die home.html darunter? Ich probier jetzt zunächst ersteres, vergab beim Startpunkt sonst immer den Alias "startseite".

Den Alias hatte ich auch vorher schonmal leise unter Verdacht, da könnte vielleicht irgendein Bug enthalten sein. Ich erinnere mich nämlich, als ich mal "home" als Alias angab, wurde die eingegebene pure Domain-URL in der Browsweradresszeile sofort automatisch durch "meinedomain.de/home.html/" ersetzt, wie eine garnicht gesetzte unsichtbare Weiterleitung, bei "startseite" als Alias aber nicht und das fand ich ziemlich komisch.

Ja, Contao 2.x, genauer gesagt beobachtete ich denselben seltsamen Effekt sowohl bei 2.11.x wie auch bei 2.9.x Installationen.

[Spooky]

Danke für den Tipp! Meintest Du die obere "Startpunkt einer Webseite" oder die home.html darunter? Ich probier jetzt zunächst ersteres, vergab beim Startpunkt sonst immer den Alias "startseite".

Nein, nicht den Website Root, sondern die Startseite, deine jetztige "home.html". Dort den Alias von "home" auf "index" ändern.

Ja, Contao 2.x, genauer gesagt beobachtete ich denselben seltsamen Effekt sowohl bei 2.11.x wie auch bei 2.9.x Installationen.

Der Bug mit dem Cache existiert schon länger. Falls es wirklich daran liegt (schwer zu sagen ohne genauere Analyse), dann bleibt dir nur über auf Contao 3.5 zu aktualisieren.

[soweit_ok]

Nein, nicht den Website Root, sondern die Startseite, deine jetztige "home.html". Dort den Alias von "home" auf "index" ändern.

Danke, hab ich gemacht. Und dem Website Root den Alias "startseite" gegeben. Das Problem beseitigt hat´s leider nicht, keine Veränderung. Schaute mir auch nochmal den Quellcode der index.php an, mir fiel aber nichts Verdächtiges auf. Vielleicht vergleiche ich mal mit C 3.5, was dort beim Domainaufruf anders ist. Na klar, irgendwann ist auch das Contao Update dran.

[dazzle89]

Ich glaube ja, dass es ziemlich normal ist wenn du dort jedesmal ein anderes Ergebnis bekommst. Also auch wenn du die Seite mehrmals ohne den Alias testest...

Hast du auch schon andere Seiten als webpagetest.org probiert?

[soweit_ok]

Ich glaube ja, dass es ziemlich normal ist wenn du dort jedesmal ein anderes Ergebnis bekommst. Also auch wenn du die Seite mehrmals ohne den Alias testest...

Hast du auch schon andere Seiten als webpagetest.org probiert?

Hmmh, abweichende Ladezeiten sind zwar normal, auch was die Zeit bis zum ersten Byte angeht. Dieses Phänomen hier ist jedoch auch bei vielen Wiederholungen krass auffällig eindeutig dasselbe. Dass die TTFB auf derselben Seite nur noch zwischen 200ms bis max. 450ms beträgt statt mindestens 1,5 Sek., kann bei Dutzenden Tests kein Zufall sein.

Mit dem Alias scheint es nicht zusammenzuhängen. Egal was ich da eintrage, es ändert nichts. Auch die URL-Umschreibung zu deaktivieren, änderte nichts. Ja, ich probierte auch schon andere Testseiten. U. a. eine, die speziell nur die TTFB misst, geht schneller. Gleiches Ergebnis.

[tab]

Es wird wohl wirklich mit dem Bug zusammenhängen, den Spooky erwähnt hat. Komplett habe ich den zwar auch nicht verstanden, aber es läuft darauf hinaus, dass unter bestimmten Bedingungen für eine "leere URL" (also nur Domain), die Seite nie aus dem Cache geladen wird. Siehe auch https://github.com/contao/core/issues/7618

[soweit_ok]

Es wird wohl wirklich mit dem Bug zusammenhängen, den Spooky erwähnt hat. Komplett habe ich den zwar auch nicht verstanden, aber es läuft darauf hinaus, dass unter bestimmten Bedingungen für eine "leere URL" (also nur Domain), die Seite nie aus dem Cache geladen wird. Siehe auch https://github.com/contao/core/issues/7618

Ja, scheint tatsächlich so zu sein und diesen Bug gabs offensichtlich auch schon bei Contao 2. Wenn ich den Haken bei Sprachenfallback rausnehme, verkürzt sich die TTFB sofort auf zwischen 250ms bis max. 500 ms. Mit Sprachenfallback ~ 1,7 Sek. Wär ja schön, könnte ich es so einfach lösen, denn ich brauch diesen Fallback auf den betreffenden Seiten garnicht. Dummerweise kommt dann aber Fehler 404 bei Testtools und Robots. Google findet die Webseite also ohne Fallback auch nicht, obwohl der Aufruf im Browser normal funktioniert. Threads dazu gibt´s genügend im Forum, aber Leo Feyer baute deshalb lediglich ne Warnmeldung ein ab 2.10, falls das Fallback nicht angehakt ist. Das Problem, was mich jetzt tierisch nervt, ist wohl erst ab Version 3.5 ordentlich gefixt, siehe Dein Link. Weiß noch nicht, was ich nun wieder gegen den 404 machen kann. Muss notgedrungen deshalb den Sprachenfallback aktiviert lassen, bis ich rausfand, ob ich das vllt. irgendwie anders geregelt kriege. Die Wahl von "de" als Sprache scheint nicht zu reichen, was mir überhaupt nicht einleuchtet.

Auf jeden Fall nochmal ein herzliches Danke, das ist die jedenfalls wohl die richtige Spur.

[Spooky]

Auch in Contao 3.5 scheint es noch Probleme zu geben (siehe letzter Kommentar im Issue).

Die Wahl von "de" als Sprache scheint nicht zu reichen, was mir überhaupt nicht einleuchtet.

Was meinst du damit? Ohne Sprachenfallback kann Contao ja nicht wissen, welcher Seitenbaum ausgewählt werden soll, wenn der Browser des Clients eine Sprache eingestellt hat, die in keiner deiner Seitenbäume existiert.

[soweit_ok]

Ohne Sprachenfallback kann Contao ja nicht wissen, welcher Seitenbaum ausgewählt werden soll, wenn der Browser des Clients eine Sprache eingestellt hat, die in keiner deiner Seitenbäume existiert.

Damit meinte ich, auf den betroffenen Webseiten nur einen Seitenbaum zu haben, nämlich für "de". Käme tatsächlich mal ein Besucher mit anderer Browsersprache, wär mir das bei diesen Webseiten egal. Bei mehrsprachigen Webseiten natürlich eine nötige Funktionalität, aber eine derart lange Wartezeit auf das erste Byte für nix finde ich reichlich nervig.

Wenn eine Webseite eh nur in deutscher Sprache ist, könnte sie doch eigentlich ohne umständliche zeitraubende Prüfungen einfach ausgegeben werden, egal welche Sprache im Browserclient eingestellt ist. Ich versteh halt einfach nicht, wozu diese Überprüfung bei Webseiten mit nur einer Sprache. Wenn nichts anderes geht, würde ich das Ganze am liebsten einfach im Core umgehen. Doch dafür müsste ich sicher sein, wie, um nicht das Kind mit dem Bade auszuschütten.

[soweit_ok]

Habs doch noch hingefummelt bekommen und will euch noch kurz berichten, wie.

Obwohl ich garkeine zweite Sprache außer Deutsch brauche, hab ich nun doch einen zweiten Startpunkt für Englisch angelegt, als erste reguläre Seite darunter meine deutsche Startseite kopiert und der als Fallbackseite die Startseite im deutschen Zweig zugewiesen. Den Haken bei "Sprachenfallback" setzte ich im deutschen Startpunkt, im englischen dementsprechend nicht.

Das war´s. Nun ist die TTFB wie erhofft nur noch zwischen ca. 200 und 500ms und die Gesamtladezeit meiner Startseite beim Firstload hat sich fast halbiert von vorher zwischen 4,5 und 5 Sek. auf jetzt max. 2,6 Sek., wieder gemessen bei webpagetest.org. Interessant finde ich daneben, dass die Zahl der Requests von vorher 78 auf 53 sank. Es wird aber nach wie vor alles geladen, hab ich geprüft. Fast ein Drittel weniger Requests ist schon ziemlich wundersam. Außerdem läuft das Laden insbesondere der großen Klötze am Anfang komischerweise auf einmal perfekt parallel (ich verteile das Laden auf 3 cookiefreie Subdomains), was doch eigentlich mit der TTFB bzw. dem initialen Sprachmapping garnichts mehr zu tun haben dürfte. Könnte mir denken, das hängt vllt. mit den 25 weniger Requests zusammen. Aber auch der Blick in den Core erhellte mich bislang nicht, wo die geblieben sind.

Na egal jetzt, Hauptsache das nervige Ladezeitproblem ist erledigt. Ich dank euch nochmal für die Tipps, die mich auf die richtige Spur brachten. Hatte mir das Ganze ja auch im Core mal angeguckt. So weiß ich jetzt immerhin auch mal, was da in etwa passiert. Der Code schaut eigentlich nicht allzu kompliziert aus, aber die Zusammenhänge des Browser-Sprachgedöns sind wohl für einige Überraschungen gut.

Update:
Hab jetzt mal auch den zweiten Startpunkt und dessen Unterseite von en auf de gesetzt. Weil ich die Hyphenator-Silbentrennungsbibliothek verwende, wollte ich kein sinnloses Laden der en-Patterns, da ich ja kein Englisch brauch. Ja, der Reparatureffekt erheblich kürzerer TTFB und 25 weniger Requests blieb unverändert bestehen - wurde also nur vom zweiten Startpunkt bewirkt, Sprache egal.

[pipkin]

Nach 5 Jahren hab ich hierzu nun auch eine Rückfrage :-)
Ich habe das TTFB-Problem mit einer 3.5.40-Contao Version. Ja, ich weiß, veraltet. Ist aber leider nicht zu ändern.

Obwohl ich garkeine zweite Sprache außer Deutsch brauche, hab ich nun doch einen zweiten Startpunkt für Englisch angelegt, als erste reguläre Seite darunter meine deutsche Startseite kopiert und der als Fallbackseite die Startseite im deutschen Zweig zugewiesen. Den Haken bei "Sprachenfallback" setzte ich im deutschen Startpunkt, im englischen dementsprechend nicht.

Wie in der Lösung beschrieben, handelt es sich um eine Seite mit nur einem de-Seitenbaum. TTFB liegt immer über 1.000 ms. Setze ich keinen Haken beim Sprachenfallback, halbiert sich die TTFB. Nun habe ich versucht, die Lösung nachzubauen: einen zweiten en-Startpunkt mit einer Kopie der Startseite, die als Fallback-Seite mit der Original-Startseite im de-Baum verknüpft ist. Leider ernte ich so aber wieder über 1.000 ms TTFB.

Mach ich was falsch?
Oder gibt es noch einen anderen Kniff?

Danke
Pipkin